Petit éventail des outils de construction (« builder ») libres

Posté par  . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
43
5
sept.
2011
Ligne de commande

Je vous propose dans cette dépêche de revenir sur la panoplie d'outils de construction qui s'offre à nous (c'est à dire les outils permettant d'automatiser les étapes de préprocessing, compilation, éditions des liens, etc).
Je ne cherche pas à faire un comparatif, mais juste à les décrire pour en faire ressortir les avantages et inconvénients ainsi que les cas d'utilisation. Cette dépêche peut être vue comme un état de l'art allégé des outils de construction libres.

Je tiens à remercier les contributeurs de cette dépêche :

  • GeneralZod
  • tiennou
  • NedFlanders
  • claudex

Ce sont eux qui ont écrit la majeure partie de cette dépêche et qui l'ont améliorée et complétée grâce à leurs connaissances et au temps qu'ils y ont consacré.

Cette dépêche a pour objectif de faire découvrir ou redécouvrir des outils de constructions. Si vous en connaissez d'autres n'hésitez pas à en parler en commentaire.

Sommaire

Un « builder » ?

Nous avons dans nos dépôt un grands nombre d'outils qui ont chacun leur philosophie. Le reste de la dépêche s'attelle à en décrire un certains nombre parmi les plus connus.
Un builder est un outil qui permet de construire un logiciel (et plus si affinité) à partir des sources. Il doit être le chef d'orchestre de la chaîne de fabrication du logiciel (le compilateur, l'éditeur de liens, etc).

Les critères importants de ce genre d'outils sont la facilité d'utilisation : pour le développeur et pour l'utilisateur. La performance : lorsqu'un projet est gros, le temps de création du logiciel peu devenir très important et la vitesse du builder peut avoir un impact important. La flexibilité : peut-on en faire ce que l'on veut avant et après chaque étape ? Gère-t-il n'importe quel langage ?

Le vénérable Make

make est l'outil de base pour beaucoup. C'est un outil très vieux, mais encore beaucoup utilisé. Il est le seul outil de la liste de cette dépêche à faire partie de POSIX. Sous nos distributions GNU/Linux, c'est généralement GNU Make qui est utilisé.

Make est une sorte de langage Rule Based Programming quand lequel on spécifie des règles sous la forme :

cible: dépendance
        cmd

Avec :

  • cible : fichier ou pattern de fichier que l'on cherche construire
  • dépendance : liste des fichiers nécessaires pour construire la cible
  • cmd : commande pour produire la cible

Les avantages de cette approche sont :

  • la souplesse : on utilise make pour tout et n'importe quoi aujourd'hui (créer un PDF, latex ou lout, compiler dans tout type de langage, etc.)
  • la simplicité : si vous savez construire à partir de votre ligne de commande vous saurez le faire avec make
  • rapidité : il construit un arbre de dépendance et éxecute une parallèle ce qui peut l'être (aujourd'hui tout les builders le font)

En revanche, il possède aussi un certain nombre d'inconvénients :

  • dépendances : on doit gérer à la main les dépendances entre les fichiers, plus le projet devient gros plus ça devient lourd à gérer ;
  • manque de portabilité : on utilise des commandes, généralement on ne se gène pas pour utiliser les options GNU de nos outils favoris, il faut aussi que ces outils soient installés sur la machine, etc. ;
  • manque de réutilisabilité : quand on se met à beaucoup l'utiliser, on a tendance à recopier des blocs de Makefile car rien n'est mutualisé.

Ce dernier point est tout de même à relativiser, GNU Make intègre beaucoup de règles par défaut qui simplifient son utilisation. Par exemple, si vous avez un simple fichier coucou.c que vous souhaitez compiler, il vous suffit de taper cette commande (sans avoir créé de Makefile au préalable) pour créer l'exécutable :

$ make coucou
cc coucou.c -o coucou

Si vous souhaitez passer des arguments au compilateur :
sh
$ export CFLAGS='-g'
$ make coucou
cc -g coucou.c -o coucou

Le peu connu OMake

Il utilise une syntaxe similaire à Make mais offre quelques fonctionnalités supplémentaire :

  • La gestion du projet dans plusieurs répertoires ou dans une hiérarchie de répertoire ;
  • Une analyse automatique et rapide des dépendances, basée sur MD5 ;
  • Lorsqu'une cible est spécifiée dans la ligne de commande, elle est automatiquement considérée comme obsolète et reconstruite ;
  • Il est complètement scriptable et une bibliothèque est fournie pour les langages C, C++, OCaml, et LaTeX. Il est donc possible d'avoir une seule ligne pour le projet :
.DEFAULT: $(CProgram prog, foo bar baz)

Cette ligne suffit pour construire la cible prog à partir des fichier foo.c, bar.c et baz.c. OMake va aussi chercher les dépendances implicites comme les includes des fichiers C.

  • Les règles qui construisent plusieurs fichiers en une fois sont complètement prises en charge ;
  • Il fonctionne sur Linux, Windows, Cygwin et Mac OS ;
  • Des fonctions telles que grep, sed et awk sont directement incluses dans le programme, cela permet d'améliorer la portabilité sous Windows ;
  • Il est possible de surveiller le système de fichier en continu pour relancer la construction dès qu'un fichier est modifié ;
  • Il dispose d'un interpréteur de commande, osh, qui permet l'utilisation interactive.

Un challenger scons

Scons est écrit en python, et les scripts scons (fichiers SConstruct et SConscript) sont eux-même en python. Ceci lui procure une très grande souplesse. La contrepartie de cette souplesse est une certaine complexité, scons fait un peu moins "clef-en-main" que certains autres outils de construction.

Avantages de scons :

  • c'est du python : c'est un vrai langage, pas un truc tout bancal, ça roxe
  • sait extraire out-of-the-box les dépendances des sources de nombreux langages (C, C++, Java, Fortran, etc.)
  • garantie d'avoir toujours des constructions correctes, ce qui est assez confortable. Scons garde trace du hash du contenu de chaque fichier apparaissant dans l'arbre de dépendances.
  • lance les compilations en parallèle
  • killer feature : scons cache le résultat chaque opération (compilation, liaison, etc.), un peu comme ccache, mais pour toutes les opérations et tous les langages.
  • gère de base les chaînes de compilation sur les systèmes d'exploitation majeurs (outils GNU sous Linux, Visual Studio sous Windows, XCode sous Mac OS X), tout ceci étant bien entendu totalement paramétrable.
  • range tous les produits de la compilation dans un "build directory", pratique pour séparer les choux et les carottes.

Inconvénients :

  • relativement complexe à prendre en main, et plutôt bas niveau
  • plutôt lent par rapport à la concurrence, en partie à cause de python, et en partie à cause de la gestion très rigoureuse des dépendances.

