Journal Gestionnaire de dépendances en C++

Posté par rewind (Mastodon) le 07 avril 2015 à 13:53. Licence CC By‑SA.

Étiquettes :

avr.

2015

Le problème de la gestion des dépendances en C++ serait-il en passe d'être pris suffisamment au sérieux ? On en a parlé il y a quelques temps, à propos de biicode, un gestionnaire de dépendance qui a l'inconvénient de ne pas être libre. Mais on risque de voir le paysage bouger.

Au programme de la prochaine conférence C++Now, qui aura lieu mi-mai à Aspen (Colorado), pas moins de 4 présentations sur le sujet ou approchant. On retrouve évidemment le sus-nommé biicode (Biicode, a C/C++ dependency manager with a hosting service), mais aussi:

Why in heaven there is no dependency management for C++? : on remarquera que la présentation est faite par un des devs de biicode et que ça risque d'être biaisé
New Build System for New C++ : qui aborde la problématique globale de la construction multi-platforme et de la gestion des paquets
Big Projects, and CMake, and Git, Oh My! : un tutorial pour montrer comment utiliser git et CMake pour gérer possiblement des centaines de dépendances

Personnellement, je pense qu'il y a un marché pour ce genre de produit. Le manque est criant, il suffit d'aller dans n'importe quel entreprise qui fait du C++ pour s'en rendre compte. Et même pour nous, développeurs occasionnels, ça nous simplifierait la vie d'avoir un outil qui permettent de dire : "tape 'machin build' et c'est bon" plutôt que "tape 'cmake' puis… ha non, il faut que tu ailles chercher la lib toto sur ce site… et pour la lib toto, il faut taper './configure' puis…" Dans l'idéal, j'aimerais qu'un tel outil ait les caractéristiques suivantes :

multi-plateformes : l'outil devrait gérer les différents systèmes (et fonctionner de manière similaire), mais également gérer des suites d'outils différentes (GCC, Clang, VS, etc)
impose une organisation des sources : un peu comme Maven, ça ferait du bien, ça permettrait de savoir où chercher quand on découvre un nouveau projet, gain de temps et mutualisation des connaissances
libre : ça me semble être une caractéristique essentiel pour ce genre d'outil, on ne peut plus se permettre d'avoir du propriétaire (c'est un des reproches qu'on peut faire à biicode)
simple à utiliser pour des petits projets : un simple fichier où on indique le nom de l'exécutable et la liste des sources devrait suffire pour tous les projets simples, avec des options par défaut sensées. Actuellement avec CMake, il faut quand même écrire un sacré pâté pour avoir un truc utilisable.

Vous ajouteriez quoi ?

# Piste de réflexion

Posté par Elfir3 le 07 avril 2015 à 14:23. Évalué à 2.

Je ne suis absolument pas développeur c++, mais ayant lu/vu quelques trucs sur le sujet en ce qui concerne l'organisation des données en fonction de la plateforme cible, je me pose la question de l'optimisation du code en fonction de la machine cible à l'installation (cache Lx, instructions…).

Il faut recompiler le programme en fonction de la machine cible pour pouvoir agencer certaines données de la manière la plus optimisée possible. La compilation serait faite sur la machine de l'utilisateur final.

Bref, avoir la possibilité de considérer le compilateur comme une dépendance temporaire. Avec téléchargement d'une version statique pour les environnements n'en disposant pas déjà d'un.

Un bête installateur pourrait alors reposer sur ce gestionnaire de dépendance pour installer ce qui est nécessaire tout en laissant au développeur/utilisateur la possibilité d'avoir un binaire optimisé sur sa machine.
- [^] # Re: Piste de réflexion
  
  Posté par rewind (Mastodon) le 07 avril 2015 à 21:37. Évalué à 2.
  
  Il faut recompiler le programme en fonction de la machine cible pour pouvoir agencer certaines données de la manière la plus optimisée possible. La compilation serait faite sur la machine de l'utilisateur final.
  
  Est-ce que ça en vaut bien la peine ? Je ne le pense pas. Es-tu sûr que le gain va être perceptible sur la plupart des programmes ? Je ne le pense pas. D'autre part, la mode est à la recompilation reproductible, donc avoir des options de compilations différentes suivant les machines, ce n'est pas top de ce point de vue. Enfin, il faut aussi penser à la cross-compilation (par exemple, compiler un binaire Windows depuis Linux) qui est assez compliquée par nature sans rajouter des options de compilation tordues.
# Un projet n'est pas que du C++

Posté par Patrick Nicolas le 07 avril 2015 à 15:04. Évalué à 2.

Je voudrais que le système pour construire mon projet puisse faire beaucoup de choses
- gérer le paramétrage de la configuration
- générer des fichiers source à compiler
- permettre de construire des ressources autres que les exécutables, comme des images générées, de la documentation, des fichiers de configuration
- s'intégrer à des outils pour faire des paquets pour les distributions

