it-swarm.com.de

Was bedeutet CMake für "configure --prefix = DIR && make all install"?

Ich mache cmake . && make all install. Dies funktioniert, wird jedoch auf /usr/local Installiert.

Ich muss auf ein anderes Präfix installieren (zum Beispiel auf /usr).

Was ist die cmake und make Befehlszeile, die unter /usr Anstelle von /usr/local Installiert werden soll?

354
Andrei

Sie können jede CMake-Variable in der Befehlszeile übergeben oder zwischengespeicherte Variablen mit ccmake/cmake-gui bearbeiten. In der Kommandozeile

cmake -DCMAKE_INSTALL_PREFIX: PATH =/usr. && alles installieren lassen

Konfiguriert das Projekt, erstellt alle Ziele und installiert das Präfix/usr. Der Typ (PATH) ist nicht unbedingt erforderlich, würde jedoch dazu führen, dass die Qt-basierte cmake-gui den Verzeichnisauswahldialog anzeigt.

Einige geringfügige Ergänzungen in Form von Kommentaren machen deutlich, dass die Bereitstellung einer einfachen Äquivalenz für einige nicht ausreicht. Eine bewährte Methode besteht darin, ein externes Erstellungsverzeichnis zu verwenden, dh nicht die Quelle direkt. Außerdem sollte eine allgemeinere CMake-Syntax verwendet werden, die den Generator abstrahiert .

mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX: PATH =/usr .. && cmake --build. --target install --config Release

Sie können sehen, dass es etwas länger wird und nicht mehr direkt äquivalent ist, sondern Best Practices in einer ziemlich übersichtlichen Form näher kommt ... Die --config wird nur von Generatoren mit mehreren Konfigurationen (dh MSVC) verwendet, die ignoriert werden Von anderen.

406

Der Teil ": PATH" in der akzeptierten Antwort kann weggelassen werden. Diese Syntax kann einprägsamer sein:

cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install

... wie in den Antworten verwendet hier .

37
user2023370

Beachten Sie, dass Sie in CMake und Autotools nicht immer den Installationspfad zum Zeitpunkt der Konfiguration festlegen müssen. Sie können DESTDIR zum Zeitpunkt der Installation verwenden (siehe auch hier ) stattdessen wie in:

make DESTDIR=<installhere> install

Siehe auch diese Frage was den subtilen Unterschied zwischen DESTDIR und PREFIX erklärt.

Dies ist für gestaffelte Installationen gedacht und ermöglicht das Speichern von Programmen an einem anderen Ort als dem, an dem sie ausgeführt werden, z. /etc/alternatives über symbolische Links.

Wenn Ihr Paket jedoch verlagerbar ist und keine fest codierten (Präfix-) Pfade benötigt, die über die Konfigurationsstufe festgelegt wurden, können Sie es möglicherweise überspringen. Also statt:

cmake -DCMAKE_INSTALL_PREFIX=/usr . && make all install

du würdest laufen

cmake . && make DESTDIR=/usr all install

Beachten Sie, dass dies, wie user7498341 betont, nicht für Fälle geeignet ist, in denen Sie PREFIX wirklich verwenden sollten.

24
Bruce Adams

Die Art und Weise, wie ich CMake-Projekte plattformübergreifend erstelle, ist folgende:

