Cadre pour la construction et la gestion de bibliothèques tierces

Question

Je travaille sur un projet multi-plateforme qui utilise un grand nombre de bibliothèques tierces (actuellement 22 et comptant, et je m'attends à ce que ce nombre augmente considérablement). Mon projet est basé CMake, et maintient le ThirdParty/répertoire organisé comme ceci:

ThirdParty/libname de $/include/
ThirdParty/$ libname/lib/plate-forme $/buildtype $/

Mes CMakeLists. txt a la logique pour déterminer les valeurs appropriées pour $ platform (mac-i386, mac-ia64, win32-i386, et ainsi de suite) et $ buildtype (debug/release).

La difficulté se pose de garder ces bibliothèques à jour pour chaque plate-forme. Actuellement, je le fais manuellement - quand je mets à jour une bibliothèque, je vais la reconstruire pour chaque plate-forme. Mais c'est un cauchemar, et l'ajout d'une nouvelle plate-forme est une affaire de deux jours.

Ce serait facile à automatiser si les bibliothèques tierces étaient elles-mêmes basées sur CMake, mais elles utilisent tout de CMake à autoconf pour des solutions personnalisées aux Makefiles roulés à la main. Il n'y a pas de cohérence entre eux, et tous exigent de franchir différents obstacles en ce qui concerne la construction de la plate-forme (en particulier en ce qui concerne les builds de 32 à 64 bits).

Existe-t-il des outils (ou des extensions CMake) qui faciliteraient la gestion? Y a-t-il même un terrain d'entente raisonnable entre CMake et autoconf, par exemple? La solution idéale me donnerait une seule commande pour construire tout ce qui doit être reconstruit pour une plate-forme donnée (la compilation croisée n'est pas nécessaire, car j'ai accès à toutes les plateformes nécessaires), mais tout ce qui me faciliterait la vie progressivement être apprécié.

Answer 1

Vous pouvez probablement utiliser ExternalProject pour cela.

Créez des cibles personnalisées pour créer des projets dans des arborescences externes. La fonction 'ExternalProject_Add' crée une cible personnalisée pour le téléchargement, la mise à jour/la correction, la configuration, la construction, l'installation et le test des étapes d'un projet externe.

Si vous avez déjà la source dans votre hiérarchie de fichiers de projet, vous pouvez utiliser quelque chose comme ça (pour zlib):

include(ExternalProject) 
ExternalProject_Add(zlib URL ${CMAKE_CURRENT_SOURCE_DIR}/zlib-1.2.4/ 
    CONFIGURE_COMMAND cd <SOURCE_DIR> && ./configure --prefix=${CMAKE_CURRENT_BINARY_DIR}/zlib-build 
    BUILD_IN_SOURCE 1 
    BUILD_COMMAND make) 

qui copie le code source zlib de votre arbre source dans le construisez l'arborescence, lancez l'étape de configuration (après cd'ing dans le répertoire copié), puis exécutez make sur le répertoire configuré. Enfin, la version construite de zlib est installée dans le répertoire de construction actuel, dans un sous-répertoire appelé zlib-build.

Vous pouvez modifier les étapes d'installation, de configuration et de construction comme bon vous semble - zlib 1.2.4, par exemple, n'aime pas que "configure" soit out-of-source. Pour une configuration personnalisée, vous pouvez ignorer l'étape CONFIGURE et simplement exécuter la commande de construction (par exemple). Cela nécessite une version récente de CMake pour fonctionner (2.8+).