Buildroot 2010.02 est sorti !

Posté par (page perso) . Modéré par patrick_g.
Tags :
30
8
mar.
2010
Matériel
Buildroot est un outil permettant la construction de systèmes Linux embarqués. Il automatise le processus de téléchargement, configuration, compilation et installation de tous les composants d'un système Linux embarqué : chaîne de compilation croisée, chargeur de démarrage, noyau, système de fichiers racine avec BusyBox, bibliothèques graphiques, réseau, multimédia, etc.

Utilisant le même système de configuration que celui du noyau, Buildroot permet de générer un système embarqué adapté à vos besoins. Il permet de compiler en standard près de 600 paquets : BusyBox, X.org, D-Bus, DirectFB, Gtk, Qt, GStreamer notamment, et il est très aisé d'ajouter d'autres paquets. Buildroot est utilisé officiellement par plusieurs fabricants de matériel, notamment Atmel, Armadeus Systems et Calao Systems et de nombreuses sociétés l'utilisent pour leurs projets Linux embarqué, notamment industriels. Jusqu'en janvier 2009, le projet était à l'abandon, sans mainteneur officiel ni processus de sortie. Depuis cette date, Peter Korsgaard a repris la maintenance du projet, et l'activité s'est drastiquement accélérée, avec des sorties tous les trois mois et un gros travail de nettoyage a été engagé. Pour plus d'informations sur le projet, voir la conférence Buildroot aux Rencontres Mondiales du Logiciel Libre 2009 (slides et vidéo).

La version 2010.02 de Buildroot, publiée fin février, s'inscrit dans la continuité du nettoyage entrepris depuis janvier 2009 :
  • Le mécanisme de toolchain source externe utilisé pour construire les toolchains AVR32 a été fusionné avec le mécanisme traditionnel de construction des chaînes de compilation croisée, afin de factoriser le code.
  • Une infrastructure générique de construction des paquets a été ajoutée, sur le principe de l'infrastructure existante pour les paquets utilisant les autotools. Cette infrastructure permet de factoriser les étapes de construction qui sont communes à tous les paquets, et permettra dans le futur de réaliser plus facilement des modifications sur l'ensemble des paquets. Les paquets Buildroot sont convertis au fur et à mesure vers cette nouvelle infrastructure.
  • Soixante paquets ont été mis à jour ou corrigés, plusieurs nouveaux paquets ont été ajoutés et une trentaine de bugs ont été corrigés.

La prochaine version (prévue pour le mois de mai) poursuivra ce travail de nettoyage, notamment au niveau de la construction du noyau, du chargeur de démarrage et de la prise en charge des cartes matérielles. Elle devrait aussi permettre d'ajouter une intégration avec l'excellent outil de construction de chaîne de compilation croisée Crosstool-NG.

