Proxy-instellingen voor CMake ExternalProject-downloads

CMake configureert met succes. De build begint later, probeert een externe afhankelijkheid te downloaden en faalt bij de proxy. Het eerdere succes had die download misschien helemaal niet uitgevoerd.

ExternalProject_Add() maakt stappen die tijdens de build kunnen draaien. Het proces dat die stappen start, kan een andere omgeving hebben dan de terminal of IDE die het hoofdproject configureerde. Dat verschil is in CI makkelijk te missen, waar configuratie en compilatie gescheiden jobs kunnen zijn.

Lokaliseer de netwerkoperatie

• Een URL-download gebruikt het downloadpad van CMake.
• Een Git-bron roept een Git-transport met eigen ondersteunde configuratie aan.
• Een aangepaste DOWNLOAD_COMMAND gebruikt welk programma het project ook heeft opgegeven.

Ga er niet van uit dat de proxy-instelling voor één programma alle drie configureert. Lees het commando en de fout van de mislukte stap voordat je de URL van de afhankelijkheid wijzigt.

Als de gekozen downloader proxy-omgevingsvariabelen ondersteunt, geef ze dan aan het proces dat die stap daadwerkelijk uitvoert. Voor openbare downloads waarvan de client een HTTP-proxy accepteert, biedt de HTTP-proxylijst eindpuntkandidaten wanneer die route is toegestaan. Een gewone CMake-cachevariabele met een vergelijkbare naam doorgeven is niet automatisch hetzelfde als een omgevingsvariabele van een kindproces instellen.

Behoud ook het onderscheid met FetchContent: de gebruikelijke afhankelijkheidsvulling daarvan gebeurt tijdens de configuratie, dus een recept dat daar werkt, bewijst niet de omgeving van een ExternalProject-buildstap.

Een oud antwoord dat een aangepaste downloader aanraadt om een historische redirectbeperking te omzeilen, is geen bewijs dat elke moderne fout een nieuw downloadcommando nodig heeft. Controleer of de huidige fout een redirect, proxy-authenticatie, certificaatvertrouwen of simpele bereikbaarheid is. Behoud de verwachte archiefhash en TLS-validatie terwijl je de relevante route repareert.