Journal biicode, c'est fini

Posté par rewind (Mastodon) le 17 août 2015 à 11:12. Licence CC By‑SA.

Étiquettes :

août

2015

biicode est un gestionnaire de dépendances pour C/C++. La startup qui développait biicode depuis le début vient d'annoncer l'arrêt de ses activités, ce qui signe sûrement l'arrêt de biicode également.

Quelles sont les raisons d'un tel échec alors qu'il y a un besoin criant pour un tel outil en C/C++ ? Le CEO de l'entreprise dit qu'ils n'ont pas réussi à trouver suffisamment de clients payants pour le service qu'ils offraient (on pouvait avoir un compte payant sur leur plateforme, façon github), malgré un afflux d'utilisateurs depuis des mois (25% de croissance par mois). Mais surtout, il dit qu'ils n'ont pas assez écouté la communauté et qu'ils avaient une mauvaise vision des processus de génie logiciel.

Sur la conversation reddit sur le sujet, Stephan T. Lavavej dit simplement que lui, personnellement, n'avait aucun besoin pour un outil de ce type. Le truc drôle, c'est qu'il dit que pour ses projets persos, il télécharge à la main les dépendances et qu'il écrit un Makefile pour les construire. Pourquoi c'est drôle ? Parce que le monsieur est le développeur en chef de la bibliothèque standard C++ de Visual Studio ! Pour le reste de la conversation, le constat qu'il manque toujours un outil pour gérer les dépendances (et les processus associés) est toujours là et n'a toujours pas de réponse satisfaisante.

D'après moi, biicode était une mauvaise réponse. J'ai déjà eu l'occasion de le dire ici même et je n'ai pas changé d'avis. Il y a eu deux erreurs au départ : un code fermé et une adaptation nécessaire du code (il fallait changer les include). Ils ont corrigé les deux erreurs avec le temps (mais trop tard à mon avis) mais même après ça, ça restait compliqué à utiliser. Et il restait l'aspect centralisé du dépôt (nécessaire pour pouvoir faire du business). Maintenant que l'entreprise est morte, je pense que ça va s'arrêter très vite, parce que déjà, ils disent eux-même qu'ils ne pourront pas maintenir le site et le nom de domaine pendant plus d'un an. Donc après, bye bye, à moins que la communauté reprenne le flambeau. Mais ça aussi ça m'étonnerait parce que l'outil est codé en Python donc il faut trouver une intersection assez grande entre des développeurs Python et des développeurs C++ et en plus, qui ont envie de coder ce genre de logiciel.

Bon, c'est décidé, je vais m'y mettre et en coder un.

# Nostradamus

Posté par Thomas Douillard le 17 août 2015 à 12:49. Évalué à 2.

Bon, c'est décidé, je vais m'y mettre et en coder un.

Sachant que l'effet réseau est ultra important dans ce genre de choses, si ils ont déjà une communauté d'utilisateurs, il y a fort à parier que le truc qui marchera s'appuiera sur la communauté existante. Débarrassé de l'aspect «on doit faire des sous» d'autres auront sans doute moins de soucis à se greffer dessus, et ceux qui ont commencé à s'appuyer sur le travail vont peut être essayer de pérenniser le truc … Si ils ont une communauté qui commence à grandir ça risque de vampiriser tous les utilisateurs d'une putative alternative.

