Proxyinställningar för CMake ExternalProject-nedladdningar

CMake konfigureras utan problem. Bygget startar senare, försöker ladda ner ett externt beroende och misslyckas vid proxyn. Den tidigare framgången hade inte nödvändigtvis övat den nedladdningen alls.

ExternalProject_Add() skapar steg som kan köras under bygget. Processen som startar dessa steg kan ha en annan miljö än terminalen eller IDE:n som konfigurerade huvudprojektet. Den skillnaden är lätt att missa i CI, där konfiguration och kompilering kan vara separata jobb.

Hitta nätverksoperationen

• En URL-nedladdning använder CMakes nedladdningsväg.
• En Git-källa anropar en Git-transport med egen stödd konfiguration.
• Ett anpassat DOWNLOAD_COMMAND använder vilket program projektet än angav.

Anta inte att proxyinställningen för ett program konfigurerar alla tre. Läs det misslyckade stegets kommando och fel innan du ändrar beroendets URL.

Om den valda nedladdaren stöder proxy-miljövariabler, ge dem till processen som faktiskt kör steget. För offentliga nedladdningar vars klient accepterar en HTTP-proxy erbjuder HTTP-proxylistan kandidater för slutpunkter när den vägen är tillåten. Att skicka en vanlig CMake-cachevariant med liknande namn är inte automatiskt samma sak som att sätta en miljövariabel för en barnprocess.

Behåll också skillnaden mot FetchContent: dess vanliga beroendefyllning sker under konfigurationen, så ett recept som fungerar där fastställer inte miljön för ett ExternalProject-byggsteg.

Ett gammalt svar som rekommenderar en anpassad nedladdare för att kringgå en historisk omdirigeringsbegränsning är inte bevis för att varje modernt fel behöver ett nytt nedladdningskommando. Kontrollera om det aktuella felet är en omdirigering, proxyautentisering, certifikattillit eller helt enkelt nåbarhet. Bevara förväntat arkivhash och TLS-validering medan du rättar den relevanta vägen.