Ein Build-Wrapper lässt dich möglicherweise CMake-Argumente hinzufügen, verbirgt aber die Umgebung, mit der CMake gestartet wird. Ein früher Projekt-Hook gibt dir eine Stelle, an der du die Proxy-Werte für den Konfigurationslauf bereitstellen kannst.

Speichere eine kleine Datei unter einem stabilen absoluten Pfad, zum Beispiel /home/alex/cmake/proxy-env.cmake:

set(ENV{http_proxy} "http://proxy.example:8080")
set(ENV{https_proxy} "http://proxy.example:8080")

Übergib diese Datei an die Konfiguration:

cmake -S . -B build -DCMAKE_PROJECT_INCLUDE_BEFORE=/home/alex/cmake/proxy-env.cmake

CMAKE_PROJECT_INCLUDE_BEFORE bindet die Datei zu Beginn jedes project()-Aufrufs ein. Sie läuft daher früher als CMAKE_PROJECT_INCLUDE, das am Ende dieses Aufrufs läuft. Dieser Unterschied zählt, wenn die Sprachkonfiguration oder ein verschachteltes Projekt die Route braucht.

Für öffentliche Downloads zur Konfigurationszeit, die über einen öffentlichen Vermittler erlaubt sind, wähle die HTTP-URL-Werte aus der HTTP-Proxy-Liste. Der Hook kann trotzdem keine Arbeit beeinflussen, die vorher lief, einschließlich eines Downloads vor dem ersten project()-Aufruf. Er schreibt auch keine dauerhafte Betriebssystem-Umgebungseinstellung.

Prozesse, die dieser CMake-Prozess danach startet, können die Werte erben, sofern ihre Netzwerk-Clients sie unterstützen. Ein später, separat gestarteter Build hat seine eigene Umgebung. Ein auf diese Build-Phase verschobener Download muss dort ebenfalls seinen Proxy erhalten.

Halte die Hook-Datei außerhalb eines öffentlichen Quellbaums, wenn sie private Verbindungsdetails enthält. Das -D-Argument speichert den Hook-Pfad als CMake-Variable; set(ENV{...}) ändert die Umgebung des laufenden Prozesses, statt eine Cache-Variable in eine Proxy-Einstellung zu verwandeln.

Ähnliche Artikel