Notons également que Buildroot fera l'objet de deux articles dans le prochain Linux Magazine Hors Série n° 47, « Créez un environnement Linux complet grâce au système de construction Buildroot » et « Cas pratique de mise en œuvre de Buildroot sur carte ARM9 DEV2410 », qui sortira en kiosque le 12 mars.
  • # Mauvaise catégorie !

    Posté par . Évalué à  -2 .

    Pourquoi avoir classé cet article dans la catégorie Hardware ? Visiblement, c'est du pur logiciel !
  • # ./configure

    Posté par . Évalué à  4 .

    Moi ce qui me gêne le plus dans buildroot (et les systèmes similaires) c'est le ./configure qui est répété autant de fois qu'il y a de "paquets".
    C'est déjà long pour un seul logiciel, alors répété des dizaines de fois, c'est une énorme perte de temps.

    Est-ce vraiment nécessaire? Est-ce que les systèmes comme buildroot, qui ont une vision globale de tous les paquets, ne pourraient pas factoriser les tests du ./configure?
    • [^] # Re: ./configure

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

      Ça a été un des projets internes de Gentoo, mais j'ai l'impression que c’est tombé à l'eau.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: ./configure

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

        Ça s'appelle "confcache", j'ai pas trop regardé comment ça marche en interne, mais il faut le désactiver pour certains paquets. En fait, il manque certaines choses dans les autotools, par exemple le système de cache ou le fait d'être obligé d'avoir accès à la target pour certains paquets (pour résoudre cette dernière chose il y a bien le projet scratchbox, mais c'est un peu overkill je trouve).

        Je rève d'un monde où tout ça serait résolu mais le projet des autotools va toujours dans la même direction donc il y a peu de chance d'avoir du neuf par là)
        • [^] # Re: ./configure

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

          Tiens, je ne connaissais pas de confcache. Qu'est-ce que ça apporte par rapport au mécanisme de cache intégré aux autotools ?

          Concernant le fait d'être obligé d'accéder à la machine cible, les autotools permettent d'indiquer à ./configure le résultat qu'aurait un test si il était fait sur la machine cible, sans avoir besoin d'y accéder effectivement.

          Par exemple, quand les autotools veulent tester si ta machine cible et big ou little endian, tu passes ac_cv_c_bigendian=yes quand tu es big endian, et ac_cv_c_bigendian=no quand tu es little endian, et le tour est joué. C'est le rôle du système de build autour de passer les options qui vont bien.

          Et effectivement, je trouve aussi que Scratchbox est une approche overkill. D'ailleurs, avec la fusion entre Maemo et Moblin (pour donner MeeGo), ils ont annoncé l'abandon du format de paquet Debian (utilisé par Maemo) pour passer à RPM (utilisé par Moblin). Du coup, je me demande ce qu'il va rester de Scratchbox qui était quand même très fortement orienté paquet Debian.
          • [^] # Re: ./configure

            Posté par . Évalué à  3 .

            les autotools c'est quand même la grosse merde pour faire de la cross compilation : entre les test qui cherche a exécuter des programmes, d'autres test qui hardcode des résultats dans le cas de cross compilation, encore d'autre qui cherche des headers/libs dans /lib ou /usr il faut souvent les patcher.

            Je ne parle même pas de libtool qui fait les 3/4 du temps pas ce que tu veux.

            Et le plus triste c'est qu'il y a souvent un moyen plus ou moins portable de faire le test.

            Par exemple, quand les autotools veulent tester si ta machine cible et big ou little endian, tu passes ac_cv_c_bigendian=yes quand tu es big endian, et ac_cv_c_bigendian=no quand tu es little endian, et le tour est joué.
            $ touch endian.c
            $ cc -o endian.o -c endian.c
            $ objdump -a /tmp/endian.o

            ou encore

            $ echo "unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E';" > end.c
            $ gcc end.c -c -o end.o
            $ od -t x1 end | grep -q '42 *49 *47 *45' && echo big
    • [^] # Re: ./configure

      Posté par . Évalué à  4 .

      Peut être parceque, là, cela ne factoriserai pas le temps de travail ? :p
      Dans la mesure où tu va avoir besoin de telles options pour tel configure de tel logiciel, et que chaque options de chaque configure peux varier. Du coup, au mieux tu aurais une belle liste de départ, avec des catégories nommées par briques logicielles, et comprenant chacune la liste des options non communes autotools, mais certaines redondantes quant même (dans la mesure où tu peux vouloi telle option pour tel soft, mais pas pour tel autre). Au final, le temps passé à chaque étape se retrouve concentrer sur le temps à passé en début de compilation. Pas de gain de temps, donc.
      Cela doit pouvoir se scripter, ça, c'est typiquement le genre de trucs qu'on peux avoir besoin personnlellement mais qui n'a que peu d'intérêt pour tous : tu connais tes softs, tu sais quelles options tu va choisir, tu le prépare pour toi.
      Non ?
      • [^] # Re: ./configure

        Posté par . Évalué à  4 .

        En même temps dans les "configure" en général, t'as un paquet de temps à faire des trucs qui varient pas du tout suivant le paquet, genre la détection de l'architecture ou le nombre maximum de lignes traitables par bash.

        Il pourrait presque être avantageux de cacher les résultats de ce genre de macros si on est sûr que c'est invariant suivant le paquet.

        Cela dit, faudrait toucher aux autotools, donc au final, le jeu en vaut sûrement pas la chandelle ;)
        • [^] # Re: ./configure

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

          Il pourrait presque être avantageux de cacher les résultats de ce genre de macros si on est sûr que c'est invariant suivant le paquet.

          Et c'est exactement ce que nous faisons, grâce à l'option --cache-file des fichiers de configure. Nous faisons ainsi partager un fichier de cache entre tous les scripts configure, ce qui améliore effectivement significativement le temps d'exécution de ces scripts.

          En dehors de ça, il n'y a pas vraiment grand chose que nous puissions faire, je le crains.
    • [^] # Re: ./configure

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

      Est-ce vraiment nécessaire? Est-ce que les systèmes comme buildroot, qui ont une vision globale de tous les paquets, ne pourraient pas factoriser les tests du ./configure?

      Comme dit plus bas, c'est ce que nous faisons avec --cache-file. Voir http://www.gnu.org/software/hello/manual/autoconf/Cache-File(...)

      C'est implémenté ici: http://git.buildroot.net/buildroot/tree/package/Makefile.aut(...)
      • [^] # Re: ./configure

        Posté par . Évalué à  1 .

        Merci Thomas pour cette info.
        Je ne connaissais pas l'option --cache-file. Ça risque en effet d'améliorer sérieusement la vitesse des scripts ./configure.

        Je teste ça dès que possible :-)
  • # je vote pour (c'est le moment)

    Posté par . Évalué à  0 .

    un vrai merci pour cette info de taille, d'autant plus que j'allais passer à coté de l'article de Linux Mag.

    BuildRoot est véritablement indispensable pour les utilisateurs de Mini2440 (FriendlyArm et Hiteg), et ceci sauve la vie.
    Par contre je n'ai pas trouvé où se situait la contrib de FreeElectrons.



    PS : je suis aussi ok pour une section embarqué.

Suivre le flux des commentaires

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