Qu'est-ce que CMake l'équivalent de 'configure --prefix=DIR && make install '?
Je ne cmake . && make all install
. Cela fonctionne, mais s'installe à /usr/local
.
J'ai besoin d'installer sur un autre préfixe (par exemple, pour /usr
).
Quel est le cmake
et make
ligne de commande pour installer à /usr
au lieu de /usr/local
?
- C'est une grande question pour changer le répertoire d'installation à la volée, mais pourquoi est-ce une telle apparemment besoin commun? De mon point de vue, la réponse devrait être de NE PAS utiliser une option de ligne de commande, au lieu de modifier la base de
CMakeLists.txt
de sorte que vous pouvez régler et oublier. Je ne dis pas qu'il n'est pas une utilisation pour changer le répertoire d'installation sur le fly-clairement il y a en juger par le nombre de votes -- je suis juste assez nouveau à CMake et curieux lorsque ce problème se présente. - c'est pour répondre aux utilisateurs qui veulent construire & installer le projet à un endroit particulier, mais ne sont pas les mêmes personnes que les développeurs ou les responsables du projet.
- Donc, en tant que responsable, il n'est pas inhabituel pour moi de tester mon
make install
à un chemin d'accès temporaire à assurez-vous que tout ce qui doit être installé, s'est installé au bon endroit sans perturber le fonctionnement de ma machine de développement. Juste un exemple. Un autre cas est la compilation croisée pour une autre architecture. - J'ai besoin de cela parce que je veux créer un paquetage RPM. Si j'aurais besoin de changer la
CMakeLists.txt
, alors j'ai besoin de patch de la source d'origine. Juste d'avoir une option de ligne de commande me permet d'obtenir les chemins à droite dans la Fedoraspec
fichier. - d'autres la lecture de ce) pour info, il est généralement considéré comme une mauvaise idée de modifier le
CMakeLists.txt
fichier si vous êtes simplement à la construction et à l'installation de logiciel prépondérant/définition des variables à partir de la ligne de commande initiale ou fichier de cache, etc. est le préféré le "consommateur" moyen d'options de configuration.
Vous devez vous connecter pour publier un commentaire.
Vous pouvez passer dans tous les CMake variable sur la ligne de commande, ou de modifier la mise en cache des variables à l'aide ccmake/cmake-gui. Sur la ligne de commande,
Faudrait configurer le projet, créer toutes les objectifs et les installer dans le répertoire /usr préfixe. Le type (CHEMIN d'accès) n'est pas strictement nécessaire, mais serait la cause de l'intervalle Qt en fonction de cmake-gui de présenter le répertoire de dialogue sélecteur.
Quelques ajouts mineurs comme des commentaires, il est clair que fournissant un moyen simple d'équivalence n'est pas assez pour certains. La meilleure pratique serait d'utiliser un externe répertoire de construction, c'est à dire pas directement la source. Également à une utilisation plus générique CMake syntaxe abstraction de la génératrice.
Vous le voyez c'est un peu plus longue, et n'est pas directement l'équivalent de plus, mais est plus proche de meilleures pratiques et d'une manière très concise forme... L' --config est uniquement utilisé par les multi-configuration des générateurs (c'est à dire MSVC), ignoré par les autres.
:PATH
est nécessaire./usr .
/usr/local
au lieu de cela, en fait), les fichiers de toujours obtenir installé dans./install
. A quelque chose de changé dans les nouvellescmake
(2.18.12.2)?CMAKE_INSTALL_PREFIX
dansCMakeLists.txt
!Le "CHEMIN" dans le cadre de la accepté de répondre peut être omis. Cette syntaxe peut être plus mémorable:
...comme utilisé dans les réponses ici.
:PATH
n'est pas une erreur.Noter que dans les deux CMake et Autotools vous n'avez toujours pas de définir le chemin d'installation à configurer l'heure. Vous pouvez utiliser DESTDIR au moment de l'installation (voir aussi ici) plutôt que dans:
Voir aussi cette question ce qui explique la différence subtile entre DESTDIR et PRÉFIXE.
C'est prévu pour la mise en scène installe et pour permettre le stockage de programmes dans un endroit différent de celui où elles sont exécutées par exemple
/etc/alternatives
via des liens symboliques.Toutefois, si votre colis est transférable et n'a pas besoin de tout codé en dur (préfixe) chemins d'accès définis par l'étape de configuration vous peut être en mesure de le sauter.
Ainsi, au lieu de:
vous devez exécuter:
Noter que, comme user7498341 points, ce n'est pas appropriée dans les cas où vous devez vraiment être à l'aide du PRÉFIXE.
DESTDIR
. Mais en fait ce qui est mal. Reportez-vous à la cmake docs cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html ...make DESTDIR=/home/john install
qui va installer le logiciel concerné en utilisant le préfixe d'installation, par exemple, “/usr/local” précédées de la DESTDIR valeur qui donne enfin “/home/john/usr/local”.La façon dont je construis CMake projets de la croix-plate-forme est la suivante:
./project-root/build/stage
- le chemin est toujours considéré comme relatif au répertoire courant si elle n'est pas absolue).
avec le buildsystem configuré dans la ligne avant. Il exécutera lainstall
cible, qui s'appuie également tout le nécessaire dépendant de la cible si ils ont besoin d'être construit, puis copie les fichiers dans leCMAKE_INSTALL_PREFIX
(qui dans ce cas est./project-root/build/stage
. Pour le multi-configuration s'appuie, comme dans Visual Studio, vous pouvez également spécifier la configuration avec l'option--config <config>
drapeau.cmake --build
commande est qu'elle fonctionne pour tous les producteurs (c'est à dire des fichiers makefile et Visual Studio) sans avoir besoin de différentes commandes.Par la suite-je utiliser les fichiers installés pour créer des packages ou les inclure dans d'autres projets...
cmake -G "<generator>" -DCMAKE_INSTALL_PREFIX=stage ..
make -j $(nproc)
, pour spécifier le nombre de construire fils, necmake --build . --target=install --config=Release -- -j 8
pour générateur de Makefile oucmake --build . --target=install --config=Release -- /m:8
pour Visual Studio générateur avec 8 threads. En fait, vous pouvez passer tous les paramètres de ligne de commande après--
Concernant Bruce Adams réponse:
Votre réponse crée dangereuse confusion. DESTDIR est prévu pour
installe sur la racine de l'arbre. Elle permet de voir ce qui serait
installé à la racine de l'arbre si l'on ne précise pas DESTDIR.
PRÉFIXE est le répertoire de base sur lequel l'installation est
en fonction.
Par exemple, PREFIX=/usr/local indique que le final destination
d'un paquet est /usr/local. À l'aide de DESTDIR=$HOME va installer les fichiers
comme si $HOME est le répertoire racine (/). Si, par exemple DESTDIR, a /tmp/destdir, un
pu voir ce que 'make install' aurait une incidence sur. Dans cet esprit, DESTDIR
devrait jamais affecter l'objet construit.
Un makefile segment de l'expliquer:
Programmes doit supposer que le PRÉFIXE est le répertoire de base de la finale
(c'est à dire la production d'un répertoire. La possibilité de faire un lien symbolique d'un programme
installé dans DESTDIR=/quelque chose ne signifie pas que le programme n'a pas
accéder à des fichiers basé sur le PRÉFIXE comme il ne serait tout simplement pas de travail. chat(1)
est un programme (dans sa forme la plus simple) peut fonctionner à partir de n'importe où.
Voici un exemple qui ne marche pas:
Si vous avez essayé d'exécuter prog d'ailleurs que $PREFIX/bin/prog,
prog.db ne serait jamais trouvé qu'il n'est pas dans son emplacement prévu.
Enfin, /etc/alternatives vraiment ne fonctionnent pas de cette façon. Il y a
les liens symboliques à des programmes installés dans l'arborescence de la racine (par exemple, vi -> /usr/bin/inb,
vi -> /usr/bin/vim, etc.).
Il est considéré comme une mauvaise pratique d'invoquer le réel générateur (par exemple via
make
) si vous utilisez CMake. Il est fortement recommandé de le faire comme ceci:Configurer phase:
Construire et Installer phases
En suivant cette approche, le générateur peut être facilement changé (par exemple,
-GNinja
pour Ninja) sans avoir à se souvenir de tout générateur de commandes spécifiques.--config
argument?