Настройки прокси для загрузок CMake ExternalProject

CMake успешно конфигурируется. Сборка начинается позже, пытается загрузить внешнюю зависимость и терпит неудачу на прокси. Предыдущий успех вовсе не обязательно проверял эту загрузку.

ExternalProject_Add() создаёт шаги, которые могут выполняться во время сборки. Процесс, запускающий эти шаги, может иметь окружение, отличное от терминала или IDE, которые конфигурировали основной проект. Эту разницу легко упустить в CI, где конфигурация и компиляция могут быть отдельными заданиями.

Определите сетевую операцию

• Загрузка по URL использует путь загрузки CMake.
• Источник Git вызывает транспорт Git с собственной поддерживаемой конфигурацией.
• Пользовательская команда DOWNLOAD_COMMAND использует любую программу, указанную проектом.

Не считайте, что настройка прокси для одной программы настраивает все три. Прочитайте команду и ошибку неудачного шага, прежде чем менять URL зависимости.

Если выбранный загрузчик поддерживает переменные окружения прокси, передайте их процессу, который действительно выполняет этот шаг. Для публичных загрузок, клиент которых принимает HTTP-прокси, список HTTP-прокси предлагает кандидатов конечных точек, когда этот путь разрешён. Передача обычной переменной кэша CMake с похожим именем не то же самое, что установка переменной окружения дочернего процесса.

Сохраняйте и отличие от FetchContent: его обычное наполнение зависимостей происходит во время конфигурации, поэтому рецепт, работающий там, не подтверждает окружение шага сборки ExternalProject.

Старый ответ, рекомендующий собственный загрузчик в обход исторического ограничения перенаправлений, не доказывает, что каждая современная ошибка требует новой команды загрузки. Проверьте, является ли текущая ошибка перенаправлением, аутентификацией прокси, доверием к сертификату или просто недоступностью. Сохраняйте ожидаемый хеш архива и проверку TLS, исправляя нужный путь.