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 Thomas Douillard . É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 Chuck #1 . É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 rvlander . Évalué à 1.
Tout est dans le titre.
[^] # Re: Sinon il a nix+autotools et ça marche très bien
Posté par rewind (Mastodon) . Évalué à 4.
S'il n'y avait que nix à gérer, ça serait merveilleux, on a déjà des systèmes de paquets qui permettent d'installer tout ce qu'il faut en une commande. Mais il y a l'autre machin là…
# Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par MCMic (site web personnel) . Évalué à 3.
Ou pas :-)
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par barmic . É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 :
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 MyLordAngus . É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 devnewton 🍺 (site web personnel) . Évalué à 1.
Docker n'est pas utilisable pour des applis graphiques il me semble.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Tangi Colin . Évalué à 1.
Docker fonctionne très bien avec des applis graphique, vu juste pensé à "binder" la socket Xorg du "host" au lancement de son conteneur.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Pierrick Bouvier . É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 rewind (Mastodon) . É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 Pierrick Bouvier . Évalué à 1. Dernière modification le 07 janvier 2016 à 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 rewind (Mastodon) . Évalué à 4.
Le problème du compilo de MS, c'est qu'il est très à la traîne sur la gestion des standards. Ils en sont même à prendre le front-end de clang et leur backend (mots-clefs: Clang + C2). Bref, je suis d'accord avec toi, ça sera sans doute une bonne chose d'avoir un clang-cl.exe.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par barmic . Évalué à 3.
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.
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 MCMic (site web personnel) . É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 barmic . Évalué à 3.
Ce qui marche quand tu travail pour toi. Quand tu dois collaborer c'est moins drôle, quand tu multiplie les projets aussi.
Tu m'a vu dire ça quelque part ? Je dis juste que ce genre d'outil est très utile.
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.
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 pizaninja . É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…
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par rewind (Mastodon) . Évalué à 2.
tu as de la doc sur tout ça ?
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par pizaninja . Évalué à 3. Dernière modification le 09 janvier 2016 à 08:56.
Non, je garde tout ça pour moi, pour me "créer de la valeur" comme disent nos amis de la finance…
Plus sérieusement, je suis tout à fait disposé à partager ce savoir. Mais où? Wikipedia? Un journal linuxfr? Ma page facebook (non, je déconne, pas facebook, j'ai pas d'amis)?
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par barmic . Évalué à 3.
Ce dont parle Pierrick est au delà de ça. Il parle de vrai reproductibilité. Donc il faut valider qu'il n'y a pas des bibliothèques système en trop dans ton environnement, quelles sont les variables d'environnements, les versions de tous les outils de ta toolchain, etc
Maven peux le faire il est turing complete, mais c'est vraiment tordre l'outil, le lancer en tant que root, etc.
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 pizaninja . Évalué à 1.
Ben heu… "tordre l'outil", je ne sais pas…
Si c'est vraiment lié à tout un OS et un environnement, je preconiserais d'utiliser des VMs à base de vagrant et d'ansible…
# Crom!
Posté par devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Business model
Posté par Ignatz Ledebur . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.