Bonjour Nal,
Je suis fortuitement tombé sur biicode, un gestionnaire de dépendance c++ peut-être bientôt open source.
Il s'appuie sur CMake pour construire les projets et permet de déclarer ses dépendances dans un flat file à la manière d'un pip.
Pourquoi ça me semble intéressant?
- Parce que j'ai toujours trouvé délicat de gérer les dépendances en c++. Attention je ne suis pas un pro du c++ et il est très probable que je fais "pas comme y' faut". Écrire un module find pour cmake, c'est pas drôle. Biicode promet de simplifier tout ça, j'espère pouvoir le tester prochainement.
- Mais surtout biicode pourrait devenir open-source! Les auteurs ont l'air convaincus de l'intérêt du modèle open source et leurs investisseurs sont prêts à suivre si jamais ils atteignent la barre des 10000 utilisateurs. Voir l'annonce sur leur blog pour plus de détails.
Je trouve la tentative de passer en open source louable. Au delà de ça, je ne suis pas le mieux placé pour juger de la pertinence de l'outil. À mes yeux de néophyte ça semble intéressant mais qu'en disent les pros du milieu?
Par ailleurs je suis un peu surpris que leur appel à utilisateurs lancé en octobre 2014 n'ai rassemblé que 3033 utilisateurs à ce jour.
Bref un truc de plus dans ma todo-test-list.
PS: Leur logo est une abeille, rapport au jeu de mot bii - bee, mais ils proposent de gagner un t-shirt Dark-Vador qui a quand même vachement plus de gueule.
# Des promesses...
Posté par rewind (Mastodon) . Évalué à 10.
L'annonce date du 20 octobre 2014 et ils n'ont toujours pas passé la barre des 10000. On peut même dire qu'ils stagnent franchement. Et ils ont eu un article sur LWN et des articles sur d'autres médias avec une audience large comme le blog isocpp.org où il n'y a pas que des libristes échevelés. Et malgré tout ça, toujours pas l'ombre d'un début de bout de code ouvert et toujours pas 10000 utilisateurs.
Et même s'il était ouvert, le principal inconvénient de ce projet est qu'il force à changer les includes par rapport aux includes normaux, c'est-à-dire ceux qui sont dans la doc. Et ça, pour moi, c'est un énorme frein. Je n'ai pas envie de changer mes includes pour me lier à un outil particulier, je veux utiliser les includes qui sont dans la doc, comme tout le monde. Je ne sais pas si c'est ça qui freine les gens mais en tout cas, pour moi, c'est rédhibitoire.
Et puis, il me semble qu'ils essaient un peu de tout faire, notamment ils essaient de gérer plusieurs langages. C'est complètement idiot parce que C++ est déjà suffisamment complexe, et les autres langages ont parfois leur propre gestionnaire et n'ont pas besoin d'un outil supplémentaire.
Enfin, ils disent clairement qu'ils ne sont pas maîtres du développement, ils ont des investisseurs qui ne semblent pas comprendre grand chose à l'éco-système. Du coup, même si c'était ouvert, rien ne dit que ça irait dans une bonne direction, celle souhaitée par la communauté et pas celle souhaitée par les investisseurs.
Donc, je n'ai toujours pas de baril mais je ne vais certainement pas acheter celui-ci !
[^] # Re: Des promesses...
Posté par Firwen (site web personnel) . Évalué à 6. Dernière modification le 19 mars 2015 à 13:54.
Pareillement,
L'idée est intéressante. Je rêve d'un système de dépendance en C++ à la Go ou la homebrew qui télécharge / compile directement l'arborescence de toute projet en utilisant GitHub ou similaire.
Le projet le semble beaucoup moins.
A mon humble avis, un nouveau projet pour outil de développement, en 2015, qui n'est pas open source, encore moins libre…. est un projet qui va droit dans le mur.
Je n'ai aucune envie de lier la compilation de mes projets avec un outil que:
On parle d'un soft qui peut avoir un rôle centrale pour la durée de vie d'un logiciel là…. pas d'un jouet pour enfant.
[^] # Re: Des promesses...
Posté par pizaninja . Évalué à 3.
Maven?
Oui, au risque de passer pour un extra-terrestre, maven fonctionne très bien pour la gestion de dépendance avec suivi de version.
Et ça peut fonctionner pour n'importe quel langage source.
Certe, le coût de prise en main est assez élevé, mais comme tous les autres outils de gestion de dépendances.
Retour d'XP d'un devops (moi):
- Maven est libre d'utilisation
- Il permet de gérer des compilations avec gcc, msvc et même bcc.
- Et tout ce qui n'est pas déjà géré par un plugin maven peut être lancé avec ant ou par lancement de commande shell ou dos.
- Et ça marche en multi environnement (multiOS) et avec jenkins, vagrant, etc…
[^] # Re: Des promesses...
Posté par rewind (Mastodon) . Évalué à 2.
Je suis partisan d'utiliser un outil C++ pour gérer du C++. Eat your own dog food comme on dit. Et puis, il y a tellement de cas tordus à gérer en C/C++ que ça vaut le coup de développer un outil spécifique au C/C++.
[^] # Re: Des promesses...
Posté par Firwen (site web personnel) . Évalué à 1.
Maven a été designé pour Java.
Si j'étais d'humeur à troller, je dirais que même pour Java il a déja quelques problèmes ( c'est Vendredi)
Il n'est pas adapté au dev C++, même si il peut le faire pour des raisons évidentes.
Dans un environment C++, l'architecture, la taille des registres, la gestions des instructions de vectorisations (SSE…), le compilateur, la plate-forme sont des paramètres bien plus cruciaux que dans un environnent Java.
Maven n'a jamais réellement été développé avec ces problèmes en tête.
Sans même parler qu'installer une JVM de 200Mo pour compiler un programme de 20ko est propablement pas la manière la plus optimale de faire la chose.
[^] # Re: Des promesses...
Posté par pizaninja . Évalué à 2.
Oué, ça troll dure.
Ce que je dis, c'est que j'ai plusieurs fois prouvé par la pratique que ça marchait et qu'une fois en place, c'était un vrai bonheur pour la gestion des dépendances et les évolutions de versions.
Quand à comparer la taille d'une JVM (tu as pris une taille de JDK apparemment), à celle d'un programme de 20ko…
Tu développes tes programmes sur un arduino quand ta cible est un arduino?
Est-ce que tu compares la taille que prends ton compilateur gcc et toutes les libs système que tu utilises avec la taille de ton programme?
Imagine si les dev sous windows s'amusaient à comparer la taille d'une installation de MSVC + tous les composants .NET nécessaires à la taille de leur programme…
Et qu'en est-il de la taille que ta distrib linux prend sur ton disque comparé à la taille de ton programme?
[^] # Re: Des promesses...
Posté par rewind (Mastodon) . Évalué à 1.
Il y a une différence entre "ça marche" et "c'est adapté". Maven marche peut-être, mais n'est clairement pas adapté pour la fonction. Dans beaucoup de langages, il y a une gestion des dépendances qui est faite avec un outil codé dans le langage lui-même… sauf en C/C++. Laisse-nous espérer qu'un jour ça arrive et que ce soit un peu plus adapté que Maven pour la tâche. Parce que le commentaire parent donne plein de raisons pour lesquels Maven n'est pas adapté mais tu n'y réponds pas, tu prétends uniquement que chez toi, ça marche.
[^] # Re: Des promesses...
Posté par barmic . Évalué à 3.
Les quels ? Parce que parler des optimisations du compilateur pour comparer des builders ça n'a de sens que pour ceux qui ne font pas la différence entre
makeetgcc(en quoi make, cmake ou le builder que tu veux s'y connaît en « architecture, la taille des registres, la gestions des instructions de vectorisations (SSE…) » ? Note que c'est une question piège si tu en trouve un qui répond à la question c'est que c'est de la daube qui ne sera pas capable de gérer facilement des chaîne de compilations alambiquées).Perso je vois pas comment maven peut gérer les dépendances en C++ (il a un moteur de gestion de dépendance, mais l'installation des bibliothèques n'a rien avoir et il faut trouver un dépôt pour le C et le C++) et il sera désagréable car il est lent à démarrer à cause de la JVM, mais des arguments contre intéressants j'en ai pas vu dans le commentaire parent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des promesses...
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 07 avril 2015 à 23:12.
Tu arrives un peu tard Michel ^ Mais peu importe, je vais essayer d'être plus clair.
Mon commentaire précédent pourrait se résumer à "Concernant les tools de compilations, evil is in the details" et par conséquent un outil designé pour un language est bien souvent inadapté pour un autre.
Les builds tools sont bien plus compliqués qu'il n'y parait dés qu'on creuse un peu.
Ça n'a rien à voir avec Maven ou pas maven.
Je conseillerais vivement la personne qui utilise autotools pour gérer un projet complètement en python d'aller voir un psy: c'est du sadomasochisme, ça n'a jamais été fait pour ça.
Il en va de même pour Java et Maven: Maven a principalement été conçu avec Java en tête : il est déclaratif, minimaliste, adapté à une chaine de compilation relativement simple pour un langage à bytecode multi-plateforme.
Maintenant, compare ça à C/C++ avec cmake ou autotools qui sont les mastodontes du secteurs pour de bonne raisons.
Ils gèrent un véritable dictionnaire de fonctionnalités nécessaires à la compil C/C++ :
ils parsent / transforment dynamiquement suivant la configuration/plateforme les headers de configurations ( les fameux config.h ) automatiquement pour garantir une certaine portabilités entre plateforme avant de les compiler
ils gèrent de manière transparente le bordel liés à la multi-tudes d'options et de paramètre différents propre à chaque linker et à chaque compiler.
ils changent les options passé au compilateurs suivant l'OS, la plateforme, l'architecture
ils détectent et enregistre la dernière date de modification ( ou checksum ) de chaque fichier du projet ( et uniquement du projet ) pour ne recompiler QUE les fichiers qui ont changer et minimiser les temps de compilations relativement long du C/C++.
ils créent des arbres de dépendance pour pouvoir paralléliser la compilation de chaque fichier "objet" / shared library / executable sans causer des problèmes de linkages.
ils doivent pouvoir supporter une gestion à la fois "automatique" et "fine grain" pour pouvoir supporter tous les hacks propres à la compilation C/C++
Et j'en oublie encore beaucoup. Les build systems C/C++ sont des usines à gaz et c'est pas juste pour le plaisir de les rendre monstrueux.
Maven ne supporte pas ça, n'est pas adapté pour ça, ne le sera sûrement jamais…. Et à mon humble avis, ne doit pas essayer de l'être…. sous peine de devenir un bordel encore plus complexe que les autotools eux même.
[^] # Re: Des promesses...
Posté par barmic . Évalué à 3.
Il n'y a rien dans ce que tu décris qui ne puisse être géré par un plugin. Sérieusement avoir un découpage net entre ce qui touche au langage et ce qui gère le projet, c'est un minimum de propreté dans le travail. make ne sait pas lire du C++, il ne comprends rien au C non plus. Idem pour les autotools qui ne bittent rien d'autre que le langage spécifique de chacun des outils. CMake lis du C++ comme un développeur js.
Bref non aucun de tes outils existant ne fait ce que tu dis. Ce qu'ils font c'est des paramétrages de programmes (en fonction du système, d'un paramétrage dans leur fichier de configuration ou en paramètre lors de leur lancement) et ça n'a rien rien de difficile ni pour maven, ni gradle, ni scons, etc.
Il n'a pas à le supporter. Les gens qui ont permis à maven de travailler sur du groovy, du scala, du ceylon voir de faire des choses plus tordus comme gwt n'ont pas touché au code de maven pour ça. De même pour ceux qui ont créé le plugin nar pour gérer du C et C++ (il est peut être pas complet, mais il peut s'améliorer) : http://stackoverflow.com/questions/1541771/using-maven-for-c-c-projects
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des promesses...
Posté par Firwen (site web personnel) . Évalué à 2.
Bien evidemment, ce n'est pas des compilateurs et je n'ai jamais dit ça….
Mais ils intègrent tout ce qu'il faut pour faire ce que j'ai décris plus haut en une simple ligne de configuration.
Est-ce que Maven le fait ? non.
En effet, SCons est l'exemple typique de build système qui tend à être universel et qui est au final un magnifique ratage. J'ai utilisé SCons dans plusieurs projets par le passé, et la finalité a été de tout migré sous CMake.
Tous des langages à JVM en gros ?
Qui est tout juste bon pour intégrer quelques morceaux de C/C++ dans un projet java existant en bidouillant. ( Et encore si la chaine de compilation est pas trop dégeu. )
Mais si tu te sens un ame de révolutionnaire, n'hesite pas à me prouver que j'ai tord et créer ton propre plugin maven pour re-faire autotools, je suis curieux de voir….
[^] # Re: Des promesses...
Posté par barmic . Évalué à 3.
Tu me montre « la simple ligne de configuration » qui permet ça dans make, gprbuild, cmake ?
Oui.
Si tu relis ce que j'ai écris plus haut tu verra que j'ai dis que ce n'est pas forcément une bonne idée, juste que donner des arguments du genre "non mais avec C++ c'est différents" ça n'est pas pertinent parce que si tu réfléchis ton système de build par le petit bout de la lorgnette (en listant d'abord des détails) tu n'arrive pas loin et au contraire tu fini par un mauvais design.
L'objectif c'est de lancer des tâches, d'avoir un cycle de vie intéressant (1 gestion de dépendance, 2 build, 3 lancement des tests, 4 déploiement là où tu veux - par exemple -), ensuite que lors du lancement des tâches (à chaque étape) tu puisse passer le maximum d'information à l'outil en question, d'avoir la possibilité de mettre des hooks dans tous les sens, remplacer une tâche par une autre (je veux remplacer gcc par pdflatex),… ce sont des question qui :
Pour ce qui est de maven, ses 2 principaux défauts AMHA c'est :
.javaen.class). Donc la gestion de comment je choisi si je compile tel ou tel fichier doit être dupliquéeTous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des promesses...
Posté par rewind (Mastodon) . Évalué à 3.
Chercher un outil qui fait tout, il y a de grandes chances que ça ne fasse rien de bien. Sinon, juste par curiosité, tu as déjà fait un code en C++ avec des dépendances ?
[^] # Re: Des promesses...
Posté par barmic . Évalué à 3.
Justement on est d'accord, il ne faut pas que l'outil s'intéresse à autre chose qu'à la construction de projet.
Un petit logiciel qui travaillait sur des distances d'images en C++ avec Qt, boost et eigen, ça te va ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des promesses...
Posté par rewind (Mastodon) . Évalué à 2.
La construction de projet dépend du langage que tu utilises ! Donc si tu fais de la construction de projet générique, tu fais bien des dizaines de choses différentes, même si de loin dans le brouillard ça se ressemble.
Et tu as utilisé Maven ?
[^] # Re: Des promesses...
Posté par barmic . Évalué à 3.
Non tu laisse le soin à des dizaines de choses différentes le soin de faire de ces dizaines de choses. Toi tu veux un outils qui fasse à la fois du grep, du templating, de la génération de code,… si les autotools ont découpés ça en plusieurs morceaux ce n'est pas pour rien. Pour moi ils pêchent parce que l'ensemble est devenu compliqué.
Regarde comment maven gère ça. Toutes ces actions spécifiques sont gérées par des plugins et écrire un plugin est trivial. Les plugins se configurent de manière standard de la même façon pour tous et ils exposent des targets spécifiques.
C'est déroutant tellement c'est simple et si tu veux que le build change en fonction de la météo et de la position de ton smartphone le tout avec un langage que t'as pondu toi, c'est possible et ça demande uniquement décrire un nouveau plugin.
Tu prône de la spécificité pour la spécificité en avançant comme seul argument que "de toute manière C++ c'est différent des autres". Alors que je te parle de modularité et de simplifier l'utilisation par des convention. Que l'outil soit écrit en ada je m'en fou mais réfléchir pour avoir de la flexibilité c'est mieux.
Je ne connaissais pas à l'époque et aujourd'hui je ne m'en servirais pas. Pour les raisons que j'ai donné plus haut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Des promesses...
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 08 avril 2015 à 15:38.
C'est la dernière fois que je poste ici. J'ai la net impression que je perds mon temps et que tu n'as même pas essayer de comprendre ce que je voulais dire.
Exemple de mon point N°1, cmake :
CHECK_SYMBOL_EXISTS(SetConsoleMode "windows.h" HAVE_SETCONSOLEMODE)Exemple de mon point N°2, cmake :
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in ${CMAKE_CURRENT_BINARY_DIR}/config.h)Exemple de mon point N°3, cmake: un simple "target_link_libraries(myexe somesystemlib)", PS: jette un coup d’œil à ce qu'il fait RÉELLEMENT derrière sur différente plateformes / compiler et tu comprendras la différence par rapport à Java / Gradle / Ceylan.
Je suis curieux de comment tu fais les deux premiers avec Maven… juste pour voir.
Non, non et non.
Si tu es payé pour étudier et faire ton propre build system alors oui peut être.
Si ton objectif est d'avoir un outil qui t'autorise à automatiser au mieux les différentes taches d'un build, de la manière la plus efficace et la moins verbeuse possible, pour te faire gagner du temps alors non.
Ce que tu veux c'est un outil qui couvre tous tes besoins et au mieux. Et c'est justement ces "détails du bout de la lorgnette" qui te font gagner le plus de temps car ils sont spécialement fait pour le/les languages associés..
[^] # Re: Des promesses...
Posté par barmic . Évalué à 3.
Tu peut écrire un plugin qui se configure ainsi :
Pour le second, il existe déjà un plugin filter, on peut en imaginer un qui utilise la syntaxe qui te fais plaisir.
Ce n'est pas la question. Moi je te dis et je pense sincèrement qu'il n'y a rien d'impossible à créer un outil suffisamment modulaire pour se foutre du langage ou plus précisément d'encapsuler les parties spécifiques aux langages dans des modules/plugins/greffons/addons dédiés. Maven est l'exemple le plus connu, mais arrête de faire une fixette dessus (je t'ai déjà dis plus haut qu'utiliser maven n'est pas une bonne idée).
CMake a tenté de le faire via leur macro (on peut créer ces propres macro si je ne m'abuse), mais c'est tellement simple que personne ne le fait et le fait de ne pas être un outil de build mais un outil qui génère les fichiers d'un build le rend compliqué à utiliser hors du cadre prévu par les développeurs.
Et donc à faire outil que je peux customiser pour qu'il me génère des fichiers à partir d'autres (comme générer un fichier de données LDAP à partir d'un fichier xls, cas vécu).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ha...
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 19 mars 2015 à 14:13.
Ha? je sais pas pour toi, mais moi je me dis que quand une personne est convaincue par le modèle open source, il ne fait pas de closed source. Je me dis qu'une personne convaincue va faire de l'open source pour avoir des utilisateurs, et non l'inverse (avoir des utilisateurs pour faire de l'open source).
J'ai plutôt l'impression qu'au bout de 2 ans d'existance, ils pataugent et cherchent à récupérer des adresses email ("you have to register", bam) comme ils peuvent.
Et ça n'inspire pas du tout confiance :
Ils pourraient faire attendre, et annoncer le moment venu du CC ND NC, "c'est open source, regardez il y a le code".
La licence, c'est 50% d'un projet, ça ne se débat pas plus tard (surtout si tu ne dis pas entre quoi tu hésites).
bref : pas convaincu qu'ils soient convaincus par l'open source.
# Ça commence mal
Posté par David Demelier (site web personnel) . Évalué à 1.
J'ai tout de suite regardé pour SDL2, et je vois qu'ils ont mal écrit l'auteur de la bibliothèque.
Maintenant ce que je me demande, c'est comment on définit qu'on veut utiliser tel ou tel compilateur, car par exemple sur Windows on a le choix entre diverses options qui ne sont pas du tout compatibles (MSVC et MinGW par exemple).
Mais sinon j'avoue que l'idée est très intéressante et pendant un long moment j'avais envie de coder moi même un truc comme ça !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ça commence mal
Posté par rewind (Mastodon) . Évalué à 2.
Pareil. Après Akagoria, je m'y mets !
# et maven?
Posté par pizaninja . Évalué à 1.
Non, je dis ça juste comme ça…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.