Y a-t-il des efforts pour créer un gestionnaire de paquets pour C ++?

L’une de mes plus grandes frustrations avec mon langage préféré est l’effort nécessaire pour que différentes bibliothèques travaillent ensemble dans un environnement de développement unifié. Mon plus grand souhait est simplement de pouvoir dire à mon IDE, ou autre chose, que j’ai besoin d’une certaine bibliothèque, et qu’elle s’occupe de la télécharger, de la comstackr (si nécessaire), de l’installer, puis de définir les chemins d’inclusion et de bibliothèque.

Ce que je veux c’est ceci , mais pour C ++. Je préférerais que cela fonctionne avec Visual Studio, mais gcc aussi. Ou si c’est son propre système, c’est bien aussi. Il doit cependant fonctionner sous Windows.

Quels projets prometteurs existent pour résoudre ce problème?

    Si vous utilisez MinGW, il existe déjà un gestionnaire de paquets similaire à apt-get / aptitude qui fait ce que vous voulez: mingw-get

    Il se comporte comme apt-get / aptitude de Debian. Parmi les paquets déjà inclus, vous pouvez trouver expat, libxml2, zlib, pthread, etc.

    De toute évidence, vous aurez besoin d’une copie de MinGW pour commencer à travailler avec elle.

    Avez-vous considéré Git comme un gestionnaire de paquets? J’ai utilisé des sous-modules git pour les dépendances et les sous-dépendances et, combiné avec les services d’hébergement git gratuits, l’idée est assez puissante.

    Entrez simplement dans votre projet git,

     git submodule add git://somehosting.com/you/package.git git submodule init package git submodule update package cd package && ./configure --stuff && make && cd .. 

    Pour sélectionner des versions de dépendance particulières,

     cd package && git checkout v3.2 && cd .. && git add package/ git commit -am "package version 3.2 pinned" && git push 

    Vous avez maintenant épinglé votre dépendance de package à une balise particulière et enregistré vos parameters dans votre référentiel de projet. La prochaine fois que quelqu’un fait:

     git pull && git submodule update 

    Leur dépendance de paquet sera également épinglée à la v3.2.

    Certains systèmes de gestion de paquets comportent également des packages signés. Git vous permet de signer vos balises par GPG et de les vérifier en ajoutant votre clé publique à leur trousseau de clés.

    Nous avons donc le téléchargement de paquets, les versions de dépendance et nous pouvons émuler “la signature de paquet”. Une partie manquante est des binarys pré-construits qui, à mon avis, ne sont pas une nécessité absolue. Une autre partie manquante est la gestion globale des paquets. Vous devrez gérer manuellement chaque référentiel git lorsqu’une dépendance d’une dépendance sera mise à jour.

    La réponse est d’utiliser Conda pour la gestion des empaquetages / dépendances et n’importe quel outil que vous aimez pour construire (j’utilise CMake).

    Vérifiez le ici:

    http://conda.pydata.org/

    Conda est similaire aux gestionnaires de paquets comme apt-get, yum, nuget, etc., mais avec plusieurs avantages importants:

    1) entièrement multi-plateforme (actuellement Linux, Windows et OSX, mais d’autres plates-formes peuvent être ajoutées facilement)

    2) N’exige pas l’access root à l’utilisation. En fait, ne se soucie pas du tout de vos paquets système. C’est similaire à la construction d’une stack entière (jusqu’à la libc si vous le souhaitez) dans votre homedir, sauf que quelqu’un les a déjà construites pour vous. Cette magie est obtenue en rendant les paquets relogeables .

    3) vous pouvez maintenir autant d’environnements différents que vous le souhaitez côte à côte. Une de vos applications nécessite-t-elle python 2.7.6, mais une autre nécessite python 2.7.4? Pas de problème – ils peuvent coexister en paix

    4) vous ne serez plus jamais obligé de maintenir des versions séparées pour les différentes dissortingbutions Linux. Un environnement Conda correctement construit fonctionnera sur chacun d’entre eux. N’oubliez pas également les autres plates-formes (par exemple Windows et OSX)!

    5) vous n’êtes plus marié à des versions de bibliothèques qui ont été décidées pour vous par un système ou un service informatique. Par exemple, j’ai été obligé de travailler sur des nœuds RHEL5. Le python il y a une blague (plus de 10 ans maintenant). En utilisant Conda, j’ai évité cette douleur et j’ai pu travailler sur n’importe quelle version de Python que je voulais sans affecter personne d’autre.

    6) les environnements peuvent être transformés en “installateurs” pour la dissortingbution.

    7) Vous pouvez gérer votre propre repository privé derrière votre pare-feu pour les bibliothèques propriétaires. Le référentiel public centralisé s’appelle Binstar. Vos dépendances peuvent provenir de l’une ou l’autre (ou des deux).

    Beaucoup de gens croient à tort que Conda est un système uniquement Python, mais en fait, Conda a été créé pour un emballage natif (il est indépendant de la langue). Il a une présence énorme en Python simplement parce que sa motivation originale était de surmonter le terrible support natif des bibliothèques dans les autres systèmes de packaging de Python (pip + pypi).

    Le seul problème avec Conda est que Binstar (le repository central) n’a pas encore tous les paquets. Vous allez certainement rencontrer des bibliothèques manquantes que vous voulez – mais c’est facile à corriger: vous pouvez créer n’importe quel paquet que vous aimez et le pousser vers Binstar. J’ai dû le faire pour des dizaines de bibliothèques natives. Cela fonctionne assez bien.

    Je ne reviendrai jamais sur les gestionnaires de dépendance du système lors du développement du code C ++.

    À partir de NuGet 2.5, NuGet prend en charge les projets natifs . Cependant, rendre le paquet à la main est assez complexe, ils suggèrent donc d’utiliser les outils Powershell de CoApp pour NuGet ( documentation ici ). En utilisant ces outils, vous pouvez maintenant héberger vos packages C / C ++ sur NuGet.

    Il est peu probable que cela se produise simplement parce que des bibliothèques C ++ différentes utilisent souvent des systèmes de construction VASTLY différents. Autoconf, scons, make, MSBuild, VCBuild, Boost Jam, CMake, NMake et QMake sont des exemples. En outre, de nombreux développeurs C et C ++ génèrent du code avec des outils tels que Yacc et Bison.

    Maven et NuGet fonctionnent comme ils le font car ils supportent les écosystèmes avec (relativement) peu de variation dans les outils de construction. Ant dans le cas de Maven, MSBuild dans le cas de NuGet. Construire un système similaire pour travailler avec la vaste gamme de systèmes de construction C ++ utilisés serait irréalisable et peu pratique (étant donné le manque apparent de demande pour de tels systèmes).

    J’ai travaillé sur un gestionnaire de paquets dissortingbué multi-plateforme et multi-architecture . Tous les paquets sont installés dans le répertoire du projet (un peu comme fonctionne nodejs). C’est un travail en cours.

    Il y a la proposition de module de Daveed , qui n’est pas entrée dans C ++ 0x.

    Il y a CoApp , qui semble avoir le support de Microsoft.

    ryppl semble faire ce que vous avez exigé et plus encore, multiplateforme:

    Notre mission est de créer les conditions d’un écosystème logiciel C ++ portable et modulaire

    Les ont déjà joué sur GitHub: https://github.com/ryppl/ryppl