Bref, bon courage :)
- [^] # Re: Nostradamus
  
  Posté par rewind (Mastodon) le 17 août 2015 à 13:28. Évalué à 2.
  
  Ils n'ont pas une grosse communauté. Ils ont surtout bénéficié d'une publicité sur plein de gros sites qui fait que chaque fois que quelqu'un demandait un gestionnaire de dépendance, c'était la réponse automatique (même si celui qui donnait la réponse ne l'utilisait pas lui-même). Et puis, avec une annonce comme ça, ça ne va pas rassurer la communauté, parce que pour l'instant, rien ne garantie que le service va continuer sur le moyen terme. Il existe des alternatives qui ont eu moins de pub et une petite communauté également (et qui souffrent d'autres problèmes).
# Naïveté

Posté par arnaudus le 17 août 2015 à 15:46. Évalué à 1.

J'imagine que je suis trop naïf ou que je vise trop bas (pas assez "pro"), mais personnellement, je n'aurais pas besoin d'un outil super-complexe qui fait le café : il suffirait d'un truc qui parse le répertoire courant récursivement jusqu'à trouver un main(), qui suit tous les include, à la fois dans le répertoire courant et dans les lib système, pour au final générer un Makefile valide. Rien qu'un truc comme ça pourrait remplacer les obcurs autotools pour la plupart des usages…
- [^] # Re: Naïveté
  
  Posté par rewind (Mastodon) le 17 août 2015 à 17:03. Évalué à 7.
  
  Ce que tu décris, ça peut se faire avec une ligne de shell avec gcc -E -M main.c et ça va marcher pour les programmes simples.
  - [^] # Re: Naïveté
    
    Posté par arnaudus le 17 août 2015 à 18:29. Évalué à 1.
    
    Mouais, c'est quand même loin de filer la liste des fichiers à compiler et des LD_FLAGS :-)
    
    C'est quoi la différence entre un programme simple et un programme complexe? D'une amnière générale, si tu as des trucs vraiment spécifiques (dépendances différentes en fonction de l'OS, etc), tu vas finir par gérer ta chaîne de compilation à la main, non?
    
    J'ai un peu l'impression que le besoin principal, c'est de générer un Makefile (ou l'équivalent) automatiquement à partir d'un répertoire qui contient les sources, avec éventuellement des outils pour cross-compiler, ou construire des paquets pour des distributions différentes. Les gros projets complexes disposent des ressources humaines et des compétences pour gérer tout ça (sans compter que je n'aurais pas trop confiance dans un outil automatique qui prétendrait compiler GNOME ou Linux sans intervention humaine), et a priori, sont moins concernés par un tel besoin.
- [^] # Re: Naïveté
  
  Posté par Mildred (site web personnel) le 19 août 2015 à 13:44. Évalué à 1.
  Sur ce principe, tu as le projet cjdns qui utilise un script nodejs pour compiler. le principe est le suivant:
  - tu spécifie le main.c principal
  - le script va compiler main.c, et va voir que main.c va inclure class1.h et class2.h
  - le script va déduire que main.o dépend de class1.o et class2.o, il les compile
  - ainsi de suite pour toutes les dépendances
  Ensuite, comment le script sait que les interfaces de class1.h sont fournies par class1.c, c'est une macro spécifique qui est utilisée (et qui est ensuite enlevée du code source pour ne pas poser problème au compilateur C.
  
  Le script node mentionné au dessus va aussi faire d'autres choses sympa. Comme générer automatiquement avec du code javascript des constantes dans le code C. Comme la date de build, le numéro de version, des valeurs aléatoires…
  
  J'ai tenté une version plus simple de ce système en utilisant les Makefiles, mais ça ne marche pas si bien: linkopts
  
  mais sinon, ceci n'a rien a voir avec un gestionnaire de dépendances.
# Gradle

Posté par potate le 17 août 2015 à 21:09. Évalué à 2.

Attention : je parle d'un outil que je n'ai pas utilisé. Je n'ai qu'une connaissance superficielle des autres outils de construction (que l'on parle d'automake, cmake, scons, ninja ou même make), donc je ne ferai pas de comparaison.

Gradle, (un outil de gestion de dépendances/compilation de projets issu de l'écosystème Java), permet de gérer des projets (entre autres) en C et C++ depuis quelques temps. Cette fonctionnalité n'est pas stable pour l'instant et donc que la configuration peut changer dans les prochaines versions.

La configuration des projets se fait par un DSL en Groovy (un langage dynamique pour la plateforme Java). Si pour les projets simples on peut sans doute s'en sortir avec des morceaux de configuration copié ici et là, avoir une base de la programmation en Groovy peut aider, que ce soit pour de la configuration avancée ou simplement pour avoir une plus grande connaissance du fonctionnement de l'outil.
Une recherche rapide m'a permis de voir qu'il est possible de publier ses projets sur des dépôts (dépôts Maven ou Ivy, traditionnellement utilisés pour des bibliothèques Java).

Donc, à ce que je vois, Gradle permettrait de gérer convenablement des gros projets en C ou C++, avec leurs dépendances. Après le côté "centré sur Java" peut certainement rebuter. Il est sans doute plus aisé d'introduire ce genre de techno sur un projet Android faisant intervenir à la fois des composants natifs et des composants ciblant la JVM que sur un projet C pur jus, bien que son utilisation reste possible.
- [^] # Maven
  
  Posté par pizaninja le 17 août 2015 à 22:30. Évalué à 4.
  
  Pour ma part, je suis parvenu à piloter des petits et très gros projets C/C++, Qt, embarqué, multiplateforme, à chaque fois avec maven.
  
  Les 'classifiers' me permettent de générer différents 'artefacts' (paquets prêts à l'emploi) selon qu'il s'agit d'un exe, d'une lib, de ressources, de headers et selon les plateformes (proc/OS), à partir des mêmes sources.
  
  Je ne dis pas que c'est facile à prendre en main et rapide à mettre en oeuvre, mais c'est un vrai bonheur à piloter (jenkins au hasard) une fois en place.
  
  Les dépendances entre projets sont claires, et chaque brique peut être independemment versionnée.
  
  Bon, j'avoue, je suis passé à un moment donné par une XP de dev java pour découvrir la puissance de l'outil maven.
  
  Même docker et vagrant peuvent être orchestrés par maven et jenkins: démarrage de containers ou VM à la volée pour compiler et construire des paquets (RPM, .deb, dmg, msi, etc…).
  
  Dommage que maven soit si méconnu par les dév étrangers au java…
  - [^] # Re: Maven
    
    Posté par Mildred (site web personnel) le 19 août 2015 à 13:45. Évalué à -1.
    
    non mais c'est une blague ?
    - [^] # Re: Maven
      
      Posté par pizaninja le 20 août 2015 à 21:54. Évalué à 2.
      
      Pas très gentil de chambrer sans arguments…
      - [^] # Re: Maven
        
        Posté par rewind (Mastodon) le 21 août 2015 à 13:45. Évalué à 2.
        
        Tu peux aller voir les discussions précédentes pour trouver des arguments, notamment ceux de Firwen.
    - [^] # Re: Maven
      
      Posté par xcomcmdr le 20 août 2015 à 22:03. Évalué à 3.
      
      Il est où le problème ?
      
      J'entends souvent des louanges sur Maven, et ça me semble être un cas d'usage justifié.
      
      Alors, c'est quoi la blague ?
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: Maven
        
        Posté par barmic le 20 août 2015 à 22:23. Évalué à 7.
        
        Alors, c'est quoi la blague ?
        
        Tu n'imagine pas ! C'est… C'est du JAVAAA ! Ah ? Gradle ?
        Mais c'est… ça utilise la JVM !!!!!
        
        Technologie de satan conçu pour être lente ! Jamais cette saleté n'aura droit de vie sur la machine d'un développeur C ou C++, ces gens sont au dessus de ça. Ils préfèrent utiliser make, puisque make c'est rapide (à exécuter en tout cas).
        
        Non, non, non et non. Tout ce qui est en python, ruby, java (ou sur la JVM), C# ou autre, tu oublie c'est mal (on va pas réutiliser 15 ans d'expérience tout de même). Non on réinvente notre outil avec nos bugs, il sera peut être moche, mais au moins ce sera le notre à nous et on pourra toujours dire qu'il est plus rapide (même si c'est pas vrai).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Maven
        
        Posté par rewind (Mastodon) le 21 août 2015 à 13:43. Évalué à 3.
        
        Ces arguments vont être mis à l'épreuve dans le cas de biicode qui est en python. On va voir si développer un outil dans le langage qu'il est censé gérer est une bonne idée ou si on peut prendre un autre langage sans risquer de s'aliéner une énorme partie de la communauté. Mais j'imagine bien le résultat (au vu de tous les autres outils similaires dans les autres langages) : biicode ne sera pas développé alors que pourtant, python c'est tellement plus mieux que C++ pour développer ce genre d'outils (remplace python par ruby, java, C# ou autre, selon ton bon vouloir). Le futur nous le dira assez vite.
        
        On a déjà eu cette discussion ailleurs mais on peut recommencer. L'argument qui consiste à dire qu'on utilise le langage le plus approprié pour une tâche se heurte à une impasse dans ce genre d'outils qui doit gérer un langage particulier. Parce qu'outre le fait de devoir se traîner une autre pile logicielle (et dans le cas d'un développeur, la première prend souvent déjà beaucoup de place), il faut trouver l'intersection des développeurs entre les deux langages, et même en prenant des langages aussi répandus que C++ et Python, ça n'est pas gagné. Il n'y a aucun contre-exemple digne de ce nom (c'est-à-dire largement utilisé) dans aucun langage.
        
        [^] # Re: Maven
        
        Posté par barmic le 21 août 2015 à 14:54. Évalué à 4.
        
        Ces arguments vont être mis à l'épreuve dans le cas de biicode qui est en python.
        
        C'est un exemple pas une démonstration.
        
        On va voir si développer un outil dans le langage qu'il est censé gérer est une bonne idée ou si on peut prendre un autre langage sans risquer de s'aliéner une énorme partie de la communauté.
        
        Il y a 48 contributeurs à make.
        
        L'argument qui consiste à dire qu'on utilise le langage le plus approprié pour une tâche se heurte à une impasse dans ce genre d'outils […]
        
        Je n'ai pas parlé de qualité intrinsèque de langage. AMHA seul prolog est peut être un peut mieux fait pour ça car la gestion de dépendance est intégrée. Je parle de maturité d'outils.
        
        […] qui doit gérer un langage particulier.
        
        Quel est le langage particulier de make, des autotools, de cmake, de gprbuild, etc ?
        
        Parce qu'outre le fait de devoir se traîner une autre pile logicielle (et dans le cas d'un développeur, la première prend souvent déjà beaucoup de place) […]
        
        Voir en dessous.
        
        Il n'y a aucun contre-exemple digne de ce nom (c'est-à-dire largement utilisé) dans aucun langage.
        
        Automake ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Maven
        
        Posté par rewind (Mastodon) le 21 août 2015 à 23:25. Évalué à 2.
        
        Il y a 48 contributeurs à make.
        
        Je croyais qu'on parlait de gestionnaire de dépendances.
        
        Je parle de maturité d'outils.
        
        Il n'y a actuellement aucun outil pour gérer les dépendances en C++ donc aucun outil mature.
        
        Quel est le langage particulier de make, des autotools, de cmake, de gprbuild, etc ?
        
        Les autotools et CMake servent à 99% à gérer C/C++. gprbuild sert à 99% à gérer de l'Ada.
        
        Automake ?
        
        Automake tout seul ne sert à rien et n'est pas un gestionnaire de dépendance.
        
        [^] # Re: Maven
        
        Posté par Lizzie Crowdagger (site web personnel) le 21 août 2015 à 23:52. Évalué à 3.
        
        Dans l'absolu je suis plutôt d'accord avec ce que tu dis (pour écrire un tel outil ciblé pour un langage spécifique, ça me paraît effectivement avoir plus de chances de drainer un minimum de contributeurs si c'est écrit dans le langage en question), seulement il me semble que le commentaire de base ne disait pas « il faudrait écrire un tel outil pour le C++ en Java » mais simplement « moi j'ai réussi à me démerder en utilisant Maven », ce qui est quand même assez différent.
        
        [^] # Re: Maven
        
        Posté par rewind (Mastodon) le 22 août 2015 à 00:04. Évalué à 1.
        
        L'argument de Barret Michel, c'est de dire que puisque Maven fait déjà le travail de gestion de dépendances, il n'y a pas besoin de coder autre chose. Sauf que je lui ai déjà demandé (et il n'a jamais répondu) pourquoi chaque langage choisissait de refaire son propre outil (et j'ai donné une grosse liste dans un journal précédent) dans son propre langage. Donc soit l'argument de Barret Michel est moisi, soit tous ces devs qui ont fait ce choix sont de gros abrutis.
        
        En plus, dire ça marche chez moi, ça n'est pas tout à fait pareil que de dire que c'est l'outil adapté. Et là aussi, Barret Michel n'a jamais rien répondu aux nombreuses objections qui ont été faites comme quoi Maven n'était pas adapté pour C/C++. Sa seule réponse, c'est de dire que ça doit être possible. Supaire.
        
        [^] # Re: Maven
        
        Posté par barmic le 22 août 2015 à 00:45. Évalué à 4.
        
        Et là aussi, Barret Michel n'a jamais rien répondu aux nombreuses objections qui ont été faites comme quoi Maven n'était pas adapté pour C/C++.
        
        T'es pas foutu de lire mon premier commentaire sur le sujet¹ :
        
        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[…]
        
        Tu (toi et d'autres) te focalise sur maven, maven, maven,… là où j'ai simplement dis qu'il est tout a fait possible d'avoir un outil souple qui puisse marcher pour ton langage à toi et pour d'autres. J'ai donné des exemples avec maven parce que c'est celui que je connais.
        
        Maintenant je ne sais pas si tu cherche à faire un outil de gestion de dépendance tel Ivy ou bower ou si tu cherche à faire un outil de build qui gère les dépendances, mais sincèrement je m'en fou. Tu fais bien ce que tu veux ton langage est suffisamment spécifique, pour que je n'ai jamais a y toucher (que dieu m'en garde). Tu veux coder un truc hyper spécifique avec un couplage fort entre ton moteur et ton langage c'est ton droit le plus strict.
        
        S'il te faut une explication de texte j'ai en plus répété ça dans un commentaire un peu plus tard : « 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) » et j'ai décris des limites précises de maven dans un autre commentaire. Et je n'ai cessé d'expliqué que la plupart des fonctionnalités n'existent pas mais qu'elles peuvent facilement s'ajouter. ↩
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Maven
        
        Posté par rewind (Mastodon) le 22 août 2015 à 09:43. Évalué à 3.
        
        Tu ne réponds toujours pas à la première remarque.
        
        Maintenant je ne sais pas si tu cherche à faire un outil de gestion de dépendance tel Ivy ou bower ou si tu cherche à faire un outil de build qui gère les dépendances, mais sincèrement je m'en fou. Tu fais bien ce que tu veux ton langage est suffisamment spécifique, pour que je n'ai jamais a y toucher (que dieu m'en garde).
        
        Alors tu viens troller sur toutes les news concernant les gestionnaires de dépendances pour C++ pour le plaisir ? Certes, tu as dit que Maven ne convenait pas mais tu n'as jamais proposé autre chose qui puisse convenir, tu t'es contenté de dire que faire un nouveau truc en C++, c'était le mal.
        
        [^] # Re: Maven
        
        Posté par flan (site web personnel) le 22 août 2015 à 00:05. Évalué à 1. Dernière modification le 22 août 2015 à 00:06.
        
        Mais avec cette logique, on se retrouve avec des outils magiques comme SBT (le Maven de Scala) : sur ma petite machine, pas loin de deux minutes pour lancer SBT pour quelque secondes de compilation (bah oui, mon fichier de conf' fait 10 lignes, ça prend du temps à parser) et j'ai régulièrement des OOM (Out of Memory Error) quand je veux créer un .jar de classes déjà compilées (donc en gros, faire un fichier zip de 10 Mo) malgré mes 4 Go de RAM.
        
        [^] # Re: Maven
        
        Posté par barmic le 22 août 2015 à 00:48. Évalué à 3.
        
        Je ne connais pas sbt gradle ne pourrait pas faire ton bonheur ? https://docs.gradle.org/current/userguide/scala_plugin.html
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Maven
        
        Posté par fredoche le 22 août 2015 à 23:02. Évalué à 1.
        
        Scala et sbt sont connus pour être des veaux, l'un pour la lenteur de son compilateur, l'autre pour sa lenteur tout court et ses fuites mémoires en mode console… Je fais pas l'apologue de maven mais on peut mettre sbt dans un panier a part…
        
        [^] # Re: Maven
        
        Posté par flan (site web personnel) le 22 août 2015 à 23:24. Évalué à 3.
        
        Autant ça peut se comprendre pour Scala (je veux dire que ce n'est pas gravissime si un compilo est un peu lent, et je comprends que ça soit complexe), mais faire un OOM en créant un zip de 10 Mo ou mettre deux minutes à se lancer pour un truc relativement simple (et qui n'apporte rien par rapport aux autres outils) est franchement incompréhensible :/
  - [^] # Re: Maven
    
    Posté par GeneralZod le 21 août 2015 à 22:23. Évalué à 2.
    
    Dommage qu'autotools/CMake soit si méconnus des devs java …
    
    Sérieusement, Maven est encore plus abscons qu'autotools, il est inutilement compliqué. Puis quand on voit les discussions où les devs Java sont tout excités de découvrir le versionnage sémantique (bref, la gestion de version saine et pratiqué depuis plusieurs décennies ailleurs)
    Maven est une usine à gaz immaintenable à grande échelle, le "ça marche sur mon poste" c'est sympa quand on veut verrouiller son job ou qu'on s'en fout des autres et Maven est l'outil idéal pour le mettre en place
    - [^] # Re: Maven
      
      Posté par barmic le 22 août 2015 à 01:01. Évalué à 5.
      Sérieusement, Maven est encore plus abscons qu'autotools, il est inutilement compliqué.
      
      Bof pour connaître les 2, maven est plutôt trop simple que trop compliqué, tu n'a pas de langage à apprendre (là où les autotools t'en demandent 2 à 3), les conventions sont bien explicités.
      
      Puis quand on voit les discussions où les devs Java sont tout excités de découvrir le versionnage sémantique (bref, la gestion de version saine et pratiqué depuis plusieurs décennies ailleurs)
      
      Je vois pas le rapport
      
      « Puis quand on voit les discussions où les devs gcc sont tout excités de découvrir le versionnage temporel » hum… Les hackers du noyau peut être ? Non plus. Les développeurs de Chrome ou de Firefox ? Non ? Bon. Ça fait pas mal de monde plutôt respectables AMHA qui ont arrêté sciemment d'utiliser une gestion de version « saine et pratiqué depuis plusieurs décennies ». Bizarre, non ?
      
      Je vois pas le rapport
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Maven
      
      Posté par devnewton 🍺 (site web personnel) le 22 août 2015 à 12:13. Évalué à 3.
      
      Maven est encore plus abscons qu'autotools
      
      Pour 99% des projets, ça se limite à un petit fichier pom.xml avec le nom du projet, sa version et ses dépendances. Difficile de faire plus simple.
      
      Maven est une usine à gaz immaintenable à grande échelle
      
      Maven est très utilisé en entreprise pour des projets à grande échelle et ses alternatives (SBT, Gradle & co) sont obligés d'être compatible avec sa gestion des dépendances pour exister.
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Gestion de code source (espace de travail) != Gestion des dépendances

Posté par Tangi Colin le 17 août 2015 à 21:31. Évalué à 1.

J'ai toujours trouvé bizarre l'idée d'associer dans un même outil, la gestion des dépendances et la gestion de code source (espace de travail). Ce que je veux dire par la, c'est que pour gérer mon espace de travail qui est composé de plusieurs git, j'utilise un outils dédié (dans mon cas l'outil repo d'android). De plus avec git-lfs ce n'est plus un problème de versionner aussi ses binaires à travers git. Ceci me permet de régénérer n'importe où ma base de code et ceci quelque soit le langage de programmation. Ensuite suivant le langage la partie gestion de dépendance de build et de runtime est géré par le système de build que je choisie.
En C/C++, pour un petit projet, j'aime assez bien la syntaxe android (android.mk).
Pour des projets plus complexes et devant intégrer plusieurs code open-source (qui viennent chacun avec leur système de build), j'utilise le "meta-build-system" yocto mais en prenant soins d'écrire une majorité de mes recettes en utilisant la bbclass "externalsrc" ou avec un git local.
- [^] # Re: Gestion de code source (espace de travail) != Gestion des dépendances
  
  Posté par barmic le 18 août 2015 à 14:00. Évalué à 3.
  
  J'ai pas bien compris de quoi tu parle, mais j'ai l'impression que par gestion de code source tu parle de gestion de version.
  
  Si on parle de maven (qu'on l'aime ou pas c'est une référence), il s'occupe en faite de tout le cycle de vie de tes sources. Y compris de la création de version (donc avec un passage des tests, la création de tag et l'upload de version).
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# piste si tu créer effectivement un gestionnaire de dépendences

Posté par robin le 21 août 2015 à 18:55. Évalué à 1.

Bonjour rewind,
Si tu fabriques ton gestionnaire de dépendance, voici quelques idées en vrac.
Pour la gestion des dépendances, comme tu le faisais remarquer gcc -E -M est un bon début. Pour les bibliothèques, on peut utiliser pkg-config.
Pour télécharger les dépendances ne pas profiter de celui déjà fournis par nos distributions (pacman, apt, dnf, …), et de leur paquets. Ça peut être très pratique pour aller chercher les gazillions de dépendances, notamment lors d'une cross-compilation (je compile sous ubuntu amd64 pour debian armhf, et j'ai téléchargé tous les paquets *-dev pour les headers + leurs dépendances qui contiennent les .so/.a depuis les serveurs debian arm).
Et enfin pour fabriquer des paquets, on peut utiliser fpm. Je n'ai toujours pas pris le temps d'en faire un journal, je voulais le tester un peu avant, mais cet outil est vraiment très bien.

bépo powered
- [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
  
  Posté par robin le 21 août 2015 à 20:05. Évalué à 1.
  
  Je complète mon post précédant avec des infos que j'ai trouvées sur un vieux journal :
  - auto-apt pour télécharger automatiquement les headers (à mon avis c'est basé sur apt-file search mon_header_qui_pose_problème.h)
  - checkInstall pour fabriquer des paquets. Je n'ai pas testé, mais ça m'a l'air similaire à fpm.
  
  bépo powered
- [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
  
  Posté par rewind (Mastodon) le 21 août 2015 à 23:12. Évalué à 2.
  
  Pour la gestion des dépendances, comme tu le faisais remarquer gcc -E -M est un bon début.
  
  Ça, c'est bien pour connaître les en-têtes dont dépend un .c mais ça ne dit pas la vraie dépendance.
  
  Pour les bibliothèques, on peut utiliser pkg-config.
  
  pkg-config est une idée super, mais il est très lié à gcc (et aux compilateurs qui utilisent la même syntaxe d'optons). En tout cas, c'est une bonne source d'inspiration sur les concepts de base.
  
  Pour télécharger les dépendances ne pas profiter de celui déjà fournis par nos distributions (pacman, apt, dnf, …), et de leur paquets.
  
  Je suppose qu'il y a un «pas» en trop. Mais après, ça me paraît compliqué, parce que l'idée, c'est aussi de pouvoir compiler sur Windows, et là, pas de paquets.
  - [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
    
    Posté par devnewton 🍺 (site web personnel) le 22 août 2015 à 12:25. Évalué à 4. Dernière modification le 22 août 2015 à 12:34.
    ça me paraît compliqué, parce que l'idée, c'est aussi de pouvoir compiler sur Windows, et là, pas de paquets.
    
    A mon avis, il faut proposer d'utiliser les dépendances de la distrib et sinon les télécharger.
    
    C'est un peu le scope "provided" de maven. Pour ton projet, on pourrait avoir une syntaxe:
```
    dependencies : [
    { name:"masuperlib" version:"12.0" when: { os="other" } },
    { name:"masuperlib" version:"0.1.3.rc-beta" deb: "libmasuperlib" when: { os="debian" } }
    }
```
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
      
      Posté par rewind (Mastodon) le 22 août 2015 à 14:39. Évalué à 2.
      
      Oui, ça me paraît pas mal comme approche, je note.
  - [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
    
    Posté par robin le 23 août 2015 à 07:30. Évalué à 1. Dernière modification le 23 août 2015 à 07:31.
    
    Pour la gestion des dépendances, comme tu le faisais remarquer gcc -E -M est un bon début.
    
    Ça, c'est bien pour connaître les en-têtes dont dépend un .c mais ça ne dit pas la vraie dépendance.
    
    Si on sait que a.c dépend de a.h et b.h, alors si a.c a.h ou b.h ont été modifiés depuis la dernière compilation de a.o (il faut mémoriser les timestamps, chose que make fait très bien), et donc il faut recompiler a.o, sinon ce n'est pas nécessaire. Mais c'est peu-être que je n'ai pas compris ce que tu voulais dire par « vrai » dépendance.
    
    pkg-config est une idée super, mais il est très lié à gcc (et aux compilateurs qui utilisent la même syntaxe d'optons). En tout cas, c'est une bonne source d'inspiration sur les concepts de base.
    
    Concernant les concepts de base les aur sont certainement une autre source d'inspiration.
    
    Pour télécharger les dépendances ne pas profiter de celui déjà fournis par nos distributions (pacman, apt, dnf, …), et de leur paquets.
    
    Je suppose qu'il y a un «pas» en trop. Mais après, ça me paraît compliqué, parce que l'idée, c'est aussi de pouvoir compiler sur Windows, et là, pas de paquets.
    
    C'était un « pourquoi » en pas assez (pourquoi pas) :)
    D'après ce journal, il semblerai que Fédora ait des binaires pour windows (je n'ai encore jamais utiliser crossroad, mais il me semble que jehan est quelqu'un d'assez fiable pour le croire :) ).
    
    bépo powered
    - [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
      
      Posté par rewind (Mastodon) le 23 août 2015 à 09:27. Évalué à 2. Dernière modification le 23 août 2015 à 09:28.
      
      Si on sait que a.c dépend de a.h et b.h, alors si a.c a.h ou b.h ont été modifiés depuis la dernière compilation de a.o (il faut mémoriser les timestamps, chose que make fait très bien), et donc il faut recompiler a.o, sinon ce n'est pas nécessaire. Mais c'est peu-être que je n'ai pas compris ce que tu voulais dire par « vrai » dépendance.
      
      La vraie dépendance, c'est à quel projet appartient b.h. Est-ce un en-tête du projet lui-même ou alors est-ce un en-tête d'un projet externe ?
      
      D'après ce journal, il semblerai que Fédora ait des binaires pour windows (je n'ai encore jamais utiliser crossroad, mais il me semble que jehan est quelqu'un d'assez fiable pour le croire :) ).
      
      Oui, j'ai déjà essayé crossroad et j'ai utilisé ces binaires. Le problème avec Windows, c'est que les binaires dépendent du compilateur utilisé (et parfois de la version du compilateur utilisée) à cause des ABI qui changent. Donc des paquets binaires sont forcément liés à un compilateur particulier.
      - [^] # Re: piste si tu créer effectivement un gestionnaire de dépendences
        
        Posté par robin le 23 août 2015 à 17:30. Évalué à 1.
        
        La vraie dépendance, c'est à quel projet appartient b.h. Est-ce un en-tête du projet lui-même ou alors est-ce un en-tête d'un projet externe ?
        
        Merci pour la précision. Je n'avais pas réalisé ça. C'est sûr que ça devient tout de suite plus touchy de le calculer automatiquement, vu que b.h peut appartenir à mon projet ou une lib selon le contexte pour le même exécutable.
        
        bépo powered

Suivre le flux des commentaires

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