Et encore dans mon cas je voudrais pouvoir compiler des parties différentes du projet avec des chaînes de compilation différentes (emscripten pour une part, natif pour l'autre).
- [^] # Re: Un projet n'est pas que du C++
  
  Posté par BAud (site web personnel) le 07 avril 2015 à 21:12. Évalué à 2. Dernière modification le 07 avril 2015 à 21:15.
  
  make permet tout ce que tu indiques… ce n'est pas si compliqué (dès lors que tous les outils et libs sont installés, ce qui ne correspond souvent qu'à l'environnement du développeur initial, il est vrai).
  
  Au pire, avec l'aide des autotools (même si elles sont peu connues pour leur côté "utilisation ponctuelle", "utilisation une seule fois", la courbe d'apprentissage initiale étant un peu ardue :/)
  
  Il manque quoi spécifiquement à ces outils concernant tes exemples ? (je connais quelques-une des limitations, notamment le multiplateforme pouvant être plus compliqué, du fait que la chaîne de compilation peut changer selon la plateforme).
  - [^] # Re: Un projet n'est pas que du C++
    
    Posté par Patrick Nicolas le 07 avril 2015 à 22:34. Évalué à 2.
    
    make permet de tout faire, mais il est difficile de garder un Makefile lisible dès qu'on a plusieurs modules, quelques options de compilation.
    
    De manière générale le problème est celui de la lisibilité des fichiers et leur apprentissage. J'ai l'impression de perdre beaucoup de temps dès que je dois faire quelque chose de plus.
    Et finalement on a toujours quelque chose à apprendre : générer la documentation, les fichiers de traduction, utiliser des outils pour son toolkit (moc), générer des sources et d'autres seront plus créatifs.
    
    Ce que je veux, mais je ne sais pas comment y parvenir est un système qui soit aussi générique qu'un Makefile, simple à prendre en main, robuste, facile à lire, capable de gérer les tous les outils de génération (pas seulement les compilateurs).
    En attendant j'utilise cmake ou les autotools.
- [^] # Re: Un projet n'est pas que du C++
  
  Posté par rewind (Mastodon) le 07 avril 2015 à 21:15. Évalué à 2.
  
  gérer le paramétrage de la configuration
  
  Qu'est-ce que tu entends par là ?
  
  générer des fichiers source à compiler
  
  Ça oui. Il y a quelques cas connus à gérer obligatoirement. Je pense à moc, mais aussi à flex/bison.
  
  permettre de construire des ressources autres que les exécutables, comme des images générées, de la documentation, des fichiers de configuration
  
  Ça, ce n'est pas forcément facile, parce que souvent, la méthode de génération est propre à un outil. Mais pareil, quelques cas particuliers devraient être gérés, comme Doxygen.
  
  s'intégrer à des outils pour faire des paquets pour les distributions
  
  La normalisation des sources devrait permettre d'améliorer l'automatisation de création de paquet, à mon avis.
  - [^] # Re: Un projet n'est pas que du C++
    
    Posté par Patrick Nicolas le 07 avril 2015 à 22:40. Évalué à 1.
    
    gérer le paramétrage de la configuration
    Qu'est-ce que tu entends par là ?
    
    Le système doit permettre de sélectionner des parties optionnelles, que ce soit pour choisir les fichiers à compiler ou des paramètres supplémentaires au compilateur. Et aussi les chemins à utiliser, pour l'installation et l'exécution.
# Vous ajouteriez quoi ?

