Proxyinnstillingar for CMake ExternalProject-nedlastingar

CMake konfigurerer utan feil. Bygginga startar seinare, prøver å lasta ned ein ekstern avhengigheit og feilar ved proxyen. Den tidlegare suksessen hadde ikkje nødvendigvis utført den nedlastinga i det heile.

ExternalProject_Add() lagar trinn som kan køyra under bygginga. Prosessen som startar desse trinna, kan ha eit anna miljø enn terminalen eller IDE-en som konfigurerte hovudprosjektet. Denne skilnaden er lett å oversjå i CI, der konfigurering og kompilering kan vera separate jobbar.

Finn nettverksoperasjonen

• Ei URL-nedlasting brukar nedlastingsbanen til CMake.
• Ei Git-kjelde kallar ein Git-transport med si eiga støtta konfigurering.
• Eit tilpassa DOWNLOAD_COMMAND brukar kva program prosjektet har oppgjeve.

Ikkje rekn med at proxyinnstillinga for eitt program konfigurerer alle tre. Les kommandoen og feilen til trinnet som feilar, før du endrar URL-en til avhengigheita.

Viss nedlastaren du valde støttar proxy-miljøvariablar, gje dei til prosessen som faktisk køyrer trinnet. For offentlege nedlastingar der klienten godtek ein HTTP-proxy, tilbyr HTTP-proxylista kandidatar for endepunkt når den ruta er tillaten. Å senda ein vanleg CMake-bufrevariabel med liknande namn er ikkje automatisk det same som å setja ein miljøvariabel for ein barneprosess.

Hald òg på skilnaden til FetchContent: den vanlege avhengigheitsfyllinga der skjer under konfigureringa, så ein oppskrift som verkar der, fastset ikkje miljøet til eit ExternalProject-byggjetrinn.

Eit gammalt svar som tilrår ein tilpassa nedlastar for å omgå ei historisk omdirigeringsavgrensing, er ikkje prov på at kvar moderne feil treng ein ny nedlastingskommando. Sjekk om den noverande feilen er ei omdirigering, proxyautentisering, sertifikattillit eller rett og slett tilgjenge. Ta vare på forventa arkivhash og TLS-validering medan du rettar den relevante ruta.