Waf - un système de construction de logiciels

Posté par . Modéré par Mouns.
Tags :
10
23
déc.
2008
Technologie
Après trois ans de développement, le projet Waf vient de présenter une version stable numérotée 1.5.2. Il s'agit d'un système de construction de logiciel généraliste et minimaliste (license BSD), basé sur Python, utilisé par de nombreux projets libres (xmms2, midori...) ou propriétaires, sur plateformes de type Linux.

Né du constat d'un manque de flexibilité d'un grand nombre de systèmes, Waf présente un système d'extensions basé sur les aspects qui lui permet d'être extrêmement adaptable tout en mettant en avant d'excellentes performances par comparaison avec d'autres outils basés sur la génération de Makefiles (comme les Autotools) ou sur l'utilisation directe d'un langage (Scons).

Les principaux éléments de cette version sont l'intégration d'exemples similaires à Make, l'ajout d'exemples pour la compilation par lots, l'utilisation de GCC en complément du préprocesseur interne à Waf, la documentation des API par le biais du Waf Book, et diverses améliorations pour le support de plateformes autres que Linux.

Waf reprend plusieurs idées principales d'autres systèmes de construction de logiciels tels que les Autotools, Scons ou Jam :
  • Configuration, compilation, installation et distribution d'un projet ;
  • Compilation en parallèle ;
  • Support pour divers langages tels que Ocaml, C, C++ ou Java ;
  • Abstraction pour la compilation sur d'autres systèmes d'exploitation ;
  • Utilisations de scripts en langage Python.

  • # Intéressant

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

    Ce système a l'air intéressant - j'utilise actuellement scons pour une appli utilisant qt4, devant compiler sous linux et mac et en cross-compilation linux->windows. Scons est assez limité dans ce domaine (pour le support de qt4 surtout). Est-ce qu'un des experts Waf pourrait me dire s'il pense que cet outil conviendrait mieux? (preuves à l'appui ;))
    • [^] # Re: Intéressant

      Posté par . Évalué à 2.

      Il y a un exemple pour qt4:
      http://code.google.com/p/waf/source/browse/trunk/demos/qt4/

      Le support est restreint à l'utilisation du style KDE pour des raisons historiques et de performances:
      #include "foo.moc" en fin de fichier cpp
      Ceci permet des temps de compilation entre 30 et 40% plus rapides, mais diverge un tout petit peu des exemples Qt (où des fichiers _moc.cpp sont générés).

      Des utilisateurs appliquent Waf pour la cross-compilation, il s'agit en général de changer les paramètres de configuration. Le développement d'applications pour Windows n'est cependant pas recommandé.
      • [^] # Re: Intéressant

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

        Le développement d'applications pour Windows n'est cependant pas recommandé.

        Pour quelle raison ?

        Waf fonctionne très bien sous Windows, je l'utilise pour un projet en Vala/GTK+ mis à part quelques spécificités au niveau de la compilation (histoire de ne pas avoir une magnifique fenêtre DOS), je prends les sources tel quel et ça fonctionne :)

        J'ai jamais vraiment compris le fonctionnement des autotools, avec Waf c'est très simple et les sources restent propres (tous est généré dans un répertoire _build_, par défaut).
        • [^] # Re: Intéressant

          Posté par . Évalué à 3.

          Pour quelle raison ?

          Linux c'est mieux :-)

          J'aurais du ajouter avec Qt, la detection automatique de Qt4 ne fonctionant que sur les systèmes de type Linux pour le moment.
    • [^] # Re: Intéressant

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

      Tiens, même problèmes, même question.
      J'aime bien SCons, simple à écrire et à retenir. Mais c'est vrai que pour le multiplateforme, il demande un peu plus de travail. Mais il ne s'en sort pas si mal que ça.
      Mon principale problème avec SCons, le checking des bibliothèques que à tendance à merdouiller sans que je n'arrive à comprendre où se trouve le problème.
    • [^] # Re: Intéressant

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

      Sinon, CMake, ca marche très bien pour ce type de projet. Perso j'en suis très content.
      • [^] # Re: Intéressant

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

        Mouais, CMake, je l'ai utilise un petit moment, histoire de pas me faire de fausses idée. En multiplate-forme il est pire que SCons.
        Et ce que je n'aime pas dans CMake, c'est que si on a pas le nez plongé dans la doc (qui est plutôt mauvaise en plus), on arrive à rien.
      • [^] # Re: Intéressant

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

        cmake, pour la cross-compilation, c'est l'enfer. Et le langage est moche. Je trouve que waf a l'air tres prometteur.
  • # Y a des amateurs de guateau dans la salle ?

    Posté par . Évalué à -6.

    Virez-moi cette horreur SVP ...
  • # Diverses fôtes

    Posté par . Évalué à 2.

    1. Améliorations est féminin, donc diverses.

    2. Plateformes ou plates-formes (2 fois).

    3. « Waf présent un système d’extensions basés », si c’est le système : basé.

    4. Il manque pas mal de virgules dans la 1re phrase (apposition de qualificatifs).

    5. « compilation en batches » → compilation par lots.

    Les modos sont en vacances ?
    • [^] # Re: Diverses fôtes

      Posté par . Évalué à 2.

      ou sur l'utilisation directe d'un language (Scons).
      Yen a qui n'ont pas du comprendre ce que j'ai écrit plus haut ...
      • [^] # Re: Diverses fôtes

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

        Tout doit être à peu près pris en compte maintenant. Sans vouloir jeter la pierre aux relecteurs, tous n'ont pas un dico dans la tête non plus, n'hésitez pas à soumettre des dépêches exemptes de fôtes :p

        totof2000 t'as pas un guateau libre à proposer ? cf. http://linuxfr.org/2008/12/11/24771.html :p
        • [^] # Re: Diverses fôtes

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

          Autoflagellation : en même temps, ils ont une correction orthographique avec suggestions intégrée au site, plus celle de leur navigateur.
        • [^] # Re: Diverses fôtes

          Posté par . Évalué à 5.

          Fondant au chocolat ...

          200 Gr de chocolat noir à cuisiner (52% de cacao minimum)
          100 Gr de beurre
          Sucre Semoule (j'en met 100 Gr mais si vous préférez vous pouvez mettre un peu plus)
          4 oeufs
          Farine et "maizena"


          - Dans un récipient assez grand (vous comprendrez pourquoi plus tard) Faire fondre le chocolat au micro-ondes ou au bain marie. Pour la fonte au micro-ondes j'ajoute un peu d'eau dedans (mais vraiment peu).

          - Pendant que le chocolat fond, casser les oeufs et séparer le blanc du jaune.

          - quand le chocolat est fondu, y incorporer les jaunes d'oeufs jusqu'à obtenir une pate homogène et luisante.

          - ajouter le beurre (attention il vaut mieux qu'il soit mou, si c'est pas le cas le passer au micro ondes pour le ramolir un peu, mais pas trop longtemps pour ne pas cuire les oeufs avec le beurre fondu), bien mélanger.

          - ajouter ensuite le sucre et mélanger jusqu'à ce que l'ensemble soit bien homogène (la dernière fois pour pas attendre trop longtemps, j'ai mis un tout petit peu d'eau dans le sucre et je l'ai passé au micro ondes pour avoir une espèce de sirop., mais c'est surtout parce que je n'avais pas assez de sucre semoule, donc j'ai du compenser avec des sucres en morceau.. Attention, je répète pas trop chaud !!!)

          - Ajouter 2 cuillers à soupe de farine et deux cuillers à soupe de maizena. Bien mélanger le tout.

          - une fois mélangé, laisser reposer et lécher la cuillère (juste lécher, hein, après on ne la remet pus dans le plat pour lécher ensuite car à ce stade c'est bon, et tout le plat risque d'y passer).

          - Beurrer un plat à gauteau (je prends un plat à tarte rond en céramique ou un truc du genre) , étaler une petite couche de beurre dans le fond pour pas que le guateau colle lorsqu'on le sortira. Vous pouvez mettre un peu de farine par dessus pour que ça colle as trop. Certains mettent une espèce de papier à cuisson, mais j'ai jamais essayé.

          - Faire préchauffer le four 5 à 8 mn à 200 °

          - Pendant que ça repose et que le four chauffe, battre les blancs en neige, bien ferme (normalement lorsque c'est bien pris vous pouvez retourner le récipient sans que les blancs retombent)

          - une fois les blancs bien montés, les incorporer à l'autre mixture. Une fois le mélange homogène, gouter pour voir si c'est bon (et attention de ne pas tout manger, c'est encore meilleur à ce stade). c'est ici que le choix initial du plat a son importance. Si vous l'avez pris trop petit, les blancs en neige le feront déborder.


          Verser la mixture dans le plat, baisser le four à 180° et mettre le plat au four. Les durées ci-dessous sont indicatives et dépendent de votre four et de la position du plat dans le four :
          - 10 mn pour qu'il soit très coulant
          - 15 mn pour qu'il soit parfait
          - 20 mn pour l'avoir plus ferme
          - 23 mn : c'est tout sec et pas bon.

          Ces durées sont à ajuster en fonction de votre four. Un truc pour voir si c'est cuit : plantez un couteau ou une aiguille à tricoter dans le guateau, s'il y a pas de résidus sur la pointe, c'est que c'est OK.

          La dernière fois que j'en ai fait, j'ai doublé les doses et mis dans deux plats. Pour éviter les srprises, j'ai interverti les plats (haut/bas) pendant la cuisson, et j'ai bien fait car l'un des plats était plus cuit sur le dessus et l'autre c'etait sur le dessous. Mais il m'a fallu un peu plus de temps que ce que j'ai mentionné plus haut, donc surveillez bien .... Et pendant que le guateau cuit, léchez bien les plats et la cuillere !!!

          Bon appétit !!!
  • # Pour GNOME

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

    Ave,

    Qu'en est-il pour le support des techno GNOME comme gtk-doc et gnome-doc ? Quel est le remplaçant d'autoheader ?

    Je suis également intéressé par waf, mais j'ai pas envie de perdre la matûrité des autotools. Pour ma part, je me débrouille bien avec automake et autoconf.

    Saint Noël,

    Cordialement,
    Étienne.
    • [^] # Re: Pour GNOME

      Posté par . Évalué à 2.

      Les technologies gnome sont en effet supportées, le mieux c'est de regarder du côté d'xmms2, mais il y a quelques exemples ici:
      http://code.google.com/p/waf/source/browse/trunk/demos/gnome
    • [^] # Re: Pour Debian

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

      Également, qu'en est-il du support par les deb et rpm ?

      Étienne.
      • [^] # Re: Pour Debian

        Posté par . Évalué à 1.

        Le support pour fakeroot est présent, ce qui permet de construire des .deb et des .rpm facilement et des commandes équivalentes à "configure; make; DESTDIR=foo make install" sont présentes.

        La redistribution du script Waf sans autre dépendance que Python facilite énormément le travail des packagers.

        La création de packages soi-même n'est pas recommandé (version du système, gestion des dépendances sur d'autres packages, version des scripts, portabilité), même s'il est possible de le faire facilement à travers de quelques fonctions en Python.

        Une commande similaire à "make dist" (waf dist) permet de générer une archive avec les sources de son projet.
    • [^] # Re: Pour GNOME

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

      j'ai pas envie de perdre la matûrité des autotools.

      à ce stade là on ne parle plus de maturité mais de putréfaction (qui sent le vieux pied moisi)
  • # Ant like. A quand un maven like ?

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

    Ok, au vue des exemples que j'ai pu voir, on reste encore à des choses du type Ant pour Java qui a été une solution très intéressante de remplacement des Makefile dans le dév Java.
    Or, depuis quelques année est apparue sur la plate-forme Java un remplacement à ce genre de système de construction de logiciels : maven.
    http://maven.apache.org/

    Pour ceux qui ne connaissent pas, maven est un système de construction de logiciel de plus haut niveau au sens où d'une part il impose une structure du projet et d'autre par il parcours différentes phases dans l'écriture de code : validate, compile, test, package, integration-test, install, deploy pour ne citer que quelques uns.
    (Voir http://www.oqube.com/formations/maven/lifecycle.html pour une vision plus complète des phases.)
    Il n'y pas plus la définition de tâches mais des plugins avec différentes cibles d'exécutions : un pour la compilation de code, un autre pour dérouler des tests, un pour archiver, etc. Chacun va s'exécuter dans une ou plusieurs phases selon son objectif.
    Un autre avantage, et un gros, de Maven, est la gestion des dépendances : les dépendances en bibliothèques sont automatiquement téléchargées de dépôts maven sur le Web et intégrées dans les phases de compilation, de tests, etc. Les dépendances transitives sont aussi prises en compte. Ce qui est aussi intéressant, c'est que seul les plugins définis dans le POM (Project Object Model, le descripteur du projet), sont chargés (et récupérés du Web s'ils ne sont pas présents dans le cache local (un dépôt local)).

    Malgré les défauts de Maven, après avoir travaillé avec aussi bien sur des petits que des plus gros projets, je ne reviendrais pas en arrière sur des systèmes de construction logicielle à la Ant ou Makefile ou Cons (dont SCons est un clone pour Python) ... Le principe de définition de tâches dans de tels systèmes peut devenir trop lourd avec de gros projets et de plus il faut soit même s'embêter à gérer les dépendances.

    Il est dommage qu'il n'y ait pas encore de projet du style Maven pour gérer la construction logicielle pour la plate-forme C/C++ ou Python.

    Sinon, il existe un concurrent à Maven : Raven, http://raven.rubyforge.org/
    • [^] # Re: Ant like. A quand un maven like ?

      Posté par . Évalué à 4.

      J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.

      Pour Maven, on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code. Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local, et la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE

      Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).

      Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).

      La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect, Maven est un peu calqué sur le modèle Windows.
      • [^] # Re: Ant like. A quand un maven like ?

        Posté par (page perso) . Évalué à -1.


        J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.

        Et pourtant, Maven n'est pas une surcouche à Ant, mais bien un outil à part entière. Maven est à une couche d'abstraction de plus haut niveau que celle de Ant et autres outils similaires dans la construction logicielle.


        on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code.

        Oui, seulement Maven n'est pas pour écrire du code ;-)
        Sinon, effectivement, l'usage du XML pour écrire le POM peut être pour certain considéré comme rébarbatif. Je ne suis moi même pas sûr que ce choix soit pertinent ; seulement, à l'heure du tout XML, bien que critiquable, je comprends le choix de celui-ci par les concepteurs de Maven.


        Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local,

        Ce qui est téléchargé de l'extérieur ce sont seulement les plugins ou dépendances qui ne sont pas présents dans le cache local (dépôt local). Une fois, téléchargés, seuls ceux présents dans le cache local sont pris en compte. Donc, au début, c'est lourd, mais après ça va très vite. De plus, l'usage de Maven dans de l'intégration continue m'est apparu plus facile qu'avec d'autres solutions.


        la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE

        Là je ne suis pas d'accord. Que la structure plaise ou non est une chose. Elle a sa propre logique et, que l'on aime ou pas, elle est cohérente pour bcp types de projets, et pas essentiellement pour du J2EE/JEE. Elle a l'avantage de proposer une structure commune aux projets, ce qui fait que les développeurs n'ont pas à réapprendre de comment celui-ci est structuré, de comment sont gérées les dépendances, etc. (Oui, effectivement, il doit connaitre celui de Maven, mais cet acquis est capitalisable.)


        Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).

        Oui, mais ça reste toujours des définitions de tâches qui sont pré-écrites dans les Makefile ou autres fichiers de build. L'enchaînement des tâches y doivent aussi être décrites. Dans Maven, l'accent est mis non plus sur les tâches, mais sur les phases d'écriture de code, Maven gérant le flot qui parcours les phases.


        Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).

        Oui, d'accord. Mais je ne pense pas que ça empêche la création d'outil pour C/C++ similaires à Maven ; il faut prendre en compte je pense les particularités de cet environnement.


        La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect

        Oui, une certaine richesse. Et c'est justement la pauvreté d'outils de type Maven, cad d'outils de construction logicielle de plus haut niveau, que je trouve dommage. Probablement que c'est encore tôt.


        Maven est un peu calqué sur le modèle Windows.

        Hooo ! Et en quoi ?
    • [^] # Re: Ant like. A quand un maven like ?

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

      Il existe surtout un ancêtre qui permet de faire ça (autconfiguration, auto-création de makefiles, cross-compilation, tests, packages, traductions, ...) depuis bien longtemps : les autotools.

      Les outils présentés ici essaient surtout de supprimmer la complexité des auto-tools.
      • [^] # Re: Ant like. A quand un maven like ?

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

        Et Maven est au dessus de ceci, à une couche d'abstraction supérieure ...

        Tu n'as pas compris ce que j'ai écris sur l'approche de Maven ; je n'ai pas dû être très clair. Le plus simple, je pense, est de l'essayer, ça vaut mieux que de grands discours.
  • # "waf"

    Posté par . Évalué à 3.

    Quand j'ai lu ça j'ai cru entendre mon chien aboyer .... Et d'un coup je me suis rappelé que je n'ai pas de chien ...

Suivre le flux des commentaires

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