Proxy-Einstellungen für CMake-ExternalProject-Downloads
Ermitteln Sie den Prozess und den Download-Schritt hinter ExternalProject, bevor Sie annehmen, eine erfolgreiche CMake-Konfiguration belege, dass spätere Abhängigkeits-Downloads denselben Weg nehmen.
CMake konfiguriert erfolgreich. Der Build startet später, versucht eine externe Abhängigkeit herunterzuladen und scheitert am Proxy. Der frühere Erfolg hatte diesen Download womöglich gar nicht ausgeführt.
ExternalProject_Add() erzeugt Schritte, die während des Builds laufen können. Der Prozess, der diese Schritte startet, kann eine andere Umgebung haben als das Terminal oder die IDE, die das Hauptprojekt konfiguriert haben. Dieser Unterschied ist in CI leicht zu übersehen, wo Konfiguration und Kompilierung getrennte Jobs sein können.
Die Netzwerkoperation lokalisieren
- Ein URL-Download nutzt den Download-Pfad von CMake.
- Eine Git-Quelle ruft einen Git-Transport mit eigener unterstützter Konfiguration auf.
- Ein eigenes
DOWNLOAD_COMMANDnutzt das Programm, das das Projekt angegeben hat.
Gehen Sie nicht davon aus, dass die Proxy-Einstellung für ein Programm alle drei konfiguriert. Lesen Sie Befehl und Fehler des scheiternden Schritts, bevor Sie die Abhängigkeits-URL ändern.
Unterstützt der gewählte Downloader Proxy-Umgebungsvariablen, übergeben Sie sie an den Prozess, der den Schritt tatsächlich ausführt. Für öffentliche Downloads, deren Client einen HTTP-Proxy akzeptiert, bietet die HTTP-Proxy-Liste Endpunkt-Kandidaten, wenn dieser Weg erlaubt ist. Eine gewöhnliche CMake-Cache-Variable mit ähnlichem Namen zu übergeben ist nicht automatisch dasselbe wie das Setzen einer Umgebungsvariable für einen Kindprozess.
Behalten Sie auch die Unterscheidung zu FetchContent bei: Dessen übliche Abhängigkeitsbefüllung findet während der Konfiguration statt, ein dort funktionierendes Rezept belegt also nicht die Umgebung eines ExternalProject-Build-Schritts.
Eine alte Antwort, die einen eigenen Downloader als Umgehung einer historischen Redirect-Einschränkung empfiehlt, ist kein Beleg dafür, dass jeder moderne Fehler einen neuen Download-Befehl braucht. Prüfen Sie, ob der aktuelle Fehler eine Weiterleitung, Proxy-Authentifizierung, Zertifikatsvertrauen oder bloße Erreichbarkeit ist. Bewahren Sie den erwarteten Archiv-Hash und die TLS-Prüfung, während Sie den betroffenen Weg korrigieren.