Une comparaison avec les autres outils est disponible sur [http://www.scons.org/wiki/SconsVsOtherBuildTools]

Un dérivé de scons qui semble avoir le vent en poupe est waf. Il comble les lacunes de scons (complexité et lenteur) en proposant des améliorations tel qu'une sortie en couleur et un meilleur support de la compilation parallèle.

Celui de Google : Ninja

Ninja est le moteur de production créé par l'équipe de développement de Google Chrome. Ceux-ci utilisaient Make mais trouvaient que la génération de l'arbre des dépendances était bien trop lent (le temps avant de commencer serait d'une minute).

Ils ont choisi de développer leur propre outil (pourquoi donc patcher le logiciel existant ?). Celui-ci est plus simpliste que Make car il ne possède aucune logique interne liée aux langages (contrairement à make qui possède des règles prédéfinies). Néanmoins, il a une syntaxe qui est un peu plus flexible.

L'utilisation de ninja passe par la création d'un fichier build.ninja. En voici un exemple tiré de la documentation officielle :

cflags = -Wall

rule cc
  command = gcc $cflags -c $in -o $out

build foo.o: cc foo.c

```cflags = -Wall

rule cc
command = gcc $cflags -c $in -o $out

build foo.o: cc foo.c
```

Cet exemple, bien que simpliste permet de voir l'usage basique du logiciel. Voici une petite explication de la syntaxe :

cflags = -Wall

Déclare une variable cflags.

rule cc
  command = gcc $cflags -c $in -o $out

Déclare une règle cc :

  • $in corresponde aux fichiers d'entrée
  • $out au fichier de sortie
build foo.o: cc foo.c

Ceci va invoquer la règle cc avec foo.c comme variable $in et foo.o comme variable $out.

L'univers Java

L'historique Apache Ant

Le premier moteur de production orienté Java développé par la fondation Apache. Il repose sur la notion de tâches et a la particularité d'utiliser un format XML pour son fichier de configuration. On peut étendre les fonctionnalités d'Ant en écrivant des nouvelles tâches.
Bien qu'écrit en Java, il est utilisable avec d'autres langages.

Avantages :

  • une riche collection d'extensions via antcontrib ;
  • portable ;
  • excellente intégration aux outils Java existants (tests unitaires, qualité de code etc…).

Inconvénients :

  • XML ?
  • Difficulté d'avoir un environnement standard (compilation, paquetages, etc) rapidement. On doit partir de zéro pour les tâches standards
  • Pas d'héritage sur les fichiers build.xml et la composition est fastidieuse.

L'usine à build Apache Maven

Maven est une plateforme moderne de construction de projet, développé également par la fondation Apache.
Attaché à la devise « Convention plutôt que configuration », Maven impose sa manière d'organiser les fichiers et un cycle de construction en plusieurs phases (les principales étant clean, compile, test, package, install, deploy). L'intérêt de maven est qu'il impose de la rigueur dans l'infrastructure du projet, apportant par la suite énormément de confort puisqu'on est à peu près sûr de pouvoir reconstruire le projet sur un nouvel environnement.

La gestion des dépendances est un point fort de maven. Chaque module est identifié par (au minimun) le triplet (groupId, artifactId, version). L'ajout d'une dépendance à un projet se fait donc juste en spécifiant le triplet correspondant. Maven se charge automatiquement de récupérer les dépendances sur les dépôts comme un gestionnaire de paquets le fait sur notre distribution GNU/Linux favorite.
Maven est lui-même extrèmement modulaire et les nombreuses extensions disponibles seront résolues au besoin au moment de leur utilisation.

Un projet maven est décrit dans un fichier pom.xml contenant l'identification du projet, des métadonnées optionnelles mais intéressantes (licence, page web, description…), la liste des dépendances, des dépôts additionnels, la liste des extensions supplémentaires utilisées.

En résumé, les avantages :

  • description standardisée d'un projet
  • richesse des extensions disponibles
  • plateforme modulaire et autonome, garantissant une utilisation rapide dans un nouvel environnement

Les inconvénients :

  • la résolution des dépendances peut s'avérer un peu longue
  • une connexion au dépôt de bibliothèques est nécessaire au moins pour la première fois, sinon le projet est inutilisable
  • une description plus détaillées des inconvénients se trouve sur le blog de Sonatype : We're Used to the Axe Grinding

Les autres (buildr, gradle…)

La communauté Java - et plus particulièrement la communauté Apache - est très productive ces derniers temps en terme de builder. En plus de Ant et Maven, Apache compte plusieurs projets intéressants. Quelques-uns sont à souligner :

  • Apache Ivy est un sous-projet d'Ant. Il vise à ajouter la gestion des dépendances (compatibles Maven) dans des projet gérés par Ant. Cela permet de simplifier la gestion des dépendances à un projet qui était déjà géré par Ant.
  • Gradle celui-ci gère les projet via un DSL à la place de fichier XML, il vise notamment à être plus indépendant du langage que Maven, ainsi il pourra plus facilement travailler sur des projet Groovy ou Scala. Il utilise, comme Maven, la convention plutôt que la configuration ce qui lui permet de simplifier son utilisation. Voici pour exemple le fichier minimal pour un projet Java :
apply plugin: 'java'
  • Apache Buildr est fait pour être le plus simple possible. Il est aussi prévu pour gérer plus facilement Groovy et Scala. Voici un fichier montrant sa simplicité, il permet de compiler un projet my-app et de créer un jar :
define 'my-app' do
  project.version = '0.1.0'
  package :jar
end
# Du code avec coloration syntaxique
class Ruby
end
apply plugin: 'java'

Les surcouches

CMake

Contrairement aux outils présentés auparavant, CMake est un générateur de "projets". Il génére un ou des fichier(s) recette(s) qui seront manipulés par un moteur de production bas-niveau (make, nmake, …) ou pouvant être ouverts par un environnement de développement (eclipse, XCode, Visual Studio, KDevelop, …). Depuis son adoption par KDE, il connait une grande popularité.

CMake fournit un langage dédié et un jeu de macros permettant de gérer un projet complet. Il est ainsi capable de retrouver seul les bibliothèques ou les utilitaires installés sur le système et ainsi s'abstraire de la platforme de compilation.

Plus généralement, CMake fait partie de la suite de processus logiciel qualité Kitware qui comporte également :

  • CTest : un outil de tests qui étend CMake. Il permet de récupérer le code source à partir d'un gestionnaire de version, de compiler ces sources, et d'exécuter les tests unitaires (CMake supporte GoogleTest, CXXTest, SQuish et s'intégre facilement aux autres systèmes). Il permet également de récupérer la couverture de code et d'exécuter les tests sous Valgrind. Il génère des rapports XML qui pourront être traités par un serveur d'intégration continue.
  • CDash : serveur web de tests, associé à CTest, il fournit une plateforme d'intégration continue flexible.
  • CPack : la boite à outils pour générer des paquets très simplement. Il supporte les formats suivants : dpkg, rpm, tarballs, installeurs Mac (dmg, drag'n'drop, etc.), NSIS, Cygwin.

Avantages :

  • multiplateforme
  • permet de générer des projets pouvant être ouverts par un IDE
  • robuste
  • prise en charge de la compilation parallèle
  • une collection de modules qui s'enrichit régulièrement

Inconvénients :

  • un langage de script relativement pauvre comparé à python ou lua
  • documentation éparse

Les autotools

Derrière la dénomination autotools se cache toute une famille d'outils GNU constituant un moteur de production complet mais également complexe :

  • autoconf : un générateur de scripts shell à partir de macros m4 permettant de configurer les sources d'un projet (ex: tester la version d'une bibliothèque, la présence ou non d'une fonction etc…). C'est lui qui est responsable de la génération du fameux "configure".
  • automake : générateur de makefile portables, il est écrit en perl.
  • libtool : abstrait la génération des bibliothèques dynamiques.
  • gnu make : bien évidemment le moteur GNU make pour exécuter le makefile résultant.

Avantages :

  • facilite l'écriture de programmes multi-plateformes.
  • simplifie le processus de compilation par l'utilisateur (le célèbre triptyque : "./configure && make && make install")
  • système de construction robuste et extrêmement modulaire.
  • la plus large collection d'extensions parmi tout les moteurs de production de haut niveau présentés.

Inconvénients :

  • complexe d'utilisation
  • dépendance à la présence d'un shell bourne (ou compatible), m4, et perl
  • relativement lent (même si il est possible d'améliorer ce point en passant par une construction non récursive, c'est-à-dire en utilisant un unique Makefile.am à la racine du projet)
  • les différentes versions d'automake sont incompatibles entre elles
  • re-générer le système de construction est une tâche relativement complexe, souvent laissé à la charge d'un script shell (autogen.sh)

Aller plus loin

  • # Indispensable

    Posté par  (site web personnel) . Évalué à 9.

    Bonjour,

    Ça fait maintenant quelques années que j'utilise systématiquement maven pour mes projets java. Auparavant, j'utilisais ant. Maven a vraiment apporte une structure cohérente au projet. Là ou avec ant, chaque développeur a ses petites bidouilles rendant difficile la réutilisation (sauf avec beaucoup de rigueur, cf. le projet netbeans), maven laisse peu de place à l'improvisation et fournit des solutions prêtes à l'emploi pour de nombreux besoins.
    D'apparence compliqué à appréhender, le pom (le fichier de configuration) s'avère très simple dès lors qu'on ne cherche pas à le tordre et bougrement efficace. Le démarrage d'un nouveau projet se fait très rapidement, on ajoute les dépendances en 3 clics (ou quelques copier-coller), et on peut alors avec quelques commandes générer le jar du projet, le déployer sur son dépôt, faire de même pour la javadoc. Le couplage avec hudson (serveur d'intégration continue) est aussi un jeu d'enfant et rend des services inestimables.
    Non, franchement, j'aurai du mal à me passer de maven sur un projet java, et si je devais changer de langage, j'espère trouver un outil équivalent.
    Voilà pour mon expérience :-) (c'est d'ailleurs moi qui ait rédigé en grande partie, et un peu vite-fait, la partie sur maven ;-) )

    Merci pour la dépêche, je vais jeter un œuil sur les autres outils.

    • [^] # Re: Indispensable

      Posté par  . Évalué à 3.

      Je suis aussi très satisfait de maven pour du java (même si j'ai encore peu d'expérience et que je n'ai pas encore touché à des archétypes).
      J'aimerais bien avoir l'occasion de toucher à gradle ou buildr qui ont l'air intéressants et qui évite de faire du XML. Je sais que maven 3 permet d'avoir une configuration XML compact. Avec ça :

      <dependencies>
  <dependency groupId="org.apache.maven" artifactId="maven-artifact" version="${mavenVersion}" />
  <dependency groupId="org.apache.maven" artifactId="maven-project" version="${mavenVersion}" />
</dependencies>

      À la place de :

      <dependencies>
  <dependency>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-artifact</artifactId>
    <version>${mavenVersion}</version>
  </dependency>
  <dependency>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-project</artifactId>
    <version>${mavenVersion}</version>
  </dependency>
</dependencies>

      Mais ce n'est pas très mis en valeur et je n'ai pas eu l'occasion d'essayer.

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

    • [^] # Re: Indispensable

      Posté par  (site web personnel) . Évalué à 5.

      hum... je suis plutôt mécontent pour ma part de maven.
      Ha c'est sur si on reste dans du java "classique" ça fonctionne plutôt bien.
      Par contre, dès qu'on a un truc un peu plus couillu c'est la fête du slip. Les cas tordus se résolvent de deux manières en général : soit on crée un plugin maven (mouai... bof quoi, on est très mais alors très loin du convention over configuration tout d'un coup). Soit on crée du ant et on utilise le plugin ant !

      Le problème surtout c'est qu'un build c'est une suite d'étapes. C'est un processus. Et maven masque tellement ça que parfois on ne peut pas s'en sortir (j'ai quelques exemples de cas où je voudrais réaliser des actions sur les fichiers juste avant la mise en war, mais pas moyen sans créer un nouveau plugin. Mon war est faux mais le répertoire sur le disque (donc juste non zippé) est lui ok. Super !

      Maven c'est bien sur le principe, dans beaucoup de cas ça fonctionne, les archetypes sont plutôt sympa, les dépendances assez bien foutu.
      Mais c'est tout de même limité (et encore je ne parle pas du fait de devoir mixer plusieurs langages à builder dans la même archive, évidemment je parle de langages hors JVM).

      Pour ma part je serais plutôt adepte de systèmes de builds mélangeant description (dépendances par exemple, ce que maven fait bien) et étapes de build qui pour moi doit être plutôt de type script, scénario, ce que maven fait mal.

      • [^] # Re: Indispensable

        Posté par  . Évalué à 3.

        C'est un problème connu de maven, dès qu'on sort des clous c'est très compliqué. Peut être que tu devrais regarder du coté de gradle ?

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

    • [^] # Re: Indispensable

      Posté par  . Évalué à 0.

      Je partage le point de vue sur Maven, mais je ne comprends pas les inconvénients reprochés à Ant :

      • XML ? : Je ne vois pas le problème, la syntaxe est assez claire. Sinon on peut reprocher la même chose à Maven non ?
      • Difficulté d'avoir un environnement standard (compilation, paquetages, etc) rapidement. On doit partir de zéro pour les tâches standards. En effet, mais une fois une structure projet bien définie, on peut réutiliser les xml d'un projet sur l'autre. C'est pas vraiment spécifique à Ant, on peut faire le même reproche à make, non ?
      • Pas d'héritage sur les fichiers build.xml et la composition est fastidieuse. Qu'appelez vous héritage ? Parce qu'on peut enchainer les build.xml et les spécialiser à différentes tâches par exemple.

    • [^] # Re: Indispensable

      Posté par  . Évalué à 2.

      A noter que Maven dispose d'un petit frere: ployglot maven (pmaven) http://polyglot.sonatype.org/why.html .
      Il permet de spécifier les dépendances dans d'autre langages qu'XML tel que Clojure, Groovy ou Scala pour le moment.

      Bien sur je rejoins les autres commentaires: maven est super pour le cote convention: tous les projets maven se compilent en 2 coups de cuillère a pot. Les plus gros projets sont faciles a gérer pour peu que la base de code n'est pas monolithiques et que les dépendances sont bien découpées. J'ai de mauvais souvenirs avec les scripts ant sur de tels projets! Tres flexibles, mais rapidement compliqués a debugguer (pas insurmontable, juste chiant).
      J'aime bien la possibilité de pouvoir utiliser les taches ant lorsque l'on vient a bout des possibilités de Maven et avant que l'on n'en vienne a créer son propre plugin maven. C'est pratique. Je crois que l'inverse est aussi possible, mais je ne suis pas sur de comprendre l’intérêt.

      Les seuls trucs qui me gonflent dans maven sont de petits bugs ou des petits manques ici ou la qui te compliquent la vie puissance 10 dans certains cas. J'ai fais chauffer mon compilateur, mais j'attends les commentaires sur mon patch et une intégration. On va voir.

  • # robuste ?

    Posté par  . Évalué à 1.

    Ça veut dire quoi ?

    • [^] # Re: robuste ?

      Posté par  (site web personnel) . Évalué à 9.

      c'est par opposition à un truc tout branlant , fait de bric et et broc et assemblé avec du scotch, les autotools par exemple.

      • [^] # Re: robuste ?

        Posté par  . Évalué à 1.

        Je ne comprends pas.
        Tu dis que les autotools sont un truc tout branlant ou justement qu'ils ne le sont pas ?

        • [^] # Re: robuste ?

          Posté par  (site web personnel) . Évalué à 10.

          ils le sont bien entendu. Il n'y a rien de robuste dans les autotools c'est un assemblage hétéroclite de bout de scripts shell , de makefile et de macros m4 emballé dans du perl, qui genere plus ou moins automatiquement un milliard de micro-fichiers plus ou moins indispensables. Pour moi il est vraiment temps que le libre se trouve un autre outil de build que l'infernale combinaison autoconf/automake/libtool/make . Quelque chose qui soit vraiment portable (parce que les autotools n'ont rien de portable , ça ne fonctionne relativement fiablement que sous les derives de gnu/linux avec un toolchain gnu), qui soit simple a ecrire quand on sort du GNU/Hello trivial , qui ne genere pas un ./configure de 350Ko pour gnu/hello

          • [^] # Re: robuste ?

            Posté par  . Évalué à 3.

            En fait tu vas commencer par faire un truc simple.
            Puis un jour un gars voudra faire un truc pas prévu et se retrouvera bloqué.
            si c'est libre, alors il fera un plugin.
            Puis ce gars n'est pas tout seul.
            Tu te retrouves avec une usine à gaz avec pleins de modules (dont certains lance la cafetière au début de la compil si la durée estimé est supérieur à cinq minutes )

            Et quelqu'un va râler pour dire que c'est trop compliqué, et lancer un nouveau projet de builder simple...

            Si on part du principe que les autotools ne sont pas protable, alors aucun builder n'est portable.
            aucun ne marche sous windows sans devoir installer des outils tiers. (ici bash & make)

            Pour avoir utilisé les autotools, le truc tu dis ce qui te manque, ce qui est nettement plus parlant que 'truc.h not found', ou des erreurs lors de l'édition de lien.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: robuste ?

              Posté par  (site web personnel) . Évalué à 10.

              le truc tu dis ce qui te manque, ce qui est nettement plus parlant que 'truc.h not found'

              Sauf quand tu dois farfouiller dans le config.log pour comprendre qu'est ce qui lui pose vraiment probleme avec la libtruc après qu'il t'ait dit "checking for truc.. no". Et sauf quand tu as installé la libtruc qui manque et que le configure persiste a ne pas la voir et que tu passes des heures à chercher la bonne manière de lui faire ajouter le bon flag qui va bien sur le bon fichier.

              Accessoirement, je n'ai pas de probleme avec les usines a gaz quand elles savent faire des trucs puissants et compliqués. Le probleme des autotools c'est que c'est une usine à gaz , mais sans etre puissant ou portable, c'est juste mauvais, lent, et fragile. Ainsi que mal documenté.

            • [^] # Re: robuste ?

              Posté par  (site web personnel) . Évalué à 8.

              Si on part du principe que les autotools ne sont pas protable, alors aucun builder n'est portable.
              aucun ne marche sous windows sans devoir installer des outils tiers. (ici bash & make)

              Je peux t'en citer un très rapidement, je pense qu'il doit y en avoir plusieurs autres: CMake

              • [^] # Re: robuste ?

                Posté par  . Évalué à 4.

                j'ai du mal me faire comprendre, quand j'ai dis sans installer d'outils tiers, ou alors il y a un truc que j'ignore sous windows.

                à partir du moment où il faut cliquer sur un setup.exe, dezipper une archive, ce n'est pas plus ou moins portable, c'est juste équivalent, avec plus ou moins de galère.

                Tu peux très bien avoir un packaging des autotools contenu dans une archive, le fait qu'il y ait 1, 2, 10, 1000000 exécutables dans l'archive ne change rien : il faut installer un système de build sur la machine.

                Cela dit, cmake est nettement plus facile à utiliser que les autotools.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: robuste ?

              Posté par  . Évalué à 4.

              aucun ne marche sous windows sans devoir installer des outils tiers

              CMake est relativement self-contained: compilateur C++, puis selon les fonctionnalités souhaités: zlib, libarchive, curl, curses, xmlrpc-c. Ensuite, ça te génére un projet qui utilises les outils "natifs" (nmake, jom, borland, mingw, cygwin sous windows)
              Pour scons, waf, t'as juste besoin d'un interpréteur python classique, ce qui n'a rien d'extravagant pour des builders écrit en ce langage.
              Autotools, ça a besoin: un shell posix (voire bash à cause des bashisms), perl, m4, pkg-config, et pas mal d'emmerdes parce que autotools a été fait pour les vrais systèmes d'exploitations et pas les jouets de micromou.

              • [^] # Re: robuste ?

                Posté par  . Évalué à 3.

                maven, il te faut Java (pour un projet Java on va dire que c'est le minimum de toute manière) et maven qui s'installe en décompressant un zip.

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

                • [^] # Re: robuste ?

                  Posté par  . Évalué à 3.

                  Oui en même temps pour un truc qui t'impose ta façon de travailler au lieu de s'adapter à un contexte donné c'est facile.

                  Note que je ne critique pas le fait de travailler de manière standard, juste que j'imagine les contorsions qu'il faudrait pour implémenter la chaîne de production d'une distrib Linux.

          • [^] # Re: robuste ?

            Posté par  . Évalué à 5.

            « Pour moi il est vraiment temps que le libre se trouve un autre outil de build que l'infernale combinaison autoconf/automake/libtool/make »

            As-tu essayé cmake ou Rake ? Il me semble que ces deux outils répondent assez au besoin d'avoir un truc simple et relativement portable et assez cohérent.

            • [^] # Re: robuste ?

              Posté par  (site web personnel) . Évalué à 3.

              perso j'ai adopté scons mais je pense que n'importe quel outil sera meilleur que autoconf/make, que ce soit cmake, waf , rake ... Il faudrait juste arreter d'utiliser par default, pour chaque nouveau projet libre , les autotools.

              • [^] # Re: robuste ?

                Posté par  . Évalué à 1.

                bah au moins, autotools/autocrotte ne te plombe pas la cross-compilation comme cmake le fait régulièrement

                • [^] # Re: robuste ?

                  Posté par  . Évalué à 4.

                  Mwai, enfin, autotruc+pkg-config en cross compil, ça peut faire des choses très très bizarres (et qui gauffrent)

  • # Exemples non visibles

    Posté par  . Évalué à 3.

    J'ai l'impression que certains exemples sont passés à la trappe (cf. Gradle).

    • [^] # Re: Exemples non visibles

      Posté par  . Évalué à 2.

      Arg ! J'avais tout relu pourtant !

      L'exemple était :

      apply plugin: 'java'

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

  • # coquilles

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    s/tryptique/triptyque/

    Et il manque l'exemple pour Gradle.

    Sinon c'est intéressant :)

    • [^] # Re: coquilles

      Posté par  . Évalué à 3.

      s/tryptique/triptyque/

      En effet, c'est le deuxième point des avantages des autotools.

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

    • [^] # Re: coquilles

      Posté par  . Évalué à 5.

      Quelques petites coquilles récoltées:

      Introduction

      Cette dépêche a pour objectif de faire découvrir ou redécouvrir des outils de construction.

      Un « builder » ?

      Le reste de la dépêche s'attelle à en décrire un certain nombre parmi les plus connus.

      Le vénérable Make

      Make est une sorte de langage Rule Based Programming dans lequel on spécifie des règles sous la forme :

      rapidité : il construit un arbre de dépendances et exécute en parallèle ce qui peut l'être (aujourd'hui tous les builders le font)

      Le peu connu OMake

      Il utilise une syntaxe similaire à Make mais offre quelques fonctionnalités supplémentaires

      La gestion du projet dans plusieurs répertoires ou dans une hiérarchie de répertoires

      Il est possible de surveiller le système de fichiers en continu pour relancer la construction dès qu'un fichier est modifié

      Un challenger scons

      killer feature : scons cache le résultat de chaque opération (compilation, liaison, etc.)

      Il comble les lacunes de scons (complexité et lenteur) en proposant des améliorations telles qu'une sortie en couleur et un meilleur support de la compilation parallèle.

      Celui de Google : Ninja

      Ceux-ci utilisaient Make mais trouvaient que la génération de l'arbre des dépendances était bien trop lente (le temps avant de commencer serait d'une minute).

      Déclare une règle cc où :
      - $in correspond aux fichiers d'entrée
      - $out au fichier de sortie

      L'usine à build Apache Maven

      une description plus détaillée des inconvénients se trouve sur le blog de Sonatype

      Les autres (buildr, gradle…)

      Gradle celui-ci gère les projets via un DSL à la place DE FICHIER XML

      ainsi il pourra plus facilement travailler sur des projets Groovy ou Scala.

      CMake

      Il génère un ou des fichier(s) recette(s)

      (CMake supporte GoogleTest, CXXTest, SQuish et s'intègre facilement aux autres systèmes)

      Les autotools

      la plus large collection d'extensions parmi tous les moteurs de production de haut niveau présentés.

      re-générer le système de construction est une tâche relativement complexe, souvent laissée à la charge d'un script shell (autogen.sh)

      • [^] # Re: coquilles

        Posté par  (site web personnel) . Évalué à 1.

        Une autre (deux en fait) : « éxecute une parallèle » —> « exécute en parallèle ».

  • # Un oublie de taille...

    Posté par  . Évalué à 4.

    Même si il a été cité: Waf, qui est un outil qui commence à être connu notamment pour sa gestion quasi-parfaite du langage Vala.

    • [^] # Re: Un oublie de taille...

      Posté par  . Évalué à 2.

      sa gestion quasi-parfaite du langage Vala.

      Qu'entends-tu par là ? Il intègre des règles pour transformer les *.vala en *.c ?

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

      • [^] # Re: Un oublie de taille...

        Posté par  . Évalué à 1.

        Je n'est pas utilisé le bon mot j'aurais dû dire "simple".
        Mais oui, ça fait partie de l'une des fonctionnalité simple et sympathique de Waf.

    • [^] # Re: Un oublie de taille...

      Posté par  . Évalué à 3.

      Même si il a été cité: Waf, qui est un outil qui commence à être connu

      Le projet Samba4 y est passé l'année dernière. Il y a 2 ou 3 billets intéressants de l'un des 2 gros contributeurs.

  • # Inconvénient des autotools

    Posté par  (site web personnel) . Évalué à 9.

    Les autotools

    Inconvénients :

    • dépendance à la présence d'un shell bourne (ou compatible), m4, et perl

    D'accord pour la complexité d'utilisation, mais ces dépendances, c'est une blague : les autotools sont faits pour que, côté utilisateur, il n'y ait qu'une dépendance au shell. Côté auteur, il faut un shell, m4 et Perl en effet, mais il semble évident que, pour utiliser un système de construction, il faut l'avoir installé, ou du moins ce qui le constitue, non ?

    • [^] # Re: Inconvénient des autotools

      Posté par  . Évalué à 4.

      Côté auteur, il faut un shell, m4 et Perl en effet, mais il semble évident que, pour utiliser un système de construction, il faut l'avoir installé, ou du moins ce qui le constitue, non ?

      Oui mais face à OMake ou ninja qui ont un nombre de dépendance extrêmement faible même coté développeur surtout qu'un bourne shell et m4 sous Windows c'est pas ce qu'il y a de plus simple.

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

      • [^] # Re: Inconvénient des autotools

        Posté par  (site web personnel) . Évalué à 8.

        Les autotools ne sont clairement pas fait pour le monde Windows (hormis Cygwin), ils sont plutôt fait le monde Unix (au sens large), qui étaient la cible privilégiée des outils GNUs. Je doute qu'il y aie beaucoup d'alternative qui gère le cas des bibliothèques partagées sous HPUX, par exemple. Le fait qu'aujourd'hui on préfère en général cibler le triptyque macos/linux/windows, et cibler autre chose que des adeptes de la ligne de commande rend certainement l'outil inadapté aux objectifs de beaucoup de monde, mais absolument pas un outil dépassé. Jusqu'à preuve du contraire, la quasi-totalité des constituants de base d'un système linux (glibc, gcc, etc...) l'utilisent encore, par exemple.

        Et je rejoins ce que disait le commentaire précédent, il n'y a aucune dépendance pour l'utilisateur final excepté le shell bourne (requis par POSIX) et la commande make. m4, comme perl et consort, c'est sur la machine du développeur que c'est nécessaire.

        Parmi les autres approximations de l'article:
        - il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison
        - il y a eu effectivement des incompatibilités entre versions, particulièrement la version 1.4 qui date de l'an 2000, et celles qui ont suivi, mais rien d'exceptionnel par rapport à d'autres outils

        Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.

        • [^] # Re: Inconvénient des autotools

          Posté par  (site web personnel) . Évalué à 3.

          Mon experience avec les autotools, qui remonte a quelques années certes mais j'en ai bouffé pas mal, c'est quand même que ça ne marche bien que dans des environnements 100% gnu. Sous hpux , irix ou dec osf il y avait toujours un truc qui foirait, en particulier quand libtool entrait en jeu , et globalement c'était bien plus simple d'écrire du platform-specifique en dur dans les makefiles pour chaque plateforme plutot que d'essayer de rescotcher les bouts d'autotools qui se detachaient.

          • [^] # Re: Inconvénient des autotools

            Posté par  (site web personnel) . Évalué à 4.

            D'un autre coté, si cela peux les forces à mettre les outils GNU, ce serait pas plus mal. J'ai fait un peu de HP-UX et de AIX et c'est vraiment la misère... C'est pas croyable d'avoir payé ces machines aussi chères à l'époque pour avoir un shell aussi pourrit. N'importe quel GNU/Linux est plus agréable.

            D'ailleurs, pourquoi ils n'installent pas les outils GNU ?

            • [^] # Re: Inconvénient des autotools

              Posté par  . Évalué à 3.

              Ils ont peur d'attraper une maladie contagieuse.

            • [^] # Re: Inconvénient des autotools

              Posté par  . Évalué à 3.

              D'ailleurs, pourquoi ils n'installent pas les outils GNU ?

              Solaris, HP-UX, AIX, c'est du UNIX, mais c'est aussi du proprio…

              Par exemple Solaris est livré avec le compilateur Sun Studio. Ça peut être intéressant de l'utiliser sur une machine SPARC pcq Sun Studio contient des options de compilations spécifiques à ce processeur qui n'existent pas dans GCC.

              Pourquoi ils ne contribuent pas plutôt à GCC ou LLVM/Clang ? Ça je n'en sais rien. Peut-être que si Oracle n'avait pas racheté Sun, ce serait le cas, vu que Sun était plus « libre-friendly » (OpenSolaris, …).

              Donc le fait qu'ils n'installent pas les outils GNU est sans doute dû au fait que ces OS sont quand même propriétaire, et qu'ils ont développé depuis de nombreuses années des logiciels maisons qui s'intègrent bien à leur OS.

              • [^] # Re: Inconvénient des autotools

                Posté par  (site web personnel) . Évalué à 3.

                Je dirais plutôt qu'ils se sont endormis sur leur shell ;-) On avait installé bash à l'époque sur ces machines et il marchait très bien et bien mieux que leur shell de base...

                • [^] # Re: Inconvénient des autotools

                  Posté par  . Évalué à 1.

                  il marchait très bien et bien mieux que leur shell de base

                  J'ai ouïe dire que ksh est plus rapide que bash. La rapidité d'exécution n'est pas le seul critère mais il compte.

                  • [^] # Re: Inconvénient des autotools

                    Posté par  (site web personnel) . Évalué à 4.

                    Je parle du shell interactif et non du shell qui sers dans les script. Par exemple, debian utilise maintenant dash dans les script par défaut et non plus bash. Le shell de l'utilisateur root reste bash.

                    De mémoire, c'était plutôt sh ou csh de base donc sans gestion de l'historique pour revenir aux dernières commandes... Bref, pour être honnête, ils s'étaient pas foulés sur cette question.

        • [^] # Re: Inconvénient des autotools

          Posté par  . Évalué à 4.

          Pour avoir rédigé cette partie, je ne suis pas d'accord sur ce que tu qualifies d'approximations.

          il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison

          Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle. Et même quand ça passe, ça ne garantit absolument pas l'absence d'effets de bords au point que certains en déconseillent l'utilisation ou bien de s'en servir comme base pour patcher directement le système de construction.
          http://www.redhat.com/archives/rhl-devel-list/2008-October/msg00866.html

          il y a eu effectivement des incompatibilités entre versions, particulièrement la version 1.4 qui date de l'an 2000, et celles qui ont suivi, mais rien d'exceptionnel par rapport à d'autres outils

          Pourquoi la majorité des distributions GNU/Linux fournissent encore autoconf 2.13 (sorti en 1999) ? Pourquoi Debian maintient 4 version d'automake, Fedora 5 ? (non, ce n'est pas par plaisir) Même si le nombre décroit petit à petit, tu as encore des paquets qui ont encore besoin de ces versions (autoreconf et autogen.sh ne peuvent pas grand chose la plupart du temps, patcher reviendrait à remettre à plat le système de construction). Ok, ça s'améliore, mais on est encore loin des autres outils en ce domaine.
          Certes, c'est symptomatique d'une mauvaise utilisation d'autotools, mais un développeur qui maitrise autotools (malgré qu'il soit le plus utilisé et le plus avancé parmi ceux discutés), ça ne court pas les rues.

          Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.

          La documentation d'autotools est certes fouillie, mais relativement complète, il y a d'excellents tutoriaux (celui d'Alexandre Duret-Lutz, l'autobook, les tutoriaux d'openismus qui présente les bases et l'utilisation non-récursive). Quant au manque d'homogénéité, c'est defective by design, à moins de réécrire en grande partie autotools, ou de se restreindre à un sous-ensemble, on ne peut faire mieux.
          Le vrai problème c'est qu'autotools est trop complexe pour le développeur "moyen" (ou que le développeur "moyen" soit incapable d'appréhender celui-ci par manque de temps ou par incapacité mentale), une meilleure documentation ne changera pas significativement cet état de fait (avec les ressources sus-mentionnées, on doit pouvoir arriver à un niveau de compétences plus que suffisant pour utiliser quotidiennement autotools sans être Fabrice Bellard)

          • [^] # Re: Inconvénient des autotools

            Posté par  (site web personnel) . Évalué à 3.

            Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle.

            Curieux, il me semble que l'empaqueteur se base sur le tar.gz, et donc plus besoin de tout re-générer ? À moins qu'il y ait besoin de patcher le système de build et donc de re-générer ?

            • [^] # Re: Inconvénient des autotools

              Posté par  . Évalué à 3.

              La plupart du temps, c'est dû au fait que la tarball a été généré avec une version plus ancienne de la chaine autotools (soit parce que c'est qu'utilise le mainteneur upstream, soit parce que cette dernière a été mise à jour depuis la dernière release du projet).
              Ça arrive fréquemment lors des cycles de développement, où la chaine autotools est très récente (ça permet de tester celle-ci, et de détecter quelques gruikeries également que l'on remonte en upstream). Même avec des projets très réactifs et avec un très bon niveau d'expertise avec autotools (ie: GNOME), il m'arrive parfois de devoir regénérer la chaine temporairement en attendant la prochaine release.

    • [^] # Re: Inconvénient des autotools

      Posté par  . Évalué à 4.

      Pour ma part, j'estime que l'article est destiné à un public de développeurs, l'utilisateur s'en branle royalement du système de construction (la plupart du temps, il récupérera un paquet binaire soit fourni par le mainteneur, soit par sa distro). De mon point de vue, la plupart des outils présentés se valent plus ou moins côté utilisateur.

      Je remarquerais que parmis les utilitaires non-java, cmake est le seul à proposer nativement la génération de paquets binaires sous différents formats. Et j'en profite pour saluer le fabuleux travail d'Eric Noulard sur CPack, sans qui CPack aurait été déprécié et inutilisable depuis longtemps.

  • # pour ruby : rake

    Posté par  . Évalué à 5.

    Un petit oubli : du côté de ruby rake qui est pas mal utilisé il me semble.

    Le Rakefile étant en ruby, la syntaxe est appréciable, surtout face aux Makefile…

    Peut-être que des gens l'utilisent ? Ça m'intéresserais d'avoir des retours dessus.

  • # Les autotools n’impliquent pas GNU make

    Posté par  (site web personnel) . Évalué à 4.

    gnu make : bien évidemment le moteur GNU make pour exécuter le makefile résultant.

    Non, à ma connaissance automake génère des Makefile n’utilisant aucune extension propre à GNU make, et qui devraient être utilisables avec à peu près n’importe quel make en circulation (sauf sans doute nmake sous Windows).

  • # Sortie de GSRC

    Posté par  (site web personnel) . Évalué à 3.

    À noter, là sortie de GSRC, un outil qui permet d'installer les dernières versions officiels des outils gnu.

  • # make

    Posté par  . Évalué à 10.

    • dépendances : on doit gérer à la main les dépendances entre les fichiers

    Heu, pas obligatoirement. Pour mon code source, les dépendances sont auto-calculées. C'est même plutôt simple :

    all: prog

SRC := $(wildcard *.c)
OBJ := $(patsubst %.c,%.o,$(SRC))
DEP := $(patsubst %.c,%.deps,$(SRC))

-include $(DEP)

%.deps: %.c Makefile
        gcc -MM $< >$@

%.o: %.c Makefile
        gcc -o $@ $<

prog: $(OBJ)
        ld -o $@ $^

    Bon, d'accord, c'est un exemple simple. Mais il est possible de créer des dépendances dynamiques avec make.

    Un des très gros avantage de make sur tous les autres builders, c'est qu'il fait partie de [POSIX](http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm), et que par conséquent il est disponible de base, ce qui n'est pas le cas des autres builders.

    Aussi, make est généraliste. Il n'a aucune connaissance d'un quelconque langage d'entée. On peut tout traiter comme une source (eg. code source, image, video, document texte...) et comme sortie (eg. binaire, image, video, document HTML...).

    J'ai même le frontal de mon projet qui est un script make (un Makefile exécutable, quoi).

    Hop,
    Moi.

    • [^] # Re: make

      Posté par  . Évalué à 1.

      Pour le coté POSIX, la souplesse et le fait que c'est un langage nous sommes d'accord.

      Je ne connaissais pas patsubst, mais le problème c'est que normalement il faut que cette recherche soit récursive.

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

      • [^] # Re: make

        Posté par  . Évalué à 6.

        Je crois que tu as raté le point important :

        gcc -M

        Et ça, ça te sort une liste dans un fichier de tous les headers ou autre include utilisés dans ton fichier source sous forme de règle make. Si tu l'inclues c'est gagné car si un des headers est plus récent que la source, on recompile les objets basés sur ce fichier source.

        (Ca fait longtemps que j'y ai plus touché, mais en gros c'est ça)

        • [^] # Re: make

          Posté par  . Évalué à 2.

          Je comprends ! C'est intéressant, mais j'aurais alors une question en plus.

          Si je comprends bien la Makefile au dessus va créer des fichiers *.deps qui sont au formats Makefile et qui sont inclus dans le Makefile par la directive -include $(DEP). Mais cette dernière prends en compte dynamiquement les fichiers en question ?

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

          • [^] # Re: make

            Posté par  . Évalué à 6.

            En fait, il y a deux directoves d'inclusion :

            include file1

            Si file1 est manquant, alors make sort en erreur.

            -include file2

            Si file2 est manquant, alors make va chercher une règle de génération qui permet de l'obtenir. Si c'est possible, alors make génère file2, et re-parse le Makefile. Si il n'y a pas de règle, alors make sort en erreur.

            Et comme dans l'exemple on a une règle de génération, alors make va gérer ça proprement, puisque tous les fichiers à inclure dépendent des fichiers sources. Magique ! :-)

            Hop,
            Moi.

            • [^] # Re: make

              Posté par  . Évalué à 3.

              Très intéressant. C'est exactement le genre de découvertes que j'espérais faire avec cette dépêche :)

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

      • [^] # Re: make

        Posté par  (site web personnel) . Évalué à 6.

        Je vois que tu ne connaissais ni patsubst ni include (avec -include et l'quivalent GNU sinclude), ni gcc -MM... Bref, tu ne connaissais pas make ! Ce n'est pas un critique mais une constatation.

        Le problème des dépendances est un problème de compilateur car il faut savoir lire le langage pour le faire correctement. Tout compilateur devrait savoir écrire les règles de dépendances (comme gcc -MM).

        Personnellement, j'utilise make car je le trouve souple et indépendant du langage. Tu l'étends avec tes macros, tes scripts... C'est pas un système à greffon qui t'impose son langage (et en plus ne parle que XML pour certain).

        Bref, make, c'est quand même du bonheur même si parfois, c'est vrai qu'on s'arrache les cheveux sur un cas particulier. Les joies du deboguage ;-)

        • [^] # Re: make

          Posté par  . Évalué à 3.

          Je vois que tu ne connaissais ni patsubst ni include (avec -include et l'quivalent GNU sinclude), ni gcc -MM... Bref, tu ne connaissais pas make ! Ce n'est pas un critique mais une constatation.

          include si mais pour faire de l'inclusion bête et méchant. gcc -MM j'en avais entendu parlé mais comme je n'avais pas trouvé de vrais moyens de s'en servir, j'ai rapidement oublié. Pour ce qui est de patsubst, j'utilisais ${SRC:.c=.o}.

          Le problème des dépendances est un problème de compilateur car il faut savoir lire le langage pour le faire correctement. Tout compilateur devrait savoir écrire les règles de dépendances (comme gcc -MM).

          Je suis d'accord avec toi. J'adapterais cette solution pour convenir à LaTeX à grand coup de sed.

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

          • [^] # Re: make

            Posté par  (site web personnel) . Évalué à 3.

            Pour compléter, il existe la commande makedepend : create dependencies in makefiles.
            Par contre, je sais pas si ça apporte quelque chose comparé à gcc -MM...

            Et je n'imagine même pas bosser sur un gros projet sans génération auto des dépendances...

  • # app, (b)jam

    Posté par  (site web personnel) . Évalué à 4.

    Il y a aussi moyen de rajouter
    - aap (de Bram Moolenaar), assez similaire à scons dans mes souvenirs dans les grands principes de fonctionnement
    - jam et bjam ; bjam est ce qui est utilisé par boost (.org)

  • # Et jam ???

    Posté par  . Évalué à 3.

    Récemment je suis tombé sur jam; mais bon je ne suis pas trop entré dans les détail vu que une fois jam compilé j'ai pu compiler le programme qui le nécessitait...

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Et jam ???

      Posté par  . Évalué à 3.

      Jam, oui mais lequel ?

      • Perforce Jam: l'original

      • Boost jam (bjam): utilisé principalement par Boost qui est en train de passer à CMake, il est à la base de Boost.Build (en gros une collection de règles pour le premier)

      • et une bonne dizaine de forks plus ou moins confidentiels.

      La famille Jam se rapproche plutôt de make et de scons, il orchestre directement la phase de compilation. À partir de maintenant, je limiterais mes propos à Boost.jam (je n'ai jamais utilisé les autres): il est extensible (boost-build utilise python), il a une syntaxe simple inspiré de make, il gére nativement les variantes de compilation (avec CMake, c'est une horreur, autotools un peu moins), il a un support décent de la plupart des chaines de compilations, par contre, très peu de règles pour gérer les outils tiers/bibliothèques tierces (de mémoire: qt, zlib, gettext, doxygen, fop, xsltproc dans la distro, pour le reste, il y a une forte probabilité que tu doives écrire à la main les règles.)
      Sinon, c'est plutôt rapide.

  • # Buildout

    Posté par  . Évalué à 7.

    J'aimerais attirer votre attention sur un outil haut niveau développé en Python par la communauté Zope/Plone : Buildout.

    Buildout est une sorte de Maven, mais agnostique de toute technologie ou langage particuliers. Il s'agit d'un outil de déploiement extrêmement puissant et efficace. A tel point que des éditeurs de Cloud Computing l'utilisent depuis quelques temps pour déployer des services : http://www.slapos.org/wiki/slapos.Why.Buildout.

    Vous pouvez trouver plus d'informations sur http://buildout.org et sur la traduction française du didacticiel officiel : http://ccomb.free.fr/buildout/tutorial.fr.html

    J'ai personnellement découvert cet outil il y a un peu plus d'un an, et j'ai maintenant du mal à m'en passer et/ou à trouver une alternative intéressante.

  • # Et premake ???

    Posté par  . Évalué à 3.

    Je tiens à citer premake que je trouve d'une grande simplicité.

  • # Avantages CMake

    Posté par  . Évalué à 5.

    Dans les avantages de CMake, il y en a un qui est très important pour mes cas d'utilisation et qui me semble important de préciser, c'est la construction du système de compilation et la compilation elle même hors sources.

    Je peux, avec la même arborescence de sources créer 4 dossiers de compilation avec des options différentes (debug/optim/cross toolchain/...) et tout est généré dans ces dossier.
    Si bien qu'un "make distclean" (ou un truc du genre) se résume en un "rm -rf build_dir"

    • [^] # Re: Avantages CMake

      Posté par  . Évalué à 3.

      Euh, ca ce n'est pas specifique a CMake, les autotools le font tres bien aussi.

      • [^] # Re: Avantages CMake

        Posté par  . Évalué à 2.

        j'ai pas dit que c'était spécifique, j'ai dit que c'était un point fort.

        d'ailleurs, c'est dans les avantages de scons aussi :

        range tous les produits de la compilation dans un "build directory", pratique pour séparer les choux et les carottes.

        Et pour les autotools, quand je m'en sers, mais c'est peut-être moi qui ne sait pas m'en servir, j'ai des fichiers générés dans les sources moi (des Makefile ou autre fichiers intermédiaires du configure)

        • [^] # Re: Avantages CMake

          Posté par  . Évalué à 3.

          Et pour les autotools, [...] j'ai des fichiers générés dans les sources moi (des Makefile ou autre fichiers intermédiaires du configure)

          Les auto-tools savent très bien générer des Makefiles pour la compilation out-of-tree. Il suffit de faire :

          $ tar xjf package-1.2.3.tar.bz2
$ ls -F
package-1.2.3/
$ mkdir build-package
$ cd build-package
$ ../package-1.2.3/configure --blabla
$ make

          Alors, tous les fichiers générés seront dans le répertoire build-package, et le répertoire des sources ne sera pas modifié.

          Si le make disponible connait les VPATH (GNU make), alors les Makefiles générés utiliseront cette fonctionnalité ; sinon, les Makefiles utiliseront des contournements pour simuler les VPATH.

          Cependant, les auto-tools génèrent effectivement des fichiers dans le répertoire sources, mais uniquement dans la phase pré-empaquetage. C'est à ce moment-là que les fichiers configure, Makefile.in (et autres) sont générés. Mais ces fichiers font partie de la livraison.

          Enfin, je ne suis pas un très grand fan des auto-tools, car ils ne savent pas très bien gérer la compilation croisée la plupart du temps, sauf si le développeur a fait bien attention. La faute en incombe pour partie (~75%) aux auto-tools, et pour partie au développeur (25%).

          Hop,
          Moi.

      • [^] # Re: Avantages CMake

        Posté par  . Évalué à 4.

        les autotools le font tres bien aussi.

        Autotools sait faire, sauf que peu de développeurs savent s'en servir correctement. Le résultat c'est que la compilation out-of-source est dysfonctionnelle sur la plupart des projets gérer par autotools.
        Lorsque je dirige des projets sous autotools, j'interdis formellement aux développeurs (sauf ceux qui ont démontrés leurs compétences à le faire) de modifier le système de construction sinon c'est le bordel assuré (scripts mal branlés, artefacts de compilations oubliés, mal testé, etc ...). Avec CMake, je peux me permettre un peu plus de souplesse à condition de fixer quelques guidelines et quelques explications (principalement, parce que la doc cmake -bouquin compris- est à chier, certes moins que celle d'autotools)
        Avec autotools, faut introduire plusieurs langages (perl, shell, m4), expliquer les différences entre chaque version, l'habituer à un environnement de développement parfois non familier (pour les terreux sous windows -l'horreur-). Bref, on perds du temps, le résultat est à chier, au final, soit j'interdis aux bras cassés de toucher au système de construction, soit j'impose un système de construction plus "simple" selon le vécu de l'équipe (CMake, make, scons, etc ...)

        • [^] # Re: Avantages CMake

          Posté par  (site web personnel) . Évalué à 2.

          Autotools sait faire, sauf que peu de développeurs savent s'en servir correctement. Le résultat c'est que la compilation out-of-source est dysfonctionnelle sur la plupart des projets gérer par autotools.

          Alors qu'un joli make distcheck va vérifier tout seul que la compilation out-of-the-source fonctionne bien (et pleins d'autres choses très agréables d'ailleurs) :(

  • # templates avec make

    Posté par  . Évalué à 5.

    Quand on commence à utiliser make, on pense qu'il faut écrire toutes les cibles à la main. En particulier quand on doit générer plusieurs exécutables ou librairies (ou autre, qui ne soit pas une simple substitution de patterns du genre .c vers .o ).

    Plutôt que d'écrire une rêgle à chaque fois, on peut utiliser la commande eval qui permet d'écrire des templates

    Avec ce système, chaque construction peut s'écrire avec une variable, contenant les sources impliquées (il faudra parfois en ajouter d'autres, contenant par exemple les libs pour le link, ou d'éventuelles options spécifiques pour le compilateur).

    C'est très bien expliqué ici:

    http://www.gnu.org/software/make/manual/html_node/Eval-Function.html#Eval-Function

    J'ajoute quand même une remarque à la doc de make, cela m'ayant posé problème au départ:
    Dans les templates, les seules variables à déréférencer sont les vars qu'on passe en paramètre depuis le "eval": $(1) et suivants.
    Les autres variables doivent être protégées avec un '$' supplémentaire.

    Donc on écrit directement $(1) pour les paramètres du template.
    Par contre, les variables qui servent à la rêgle vont s'écrire ainsi: $$(CXX)

    Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr

    • [^] # Re: templates avec make

      Posté par  (site web personnel) . Évalué à 6.

      C'est très bien expliqué ici:

      http://www.gnu.org/software/make/manual/html_node/Eval-Function.html#Eval-Function

      Oh bon sang ! C'est ça que je n'ai jamais aimé avec make, dès qu'on sort des cas simple où on écrit les règles à la main, ou à la rigueur avec des règles génériques : ça devient absolument illisible. Plus abscons, tu meurs.

      • [^] # Re: templates avec make

        Posté par  . Évalué à 2.

        Je n'ai pas dit que c'était lisible :)

        Mais ça ne s'écrit qu'une seule fois, et ça peut servir dans les projets qui construisent plein d'exécutables (dans mon cas, il s'agit de plein de petites libs et des exécutables associés pour les tests unitaires).

        Dans le post ci-dessus, j'ai oublié de préciser que peur débugger «eval», c'est à dire avoir une sortie claire des rêgles qui vont être générées, il faut utiliser «info» (en lieu et place de «eval»). C'est la commande siamoise indispensable pour s'y retrouver.

        $(info text...)
  This function does nothing more than print its (expanded) argument(s) to standard output.
  No makefile name or line number is added.
  The result of the expansion of this function is the empty string.

        Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr

    • [^] # Re: templates avec make

      Posté par  . Évalué à 4.

      Oui on peut faire plein de bonnes choses avec GNU make, par contre ça devient du GNU make et plus du make... donc la portabilité en prends un coup, non ?
      Ceci dit si quelqu'un utilise ou connait des utilisations d'autres implémentations de make, je suis preneur d'infos. De même si quelqu'un connait une bonne doc qui distingue les extensions GNU du standard. (C'est un peu comme pour le bash, difficile de savoir ce qui n'est pas du sh)

      • [^] # Re: templates avec make

        Posté par  . Évalué à 3.

        De même si quelqu'un connait une bonne doc qui distingue les extensions GNU du standard.

        C'est ça le standard: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html (ce qui n'est pas listé dedans, est une extension vendeur)
        Le manuel GNU explique quelles sont les innovations propre à GNU Make: http://www.gnu.org/software/make/manual/make.html#Features
        Pas trop de documentation à ce sujet pour bsd make (enfin, la famille dérivée de pmake, les utilitaires make ont pas mal divergés selon les *BSD)
        Le guide de référence: http://www.freebsd.org/doc/en/books/pmake/index.html (plus lire la page man fourni par ta distro *BSD)

        C'est un peu comme pour le bash, difficile de savoir ce qui n'est pas du sh

        Le shell Posix s'inspire principalement de ksh88 (avec quelques bizarreries comme echo/print, la syntaxe des fonctions etc ...)

        http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html

        • [^] # Re: templates avec make

          Posté par  . Évalué à 1.

          Merci de ces liens très instructifs (je suis un peu déçu d'avoir loupé le deuxième lors de mes longues errances sur la page de GNU make...). Ceci dit, %, $^ et define sont quand même assez essentiels pour faire un makefile réutilisable, et sont donc spécifiques à GNU make... donc quitte à ne plus être standard, pourquoi pas un outil un peu moins abscons du genre cmake (parce que le debug de makefile plein de templates, c'est quand même la galère)

          Et pour le dernier, ça m'empêchera peut-être d'écrire les bashismes que me suggéraient mes man bash

  • # Le grand absent: qmake

    Posté par  (site web personnel) . Évalué à 5.

    qmake, outil créé par les développeurs de Qt, qui sert de générateur de makefile et de format de projet pour l'IDE Qt Creator.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Y'a gprbuild aussi

    Posté par  . Évalué à 4.

    Puisqu'on en est à rajouter les outils qui ne sont pas dans la dépêche, j'en profite pour citer gprbuild. C'est un outil de build libre de la société AdaCore, qui fournit aussi gnat, un compilateur Ada libre.

    gprbuild est une sorte d'extension du système de build de gnat qui permet de gérer des projets écrits dans de multiples langages (y compris des mélanges). Bon ok, c'est fortement orienté sur Ada et C, mais on peut très bien envisager d'autres langages.

    Son principal avantage selon moi est sa simplicité enfantine : on donne les fichiers sources (ou les répertoires qui les contiennent), le nom et le type de projet (executable ou bibliothèque) et les flags à utiliser pour les étapes intermédiaires du build. Le reste juste marche tout seul.

    Côté "inconvénient", il faut crée un fichier de description pour chaque cible du build (i.e. chaque exécutable et chaque bibliothèque), mais comme ceux-ci sont vraiment petits (typiquement moins de 20 lignes, espacement compris) et qu'on peut crée des fichiers qui servent d'agrégat, ce n'est pas très génant même pour de gros projets.

    Bref, un vraiment bon outil.

    • [^] # Re: Y'a gprbuild aussi

      Posté par  . Évalué à 3.

      Ta description m'a intéressée et j'ai voulu essayé. Je l'ai installé via apt-get sans problème puis j'ai parcouru très vite fait cette doc (j'ai surtout vite fait regardé les exemples) : http://www.adacore.com/wp-content/files/auto_update/gprbuild-docs/html/gprbuild_ug.html

      J'ai donc tenté avec un petit programme d'exemple de 3 fichiers, j'ai écris un build.gpr ainsi :

      project Build is
  for Languages use ("C");
  for Source_Dirs use ("src");
  for Object_Dir use "build";
  for Exec_Dir use ".";
  for Main use ("hello");
end Build;

      un petit gprbuild et pouf j'ai l'éxécutable !

      J'ai du y passé 10 à 20 minutes grand max. Cet outil est vraiment pas mal ! Pas très flexible, mais ce qu'il fait, il le fait bien. Je le garde dans ma besace :D

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

  • # OMake, c'est bien!

    Posté par  (site web personnel) . Évalué à 3.

    Pour un projet C++, OMake est mon préféré. J'ai bataillé avec gmake et CMake, et certaines constructions sont bien plus faciles à obtenir avec OMake. Un exemple de dépendances courant est par exemple de devoir d'abord compiler un petit programme, lequel va générer du code, pour ensuite compiler le plus gros programme.

    Avec gmake et CMake, c'est un cauchemar et la gestion des dépendances devient très complexe, au point qu'il devient généralement plus aisé d'avoir deux cibles, une pour la génération, et une pour le programme principal. De plus, même si le code généré demeure inchangé, la date du fichier, elle, a changé, et on se retrouve avec des recompilations monstres qu'il faut dompter à coup de copies temporaires crades.

    Avec OMake, qui gère explicitement le code généré, et se base sur le contenu du fichier pour détecter les modifications, c'est fait en deux coups de cuiller à pot, et les compilations sont minimales mais correctes. L'on regrettera peut-être la difficulté de faire des compilations "hors sources" (les mount virtuels aident un petit peu), et la relative difficulté à utiliser des commandes un peu plus complexes, la petite taille de la communauté n'aidant pas. Par exemple, le support des en-têtes pré-compilées requiert un bidouillage des règles initiales qui est probablement simple, mais absolument pas évident.

  • # Phing

    Posté par  (site web personnel) . Évalué à 2.

    Il manque Phing dans la liste des outils de constructions. Phing est basé sur Ant mais écrit en PHP au lieu de java. Il est par exemple utilisé dans les tâches symfony (en version 1).

    http://phing.info/

  • # Simple Build Tool

    Posté par  . Évalué à 3.

    Juste pour être encore plus exhaustif je rajoute Simple build tool.
    C'est un outil de gestion et compilation de projet scala.
    https://github.com/harrah/xsbt/wiki

  • # redo : minimaliste, correct et unixien

    Posté par  . Évalué à 2.

    redo (cf article de Bruno Michel du 11/1/2011) est un outil

    • minimaliste (une version correcte mais pas optimale en quelques centaines de lignes de sh existe)
    • très unixien (on peut écrire ses scripts de compilation dans le langage de son choix)
    • qui gère correctement les dépendances (i.e. si je change un paramètre de la commande utilisée pour recompiler certains fichiers, il recompilera les fichiers en question et uniquement ceux-là).

    Le concept se comprend en quelques minutes ou quelques heures, il faut parfois un peu de pratique ensuite pour trouver comment faire bien ce qu'on faisait (mal) avec make, mais globalement, ça marche très bien. Je l'ai adopté depuis quelques mois et j'en suis très content...

Suivre le flux des commentaires

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