Proxyinnstillinger for CMake ExternalProject-nedlastinger

CMake konfigureres uten feil. Bygget starter senere, prøver å laste ned en ekstern avhengighet og feiler ved proxyen. Den tidligere suksessen hadde ikke nødvendigvis utført den nedlastingen i det hele tatt.

ExternalProject_Add() oppretter steg som kan kjøre under bygget. Prosessen som starter disse stegene, kan ha et annet miljø enn terminalen eller IDE-en som konfigurerte hovedprosjektet. Denne forskjellen er lett å overse i CI, der konfigurering og kompilering kan være separate jobber.

Finn nettverksoperasjonen

• En URL-nedlasting bruker CMakes nedlastingsbane.
• En Git-kilde kaller en Git-transport med sin egen støttede konfigurasjon.
• En tilpasset DOWNLOAD_COMMAND bruker hvilket som helst program prosjektet har angitt.

Ikke anta at proxyinnstillingen for ett program konfigurerer alle tre. Les kommandon og feilen til steget som feiler, før du endrer avhengighetens URL.

Hvis den valgte nedlasteren støtter proxy-miljøvariabler, gi dem til prosessen som faktisk kjører steget. For offentlige nedlastinger der klienten godtar en HTTP-proxy, tilbyr HTTP-proxylisten kandidater for endepunkter når den ruten er tillatt. Å sende en vanlig CMake-bufrevariabel med lignende navn er ikke automatisk det samme som å sette en miljøvariabel for en underordnet prosess.

Behold også forskjellen til FetchContent: den vanlige avhengighetspåfyllingen skjer under konfigureringen, så en oppskrift som virker der, fastslår ikke miljøet til et ExternalProject-byggesteg.

Et gammelt svar som anbefaler en tilpasset nedlaster for å omgå en historisk omdirigeringsbegrensning, er ikke bevis for at hver moderne feil trenger en ny nedlastingskommando. Sjekk om den nåværende feilen er en omdirigering, proxyautentisering, sertifikattillit eller rett og slett tilgjengelighet. Behold forventet arkivhash og TLS-validering mens du retter den relevante ruten.