Proxyindstillinger til CMake ExternalProject-downloads

CMake konfigurerer med succes. Bygget starter senere, forsøger at downloade en ekstern afhængighed og fejler ved proxyen. Den tidligere succes havde ikke nødvendigvis øvet den download overhovedet.

ExternalProject_Add() opretter trin, som kan køre under bygget. Den proces, der starter disse trin, kan have et andet miljø end den terminal eller IDE, som konfigurerede hovedprojektet. Forskellen er let at overse i CI, hvor konfiguration og kompilering kan være separate job.

Find netværkshandlingen

• En URL-download bruger CMakes downloadsti.
• En Git-kilde kalder en Git-transport med sin egen understøttede konfiguration.
• En tilpasset DOWNLOAD_COMMAND bruger det program, projektet har angivet.

Antag ikke, at proxyindstillingen for ét program konfigurerer alle tre. Læs det fejlende trins kommando og fejl, før du ændrer afhængighedens URL.

Hvis den valgte downloader understøtter proxy-miljøvariabler, skal du give dem til den proces, der faktisk kører trinnet. For offentlige downloads, hvis klient accepterer en HTTP-proxy, tilbyder HTTP-proxylisten kandidater til endpoints, når den rute er tilladt. At videregive en almindelig CMake-cachevariabel med et lignende navn er ikke automatisk det samme som at sætte en miljøvariabel for en underordnet proces.

Bevar også forskellen til FetchContent: dets sædvanlige afhængighedsudfyldning sker under konfigurationen, så en opskrift, der virker der, fastslår ikke miljøet for et ExternalProject-byggetrin.

Et gammelt svar, der anbefaler en tilpasset downloader for at omgå en historisk omdirigeringsbegrænsning, er ikke bevis for, at hver moderne fejl kræver en ny downloadkommando. Kontrollér, om den aktuelle fejl er en omdirigering, proxy-godkendelse, certifikattillid eller simpel tilgængelighed. Bevar den forventede arkivhash og TLS-validering, mens du retter den relevante rute.