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

Oui cmake . && make all install. Cela fonctionne, mais s'installe sur /usr/local.

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

Quelle est la ligne de commande cmakeet makesur laquelle installer au /usrlieu de /usr/local?

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

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

Configurerait le projet, créerait toutes les cibles et installerait le préfixe / usr. Le type (PATH) n'est pas strictement nécessaire, mais entraînerait le cmake-gui basé sur Qt à présenter la boîte de dialogue de sélection de répertoire.

Quelques ajouts mineurs en tant que commentaires montrent clairement que fournir une équivalence simple ne suffit pas pour certains. La meilleure pratique serait d'utiliser un répertoire de construction externe, c'est-à-dire pas directement la source. Également pour utiliser une syntaxe CMake plus générique faisant abstraction du générateur.

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

Vous pouvez voir qu'il devient un peu plus long et n'est plus directement équivalent, mais est plus proche des meilleures pratiques sous une forme assez concise ... Le --config n'est utilisé que par les générateurs multi-configuration (c'est-à-dire MSVC), ignoré par d'autres.

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

... comme utilisé dans les réponses ici .

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

make DESTDIR=<installhere> install

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

Ceci est destiné aux installations par étapes et permet de stocker des programmes dans un emplacement différent de celui où ils sont exécutés, par exemple /etc/alternativesvia des liens symboliques.

Cependant, si votre package est déplaçable et n'a pas besoin de chemins codés en dur (préfixe) définis via l'étape de configuration, vous pourrez peut- être l'ignorer. 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 user7498341, ce n'est pas approprié dans les cas où vous devriez vraiment utiliser PREFIX.

La façon dont je construis la plateforme 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 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é par rapport au répertoire courant s'il n'est pas absolu)
• La quatrième ligne crée le projet configuré .avec le buildsystem configuré dans la ligne précédente. Il exécutera la installcible qui crée également toutes les cibles dépendantes nécessaires si elles doivent être générées, puis copie les fichiers dans le CMAKE_INSTALL_PREFIX(ce qui est le cas dans ce cas ./project-root/build/stage. Pour les générations multi-configuration, comme dans Visual Studio, vous pouvez également spécifier la configuration avec le --config <config>drapeau optionnel .
• La bonne partie lors de l'utilisation de la cmake --buildcommande est qu'elle fonctionne pour tous les générateurs (c'est-à-dire les makefiles et Visual Studio) sans avoir besoin de commandes différentes.

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

Concernant la réponse de Bruce Adams:

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 n'a pas spécifié 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 ne devrait jamais affecter les objets construits.

Un segment 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'est-à-dire de production). La possibilité de créer un lien symbolique vers un programme installé dans DESTDIR = / quelque chose signifie simplement que le programme n'accède pas aux fichiers basés sur PREFIX car il ne fonctionnerait tout simplement pas. cat (1) est un programme qui (dans sa forme la plus simple) peut s'exécuter de n'importe où. Voici un exemple qui ne fonctionnera 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 avez essayé d'exécuter prog ailleurs que $ PREFIX / bin / prog, prog.db ne sera jamais trouvé car il ne se trouve pas à son 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.).

Il est considéré comme une mauvaise pratique d'invoquer 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. Phases de construction et 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 -GNinjapour Ninja ) sans avoir à mémoriser les commandes spécifiques au générateur.

À partir de CMake 3.15, la bonne façon d'y parvenir serait d'utiliser:

cmake --install <dir> --prefix "/usr"

Documentation officielle