2 votes

Peut-on créer des installations délocalisables (entre machines) avec cmake ?

J'aimerais construire des bibliothèques tierces à partir des sources et avoir des cibles cmake importables pour les bibliothèques préconstruites qui peuvent être partagées avec le projet (relocalisables).

Les bibliothèques que je construis sont de plusieurs types :

  • cmake moderne, qui peut exporter des cibles
  • Ancien cmake, qui n'exporte PAS de cibles, mais peut avoir pkgconf
  • Autoconf / makefiles réguliers qui ont souvent des sorties pkgconf
  • Petites pièces uniques sans fichiers de construction.

Il peut y avoir des dépendances entre les bibliothèques, et quelques dépendances système par exemple :

  • LibA dépend de LibB
  • LibB dépend de certaines bibliothèques présentes sur le système : sysLibXX, sysLibYY

Question

Comment puis-je empaqueter les bibliothèques préconstruites afin que les cibles cmake et les bibliothèques préconstruites puissent être partagées et importées pour construire mon projet sur d'autres machines ?

Problèmes

  • L'utilisation de cmake pour "installer" dans un chemin qui peut être partagé avec le projet, produit intrinsèquement des dépendances non relocalisables. Par exemple, si la librairie mathématique libm est trouvé par cmake, il est écrit en tant que chemin absolu dans la cible exportée générée par cmake /usr/lib/x86_64-linux-gnu/libm.so . Cela ne fonctionne pas sur d'autres machines dont les chemins d'accès aux bibliothèques système sont différents.

    • Puis-je d'une manière ou d'une autre demander à cmake de garder les références de bibliothèques relocalisables dans les cibles exportées ? (Comme : -lm )
  • Tous les paquets n'exportent pas les fichiers cmake, et même s'ils le font, ils peuvent le faire de manière incorrecte.

    • Dois-je éditer à la main ou écrire à partir de zéro XXConfig.cmake scripts pour les rendre relocalisables ?

des idées utiles

Il serait utile de décrire le processus permettant de passer des sources dans les différentes situations ci-dessus au script redistribuable en tirant parti de toutes les informations possibles telles que pkgconf ou les cibles d'exportation générées automatiquement.

Par exemple :

Avec la construction vanille scripts je peux le faire :

./configure --prefix="`pwd`/temp"
make
make install

Ensuite, je pourrais peut-être corriger les scripts de pkgconf à la main pour supprimer les chemins absolus et utiliser une fonctionnalité de cmake pour lire le pkgconf dans un fichier XXConfig.cmake personnalisé ?

Il serait vraiment utile de savoir si quelqu'un a essayé quelque chose de ce genre et s'il a une idée de la facilité de maintenance de ce système.

0voto

johnb003 Points 288

Il s'avère que cmake est capable de créer des paquets relocalisables, et le problème vient principalement des différentes bibliothèques tierces qui suivent des anti-modèles.

https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages

J'ai décidé de construire tous mes paquets de tierces parties de cette manière :

  • Les bibliothèques de confiance peuvent s'installer directement dans le dossier d'installation relocalisable.
  • Les bibliothèques qui ne sont pas écrites dans un emplacement temporaire sont nettoyées pour automatiser la conversion des chemins de liens complets en simples déclarations -lLib.

Ce script ressemble à ceci :

for FILE in ${CMAKE_FILES}; do
  # Find any paths that begin with "/usr/" and end with "/lib<something>.so"
  # And replace them with -l<something>
  # [^;] is used instead of .*, because ; delimites paths, and there's only greedy regex here.
  sed 's@/usr/[^;]*/lib\([^;]*\)\.so@-l\1@g' "${FILE}" > "${SCRUBBED_CMAKE_PATH}/${FILE#${TEMP_CMAKE_PATH}}"
  echo -e "Scrubbing ${FILE#${TEMP_CMAKE_PATH}}..."
  set +e  # disable error checking for a moment, because diff returns non-0 error codes intentionally
  diff "${FILE}" "${SCRUBBED_CMAKE_PATH}/${FILE#${TEMP_CMAKE_PATH}}"
  set -e  # re-enable error checking
done

Ce n'est vraiment pas portable, et c'est vraiment ennuyeux à gérer, donc j'ai tendance à essayer de pirater le fichier CMakeScripts.txt de la tierce partie en premier si je le peux pour régler les problèmes non relocalisables, par exemple. https://github.com/leethomason/tinyxml2/pull/681

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X