Налаштування проксі для завантажень CMake ExternalProject

CMake успішно налаштовується. Збирання починається пізніше, намагається завантажити зовнішню залежність і зазнає невдачі на проксі. Попередній успіх не обов'язково виконував це завантаження взагалі.

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

Визначте мережеву операцію

• Завантаження за URL використовує шлях завантаження CMake.
• Джерело Git викликає транспорт Git із власною підтримуваною конфігурацією.
• Власна команда DOWNLOAD_COMMAND використовує програму, яку вказав проєкт.

Не вважайте, що налаштування проксі для однієї програми налаштовує всі три. Прочитайте команду й помилку кроку, що не вдався, перш ніж змінювати URL залежності.

Якщо обраний завантажувач підтримує змінні середовища проксі, передайте їх процесу, який фактично виконує цей крок. Для публічних завантажень, клієнт яких приймає HTTP-проксі, список HTTP-проксі пропонує кандидатів кінцевих точок, коли цей шлях дозволено. Передавання звичайної змінної кешу CMake зі схожим ім'ям не є автоматично тим самим, що й установлення змінної середовища дочірнього процесу.

Зберігайте й відмінність від FetchContent: його звичайне заповнення залежностей відбувається під час налаштування, тож рецепт, який там працює, не встановлює середовища кроку збирання ExternalProject.

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