Yocto ou Buildroot : comment choisir pour votre projet Linux embarqué
La question revient à chaque démarrage de projet Linux embarqué, et elle est presque toujours mal posée. « Lequel est le meilleur ? » n'a pas de réponse. « Lequel correspond à la durée de vie de mon produit, à la taille de mon équipe et au silicium que j'ai choisi ? » en a une, et elle est souvent tranchée d'avance par des contraintes que l'on découvre trop tard.
Deux outils qui ne font pas la même chose
Buildroot génère un système de fichiers racine. Vous décrivez une configuration dans un menuconfig familier à quiconque a compilé un noyau, vous lancez make, et vous obtenez une image. L'ensemble tient dans des Makefiles que l'on peut lire. Un développeur qui connaît make comprend Buildroot en une journée.
Yocto ne génère pas une image : il génère une distribution, et l'outillage qui va avec. Le projet fournit BitBake, un moteur de tâches, OpenEmbedded-Core, une collection de recettes, et un modèle de couches qui permet d'empiler les contributions. À la sortie, vous n'avez pas seulement une image mais un SDK pour vos développeurs applicatifs, un flux de mises à jour, et un manifeste des licences de chaque composant.
Cette différence de nature explique presque tout le reste.
Le cycle de build, là où ça fait mal
C'est le premier reproche fait à Yocto, et il est fondé. Une première construction complète d'une image core-image-minimal prend typiquement une à trois heures sur une machine de développement correcte, et occupe entre 50 et 100 Go de disque une fois tmp/ et le sstate-cache remplis. Buildroot, sur le même matériel et pour un périmètre comparable, se compte en dizaines de minutes et en quelques gigaoctets.
Mais la première construction n'est pas celle qui compte. Ce qui décide de votre productivité, c'est la deuxième, et la centième.
Yocto met en cache l'état de chaque tâche. Modifier une recette applicative ne relance que ce qui en dépend : quelques minutes, pas quelques heures. Partagez ce sstate-cache sur un serveur, et l'intégration continue comme les nouveaux arrivants repartent d'un cache chaud. C'est là que l'investissement initial se rembourse.
Buildroot, lui, ne gère pas de dépendances incrémentales fines entre paquets. Changer une option de configuration qui touche la chaîne de compilation, et la recommandation officielle reste de repartir d'un make clean. Sur un projet où la configuration se stabilise vite, c'est indolore. Sur un projet où elle bouge chaque semaine, c'est un coût qui revient sans arrêt.
Ce que vous ne pouvez pas faire avec Buildroot
Deux limitations méritent d'être connues avant de s'engager, parce qu'elles ne se contournent pas.
Il n'y a pas de gestionnaire de paquets sur la cible. Buildroot produit une image monolithique. Vous ne déployez pas un correctif sur un composant : vous reconstruisez l'image entière et vous la poussez. Pour un produit mis à jour par image complète, ce qui est un choix parfaitement défendable et même souhaitable pour la robustesse, c'est sans conséquence. Pour un produit où l'on veut livrer une correction applicative sans toucher au reste, c'est bloquant.
La montée de version se fait par migration manuelle. Buildroot publie une version stable tous les trois mois, en février, mai, août et novembre, numérotée au format AAAA.MM. Vos modifications locales vivent dans votre arbre, et passer d'une version à la suivante consiste à rejouer ces modifications. Le modèle de couches de Yocto sépare au contraire votre travail de la base : meta-mon-produit reste votre couche, et la mise à jour d'OpenEmbedded-Core ne réécrit pas ce que vous avez fait.
Sur un produit dont la durée de vie dépasse trois ans, ce point-là pèse plus lourd que tous les temps de build réunis.
Le silicium décide souvent à votre place
C'est l'argument que l'on oublie dans les comparatifs, et c'est souvent le seul qui compte.
Les fabricants de SoC publient leur support sous forme de couches Yocto. meta-freescale chez NXP, meta-st chez STMicroelectronics, meta-ti, meta-xilinx : le BSP, les pilotes, les binaires propriétaires et les outils de mise en service arrivent packagés pour Yocto, et validés pour la version que le fabricant a choisie.
Buildroot supporte largement ces plateformes, mais avec un décalage, et parfois avec un sous-ensemble. Si votre projet dépend d'un accélérateur graphique, d'un VPU ou d'un coprocesseur temps réel dont le support n'existe que dans la couche du fabricant, le choix est déjà fait. Vérifiez ce point avant tout le reste : c'est le seul critère qui puisse invalider une décision par ailleurs bien argumentée.
Conformité et traçabilité
Si votre produit est soumis à une obligation de nomenclature logicielle, et depuis le Cyber Resilience Act beaucoup de produits européens le seront, Yocto fournit nativement les manifestes de licences, la génération de SBOM au format SPDX et l'archivage des sources. Buildroot propose make legal-info, qui produit une liste de licences correcte mais moins détaillée, et sans le lien direct avec un identifiant de build reproductible.
Ce n'est pas un point de départ pour choisir un outil. C'est un point qui coûte cher si on le découvre à la fin.
Un tableau de décision, pas un verdict
| Critère | Buildroot | Yocto |
|---|---|---|
| Première prise en main | quelques jours | plusieurs semaines |
| Build initial | dizaines de minutes | 1 à 3 heures |
| Rebuild après modification | souvent complet | incrémental via sstate |
| Espace disque | quelques Go | 50 à 100 Go |
| Paquets sur la cible | non | rpm, deb ou ipk |
| SDK pour les applicatifs | limité | généré, versionné |
| Modifications locales | dans votre arbre | isolées dans une couche |
| Support des fabricants de SoC | partiel, décalé | couche officielle |
| SBOM et licences | make legal-info | manifestes, SPDX |
Comment trancher, concrètement
Prenez Buildroot si le périmètre logiciel est stable et modeste, si l'équipe compte un ou deux développeurs système, si la mise à jour se fait par image complète, et si la plateforme est bien supportée en amont. Un produit à fonction fixe, avec un horizon de deux ou trois ans, y sera parfaitement servi, et vous aurez un système que toute l'équipe comprend.
Prenez Yocto si le produit est une gamme plutôt qu'un modèle, si plusieurs équipes contribuent, si le fabricant du SoC ne publie que pour Yocto, si vous devez livrer un SDK à des développeurs applicatifs, ou si la durée de vie se compte en années avec des obligations de traçabilité.
Le piège classique consiste à choisir Buildroot pour la rapidité initiale, puis à reconstruire au bout de dix-huit mois ce que Yocto offrait déjà : un mécanisme de couches, un SDK, un flux de mise à jour. La migration se fait, mais elle coûte plus cher que l'apprentissage qu'on avait voulu éviter.
Références
- Manuel utilisateur Buildroot, cycle de publication trimestriel et
make legal-info - Yocto Project, Documentation, modèle de couches et
sstate-cache - Yocto Project, Creating a Software Bill of Materials
Pour aller plus loin
Ces arbitrages se font mieux une fois qu'on a construit une image de bout en bout, écrit une recette et débogué un do_compile qui échoue. C'est le contenu de nos deux formations Yocto, l'une pour démarrer, l'autre pour les projets déjà engagés.