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.
Aller plus loin
- Buildroot (33 clics)
- Annonce de la sortie de 2010.02 (0 clic)
- Conférence Buildroot RMLL 2009 (15 clics)
- Buildroot 2010.02 released, contributions from Free Electrons! (1 clic)
# Mauvaise catégorie !
Posté par jcr83 . Évalué à -2.
[^] # Re: Mauvaise catégorie !
Posté par BAud (site web personnel) . Évalué à 8.
c'est dans la section Logiciel et le thème Hardware, vu que c'est fortement lié à celui-ci et sert pour l'embarqué, tu aurais proposé quel autre thème ?
[^] # Re: Mauvaise catégorie !
Posté par Thomas Petazzoni (site web personnel) . Évalué à 2.
À mon avis, il manque un thème Embarqué. Et je n'ai jamais rien compris à la distinction section et thème faite par LinuxFr pour classer les dépêches.
[^] # Re: Mauvaise catégorie !
Posté par BAud (site web personnel) . Évalué à 5.
alors, je te redonne la réponse classique de Oumph< :
- tu identifies le thème et tu fournis un logo (SVG de préférence et sous licence libre et qui passe bien sur une page telle que [https://linuxfr.org/moderateurs/moderation.html#themes] pour s'assurer que le détourage et le transparent passent bien sur à peu près tout fond)
- tu l'indiques sur http://linuxfr.org/tracker/
- et généralement ça peut être pris en compte rapidement ;-)
Et je n'ai jamais rien compris à la distinction section et thème faite par LinuxFr pour classer les dépêches.
euh, bin, c'est comme sur /. non ? :D sérieusement, c'est des catégories / sous-catégories qui apparaissent du côté gauche sur des pages comme :
- http://linuxfr.org/sections/Articles comme toutes les dépêches "articles" ou https://linuxfr.org/sections/Cin%C3%A9ma pour les dépêches préférées sur DLFP
- http://linuxfr.org/topics/Game pour les dépêches concernant le thème jeu ou https://linuxfr.org/topics/Science pour les sujets scientifiques
(oui, tu auras remarqué la distinction topics / thèmes (ça fait toujours bien sur un site francophone :D).
'fin bon, c'est aussi un peu pour ça que j'avais demandé des tags à une époque [http://linuxfr.org/tracker/623.html] ;-)
# ./configure
Posté par cjlano . Évalué à 4.
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 DLFP est mort . Évalué à 4.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: ./configure
Posté par Damien Thébault . Évalué à 3.
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 Thomas Petazzoni (site web personnel) . Évalué à 2.
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 M . Évalué à 3.
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 Didier (site web personnel) . Évalué à 3.
Pour info, voici la liste des commandes qui sont considérées comme "sûres" :
awk cat cmp cp diff echo egrep expr false grep install-info
ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch tr true
ar bison cc flex install ld ldconfig lex
make makeinfo ranlib texi2dvi yacc
Voir http://www.gnu.org/software/autoconf/manual/autoconf.html#Po(...) et plus particulièrement http://www.gnu.org/software/autoconf/manual/standards.html#U(...)
Et encore, il y a des conseils d'utilisation pour éviter de rencontrer des problèmes sur certaines plates-formes : http://www.gnu.org/software/autoconf/manual/autoconf.html#Li(...)
[^] # astuce du jour
Posté par Krunch (site web personnel) . Évalué à 5.
$ echo "unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E';" | gcc -x c -c -o end.o -
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ./configure
Posté par bubar🦥 (Mastodon) . Évalué à 4.
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 Thomas Douillard . Évalué à 4.
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 Thomas Petazzoni (site web personnel) . Évalué à 3.
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 Thomas Petazzoni (site web personnel) . Évalué à 1.
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 cjlano . Évalué à 1.
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 kezako . Évalué à 0.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.