Posté par devnewton 🍺 (site web personnel) le 07 avril 2015 à 15:07. Évalué à 5.
- un plugin pour au moins un bon IDE.
- la génération de «packages»: deb, rpm, setup.exe, setup.sh, superbinaireportable.zip…
- un déploiement / hébergement facile des dépôts (un serveur http doit suffire).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Vous ajouteriez quoi ?
  
  Posté par rewind (Mastodon) le 07 avril 2015 à 21:18. Évalué à 2.
  
  un plugin pour au moins un bon IDE.
  
  Cite moi un bon IDE. La question est rhétorique, parce que chacun a son bon IDE. Et selon moi, il faut surtout permettre que l'intégration à un IDE soit facile, de manière à laisser les utilisateurs de l'IDE en question faire le travail.
  
  la génération de «packages»: deb, rpm, setup.exe, setup.sh, superbinaireportable.zip…
  
  Mille fois oui. Mais comme je le dis plus haut, avec des sources normalisées, ça devrait sans doute être plus facile.
  
  un déploiement / hébergement facile des dépôts (un serveur http doit suffire).
  
  Entièrement d'accord. J'ajouterais même, une intégration avec le système installé (histoire de ne pas télécharger un truc déjà installé localement via un paquet par exemple).
  - [^] # Re: Vous ajouteriez quoi ?
    
    Posté par BAud (site web personnel) le 07 avril 2015 à 22:21. Évalué à 2. Dernière modification le 07 avril 2015 à 22:22.
    Mais comme je le dis plus haut, avec des sources normalisées, ça devrait sans doute être plus facile.
    
    il va falloir expliquer :-) pour le packaging, ce ne sont pas tant les sources qui sont importants :
    - une organisation des sources permet de séparer ce qui est programme de ce qui est lib
    - la liste des binaires, la manière de générer chacun et la possibilité de libifier sont particulièrement importants pour la création de paquet
    - un bon README.txt permet de mieux connaître l'environnement utilisé par le développeur et installer au préalable les dépendances qu'il a installées (parfois, il voit trop large ou en oublie qui sont par défaut sur son système)
    - l'objet est d'être robuste, notamment, aux deux cas suivants :
      
      une version supérieure que ce qui est disponible est absolument nécessaire (cas du développeur qui utilise les toutes dernières versions, sans se préoccuper que certaines distributions restent sur des versions anciennes par souci de stabilité)
      
      une version non obsolète est nécessaire (cas d'un programme ancien, qui n'a pas prévu qu'il pourrait être utilisé 4 ou 5 ans après, quand les bibliothèques ont évolué pour tenir compte des failles de sécurité)
    Pour l'IDE idéal, je veux bien des exemples aussi ;-)
  - [^] # Re: Vous ajouteriez quoi ?
    
    Posté par devnewton 🍺 (site web personnel) le 08 avril 2015 à 08:38. Évalué à 4.
    
    Cite moi un bon IDE. La question est rhétorique, parce que chacun a son bon IDE
    
    Je n'ai pas dit le bon IDE, mais un bon IDE :-)
    
    QtCreator, c'est pas bien par exemple?
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Mes idées

Posté par barmic le 07 avril 2015 à 19:46. Évalué à 5.

simple à utiliser pour des petits projets : un simple fichier où on indique le nom de l'exécutable et la liste des sources devrait suffire pour tous les projets simples, avec des options par défaut sensées. Actuellement avec CMake, il faut quand même écrire un sacré pâté pour avoir un truc utilisable.

Un truc à la gprbuild.

Il faut créer un équivalent à virtualenv pour du C++. Il serait bien qu'un outil de ce type ne touche pas au système, ne demande pas des droits particulier et qu'un projet n'est pas d'effet de bord sur le reste.

Il faut une syntaxe la plus déclarative possible tout en étant puissante. Il est intéressant de regarder gradle pour avoir un exemple de fichier parsable humainement par des outils, mais puissant.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Mes idées
  
  Posté par rewind (Mastodon) le 07 avril 2015 à 21:29. Évalué à 2.
  
  Il serait bien qu'un outil de ce type ne touche pas au système, ne demande pas des droits particulier et qu'un projet n'est pas d'effet de bord sur le reste.
  
  Si tu veux installer localement (dans /usr/local par exemple), tu es obligé de toucher un minimum au système. Mais avoir une procédure de désinstallation propre, en revanche, serait une très bonne idée (ça manque cruellement dans CMake par exemple).
  
  Il faut une syntaxe la plus déclarative possible tout en étant puissante.
  
  Entièrement d'accord. Refaire un n-ième langage de configuration est sans doute une piste à éviter en priorité.
  
  Il est intéressant de regarder gradle pour avoir un exemple de fichier parsable humainement par des outils, mais puissant.
  
  Ça a l'air intéressant, en effet. Un peu plus puissant que du YAML (ou similaire) mais pas trop complexe. Après, il faut aimer les accolades.
  - [^] # Re: Mes idées
    
    Posté par flan (site web personnel) le 07 avril 2015 à 21:49. Évalué à 3.
    
    pourquoi installer dans /usr/local ? Tu pourrais installer dans ~/.local , qui ne demande pas des droits root.
    - [^] # Re: Mes idées
      
      Posté par rewind (Mastodon) le 07 avril 2015 à 22:04. Évalué à 2.
      
      Chez moi (Debian), installer dans /usr/local ne demande pas les droits root, juste d'être dans le groupe staff (je bénis les développeurs Debian tous les jours pour ce petit truc à la con). Ceci dit, ta remarque est pertinente, on pourrait très bien définir des répertoires d'installation locaux.
      - [^] # Re: Mes idées
        
        Posté par barmic le 07 avril 2015 à 22:27. Évalué à 3.
        
        Ce n'est pas qu'une question de droit, mais simplement de propreté. Si tu fais un premier projet qui demande la bibliothèque A et que tu fais un second projet avec la même bibliothèque si tu utilise les même répertoire tu va devoir dans ton linker faire des ajouts plus compliqués, tu veux pas non plus que la bibliothèque que tu ne connais pas et que tu découvre soit accessible depuis n'importe où sur le système. Tu veux aussi en tant que développeur virer la totalité de ton dépôt (parce qu'il y a un problème ou pour faire des tests) sans pour autant casser la totalité de ton système.
        
        Utiliser ${XDG_DATA_HOME}, c'est une bonne idée.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mes idées
        
        Posté par flan (site web personnel) le 07 avril 2015 à 22:57. Évalué à 2.
        
        Les environnements virtuels de Python sont pas mal, à ce niveau (je parle de Python, mais ça existe probablement dans d'autres langages).
        
        C'est un peu la même idée qu'un chroot, mais limité à Python : la commande python correspondra à la version de Python choisie pour l'environnement virtuel en cours, et seuls les modules de l'environnement virtuel seront visibles.
        Tu peux donc facilement passer d'un venv à l'autre, en choisissant la version de Python et des bibliothèques. Très pratique pour tester !
# souvenir du C

Posté par NeoX le 07 avril 2015 à 21:05. Évalué à 0.
moi j'ai souvenir que quand je crees un projet, je lui dise de quoi j'ai besoin.
on appelait ca un makefile, eventuellement avec un configure.

le makefile decrivait les dependances de mon projet et disait quoi faire pour avoir l'objet manquant.
```
hellomake: hellomake.o hellofunc.o
     gcc -o hellomake hellomake.o hellofunc.o -I.
...
```
donc finalement, toi tu voudrais que ce makefile soit rempli automatiquement ?
c'est pour cela que les developpeurs ont inventé les outils comme "configure" et les autotools,

avec ./configure, ca te dit si tu as ou pas la lib necessaire à la compilation du projet,
il faut juste faire un wrappeur qui telechargerait le paquet manquant,
mais faut-il la version en paquet de la distrib ? la version Y ou Z issue du GIT du developpeur ?
- [^] # Re: souvenir du C
  
  Posté par rewind (Mastodon) le 07 avril 2015 à 21:32. Évalué à 2.
  
  il faut juste faire un wrappeur qui telechargerait le paquet manquant
  
  Si c'était si simple, ça se saurait. En fait, si tu le fais de cette manière, il y a de fortes chances que tu aies un wrappeur pour chaque lib que tu utilises (donc du travail à faire en plus à chaque fois, pour tous les développeurs). Sans compter que pour télécharger un tarball, tu as des outils différents sous Windows et Linux (est-ce que curl existe sous Windows ?), ce qui te fait des dépendances supplémentaires pour ton projet alors que tu voudrais bien qu'un outil unique gère tout ça pour toi.
  - [^] # Re: souvenir du C
    
    Posté par BAud (site web personnel) le 07 avril 2015 à 22:27. Évalué à 2.
    
    est-ce que curl existe sous Windows ?
    
    oui, via MinGW ou Cygwin ;-)
    
    après, c'est plutôt, make sera-t-il disponible ? la compilation aura-t-elle été prévu uniquement avec des chemins relatifs ? (ce qui évite de se poser la question si c'est installé sur C: ou D:…)
  - [^] # Re: souvenir du C
    
    Posté par BAud (site web personnel) le 07 avril 2015 à 22:41. Évalué à 2.
    Concernant le téléchargement des bibliothèques, c'est àmha généralement une mauvaise idée :
    - ce n'est pas au développeur de le gérer :
      
      cela ne résiste pas à l'épreuve du temps (les sites peuvent disparaître, les bibliothèques peuvent monter de version)
      
      et le programme devrait fonctionner avec les nouvelles versions tant que les fonctions utilisées ne sont pas devenues obsolètes)
    - c'est plutôt un README.txt au minimum qui doit identifier les fonctions utiles,
      
      à un programme distinct (humain au besoin) d'identifier quelles bibliothèques y répondent
      
      et comment les rendre disponibles pour la compil'
    - la possibilité de fournir les bibliothèques ou d'exiger une version spécifique de bibliothèque
      
      ne résiste pas aux besoins de sécurité
      
      ni à l'épreuve du temps rendant obsolète une version que le développeur choisirait…
    - c'est l'architecte logiciel qui fixe les versions minimales, en identifiant si possible
      
      les fonctions différenciantes les justifiant,
      
      ce qui peut permettre d'identifier quelles fonctionnalités ne seraient pas disponibles sans ces versions récentes de bibliothèques (parfois c'est un sous-ensemble dont on peut se passer, parfois c'est un pré-requis indispensable)
    désolé pour le style "présentation", mais cela permet de distinguer les points à souligner (et pouvant être approfondis ou détaillés)
    - [^] # Re: souvenir du C
      
      Posté par rewind (Mastodon) le 07 avril 2015 à 23:00. Évalué à 3.
      
      Tout ce que tu décris, c'est tout ce que je fais à la main et que j'aurais envie d'automatiser. Oui, on peut écrire dans un README qu'il faut telle ou telle bibliothèque. Maintenant, si je peux l'écrire dans un fichier de config et que ça va me le chercher tout seul (si ce n'est pas déjà sur le système), ça sera quand même plus facile, ça facilitera les contributions, ça permettra de ne plus faire ces tâches ingrates. Quasiment tous les langages ont ça, quasiment tous les langages ont un dépôt central pour plein de bibliothèques voire toutes les bibliothèques du langage. Tous sauf C++. Je n'ai pas l'impression que ça pose beaucoup de problème dans les autres langages.
      
      Après, pour les gens qui utilisent une version spécifique, ça peut avoir un intérêt. Et ça n'empêche pas de suivre l'évolution des bibliothèques concernées ! Pour moi, ça veut juste dire : avec telle version, ça marche, c'est validé.
      - [^] # Re: souvenir du C
        
        Posté par MCMic (site web personnel) le 08 avril 2015 à 09:15. Évalué à 2.
        
        Maintenant, si je peux l'écrire dans un fichier de config et que ça va me le chercher tout seul (si ce n'est pas déjà sur le système), ça sera quand même plus facile, ça facilitera les contributions, ça permettra de ne plus faire ces tâches ingrates.
        
        Ça s’appelle un PKGBUILD non?
        
        [^] # Re: souvenir du C
        
        Posté par rewind (Mastodon) le 08 avril 2015 à 09:24. Évalué à 2.
        
        Je doute que PKGBUILD soit multi-plateforme…
        
        [^] # Re: souvenir du C
        
        Posté par programLyrique le 08 avril 2015 à 23:53. Évalué à 3.
        
        Je dirais plutôt un ebuild, sous Gentoo.
        
        Une distribution source, ça gère déjà le téléchargement des dépendances.
        
        Je pense qu'on peut se débrouiller pour installer emerge et portage en local, de façon indépendante de la distribution (par exemple sous Debian), et ensuite se faire ses ebuilds.
        
        Pas sûr que ce soit aussi simple sur Windows…
    - [^] # Re: souvenir du C
      
      Posté par flan (site web personnel) le 07 avril 2015 à 23:01. Évalué à 4.
      
      Sinon, on peut faire comme dans (presque) tous les autres langages : un dépôt central (avec la possibilité de rajouter des dépôts secondaires) qui contient les bibliothèques avec les différentes versions.
      Je ne comprends pas le problème de la sécurité… au contraire, ça permet d'automatiser l'ensemble de la procédure (téléchargement, vérification de l'origine via une signature, vérification du téléchargement via un hash sha1).
      Si on doit télécharger à la main sur des dizaines de sites différents, tu auras en pratique beaucoup moins de garantie.
# m a v e n

Posté par pizaninja le 07 avril 2015 à 22:36. Évalué à 1.

Je ne dis pas que c'est à la portée du premier venu mais on peut faire tout ça avec maven et les plugins qui vont bien.

Les paramétrages multi-plateforme peuvent se faire avec les profils maven ou des variables de node jenkins.

Pour les compils multi-plateforme, on peut piloter des VM avec vagrant pour éviter de s'imposer de la cross compilation.

Quand à l'IDE, netbeans est très pratique pour la gestion de maven sans java. Et bien sûr, on peut gérer des projets en C++, java, scala, php, bash, javascript, etc…

De mon point de vue, maven ne signifie pas projet java mais gestion claire du système de dépendances/versions/artefacts.

Je n'invente rien, j'utilise ces solutions au quotidien (devops).
- [^] # Re: m a v e n
  
  Posté par BAud (site web personnel) le 07 avril 2015 à 22:48. Évalué à 2.
  
  Je ne dis pas que c'est à la portée du premier venu
  
  oui, ce serait pas mal que plus de développeurs réclament maven et en comprennent l'utilisation ;-)
  
  j'ai trop souvent vu maven utilisé pour réclamer pléthore de bibliothèques spécifiques, déjà disponibles dans une version supérieure pour la cible… en oubliant ce travail de rendre pérenne leurs développements.
  
  Bon, c'est toujours mieux que les logiciels que j'ai pu voir embarquant dans les binaires pas moins de 3 JVM de 2 en 1.5beta et une 1.5 (iirc), plusieurs arborescences contenant des doublons de bibliothèques (dans des versions différentes, sinon c'est pas drôle) pour traiter le XML…
- [^] # Re: m a v e n
  
  Posté par rewind (Mastodon) le 07 avril 2015 à 22:54. Évalué à -1.
  
  Je l'attendais. Maven ne convient pas parce que C++ a beaucoup de spécificités. En plus, il est quand même plus naturel d'avoir un outil pour C++ codé en C++ (eat your own dog food).
  
  Je me demande quelle tête ferait un dev Java si je lui proposais d'utiliser CMake pour compiler son code…
  - [^] # Re: m a v e n
    
    Posté par barmic le 07 avril 2015 à 23:44. Évalué à 7.
    Maven ne convient pas parce que C++ a beaucoup de spécificités.
    
    C'est quoi les spécificités ? Sachant que jamais make n'a était pensé pour du C++ (ni pour latex, etc).
    
    Ce que tu cherche c'est un système de build avec gestion de dépendance, c'est à dire :
    - une déclaration de dépendance avec téléchargement et installation de dépendance
    - pouvoir produire une série de règles qui dit à partir de quels fichiers faire quoi
    Il y a un tas de projets en C ou C++ qui utilisent (ou utilisaient scons en python).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: m a v e n
    
    Posté par MCMic (site web personnel) le 08 avril 2015 à 09:20. Évalué à 5.
    
    Oui d’ailleurs je pense qu’il faut utiliser un navigateur codé en C++ quand on fait un projet C++, à cause des spécificités. Et un IDE codé en C++, sinon ça n’a pas de sens, etc…
    
    Ya pas de raisons que les outils diffèrent selon le langage de ton programme, et pas de raisons que les outils que tu utilises soient nécessairement codés dans le même langage.
    En plus, un même projet peut utiliser plusieurs langage, et même avoir des dépendances qui ne sont pas du code (thème d’icône par exemple).
    - [^] # Re: m a v e n
      
      Posté par rewind (Mastodon) le 08 avril 2015 à 09:29. Évalué à 1.
      
      Ya pas de raisons que les outils diffèrent selon le langage de ton programme, et pas de raisons que les outils que tu utilises soient nécessairement codés dans le même langage.
      
      Il n'y a pas de raison mais c'est quand même plus crédible non ? Un outil de ce genre qui ne serait pas codé dans le langage qu'il est censé gérer, ça fait pas très crédible à mon sens. Et quand on regarde les autres langages, ils ont quasiment tous des outils codés dans le langage lui-même pour gérer ce genre de choses (Java, Python, Ruby, Go, même PHP). Pourquoi le C++ n'aurait pas droit à un outil dédié codé en C++ ?
      - [^] # Re: m a v e n
        
        Posté par MCMic (site web personnel) le 08 avril 2015 à 09:34. Évalué à 6.
        
        Un gestionnaire de dépendances qui ne gère qu’un seul langage, c’est ça que je trouve pas très crédible…
        
        [^] # Re: m a v e n
        
        Posté par rewind (Mastodon) le 09 avril 2015 à 13:50. Évalué à 3.
        
        Java a Maven écrit en Java
        
        PHP a composer écrit en PHP
        
        Ruby a gem (ou Bundler) écrit en Ruby
        
        Python a pip (ou SetupTools) écrit en Python
        
        Rust a Cargo écrit en Rust
        
        Node.js a NPM écrit en Javascript
        
        .NET a NuGet écrit en C#
        
        Lua a LuaRocks écrit en Lua
        
        Haskell a Cabal écrit en Haskell
        
        Go a Go Get écrit en Go
        
        …
        
        Je continue (j'en ai encore quelques uns) ou c'est bon ? Tu vas m'expliquer que tous ces développeurs ne sont que des neuneus et qu'ils ont tous implémentés un gestionnaire de dépendance pour leur langage dans leur langage mais qu'ils ont tous eu tort et qu'ils auraient dû n'avoir qu'un seul outil ? Et bien, personnellement, je préfère être du côté de tous ces braves idiots et considérer qu'un outil en C++ pour gérer du C++, c'est juste du bon sens.
        
        Après, peut-être que certains de ces outils gèrent autre chose que leur propre langage, mais c'est quand même pas la norme hein… et ce n'est pas l'utilisation réelle qu'en font les développeurs. Peut-être aussi parce que la plupart des dev n'ont pas envie d'avoir une deuxième pile logicielle pour gérer les dépendances.
        
        [^] # Re: m a v e n
        
        Posté par barmic le 09 avril 2015 à 18:17. Évalué à 5.
        
        Ce que tout le monde dis, c'est qu'on s'en fout du langage. Tu t'interdit un outil avec pour principal voir seul prétexte, il n'est pas dans mon langage c'est pas sérieux. Alors que tout le monde s'en fout.
        
        AMHA il vaut mieux avoir un outil qui tourne sur nodejs que pas d'outils du tout, mais après c'est toi qui vois.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: m a v e n
        
        Posté par rewind (Mastodon) le 09 avril 2015 à 18:42. Évalué à 2.
        
        Ce que tout le monde dis, c'est qu'on s'en fout du langage. Tu t'interdit un outil avec pour principal voir seul prétexte, il n'est pas dans mon langage c'est pas sérieux. Alors que tout le monde s'en fout.
        
        On s'en fout du langage mais quand même personne n'utilise un outil d'un autre langage.
        
        L'argumentaire de Firwen dans l'autre journal n'a pas eu l'air de te convaincre non plus donc, je ne vais même pas essayer d'aller plus loin. Je pense qu'on a des points de vue différent sur la question et que ça ne sert à rien de redire encore et encore les mêmes choses.
        
        AMHA il vaut mieux avoir un outil qui tourne sur nodejs que pas d'outils du tout, mais après c'est toi qui vois.
        
        Pour l'instant, le choix, il est entre rien du tout et rien du tout surtout.
      - [^] # Re: m a v e n
        
        Posté par flan (site web personnel) le 08 avril 2015 à 10:56. Évalué à 2.
        
        En effet, Scala a un truc codé en Scala (SBT)… et j'aimerais bien qu'il soit codé dans un autre langage. Je pense de plus en plus à refaire quelque chose en Python pour mes propres besoins (je trouve qu'avoir 1 min de lancement pour quelques secondes de compilation est insupportable).
      - [^] # Re: m a v e n
        
        Posté par barmic le 08 avril 2015 à 13:39. Évalué à 4.
        
        Il n'y a pas de raison mais c'est quand même plus crédible non ?
        
        Bof, tu t'offusque du fait d'utiliser un compilateur C++ qui ne soit pas écris en C++ (parce que gcc est passé en c++, il n'y a pas longtemps).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: m a v e n
        
        Posté par pasBill pasGates le 09 avril 2015 à 00:32. Évalué à 2.
        
        Tu penses que la JVM d'Oracle est écrite en Java ?
        Tu penses que la CLR de .NET est écrite en C# ?
        Tu penses que le VM Javascript de ton browser est écrite en Javascript ?
        
        Non la crédibilité n'a absolument rien à voir. Les langages ont tous des avantages et inconvénients, et lorsque tu as un projet à développer, on va dire un outil CMake par exemple, ben tu utilises le langage approprié pour accomplir la tâche de la manière la plus efficace(signifiant un mix de performance, maintenabilité, vitesse de développement, securité, … selon les cas), tu ne te mets pas à choisir le langage pour des raisons futiles.
        
        [^] # Re: m a v e n
        
        Posté par rewind (Mastodon) le 09 avril 2015 à 13:51. Évalué à 2. Dernière modification le 09 avril 2015 à 13:52.
        
        On parle de gestionnaire de dépendances là, pas de machine virtuelle… Je t'invite à lire la liste plus haut et à m'expliquer pourquoi tous les dev dans tous les langages choisissent le dit langage pour implémenter un gestionnaire de dépendance, ça m'intéresse.
        
        [^] # Re: m a v e n
        
        Posté par pasBill pasGates le 09 avril 2015 à 21:00. Évalué à 1.
        
        Parce que c'est leur langage préféré ? Parce que cela évite d'ajouter des dépendances dans certains cas ? Parce que le framework du langage leur amène des facilités techniques (genre lire un .jar en Java est simple, en C++ ça l'est moins) dans certains cas ?
        
        Tu remarqueras que pour C++, la 1ere raison n'est de toute façon pas une raison mais une préférence, et la 2ème et 3ème sont des raisons techniques. Tu prends un langage comme Perl, Prolog ou VBScript par contre, les 2 raisons techniques disparaissent.
        
        Ensuite, VM ou outil de gestion de dépendance ou jeu de strip-poker ça ne change rien. C'est un projet software au final, tu as la même approche : tu as un objectif, des contraintes, tu fais une évaluation et tu suis cela.
      - [^] # Re: m a v e n
        
        Posté par cfx le 09 avril 2015 à 19:50. Évalué à 1.
        
        Je ne pense pas que ce soit une question de crédibilité, c'est juste que si tu es développeur Ruby/Python/Js/… et que tu as besoin d'un outil pour t'aider au quotidien à faire du Ruby/Python/Js/…, il y a de grandes chances que tu choisisses de le développer dans le langage que tu maîtrises le plus.
        
        Il y a un coté pratique/logique, mais rien ne garanti que cela aboutisse à la solution la plus adaptée. Chaque langage à ses forces et ses faiblesses, et pour écrire un gestionnaire de dépendances pour le langage X, le langage Y sera peut-être plus adapté. En particulier si le langage X est le C++, j'ai en tête un tas de choses qui sont relativement pénibles à implémenter en C++ alors qu'elles peuvent être pliées en quelques lignes de n'importe quel langage de script.
# YOCTO

Posté par Tangi Colin le 08 avril 2015 à 20:23. Évalué à 1.
Yocto (ou pour etre précis bitbake et openembedded) permet déjà de répondre à tout tes problèmes :

Multi-plateformes (x86,arm,powerpc …) et multi-build système (make,autotools,scons,cmake…)
Gestion des dépendances (à la compilation et au runtime)
Multi-fetcher (git,svn,tarball,mercurial …)
Facile à modifier, étendre (patch et via layer)
Système de cache (ne rebuild que ce qu'il faut)
Système de package (rmp, deb ou opkg)
Il peut auto-construire ça propre toolchain
Peut exporté un SDK (Software development Kit)

Honnêtement, l'essayer c'est l'adopter. Y a juste deux bémol :
- La taille (on arrive vite à plusieurs Go (entre les sources, le cache)
- N'est pas vraiment pensé pour une développement en mode "agile". (Sauf si tu gère la partie fetch toit meme (avec repo android tools par example ) et en utilisant la classe externalsrc).
- [^] # Re: YOCTO
  
  Posté par rewind (Mastodon) le 09 avril 2015 à 14:26. Évalué à 2.
  
  Ça n'a pas l'air de gérer Windows en dehors de MingW. Je me trompe ?
  - [^] # Re: YOCTO
    
    Posté par BAud (site web personnel) le 10 avril 2015 à 21:42. Évalué à 2.
    
    il faut bien être en mesure de contourner les limitations de windows, non ? autant utiliser des outils efficaces, eux.
# Il existe qibuild !

Posté par alkino le 09 avril 2015 à 08:40. Évalué à 7.

Dans mon entreprise on a exactement ce genre de problématique (170 repos c++, plus des dépendances externes).

Du coup on a développé notre propre outil : https://github.com/aldebaran/qibuild La documentation est complète et à jour : http://doc.aldebaran.com/qibuild/index.html C'est sous license BSD.

C'est multi-platform : linux, windows, mac. C'est intégré (de manière simple) à des IDE, ça marche avec qtCreator et VS. Ça supporte la code review avec gerrit de manière quasi-transparente.

Nous n'imposons pas une organisation des sources par contre.

Pour la simplicité d'utilisation, mon avis est par contre biaisé. Je ne me rends sans doute pas compte de la difficulté mais ça m'as l'air simple.

L'outil est basé sur cmake et git. Il y a un fichier central (manifest.xml) où sont listés tous les repos. Et dans chaque repos il y a besoin d'ajouter un petit fichier tout simple (qiproject.xml) qui "explique" les dépendances.

Un exemple de qiproject.xml : https://github.com/aldebaran/libqi/blob/master/qiproject.xml
Un exemple de manifest.xml : https://github.com/aldebaran/manifest/blob/master/manifest.xml

N'hésitez pas à nous faire des retours ou nous demander de l'aide si besoin \o/ Le développement est assez actif.
- [^] # Re: Il existe qibuild !
  
  Posté par rewind (Mastodon) le 09 avril 2015 à 14:40. Évalué à 2.
  
  Ça a l'air intéressant. Comme je le vois, c'est une sorte de surcouche à CMake pour automatiser un peu plus les tâches de gestion de dépendances. Du coup, c'est assez invasif je trouve (par exemple, commandes à utiliser à la place des commandes habituelles).
  - [^] # Re: Il existe qibuild !
    
    Posté par Phlogistique le 10 avril 2015 à 14:56. Évalué à 1.
    En fait, oui et non. Il faut voir ça en deux parties:
    - d'une part il y a une bibliothèque de fonctions CMake qui permet de rendre plus facile l'écriture de CMakeList.txt. Une fois le build system CMake créé, il est utilisable avec les commandes habituelles (cmake && make)
    - d'autre part il y a des outils (écrits en Python) qui font une gestion des dépendances à proprement parler; il faut plutôt les comparer à gem/pip/cabal qu'à cmake/scons/autotools.
    - [^] # Re: Il existe qibuild !
      
      Posté par rewind (Mastodon) le 10 avril 2015 à 15:08. Évalué à 2.
      
      Oui mais est-ce qu'avec un tel système, tu n'es pas obligé de déclarer deux fois tes dépendances : une fois dans CMake et une fois dans tes fichiers de dépendances ?
      - [^] # Re: Il existe qibuild !
        
        Posté par cctaf le 10 avril 2015 à 15:52. Évalué à 1.
        
        Si et c'est un peu dommage.
        
        Dans qiBuild tu definis les dependances entre tes projets. (un projet inclut plusieurs target (binaire, library).
        
        Dans CMake tu definis les dependances entre tes targets. (ils trouvent les targets en cherchant dans les projets definis par qiBuild).
- [^] # Re: Il existe qibuild !
  
  Posté par robin le 09 avril 2015 à 14:40. Évalué à 1.
  
  Merci pour le pointeur, je vais aller regarder.
  
  Un question préalable : est ce que ce gestionnaire est capable de gérer les dépendances déjà décrit en c++ avec les includes ? C'est quelque chose que je trouve pénible avec make, si on veux un makefile simple, il me semble que l'on ait obligé de réécrire toutes ces dépendances à la main, et c'est vite fastidieux.
  
  bépo powered
  - [^] # Re: Il existe qibuild !
    
    Posté par Dimitri Merejkowsky (site web personnel) le 10 avril 2015 à 11:07. Évalué à 2.
    est ce que ce gestionnaire est capable de gérer les dépendances déjà décrit en c++ avec les includes ?
    
    Je comprends pas bien la question. Pour utiliser une librarie tierce en qibuild, le mieux c'est d'en faire un paquet binaire qu'on ajoute à une toolchain. Voir ici:
    http://doc.aldebaran.lan/doc/next/qibuild/beginner/qitoolchain/tutorial.html
    
    En gros y a juste un fichier cmake à écrire qui a cette tête la:
```
set(_root "${CMAKE_CURRENT_LIST_DIR}/../../..")
get_filename_component(_root ${_root} ABSOLUTE)

set(FOO_LIBRARIES
  ${_root}/lib/libfoo.so
  CACHE INTERNAL "" FORCE
)

set(FOO_INCLUDE_DIRS
  ${_root}/include
  CACHE INTERNAL "" FORCE
)

# qi_persistent_set(FOO_DEPENDS "BAR")
export_lib(FOO)
```
    - [^] # Re: Il existe qibuild !
      
      Posté par robin le 10 avril 2015 à 11:59. Évalué à 1.
      Je crois qu'on s'est mal compris. Le plus simple est un exemple :
      
      // a.c #include "a.h" // ...
      
      // a.h // ...
      
      // b.c #include "b.h" // ...
      
      // b.h #include "a.h" // ...
      
      On a donc le graph de dépendance suivant
      
      * a.h |\ | * a.c * b.h * b.c
      
      sauf erreur de ma part, dans un makefile, on aura donc
      
      a.o: a.c a.h › $(CC) $(CFLAGS) -o $@ -c $< b.o: b.c b.h a.h › $(CC) $(CFLAGS) -o $@ -c $<
      
      On peut éliminer la première règle avec (qui est particulièrement illisible)
      
      %.o: %.c %.h › $(CC) $(CFLAGS) -o $@ -c $<
      
      Par contre, je n'ai pas trouvé le moyen d'éviter la deuxième ligne
      
      bépo powered
      - [^] # Re: Il existe qibuild !
        
        Posté par Dimitri Merejkowsky (site web personnel) le 10 avril 2015 à 13:03. Évalué à 3.
        
        CMake gère ça de base. Quand tu fais un include_directories() il va rajouter une dépendance vers les headers.
        Il va aussi utiliser gcc -M pour se rendre compte que b.c dépend de a.h
        
        [^] # Re: Il existe qibuild !
        
        Posté par robin le 10 avril 2015 à 15:25. Évalué à 1.
        
        cool, merci de l'info
        
        bépo powered
- [^] # Re: Il existe qibuild !
  
  Posté par zul (site web personnel) le 09 avril 2015 à 19:32. Évalué à 2.
  
  Ça a l'air de beaucoup ressembler à catkin http://wiki.ros.org/catkin/conceptual_overview, dans le même domaine d'application (la robotique).
  Sinon une autre option, toujours dans la robotique, c'est autoproj http://rock-robotics.org/stable/documentation/autoproj/.
  
  Bref, des gestionnaires de paquets sources plus ou moins souples, avec plus ou moins de trucs déjà "packagés".
  - [^] # Re: Il existe qibuild !
    
    Posté par Dimitri Merejkowsky (site web personnel) le 10 avril 2015 à 10:58. Évalué à 3.
    
    Effectivement qibuild et catkin ont beaucoup de points communs. Voici de la documentation expliquant les différences:
    http://doc.aldebaran.com/qibuild/beginner/qibuild/other/ros.html
    
    La principale force de qibuild est qu'il est distro-agnostique (on peut utiliser des paquets précompilés sur n'importe quelle distro), et qu'il a un vrai support de Mac et Windows (y compris Visual Studio)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.