Наладкі проксі для загрузак CMake ExternalProject

CMake паспяхова канфігуруецца. Зборка пачынаецца пазней, спрабуе загрузіць знешнюю залежнасць і выходзіць з ладу на проксі. Папярэдні поспех не абавязкова выконваў гэтую загрузку наогул.

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

Вызначце сеткавую аперацыю

• Загрузка URL выкарыстоўвае шлях загрузкі CMake.
• Крыніца Git выклікае транспарт Git з уласнай падтрымліваемай канфігурацыяй.
• Карыстальніцкі DOWNLOAD_COMMAND выкарыстоўвае тую праграму, якую паказаў праект.

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

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

Захоўвайце таксама адрозненне ад FetchContent: яго звычайнае запаўненне залежнасцей адбываецца падчас канфігурацыі, таму рэцэпт, які працуе там, не ўстанаўлівае асяроддзя кроку зборкі ExternalProject.

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