{"id":6232,"date":"2024-09-03T06:00:00","date_gmt":"2024-09-03T05:00:00","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=6232"},"modified":"2024-11-13T15:33:30","modified_gmt":"2024-11-13T14:33:30","slug":"les-fichiers-parcourus-par-bitbake","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2024\/09\/03\/les-fichiers-parcourus-par-bitbake\/","title":{"rendered":"Les fichiers de configuration de Bitbake"},"content":{"rendered":"<div class=\"wp-block-image\">\n<figure class=\"alignright size-full is-resized\"><a href=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/bitbake-files-01.png\"><img loading=\"lazy\" decoding=\"async\" width=\"400\" height=\"300\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/bitbake-files-01.png\" alt=\"\" class=\"wp-image-6324\" style=\"width:306px;height:auto\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/bitbake-files-01.png 400w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/bitbake-files-01-300x225.png 300w\" sizes=\"auto, (max-width: 400px) 100vw, 400px\" \/><\/a><\/figure><\/div>\n\n\n<p>Lorsqu&rsquo;on r\u00e9alise un <em>build<\/em> pour un syst\u00e8me Linux embarqu\u00e9 avec Yocto Project, de nombreux fichiers sont parcourus par l&rsquo;outil <strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">Bitbake<\/mark><\/strong>. Il n&rsquo;est pas toujours simple de savoir <strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">dans quel ordre ces fichiers de configuration sont examin\u00e9s<\/mark><\/strong>, mais c&rsquo;est pourtant une cl\u00e9 pour la bonne compr\u00e9hension des op\u00e9rations r\u00e9alis\u00e9es.<\/p>\n\n\n\n<p>Nous allons nous int\u00e9resser ici aux fichiers de configuration et de donn\u00e9es (distro, machine, image, recettes, etc.) pas aux fichiers python internes de Bitbake, ni aux fichiers sources, objets ou ex\u00e9cutables obtenus lors de la compilation des packages.<\/p>\n\n\n\n<p>Bien s\u00fbr nous regarderons certains fichiers directement livr\u00e9s avec Yocto, mais ce qui m&rsquo;int\u00e9resse avant tout, c&rsquo;est la connaissance des <strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">fichiers sur lesquels nous avons la possibilit\u00e9 d&rsquo;agir<\/mark><\/strong>, ceux que nous pouvons personnaliser avant de lancer le build.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h1 class=\"wp-block-heading\">Environnement de travail<\/h1>\n\n\n\n<p>Nous allons nous placer dans une situation assez simple mais r\u00e9aliste pour un petit projet&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>pr\u00e9paration d&rsquo;une image pour Raspberry Pi 4 r\u00e9alis\u00e9e en utilisant la branche Scarthgap de Poky,<\/li>\n\n\n\n<li>utilisation du layer <code>meta-raspberrypi<\/code>,<\/li>\n\n\n\n<li>utilisation du layer <code>meta-oe<\/code> se trouvant dans le <em>repository<\/em> <code>meta-openembedded<\/code>.<\/li>\n<\/ul>\n\n\n\n<p>Pour \u00eatre certain de voir tous les acc\u00e8s aux fichiers demand\u00e9s par <code>bitbake<\/code>, je l&rsquo;ai lanc\u00e9 en le pr\u00e9fixant par \u00ab\u00a0<code>strace -f -o bitbake-trace.txt<\/code>\u00a0\u00bb afin d&rsquo;obtenir dans le fichier <code>bitbake-trace.txt<\/code> la liste de tous les appels-syst\u00e8me invoqu\u00e9s lors du build.<\/p>\n\n\n\n<p>Je me suis retrouv\u00e9 avec un fichier de traces de 270Go&nbsp;! J&rsquo;en ai extrait les lignes qui contiennent un appel <code>open()<\/code> &#8211; ou plus pr\u00e9cis\u00e9ment <code>openat()<\/code> &#8211; qui n&rsquo;\u00e9choue pas. Puis j&rsquo;ai filtr\u00e9 le r\u00e9sultat pour ne conserver que les extensions de fichiers qui m&rsquo;int\u00e9ressent (<code>.bb<\/code>, <code>.conf<\/code>, <code>.bbappend<\/code>, <code>.bbclass<\/code> , etc.).<\/p>\n\n\n\n<p>J&rsquo;ai obtenu au final un fichier de 8.3 Mo, comprenant 95110 lignes.  Comme il s&rsquo;agit des op\u00e9rations s\u00e9quentielles lors du build, de nombreux acc\u00e8s aux fichiers sont redondants (par exemple les classes sont h\u00e9rit\u00e9es par de nombreuses recettes diff\u00e9rentes). Si on \u00e9limine les redondances, il n&rsquo;y a \u00ab\u00a0que\u00a0\u00bb 8158 fichiers parcourus.<\/p>\n\n\n\n<p>Partant de cette base de travail et en consultant le v\u00e9ritable contenu des fichiers, on peut comprendre assez bien l&rsquo;encha\u00eenement des op\u00e9rations pour Bitbake.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Fichiers de configuration<\/h1>\n\n\n\n<p>Le comportement g\u00e9n\u00e9ral de Bitbake est le suivant&nbsp;: <\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>lire les informations de configuration globale,<\/li>\n\n\n\n<li>parcourir les <strong><em>layers<\/em> par ordre de priorit\u00e9 croissante<\/strong> et m\u00e9moriser le contenu des recettes (une recette <code>.bbappend<\/code> dans un layer de priorit\u00e9 \u00e9lev\u00e9e peut amender le contenu de la recette <code>.bb<\/code> de m\u00eame nom situ\u00e9e dans un layer de priorit\u00e9 plus faible),<\/li>\n\n\n\n<li>r\u00e9aliser les actions n\u00e9cessaires pour obtenir la cible r\u00e9clam\u00e9e au lancement de la commande (image, recette, etc.).<\/li>\n<\/ol>\n\n\n\n<p>Ici nous ne nous int\u00e9ressons qu&rsquo;aux deux premiers points. Pour \u00eatre exact c&rsquo;est m\u00eame le premier point qui nous concerne le plus.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Liste des layers concern\u00e9s<\/h2>\n\n\n\n<p>Le premier fichier lu par <code>bitbake<\/code> est <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/bblayers.conf<\/mark><\/strong><\/code>. Il renseigne principalement la variable <code>BBLAYERS<\/code> qui contient la liste des <em>layers<\/em> \u00e0 prendre en consid\u00e9ration. Voici un extrait de ce fichier&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>BBLAYERS ?= \" \\\n  \/home\/Builds\/Lab\/layers\/poky\/meta \\\n  \/home\/Builds\/Lab\/layers\/poky\/meta-poky \\\n  \/home\/Builds\/Lab\/layers\/poky\/meta-yocto-bsp \\\n  \/home\/Builds\/Lab\/layers\/meta-raspberrypi \\\n  \/home\/Builds\/Lab\/layers\/meta-openembedded\/meta-oe \\\n  \"<\/code><\/pre>\n\n\n\n<p>Le fichier <code>conf\/bblayers.conf<\/code> peut \u00eatre manipul\u00e9 manuellement ou par l&rsquo;interm\u00e9diaire de la commande <code>bitbake-layers<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Configurations des layers<\/h2>\n\n\n\n<p>Bitbake va ensuite lire les cinq fichiers <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/layer.conf<\/mark><\/strong><\/code> se trouvant \u00e0 l&rsquo;int\u00e9rieur des cinq r\u00e9pertoires mentionn\u00e9s ci-dessus. Cela va lui permettre d&rsquo;obtenir des informations sur les <em>layers<\/em>, entre autres&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>V\u00e9rifier la <strong>compatibilit\u00e9<\/strong> des <em>layers<\/em> avec la branche de Poky (par exemple&nbsp;: <code>LAYERSERIES_COMPAT_openembedded-layer = \"scarthgap\"<\/code>).<\/li>\n\n\n\n<li>Obtenir les <strong>priorit\u00e9s<\/strong> respectives des <em>layers<\/em> (<code>BBFILE_PRIORITY_openembedded-layer = \"5\"<\/code>), c&rsquo;est-\u00e0-dire l&rsquo;ordre de parcours \u00e0 venir.<\/li>\n\n\n\n<li>M\u00e9moriser les <strong>emplacements des recettes<\/strong> contenues dans les <em>layers<\/em> (<code>BBFILES += \"${LAYERDIR}\/recipes-*\/*\/*.bb ${LAYERDIR}\/recipes-*\/*\/*.bbappend<\/code>)<\/li>\n<\/ul>\n\n\n\n<p>Lorsque nous cr\u00e9ons notre propre layer (par exemple avec la commande \u00ab\u00a0<code>bitbake-layers create-layer &lt;layer-path&gt;<\/code>\u00a0\u00bb ) un fichier <code>layer.conf<\/code> est cr\u00e9\u00e9 avec des valeurs par d\u00e9faut. Il est conseill\u00e9 de le consulter et d&rsquo;ajuster \u00e9ventuellement la priorit\u00e9 et la compatibilit\u00e9 avec Poky.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Configuration de bitbake<\/h2>\n\n\n\n<p>Le fichier lu ensuite par Bitbake se trouve dans le layer <code>poky\/meta<\/code>, juste \u00e0 c\u00f4t\u00e9 de <code>layer.conf<\/code>. Il s&rsquo;agit de <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/bitbake.conf<\/mark><\/strong><\/code> et il a une tr\u00e8s grande importance pour le reste du <em>build<\/em>.<\/p>\n\n\n\n<p>Dans ce <em>layer<\/em> se trouvent tout d&rsquo;abord l&rsquo;initialisation d&rsquo;un grand nombre de variables&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>les noms symboliques des chemins qu&rsquo;on utilise dans les recettes (comme <code>${bindir}<\/code> ou <code>${sysconfdir}<\/code>),<\/li>\n\n\n\n<li>les informations sur la machine h\u00f4te, sur la cible, sur la machine pr\u00e9vue pour h\u00e9berger le SDK, etc.<\/li>\n\n\n\n<li>les valeurs par d\u00e9faut pour les variables renseign\u00e9es ou utilis\u00e9es dans les recettes (<code>SUMMARY<\/code>, <code>LICENSE<\/code>, <code>SRC_URI<\/code>, <code>PN<\/code>, <code>PV<\/code>, <code>DEPENDS<\/code>, <code>FILES<\/code>, <code>WORKDIR<\/code>, <code>D<\/code>, <code>S<\/code>, <code>B<\/code>&#8230;),<\/li>\n\n\n\n<li>les valeurs par d\u00e9faut pour les param\u00e8tres de build (<code>TCLIBC<\/code>, <code>MAKE<\/code>, <code>CC<\/code>, <code>DISTRO<\/code>, <code>OVERRIDES<\/code>, <code>DL_DIR<\/code>, <code>SSTATE_DIR<\/code>, &#8230;)<\/li>\n\n\n\n<li>l&rsquo;initialisation de variables utilis\u00e9es dans de nombreuses recettes (<code>IMAGE_FEATURES<\/code>, <code>DISTRO_FEATURES<\/code>, <code>MACHINE_FEATURES<\/code>, etc.)<\/li>\n\n\n\n<li>etc.<\/li>\n<\/ul>\n\n\n\n<p>Le second aspect extr\u00eamement important de ce fichier, c&rsquo;est qu&rsquo;il va organiser l&rsquo;inclusion de tous les autres fichiers de configuration. Voici la portion concern\u00e9e&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>require conf\/abi_version.conf\n<strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">include conf\/site.conf<\/mark><\/strong>\ninclude conf\/auto.conf\n<strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">include conf\/local.conf<\/mark><\/strong>\nrequire conf\/multiconfig\/${BB_CURRENT_MC}.conf\n<strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">include conf\/machine\/${MACHINE}.conf<\/mark><\/strong>\n<strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">include conf\/machine-sdk\/${SDKMACHINE}.conf<\/mark><\/strong>\n<strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">include conf\/distro\/${DISTRO}.conf<\/mark><\/strong>\ninclude conf\/distro\/defaultsetup.conf\ninclude conf\/documentation.conf\ninclude conf\/licenses.conf\nrequire conf\/sanity.conf\nrequire conf\/cve-check-map.conf\ninclude conf\/bblock.conf<\/code><\/pre>\n\n\n\n<p>Rappelons que la directive <code>require<\/code> concerne une inclusion obligatoire (sous peine d&rsquo;\u00e9chec du <em>build<\/em>) alors que <code>include<\/code> concerne un fichier facultatif.<\/p>\n\n\n\n<p>Les fichiers de cette liste ne sont pas tous aussi int\u00e9ressants. Nous allons nous concentrer sur les cinq que j&rsquo;ai surlign\u00e9, car ce sont les principaux points de configuration o\u00f9 nous pouvons \u00eatre amen\u00e9s \u00e0 intervenir.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_09-19.png\"><img loading=\"lazy\" decoding=\"async\" width=\"650\" height=\"310\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_09-19.png\" alt=\"\" class=\"wp-image-6297\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_09-19.png 650w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_09-19-300x143.png 300w\" sizes=\"auto, (max-width: 650px) 100vw, 650px\" \/><\/a><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Configuration sp\u00e9cifique pour le d\u00e9veloppeur<\/h2>\n\n\n\n<p>Le fichier <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/site.conf<\/mark><\/strong><\/code> est facultatif. Aucune version n&rsquo;en est fournie par Yocto. Il est toutefois tout \u00e0 fait possible d&rsquo;en ajouter un dans le sous r\u00e9pertoire <code>conf\/<\/code> de notre dossier de build (\u00e0 c\u00f4t\u00e9 de <code>bblayers.conf<\/code> et de <code>local.conf<\/code> que nous allons voir ensuite).<\/p>\n\n\n\n<p>Le r\u00f4le de ce fichier est habituellement de configurer les param\u00e8tres li\u00e9s \u00e0 l&rsquo;environnement de <em>build<\/em> local. Ceux qui ne doivent pas \u00eatre partag\u00e9s avec les autres d\u00e9veloppeurs, par exemple des r\u00e9pertoires <code>downloads\/<\/code> ou <code>sstate-cache\/<\/code> \u00e0 des emplacements particuliers, ou une configuration d&rsquo;utilisation du processeur <code>BB_NUMBER_THREADS<\/code> ou <code>PARALLEL_MAKE<\/code>.<\/p>\n\n\n\n<p>Dans le projet <a href=\"https:\/\/www.blaess.fr\/christophe\/2022\/01\/13\/yocto-cooker-1-3\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Yocto Cooker<\/strong><\/a>, nous n&rsquo;avons choisi de ne pas inclure (pour le moment du moins) <code>site.conf<\/code> dans le format des menus de configuration. Ceux-ci doivent en effet pouvoir \u00eatre partag\u00e9s entre les d\u00e9veloppeurs utilisant Yocto.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Configuration du <em>build<\/em><\/h2>\n\n\n\n<p>Avant de parcourir les <em>layers<\/em> ainsi m\u00e9moris\u00e9s, <code>bitbake<\/code> va lire le fichier <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/local.conf<\/mark><\/strong><\/code> qui va lui donner plusieurs renseignements importants&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>La variable <code>MACHINE<\/code> qui indique le nom du fichier de configuration de la cible. C&rsquo;est g\u00e9n\u00e9ralement la premi\u00e8re variable que l&rsquo;on configure pour notre <em>build<\/em>.<\/li>\n\n\n\n<li>La variable <code>SDK_MACHINE<\/code> sert lors de l&rsquo;extraction de l&rsquo;environnement de d\u00e9veloppement (pour produire du code en dehors de Yocto et l&rsquo;int\u00e9grer directement sur la cible).<\/li>\n\n\n\n<li>les variables <code>DL_DIR<\/code>, <code>SSTATE_DIR<\/code> ou <code>TMP_DIR<\/code> qui indiquent les chemins utilis\u00e9s durant le <em>build<\/em>.<\/li>\n\n\n\n<li>La variable <code>PACKAGE_CLASSES<\/code> qui d\u00e9finit le format des packages binaires utilis\u00e9s en interne par <code>bitbake<\/code> durant le <em>build<\/em>.<\/li>\n\n\n\n<li>La variable <code>DISTRO<\/code> contient le nom de la distribution.<\/li>\n\n\n\n<li>etc.<\/li>\n<\/ul>\n\n\n\n<p>Le fichier <code>conf\/local.conf<\/code> est g\u00e9n\u00e9ralement le premier point de personnalisation pour Yocto Project. Il est important de sauvegarder son contenu et celui de <code>conf\/bblayers.conf<\/code> pour assurer la reproductibilit\u00e9 du <em>build<\/em>. C&rsquo;est pourquoi le menu de configuration de Yocto Cooker contient une section sp\u00e9cifique pour m\u00e9moriser et re-g\u00e9n\u00e9rer ce fichier.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Configuration de la machine cible<\/h2>\n\n\n\n<p>La variable <code>MACHINE<\/code> indique le nom de la machine cible. Bitbake va alors rechercher dans les diff\u00e9rents <em>layers<\/em> un fichier <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/machine\/${MACHINE}.conf<\/mark><\/strong><\/code>. Dans le cas du <em>build<\/em> ci-dessus, il s&rsquo;agissait de <code>conf\/machine\/raspberrypi4.conf<\/code> se trouvant dans le <em>layer<\/em> <code>meta-raspberrypi<\/code>.<\/p>\n\n\n\n<p>Ce fichier va lui-m\u00eame inclure d&rsquo;autre fichiers du m\u00eame <em>layer<\/em> (<code>rpi-base.inc<\/code> , <code>rpi-default-settings.inc<\/code>, <code>rpi-default-providers.inc<\/code>, etc.)<\/p>\n\n\n\n<p>Ce fichier configure tout ce qui concerne l&rsquo;aspect <em>hardware<\/em> du build. On y trouve par exemple&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>TUNE_FEATURES<\/code> qui d\u00e9crit les sp\u00e9cificit\u00e9s du processeur \u00e0 destination de la <em>toolchain<\/em> de compilation (<code>armv7a<\/code>, <code>neon<\/code>, <code>thumb<\/code>, etc.) <\/li>\n\n\n\n<li><code>MACHINE_FEATURES<\/code> qui contient une liste de fonctionnalit\u00e9s offertes par le mat\u00e9riel (<code>wifi<\/code>, <code>bluetooth<\/code>, <code>keyboard<\/code>, etc.) qui pourront \u00eatre test\u00e9es dans les recettes pour inclure ou param\u00e9trer certains packages.<\/li>\n\n\n\n<li><code>WKS_FILE<\/code> et <code>IMAGE_FSTYPES<\/code> indiquant le partitionnement et les formats de sortie pour le <em>root filesystem<\/em>.<\/li>\n\n\n\n<li><code>PREFERRED_PROVIDER_virtual\/kernel<\/code> et <code>PREFERRED_VERSION_&lt;kernel&gt;<\/code> : la recette \u00e0 utiliser pour compiler le <em>kernel<\/em> et sa version.<\/li>\n\n\n\n<li><code>KERNEL_DEVICETREE<\/code> le nom du <em>device tree<\/em> \u00e0 utiliser pour ce <em>hardware<\/em>.<\/li>\n\n\n\n<li><code>PREFERRED_PROVIDER_virtual\/bootloader<\/code> et <code>PREFERRED_VERSION_&lt;bootloader&gt;<\/code> indiquant la recette pour le <em>bootloader<\/em> et sa version.<\/li>\n\n\n\n<li>etc.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Configuration de la machine de d\u00e9veloppement<\/h2>\n\n\n\n<p>Un autre fichier, moins connu que le pr\u00e9c\u00e9dent est parcouru par Bitbake, afin de conna\u00eetre les options de compilation \u00e0 appliquer lorsque l&rsquo;on veut pr\u00e9parer <strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">la <em>toolchain<\/em> de <em>cross-compilation<\/em><\/mark><\/strong> en dehors de Yocto. Il s&rsquo;agit de l&rsquo;environnement obtenu quand on ex\u00e9cute <code>bitbake -c populate_sdk &lt;image-name&gt;<\/code>.<\/p>\n\n\n\n<p>Je n&rsquo;ai jamais rencontr\u00e9 de situation o\u00f9 l&rsquo;on utilise un autre fichier de configuration que <code>poky\/meta\/conf\/machine-sdk\/x86_64.conf<\/code> m\u00eame si d&rsquo;autres architectures sont propos\u00e9es&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ <strong>ls ..\/..\/layers\/poky\/meta\/conf\/machine-sdk\/<\/strong>\naarch64.conf i586.conf i686.conf loongarch64.conf ppc64.conf ppc64le.conf riscv64.conf x86_64.conf<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Configuration de la distribution<\/h2>\n\n\n\n<p>Enfin le dernier fichier de configuration qui nous int\u00e9resse est <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">conf\/distro\/${DISTRO}.conf<\/mark><\/strong><\/code>.<\/p>\n\n\n\n<p>Rappelons que la variable <code>DISTRO<\/code> est renseign\u00e9e dans <code>conf\/local.conf<\/code> avec la valeur par d\u00e9faut <code>poky<\/code>. Le fichier concern\u00e9 est donc <code>poky\/meta-poky\/conf\/distro\/poky.conf<\/code>. Outre des param\u00e8tres comme le nom de la distribution et son num\u00e9ro de version, le r\u00f4le principal de ce fichier sera l&rsquo;initialisation de variables comme <code>DISTRO_FEATURES<\/code>, <code>DISTRO_EXTRA_RDEPENDS<\/code> ou <code>DISTRO_OVERRIDES<\/code>. Ces variables permettront de s\u00e9lectionner certains packages dans les recettes ou d&rsquo;activer des options sp\u00e9cifiques lors de la compilation des packages.<\/p>\n\n\n\n<p>Depuis la version Scarthgap de Poky, nous sommes fortement incit\u00e9s \u00e0 surcharger ce fichier, en cr\u00e9ant notre propre distro et en pla\u00e7ant le fichier de configuration dans le sous-r\u00e9pertoire <code>conf\/distro\/<\/code> d&rsquo;un layer personnel. Tant que nous utilisons la distribution <code>poky<\/code> par d\u00e9faut, un message d&rsquo;avertissement s&rsquo;affiche lors de la connexion de l&rsquo;utilisateur. Ce message se trouve dans le fichier suivant&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code has-small-font-size\"><code>$ <strong>cat ..\/..\/layers\/poky\/meta-poky\/recipes-core\/base-files\/files\/poky\/motd <\/strong>\n\nWARNING: Poky is a reference Yocto Project distribution that should be used for\ntesting and development purposes only. It is recommended that you create your\nown distribution for production use.\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Configuration personnalis\u00e9e<\/h3>\n\n\n\n<p>Nous voici donc avec cinq emplacements que nous pouvons personnaliser pour la configuration du build. Bien s\u00fbr viendront ensuite les ajustements de la <mark style=\"background-color:#ffff80\" class=\"has-inline-color\"><strong>recette d&rsquo;image<\/strong><\/mark> et des <mark style=\"background-color:#ffff80\" class=\"has-inline-color\"><strong>recettes de packages<\/strong><\/mark>.<\/p>\n\n\n\n<p>J&rsquo;ai tendance \u00e0 pr\u00e9f\u00e9rer int\u00e9grer le maximum de configuration au niveau de la distribution (dans <code>conf\/distro\/&lt;distro-name&gt;.conf<\/code>) et de la description de la cible (dans <code>conf\/machine\/&lt;machine-name&gt;.conf<\/code>), car ces fichiers se trouvent dans un layer personnalis\u00e9 ce qui simplifie leur <em>versioning<\/em> et leur partage avec d&rsquo;autres d\u00e9veloppeurs. Les fichiers <code>site.conf<\/code> et <code>local.conf<\/code> se trouvant dans le r\u00e9pertoire de <em>build<\/em>, leur sauvegarde r\u00e9clame un m\u00e9canisme sp\u00e9cifique &#8211; par exemple <a href=\"https:\/\/www.blaess.fr\/christophe\/2022\/01\/13\/yocto-cooker-1-3\/\" data-type=\"post\" data-id=\"5897\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Yocto Cooker<\/strong><\/a> \ud83d\ude42 .<\/p>\n\n\n\n<p>Pour d\u00e9finir sa propre distribution, il suffit d&rsquo;ajouter un fichier <code>conf\/distro\/&lt;distro-name&gt;.conf<\/code> dans un <em>layer<\/em> nous appartenant, et de rajouter la ligne <code>DISTRO = \"&lt;distro-name&gt;\"<\/code> dans <code>local.conf<\/code>. Pour cr\u00e9er le fichier, on peut s&rsquo;inspirer de celui de Poky, en \u00e9laguant les fonctionnalit\u00e9s inutiles pour notre projet (dans un premier temps, il suffit m\u00eame d&rsquo;inclure <code>conf\/distro\/poky.conf<\/code> avant de surcharger les variables de description).<\/p>\n\n\n\n<p>De m\u00eame, la d\u00e9finition d&rsquo;une machine revient \u00e0 ajouter un fichier <code>conf\/machine\/&lt;machine-name&gt;.conf<\/code> dans notre layer et une ligne <code>MACHINE=\"&lt;machine-name&gt;\"<\/code> dans <code>local.conf<\/code>. Souvent, on inclut directement la configuration de la machine d&rsquo;origine en intervenant simplement sur le <em>device tree<\/em>.<\/p>\n\n\n\n<p>Dans le cas de la machine, il faudra \u00e9galement intervenir sur la recette du <em>kernel<\/em> pour surcharger la variable <code>COMPATIBLE_MACHINE<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Recettes et image<\/h2>\n\n\n\n<p>Les variables lues dans toute cette s\u00e9rie de fichiers \u00ab\u00a0<code>.conf<\/code>\u00a0\u00bb sont globales, et peuvent \u00eatre surcharg\u00e9es au fur et \u00e0 mesure de leurs initialisations. L&rsquo;initialisation la plus faible est celle de l&rsquo;op\u00e9rateur \u00ab\u00a0<code>??=<\/code>\u00a0\u00bb puis vient l&rsquo;initialisation \u00ab\u00a0<code>?=<\/code>\u00a0\u00bb suivie de \u00ab\u00a0<code>=<\/code>\u00a0\u00bb et finalement l&rsquo;<em>override<\/em>  \u00ab\u00a0<code>:forcevariable<\/code>\u00a0\u00bb .<\/p>\n\n\n\n<p>Une fois cette phase d&rsquo;initialisation termin\u00e9e, Bitbake va lire le contenu des diff\u00e9rents fichiers de recette, en chargeant les variables dans des contextes ind\u00e9pendants pour chaque recette. Par exemple la variable <code>SRC_URI<\/code> est sp\u00e9cifique pour chaque package. Chaque fichier <code><strong>.bb<\/strong><\/code> renseigne sa propre instance de cette variable qui peut \u00e9ventuellement \u00eatre compl\u00e9t\u00e9e dans les <code><strong>.bbappend<\/strong><\/code> du m\u00eame package.<\/p>\n\n\n\n<p>Toutes les recettes sont ainsi lues, incluant \u00e9ventuellement des fichiers <code><strong>.inc<\/strong><\/code>. Dans le contexte de chaque recette sont \u00e9galement ajout\u00e9es les m\u00e9thodes et les variables d\u00e9finies dans les fichiers <code><strong>.bbclass<\/strong><\/code> dont elle h\u00e9rite.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><a href=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_08-45.png\"><img loading=\"lazy\" decoding=\"async\" width=\"650\" height=\"175\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_08-45.png\" alt=\"\" class=\"wp-image-6294\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_08-45.png 650w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/07\/2024-07-05_08-45-300x81.png 300w\" sizes=\"auto, (max-width: 650px) 100vw, 650px\" \/><\/a><\/figure><\/div>\n\n\n<p>Une fois les recettes charg\u00e9es en m\u00e9moire, <code>bitbake<\/code> est pr\u00eat \u00e0 commencer le <em>build<\/em> proprement dit. En cherchant la plupart du temps \u00e0 produire une recette d&rsquo;image, en suivant r\u00e9cursivement ses d\u00e9pendances. Parfois on ne veut produire qu&rsquo;un seul package (et ses d\u00e9pendances bien s\u00fbr).<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Conclusion<\/h1>\n\n\n\n<p>Nous avons examin\u00e9s la liste des fichiers de configuration de <code>bitbake<\/code> et surtout l&rsquo;ordre dans lequel ils sont lus. Ceci nous permet d&rsquo;ajuster notre production de plusieurs mani\u00e8res&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>en fournissant un fichier initialement absent, plus pr\u00e9cis\u00e9ment <code><strong>site.conf<\/strong><\/code> ;<\/li>\n\n\n\n<li>en compl\u00e9tant et modifiant un fichier fourni par Yocto comme <code><strong>local.conf<\/strong><\/code> ;<\/li>\n\n\n\n<li>en fournissant une alternative aux fichier <code><strong>&lt;distro&gt;.conf<\/strong><\/code> et <code><strong>&lt;machine&gt;.conf<\/strong><\/code> se trouvant dans les <em>layers<\/em> int\u00e9gr\u00e9s dans notre image&nbsp;;<\/li>\n\n\n\n<li>et bien s\u00fbr en cr\u00e9ant une recette <code><strong>&lt;image&gt;.bb<\/strong><\/code> personnalis\u00e9e et en ajustant les recettes fournies gr\u00e2ce \u00e0 des <code><strong>.bbappend<\/strong><\/code>.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<p>Dans le prochain article de cette petite s\u00e9rie, nous \u00e9tudierons les variables principales contenues dans ces fichiers de configuration.<\/p>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<p>Pour en savoir plus et mettre en pratique, n&rsquo;h\u00e9sitez \u00e0 participer \u00e0 une session de formation \u00ab\u00a0<strong><a href=\"https:\/\/www.logilin.fr\/formation-linux-embarque-avec-yocto-project.php\">Linux embarqu\u00e9 avec Yocto Project<\/a><\/strong>\u00a0\u00bb ou \u00ab\u00a0<strong><a href=\"https:\/\/www.logilin.fr\/formation-yocto-project-avance.php\">Yocto Project avanc\u00e9<\/a><\/strong>\u00a0\u00bb que j&rsquo;anime chez Logilin.<\/p>","protected":false},"excerpt":{"rendered":"<p>Lorsqu&rsquo;on r&eacute;alise un build pour un syst&egrave;me Linux embarqu&eacute; avec Yocto Project, de nombreux fichiers sont parcourus par l&rsquo;outil Bitbake. Il n&rsquo;est pas toujours simple de savoir dans quel ordre ces fichiers de configuration sont examin&eacute;s, mais c&rsquo;est pourtant une cl&eacute; pour la bonne compr&eacute;hension des op&eacute;rations r&eacute;alis&eacute;es. Nous allons nous int&eacute;resser ici aux fichiers [&hellip;]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-6232","post","type-post","status-publish","format-standard","hentry","category-linux-2"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/6232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=6232"}],"version-history":[{"count":54,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/6232\/revisions"}],"predecessor-version":[{"id":6981,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/6232\/revisions\/6981"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=6232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=6232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=6232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}