web-dev-qa-db-fra.com

Quel est l'équivalent CMake de 'configure --prefix = DIR && make all install'?

Je fais cmake . && make all install. Cela fonctionne, mais s’installe sur /usr/local.

Je dois installer un préfixe différent (par exemple, sur /usr).

Quelle est la ligne de commande cmake et make à installer sur /usr au lieu de /usr/local?

cmake
354
Andrei

Vous pouvez transmettre n'importe quelle variable CMake sur la ligne de commande ou éditer des variables en cache à l'aide de ccmake/cmake-gui. Sur la ligne de commande,

cmake -DCMAKE_INSTALL_PREFIX: CHEMIN =/usr. && faire tout installer

Configurerait le projet, construirait toutes les cibles et installerait le préfixe/usr. Le type (PATH) n'est pas strictement nécessaire, mais le cmake-gui basé sur Qt présenterait la boîte de dialogue du sélecteur de répertoire.

Certains ajouts mineurs en tant que commentaires indiquent clairement qu'il est insuffisant de fournir une équivalence simple. La meilleure pratique consiste à utiliser un répertoire de construction externe, c'est-à-dire pas directement le source. De plus, une syntaxe plus générique de CMake abstraite le générateur .

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

Vous pouvez voir que cela prend un peu plus de temps et n'est plus directement équivalent, mais se rapproche des meilleures pratiques sous une forme assez concise ... Le --config n'est utilisé que par des générateurs multi-configuration (MSVC), ignoré par d'autres.

406
Marcus D. Hanwell

La partie ": CHEMIN" de la réponse acceptée peut être omise. Cette syntaxe peut être plus mémorable:

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

... tel qu'utilisé dans les réponses ici .

37
user2023370

Notez que dans CMake et Autotools vous n’avez pas toujours besoin de définir le chemin d’installation au moment de la configuration. Vous pouvez utiliser DESTDIR au moment de l'installation (voir aussi ici ) à la place comme dans:

make DESTDIR=<installhere> install

Voir aussi cette question qui explique la différence subtile entre DESTDIR et PREFIX.

Ceci est prévu pour les installations par étapes et pour permettre de stocker des programmes dans un emplacement différent de celui où ils sont exécutés, par exemple. /etc/alternatives via des liens symboliques.

Cependant, si votre paquet est relogeable et ne nécessite pas de chemin codé en dur (préfixe) défini via l’étape de configuration, vous pourrez pouvoir le sauter. Donc au lieu de:

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

vous courriez:

cmake . && make DESTDIR=/usr all install

Notez que, comme le souligne l'utilisateur7498341, cela n'est pas approprié dans les cas où vous devriez vraiment utiliser PREFIX.

24
Bruce Adams

La façon dont je construis des projets multi-projets CMake est la suivante:

/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
  • Les deux premières lignes créent le répertoire de construction hors source.
  • La troisième ligne génère le système de construction en spécifiant où placer le résultat de l'installation (que je place toujours dans ./project-root/build/stage - le chemin est toujours considéré comme relatif au répertoire en cours s'il n'est pas absolu)
  • La quatrième ligne construit le projet configuré dans . avec le système de construction configuré dans la ligne précédente. Il exécutera la cible install qui génère également toutes les cibles dépendantes nécessaires si elles doivent être générées, puis copie les fichiers dans le fichier CMAKE_INSTALL_PREFIX (qui dans ce cas est ./project-root/build/stage. Comme dans Visual Studio, vous pouvez également spécifier la configuration avec l'indicateur facultatif --config <config>.
  • La bonne partie lorsque vous utilisez la commande cmake --build est qu’elle fonctionne pour tous les générateurs (par exemple, makefiles et Visual Studio) sans nécessiter de commandes différentes.

Ensuite, j'utilise les fichiers installés pour créer des packages ou les inclure dans d'autres projets ...

16
toeb

En ce qui concerne Bruce Adams, répondez:

Votre réponse crée une confusion dangereuse. DESTDIR est destiné aux installations hors de l’arborescence racine. Il permet de voir ce qui serait installé dans l’arborescence racine si l’on ne spécifiait pas DESTDIR. PREFIX est le répertoire de base sur lequel est basée l'installation réelle.

Par exemple, PREFIX =/usr/local indique que la destination finale d'un package est/usr/local. L'utilisation de DESTDIR = $ HOME installera les fichiers comme si $ HOME était la racine (/). Si, disons DESTDIR, était/tmp/destdir, on pourrait voir ce que "make install" affecterait. Dans cet esprit, DESTDIR devrait jamais affecter les objets construits.

Un segment de makefile pour l'expliquer:

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

Les programmes doivent supposer que PREFIX est le répertoire de base du répertoire final (c.-à-d. Production). La possibilité de créer un lien symbolique entre un programme installé dans DESTDIR =/quelque chose signifie simplement que le programme n’a pas accès aux fichiers basés sur PREFIX car cela ne fonctionnerait tout simplement pas. cat (1) est un programme (sous sa forme la plus simple) pouvant fonctionner de n'importe où. Voici un exemple qui ne va pas:

prog.pseudo.in:
    open("@prefix@/share/prog.db")
    ...

prog:
    sed -e "s/@prefix@/$PREFIX/" prog.pseudo.in > prog.pseudo
    compile prog.pseudo

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

Si vous essayez d'exécuter prog ailleurs que $ PREFIX/bin/prog, prog.db ne sera jamais trouvé car il ne se trouve pas à l'emplacement prévu.

Enfin,/etc/alternatives ne fonctionne vraiment pas de cette façon. Il existe des liens symboliques vers des programmes installés dans l’arborescence racine (par exemple, vi ->/usr/bin/nvi, vi ->/usr/bin/vim, etc.).

4
user7498341

Il est considéré comme une mauvaise pratique d’appeler le générateur réel (par exemple, via make) si vous utilisez CMake . Il est fortement recommandé de le faire comme ceci:

  1. Configurer la phase:

    cmake -Hfoo -B_builds/foo/debug -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=/usr

  2. Construire et Phases d'installation

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

En suivant cette approche, le générateur peut être facilement commuté (par exemple, -GNinja pour Ninja ) sans avoir à se rappeler de commandes spécifiques au générateur.

2
Florian Wolters