Journal Adieu Biicode, bonjour Conan

Posté par . Licence CC by-sa
Tags :
10
6
jan.
2016

Biicode était un gestionnaire de dépendances pour C/C++ et quelques autres trucs. La boîte qui était derrière a fermé faute d'avoir trouvé un business model adéquat. On en avait parlé ici.

Et bien, voici maintenant Conan. C'est exactement la même chose, avec la même personne (90% des commits) sauf que c'est bleu à la place d'être jaune. Ça a été lancé il y a un mois et donc, l'auteur principal nous fait un premier bilan. Entre la méthode coué et l'appel de détresse, c'est presque touchant.

Selon lui, c'est super bien parti ! On a parlé de lui sur deux blogs. Puis il répond à une série de remarques qui lui ont été faites. Tout d'abord savoir qui se cache derrière, s'il y a une entreprise. Réponse : non. C'est juste un gars seul dans son garage qui est à fond pour le libre. Mais comme tout le monde a besoin de manger, il cherche un business model (again) et pense adopter un truc comme github. Après, il veut devenir le centre du monde C/C++. Et enfin, l'auteur a déjà packagé des centaines de bibliothèques ! Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++ (c'est vrai !) donc Conan est ce qu'il vous faut (hu ?).

  • # Déjà, on parle encore de lui, spa mal !

    Posté par . Évalué à 3.

    La devise shadok Plus ça rate et plus on a de chances que ça marche a des chances de marcher du coup. On peut lui reconnaître un certain sens de la persévérance, ce qui n'est pas forcément inutile pour faire prendre un projet.

  • # Il recommence ?

    Posté par . Évalué à 5.

    Et avec un nom pareil ? Le barbare !

    Cette signature est publiée sous licence WTFPL

  • # Sinon il a nix+autotools et ça marche très bien

    Posté par . Évalué à 1.

    Tout est dans le titre.

  • # Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

    Posté par (page perso) . Évalué à 3.

    (c'est vrai !)

    Ou pas :-)

    • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

      Posté par . Évalué à 4.

      Tu fais comment pour travailler sur la version n de ton logiciel qui dépend de libA en version 2 et sur la version n+1 qui dépend, elle de la version 3 de libA ? Ta distribution distribution ne proposant que la version 1 de cette lib ?

      Question subsidiaire être capable le plus facilement possible de :

      • pour l'arrivée d'un nouveau dans l'équipe simplifier la mise en place de son environnement
      • connaître toutes les lib que l'on a d'installer dans chaque version
      • pouvoir supprimer/réinstaller ces lib sans y passer la journée
      • n'avoir rien à modifier dans les sources pour que toi sur Slackware, ton autre collègue sur OSX et encore un autre sur windows

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

        Posté par . Évalué à 1.

        Une solution pourrait être d'utiliser des conteneurs pour chaque nouvel environnement de développement. Un outil comme lxc est suffisamment léger pour cela. C'est le seul moyen que je connaisse pour être à peu près sûr des dépendances tirées par une application.

        Il y a aussi des alternatives à lxc, que je n'ai jamais utilisé, comme docker ou systemd-spawn. Voire même un outil comme schroot qui doit permettre d'utiliser plusieurs environnement de chroot de manière aisée.

      • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

        Posté par . Évalué à 3.

        C'est une problématique très intéressante que tu soulèves ici.

        Malheureusement, les gens soucieux de ces problèmes se soucient en général simplement des versions de librairies utilisées (que ce soit en C/C++ ou même d'autres langages). Alors qu'en pratique, ton compilateur et tous les outils de ta toolchain sont aussi importants. Pour moi la reproductibilité implique de recréer le même binaire au bit près, pas de s'assurer des dépendances sur des librairies.

        Dans ma dernière expérience professionnelle sur le sujet, j'avais mis en place une forme de conteneur léger (à coup de chroot) basée sur debian testing, avec génération automatique chaque semaine ou quand besoin d'une nouvelle lib/version de compilo. Le tout rapatrié avec rsync via ssh. Sinon possib de monter tout le bouzin via NFS mais c'était trop chiant en infra pour nous. Ça offrait une belle portabilité peu importe la distribution linux utilisée par les collègues (et simplifie l'intégration continue accessoirement). Quant à l'arrivée d'un nouveau, il suffit de faire: git clone && get_env.sh && make. Simple et efficace au possible. Il me restait, mais je ne l'ai pas fait, à "versionner" cet environnement de build (qui est une chose très importante aussi). Pour cela, un montage BtrFS avec snapshots permet de faire un stockage incrémental (on ne stocke que les diffs) et adapté. Reste à ajouter un hash quelque part et pointer sur le bon dans ton code, et tu as un environnement de build complètement déterministe, mais pour Linux uniquement. Un jour si je me motive, faudrait que je package et publie le tout, je suis sûr que ça pourrait attirer du monde. Bien plus qu'une solution bricolage comme Biicode (c'est mon humble avis).

        Il reste le problème de la cross compilation. MacOS ne m'intéresse pas d'un iota. Pour les BSDs un cross compilo fait le taff. Quant à Windows, soit tu peux cross compiler un gcc, soit, une autre approche que j'avais tenté sur mon temps libre, c'est d'utiliser le compilo de visual (cl.exe) via wine (et pas visual lui même). Ça fonctionne rudement bien (modulo des variables d'env à setter) et si je devais m'occuper de ça un jour, ce serait ma voie d'approche. Avec le wine dans l'env de build décrit au-dessus, tu obtiens une solution déterministe pour le build Linux/Windows depuis toute version/distrib de Linux.

        Une fois cela fait, un travail important reste de packager toi-même toutes les librairies dont tu dépends. Chez nous, on s'en était assez facilement sorti avec un peu de script.

        Cette façon d'approcher, reste, je pense, la plus simple et efficace. Des collègues plutôt orientés Java m'ont montré Nexus et le concept d'artifact repository. Pour moi, ça revient à de la gestion de libs, le tout dans une belle usine à gaz webistique. J'imagine que ça dépend des goûts de chacun, moi je n'ai pas accroché en tout cas…

        • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

          Posté par . Évalué à 4.

          Pour cl.exe, il y a clang qui est en train de faire un clang-cl.exe qui pourrait remplacer le cl.exe original (avec les mêmes options et tout). Je crois qu'ils ont encore quelques soucis avec les exceptions côté génération de code mais globalement, ils sont proches d'y arriver.

          • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

            Posté par . Évalué à 1. Dernière modification le 07/01/16 à 15:15.

            Je suis ce développement de très près qui permettrait enfin de s'affranchir de visual pour compiler sérieusement des projets sous windows. Reste à voir si les perfs suivront (comme souvent avec clang). De ce côté, le compilateur de Microsoft se débrouille plutôt très bien, malgré de nombreux autres défauts.

        • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

          Posté par . Évalué à 3.

          Malheureusement, les gens soucieux de ces problèmes se soucient en général simplement des versions de librairies utilisées (que ce soit en C/C++ ou même d'autres langages). Alors qu'en pratique, ton compilateur et tous les outils de ta toolchain sont aussi importants. Pour moi la reproductibilité implique de recréer le même binaire au bit près, pas de s'assurer des dépendances sur des librairies.

          Mais il y a des choses qui existent tout de même. J'ai par exemple vu des gens qui font construire leur logiciels par jenkins, qui lance une image docker pour chaque build. Modulo la confiance que tu as dans la contenerisation de linux, tu as un environnement totalement propre et totalement maîtrisé pour la construction de ton soft.

          Il me restait, mais je ne l'ai pas fait, à "versionner" cet environnement de build (qui est une chose très importante aussi).

          C'est de base dans docker :)

          Je ne sais pas comment tu gère avec LXC, mais docker permet d'avoir un serveur où tu peux pousser et tirer des images. Ça permet en une seule commande de tirer puis démarrer ton image avec juste docker d'installé.

          Pour le reste je suis d'accord avec toi.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

        Posté par (page perso) . Évalué à 4.

        D’une part, je n’ai jamais ressenti ce besoin quand j’ai développé des choses en C++, je fonctionnais avec le gestionnaire de paquet de ma distrib et ça marche bien.

        D’autre part, tout ceci ne nous dit pas pourquoi l’outil pour le C++ devrait être codé en C++, celui pour le PHP en PHP, celui pour le python en python…
        Il y a une multiplication des efforts complètement ridicule sur ces sujets.

        Et ça suppose du coup qu’un projet n’a des dépendances que dans un seul langage non?
        Ça marche comment si mon projet python utilise une lib en C et un outil en perl, je dois manipuler 3 gestionnaires de dépendance pour m’en sortir?

        • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

          Posté par . Évalué à 3.

          D’une part, je n’ai jamais ressenti ce besoin quand j’ai développé des choses en C++, je fonctionnais avec le gestionnaire de paquet de ma distrib et ça marche bien.

          Ce qui marche quand tu travail pour toi. Quand tu dois collaborer c'est moins drôle, quand tu multiplie les projets aussi.

          D’autre part, tout ceci ne nous dit pas pourquoi l’outil pour le C++ devrait être codé en C++, celui pour le PHP en PHP, celui pour le python en python…

          Tu m'a vu dire ça quelque part ? Je dis juste que ce genre d'outil est très utile.

          Il y a une multiplication des efforts complètement ridicule sur ces sujets.

          Parfaitement et, comme je l'ai déjà fais, je recommande vivement d'aller regarder les outils existants, notamment dans le monde Java (au sens JVM) qui est très fleuris et certains autres outils comme virtualenv de python.

          Et ça suppose du coup qu’un projet n’a des dépendances que dans un seul langage non?
          Ça marche comment si mon projet python utilise une lib en C et un outil en perl, je dois manipuler 3 gestionnaires de dépendance pour m’en sortir?

          Je te dirais que les bons sont suffisamment souples pour ce genre de cas. Sachant que multiplier les dépendances n'est pas une bonne pratique non plus.

          Dans le cas extrême, ce que tu va chercher à faire, c'est à créer un environnement complet pour ton logiciel et pour ça tu peux utiliser lxc/docker (avec un outil de gestion de configuration) ou vagran.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++

            Posté par . Évalué à 1.

            Aussi tordu que ça puisse paraître pour certains, maven permet de résoudre les pbs de dépendances quelques soient le langage (à compiler), C++ compris.

            Pour la compilation et opérations associées:
            - utilisation du plugin de compilation native (vc++, gcc, etc…)
            - appel à make
            - appel à qmake (pour projets Qt)
            - exécution de scripts
            - etc…

            L'assemblage final repose sur des artefacts, qui peuvent être aux formats suivants:
            - .so/.dll/.dylib
            - .exe
            - .tar.gz/zip
            - .rpm/.deb/.msi/.app
            - etc…

            Pour la distinction de plateformes:
            - distinction des tâches à exécuter par utilisation de profiles
            - distinction des assemblages produits (artefact) par utilisation de 'classifier'

            C'est tordu pour certain mais perso, ça m'a permis:
            - de proposer des solutions que l'équipe de dév de C++ que j'ai rejoinds ne parvenait pas à trouver dans le monde du C++;
            - de décrocher un job de DevOps.

            J'imagine qu'on doit peut-être pouvoir faire des choses équivalentes avec npm…

  • # Crom!

    Posté par (page perso) . Évalué à 3.

    J'attendais ça depuis la chute des fils d'Arius!

    Par contre ça n'a pas l'air encore très au point.

    pas cool

    http://devnewton.bci.im

  • # Business model

    Posté par . Évalué à 3.

    Écraser ses ennemis, les voir mourir devant soi, et entendre les lamentations de leurs femmes. (?)

Suivre le flux des commentaires

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