/project-root> mkdir build
/project-root> cd build
/project-root/build> cmake -G "<generator>" -DCMAKE_INSTALL_PREFIX=stage ..
/project-root/build> cmake --build . --target=install --config=Release
  • Die ersten beiden Zeilen erstellen das Out-of-Source-Erstellungsverzeichnis
  • In der dritten Zeile wird das Build-System generiert, in dem angegeben wird, wo das Installationsergebnis abgelegt werden soll (das ich immer in ./project-root/build/stage Abgelegt habe. Der Pfad wird immer relativ zum aktuellen Verzeichnis betrachtet, wenn er nicht absolut ist.)
  • In der vierten Zeile wird das in . Konfigurierte Projekt mit dem in der vorherigen Zeile konfigurierten Buildsystem erstellt. Es führt das Ziel install aus, das auch alle erforderlichen abhängigen Ziele erstellt, wenn diese erstellt werden müssen, und kopiert dann die Dateien in den CMAKE_INSTALL_PREFIX (In diesem Fall ./project-root/build/stage). Bei Builds mit mehreren Konfigurationen, wie in Visual Studio, können Sie die Konfiguration auch mit dem optionalen Flag --config <config> Angeben.
  • Der gute Teil bei der Verwendung des Befehls cmake --build Ist, dass er für alle Generatoren (d. H. Makefiles und Visual Studio) funktioniert, ohne dass andere Befehle benötigt werden.

Danach benutze ich die installierten Dateien, um Pakete zu erstellen oder sie in andere Projekte aufzunehmen ...

16
toeb

In Bezug auf Bruce Adams Antwort:

Ihre Antwort schafft gefährliche Verwirrung. DESTDIR ist für Installationen außerhalb des Stammbaums vorgesehen. Es erlaubt einem zu sehen, was im Stammbaum installiert werden würde, wenn man nicht DESTDIR spezifiziert hätte. PREFIX ist das Basisverzeichnis, auf dem die eigentliche Installation basiert.

Beispielsweise gibt PREFIX =/usr/local an, dass das endgültige Ziel eines Pakets/usr/local ist. Wenn Sie DESTDIR = $ HOME verwenden, werden die Dateien so installiert, als wäre $ HOME das Stammverzeichnis (/). Wenn DESTDIR/tmp/destdir wäre, könnte man sehen, was 'make install' beeinflussen würde. In diesem Sinne sollte DESTDIR niemals die gebauten Objekte beeinflussen.

Ein Makefile-Segment, um es zu erklären:

install:
    cp program $DESTDIR$PREFIX/bin/program

Programme müssen davon ausgehen, dass PREFIX das Basisverzeichnis des endgültigen (d. H. Produktions-) Verzeichnisses ist. Die Möglichkeit, ein in DESTDIR =/something installiertes Programm zu verknüpfen, bedeutet nur, dass das Programm nicht auf Dateien zugreift, die auf PREFIX basieren, da dies einfach nicht funktionieren würde. cat (1) ist ein Programm, das (in seiner einfachsten Form) von überall ausgeführt werden kann. Hier ist ein Beispiel, das nicht funktioniert:

prog.pseudo.in:
    open("@[email protected]/share/prog.db")
    ...

prog:
    sed -e "s/@[email protected]/$PREFIX/" prog.pseudo.in > prog.pseudo
    compile prog.pseudo

install:
    cp prog $DESTDIR$PREFIX/bin/prog
    cp prog.db $DESTDIR$PREFIX/share/prog.db

Wenn Sie versuchen, prog von einer anderen Stelle als $ PREFIX/bin/prog auszuführen, wird prog.db niemals gefunden, da es sich nicht an der erwarteten Position befindet.

Schließlich funktioniert/etc/alternatives wirklich nicht so. Es gibt Symlinks zu Programmen, die im Stammbaum installiert sind (z. B. vi ->/usr/bin/nvi, vi ->/usr/bin/vim usw.).

4
user7498341

Es wird als schlechte Praxis angesehen, den tatsächlichen Generator aufzurufen (z. B. über make), wenn CMake verwendet wird. Es wird dringend empfohlen, dies so zu tun:

  1. Phase konfigurieren:

    cmake -Hfoo -B_builds/foo/debug -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=/usr
    
  2. Build nd Installiere Phasen

    cmake --build _builds/foo/debug --config Debug --target install
    

Bei dieser Vorgehensweise kann der Generator einfach umgeschaltet werden (z. B. -GNinja für Ninja ), ohne sich an generatorspezifische Befehle erinnern zu müssen.

2
Florian Wolters