{"id":6784,"date":"2024-10-01T05:00:05","date_gmt":"2024-10-01T04:00:05","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=6784"},"modified":"2024-11-13T15:29:21","modified_gmt":"2024-11-13T14:29:21","slug":"les-variables-principales-de-bitbake-2-les-variables-contextuelles","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2024\/10\/01\/les-variables-principales-de-bitbake-2-les-variables-contextuelles\/","title":{"rendered":"Les variables principales de Bitbake &#8211; 2 &#8211; Les variables contextuelles"},"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\/09\/bitbake-variables-02.png\"><img loading=\"lazy\" decoding=\"async\" width=\"400\" height=\"300\" src=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/09\/bitbake-variables-02.png\" alt=\"\" class=\"wp-image-6874\" style=\"width:300px\" srcset=\"https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/09\/bitbake-variables-02.png 400w, https:\/\/www.blaess.fr\/christophe\/wp-content\/uploads\/2024\/09\/bitbake-variables-02-300x225.png 300w\" sizes=\"auto, (max-width: 400px) 100vw, 400px\" \/><\/a><\/figure><\/div>\n\n\n<p>Nous avons vu dans <strong><a href=\"https:\/\/www.blaess.fr\/christophe\/2024\/09\/17\/les-variables-principales-de-bitbake-1-les-variables-globales\/\" data-type=\"post\" data-id=\"6622\">l&rsquo;article pr\u00e9c\u00e9dent<\/a><\/strong> qu&rsquo;il existe de nombreuses variables pour configurer le comportement de Bitbake lors d&rsquo;un <em>build<\/em> de <strong>Yocto Project.<\/strong> Nous avons examin\u00e9 pr\u00e9c\u00e9demment les variables globales, qui sont valables durant tout le <em>build<\/em>.<\/p>\n\n\n\n<p>Nous allons \u00e9tudier \u00e0 pr\u00e9sent les principales <strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">variables contextuelles<\/mark><\/strong> (on parle aussi de variables \u00ab\u00a0scop\u00e9es\u00a0\u00bb) qui ne sont valides que dans certains contextes.<\/p>\n\n\n\n<p>Les contextes qui nous int\u00e9resseront ici sont ceux des <strong>recettes<\/strong> (<code><strong>.bb<\/strong><\/code>) et des amendements de recettes (<code><strong>.bbappend<\/strong><\/code>).<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>Petit conseil&nbsp;: lorsque vous soup\u00e7onnez une variable contextuelle de n&rsquo;\u00eatre pas correctement remplie, employez <code><strong>bitbake  -e  &lt;recipe-name&gt; | grep ^&lt;variable&gt;<\/strong><\/code> pour voir son contenu.<\/p>\n\n\n\n<p>Voici un exemple&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ <strong>bitbake  -e  vim | grep  ^SRC_URI<\/strong>\nSRC_URI=\"git:\/\/github.com\/vim\/vim.git;branch=master;protocol=https            file:\/\/disable_acl_header_check.patch            file:\/\/vim-add-knob-whether-elf.h-are-checked.patch            file:\/\/0001-src-Makefile-improve-reproducibility.patch            file:\/\/no-path-adjust.patch            \"<\/code><\/pre>\n\n\n\n<p>Le contenu de la variable n&rsquo;est pas tr\u00e8s bien format\u00e9, mais il est lisible. Cela correspond bien \u00e0 ce qui \u00e9tait renseign\u00e9 dans la recette&nbsp;:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ <strong>cat ..\/..\/layers\/poky\/meta\/recipes-support\/vim\/vim.inc <\/strong>\n &#91;...]\nSRC_URI = \"git:\/\/github.com\/vim\/vim.git;branch=master;protocol=https \\\n           file:\/\/disable_acl_header_check.patch \\\n           file:\/\/vim-add-knob-whether-elf.h-are-checked.patch \\\n           file:\/\/0001-src-Makefile-improve-reproducibility.patch \\\n           file:\/\/no-path-adjust.patch \\\n           \"<\/code><\/pre>\n\n\n\n<p>L&rsquo;option <code><strong>-e<\/strong><\/code> de <code>bitbake<\/code> lui demande de ne pas faire le <em>build<\/em> attendu, mais d&rsquo;afficher sur sa sortie standard le contenu de son environnement (ses variables et ses fonctions). En pr\u00e9c\u00e9dant le nom de la variable par <code><strong>^<\/strong><\/code> nous nous assurons qu&rsquo;elle est align\u00e9e en d\u00e9but de ligne. C&rsquo;est donc une ligne d&rsquo;initialisation de la variable, et non pas une ligne o\u00f9 elle est int\u00e9gr\u00e9e dans une autre variable.<\/p>\n\n\n\n<p>Comme dans l&rsquo;<a href=\"https:\/\/www.blaess.fr\/christophe\/2024\/09\/17\/les-variables-principales-de-bitbake-1-les-variables-globales\/\" data-type=\"post\" data-id=\"6622\">article pr\u00e9c\u00e9dent<\/a>, je suis oblig\u00e9 de faire une s\u00e9lection dans la liste imposante de variables configurant le comportement de <code>bitbake<\/code>. J&rsquo;ai choisi de retenir les variables que je me souviens avoir configur\u00e9es (ou dont j&rsquo;ai examin\u00e9 le contenu) durant les derniers mois.<\/p>\n\n\n\n<p>L&rsquo;objectif n&rsquo;est<strong> pas de faire une description compl\u00e8te<\/strong> de l&rsquo;utilisation d&rsquo;une variable donn\u00e9e, pour cela la <strong><a href=\"https:\/\/docs.yoctoproject.org\/dev\/singleindex.html#\" data-type=\"link\" data-id=\"https:\/\/docs.yoctoproject.org\/dev\/singleindex.html#\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">documentation de Yocto Project<\/a><\/strong> est la r\u00e9f\u00e9rence, mais plut\u00f4t de fournie une <strong>liste inverse<\/strong>, o\u00f9 l&rsquo;<mark style=\"background-color:#ffff80\" class=\"has-inline-color\">on part du <strong>r\u00e9sultat attendu<\/strong> pour retrouver <strong>le nom d&rsquo;une variable<\/strong><\/mark> pr\u00e9cise.<\/p>\n\n\n\n<p>Pour cela j&rsquo;ai regroup\u00e9 les variables par probl\u00e9matique et obtenu la liste suivante&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"#informations-sur-la-recette\"><strong>1 &#8211; Informations sur la recette<\/strong><\/a><\/li>\n\n\n\n<li><a href=\"#obtention-des-fichiers-sources\"><strong>2 &#8211; Obtention des fichiers sources<\/strong><\/a><\/li>\n\n\n\n<li><strong><a href=\"#compilation\">3 &#8211; Compilation<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"#gestion-des-dependances\">4 &#8211; Gestion des d\u00e9pendances<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"#installation-sur-la-cible\">5 &#8211; Installation sur la cible<\/a><\/strong><\/li>\n\n\n\n<li><strong><a href=\"#specificite-des-recettes-kernel\">6 &#8211; Sp\u00e9cificit\u00e9s des recettes kernel<\/a><\/strong><\/li>\n<\/ul>\n\n\n\n<p>Sauf mention particuli\u00e8re, les variables contextuelles des recettes sont facultatives. Il en existe tr\u00e8s peu (3) qui sont obligatoires.<\/p>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"informations-sur-la-recette\">1 &#8211; Informations sur la recette<\/h1>\n\n\n\n<p>Le d\u00e9but d&rsquo;une recette est g\u00e9n\u00e9ralement consacr\u00e9 \u00e0 des variables d&rsquo;information sur la recette. Cela permet de savoir qui a \u00e9crit la recette elle-m\u00eame et d&rsquo;avoir une id\u00e9e de son contenu.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Tra\u00e7abilit\u00e9<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><mark style=\"background-color:#ffff80\" class=\"has-inline-color\"><strong>SUMMARY<\/strong><\/mark><\/code> contient une br\u00e8ve description (une ligne de 72 caract\u00e8res au maximum) du contenu de la recette. C&rsquo;est ce qu&rsquo;on affiche lorsqu&rsquo;on pr\u00e9sente une liste de recettes comme sur le site <strong><a href=\"https:\/\/layers.openembedded.org\/layerindex\/branch\/scarthgap\/recipes\/?q=bash\" data-type=\"link\" data-id=\"https:\/\/layers.openembedded.org\/layerindex\/branch\/scarthgap\/recipes\/?q=bash\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">OpenEmbedded Layer Index<\/a><\/strong>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">DESCRIPTION<\/mark><\/strong><\/code> permet une pr\u00e9sentation plus d\u00e9taill\u00e9e du contenu. On peut pr\u00e9senter ce champ sur une <strong><a href=\"https:\/\/layers.openembedded.org\/layerindex\/recipe\/397771\/\" data-type=\"link\" data-id=\"https:\/\/layers.openembedded.org\/layerindex\/recipe\/397771\/\" target=\"_blank\" rel=\"noreferrer noopener nofollow\">page d\u00e9di\u00e9e \u00e0 une recette<\/a><\/strong> par exemple.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">RECIPE_MAINTAINER<\/mark><\/strong><\/code>, contient le nom et l&rsquo;adresse mail de l&rsquo;auteur de la recette. Bien qu&rsquo;assez rarement pr\u00e9sent, ce champ est utile lorsqu&rsquo;on int\u00e8gre une recette ind\u00e9pendante (trouv\u00e9e sur GitHub par exemple) dans un layer personnel. Cela permet de faire part \u00e0 l&rsquo;auteur original des corrections ult\u00e9rieures apport\u00e9es \u00e0 sa recette.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">HOMEPAGE<\/mark><\/strong><\/code> est un champ purement informatif qui permet de retrouver facilement les informations prises comme r\u00e9f\u00e9rences lors de la r\u00e9daction de la recette. Ceci est surtout utile dans le cas d&rsquo;un projet peu connu et dont l&rsquo;origine exacte n&rsquo;est pas \u00e9vidente.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Licence<\/h2>\n\n\n\n<p>On sait l&rsquo;importance que Yocto Project apporte \u00e0 la connaissance des termes des licences de tous les composants embarqu\u00e9s dans une image. Ceci est extr\u00eamement important pour s&rsquo;assurer de la bonne cohabitation de tous les packages, d&rsquo;autant plus dans des environnements industriels o\u00f9 les syst\u00e8mes embarqu\u00e9s doivent int\u00e9grer des logiciels propri\u00e9taires.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">LICENSE<\/mark><\/strong><\/code> indique la licence (ou la liste de licences) sous laquelle le code g\u00e9r\u00e9 par la recette est distribu\u00e9. Cette variable est <strong>obligatoire<\/strong> dans toutes les recettes. Lorsque le projet contient des fichiers sources fournis sous diff\u00e9rentes licences, on associe leurs noms avec un caract\u00e8re <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">&amp;<\/mark><\/strong><\/code>. Lorsqu&rsquo;il est possible de choisir entre les termes de diff\u00e9rentes licences, on utilise le caract\u00e8re <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">|<\/mark><\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">LIC_FILES_CHKSUM<\/mark><\/strong><\/code> est la deuxi\u00e8me variable <strong>obligatoire<\/strong> dans toutes les recettes (la troisi\u00e8me sera <code>SRC_URI<\/code>) sauf dans le cas o\u00f9 <code>LICENSE<\/code> contient <code>CLOSED<\/code>. Il s&rsquo;agit de la liste des <em>checksums<\/em> des fichiers contenant les termes des licences indiqu\u00e9es dans <code>LICENSE<\/code>. De cette fa\u00e7on l&rsquo;auteur de la recette pr\u00e9cise quelle version des fichiers il a consult\u00e9 pour d\u00e9terminer le type de licence. Lorsqu&rsquo;il n&rsquo;y a pas de fichier de licence livr\u00e9 avec les sources, on peut utiliser ceux fournis dans le r\u00e9pertoire <code><strong>${COMMON_LICENSE_DIR}<\/strong><\/code> de Poky.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">NO_GENERIC_LICENSE<\/mark><\/strong><\/code> est utilis\u00e9 pour pr\u00e9ciser que la recette utilise une licence personnelle non g\u00e9n\u00e9rique (et diff\u00e9rente de <code>CLOSED<\/code>). On peut pr\u00e9ciser que le texte de la licence se trouve dans un fichier t\u00e9l\u00e9charg\u00e9 dans l&rsquo;\u00e9tape <code>do_fetch()<\/code> avec la notation<br><code><strong>NO_GENERIC_LICENSE[&lt;license-name&gt;] = \"&lt;license-file&gt;\"<\/strong><\/code><\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">LICENSE_FLAGS<\/mark><\/strong><\/code> peut contenir un nom de licence personnalis\u00e9 qu&rsquo;il faudra obligatoirement inscrire dans la variable globale <code>LICENSE_FLAGS_ACCEPTED<\/code> (dans le fichier <code>local.conf<\/code>) pour pouvoir compiler la recette.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"obtention-des-fichiers-sources\">2 &#8211; Obtention des fichiers sources<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Emplacement des sources<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">SRC_URI<\/mark><\/strong><\/code> est une des trois variables <strong>obligatoires<\/strong> pour toutes les recettes (avec <code>LICENSE<\/code> et <code>LIC_FILES_CHKSUM<\/code>). Il s&rsquo;agit de la liste des fichiers que <code>bitbake<\/code> doit se procurer lors de l&rsquo;\u00e9tape <code>do_fetch()<\/code> pour produire le r\u00e9sultat de la recette.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">SRCREV<\/mark><\/strong><\/code> contient le num\u00e9ro de version \u00e0 extraire (pour les protocoles <code>git:\/\/<\/code>, <code>svn:\/\/<\/code>, <code>hg:\/\/<\/code> et <code>bzr:\/\/<\/code>). Avec <code>git:\/\/<\/code>, il peut s&rsquo;agir d&rsquo;un <em>hash<\/em> SHA ou d&rsquo;un tag. La sp\u00e9cification<br><code><strong>SRCREV=${AUTOREV}<\/strong><\/code><br>charge toujours la derni\u00e8re version du projet source.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">FILESEXTRAPATHS<\/mark><\/strong><\/code> contient les emplacements o\u00f9 chercher les fichiers pr\u00e9fix\u00e9s par <code>file:\/\/<\/code> en suppl\u00e9ment des chemins usuels de <code>bitbake<\/code>. Cette variable est surtout utilis\u00e9e dans les fichiers d&rsquo;amendement de recette <code><strong>.bbappend<\/strong><\/code> ainsi&nbsp;:<br><code><strong>FILESEXTRAPATHS:prepend&nbsp;:= \u201c${THISDIR}\/${PN}:\u201d<\/strong><\/code><\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">EXTERNALSRC<\/mark><\/strong><\/code> est une variable qui prend sa signification lorsque la recette h\u00e9rite de la classe <code>\"<strong>externalsrc<\/strong>\"<\/code>. On peut y indiquer le r\u00e9pertoire des sources (pendant une phase de d\u00e9veloppement par exemple) de la recette. Dans ce cas les \u00e9tapes <code>do_fetch()<\/code>, <code>do_unpack()<\/code> et <code>do_patch()<\/code> sont ignor\u00e9es, le chemin point\u00e9 par <code><strong>EXTERNALSRC<\/strong><\/code> est inscrit dans la variable <code><strong>S<\/strong><\/code>.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Versions et mises \u00e0 jour<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">UPSTREAM_CHECK_URI<\/mark><\/strong><\/code> peut contenir l&rsquo;URL des sources, qui sera consult\u00e9e lorsqu&rsquo;on appelle la commande<br><code><strong>devtool latest-version &lt;recipe-name&gt;<\/strong><\/code><br>pour v\u00e9rifier si une nouvelle version est disponible.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">UPSTREAM_CHECK_COMMITS<\/mark><\/strong><\/code> est une variable bool\u00e9enne. Quand elle vaut \u00ab\u00a0<code><strong>1<\/strong><\/code>\u00a0\u00bb le contenu de <code>UPSTREAM_CHECK_URI<\/code> est consid\u00e9r\u00e9 comme un d\u00e9p\u00f4t Git et la commande<br><code><strong>devtool latest-version &lt;recipe-name&gt;<\/strong><\/code><br>v\u00e9rifie et affiche le num\u00e9ro du dernier <em>commit<\/em>.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">V\u00e9rification des vuln\u00e9rabilit\u00e9s<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">CVE_PRODUCT<\/mark><\/strong><\/code> contient le nom \u00e0 prendre en consid\u00e9ration pour le package lorsque <code>bitbake<\/code> v\u00e9rifie la pr\u00e9sence de vuln\u00e9rabilit\u00e9s connues (quand la variable globale <code><strong>INHERIT<\/strong><\/code> contient le nom de la classe \u00ab\u00a0<code><strong>cve-check<\/strong><\/code>\u00ab\u00a0).<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">CVE_VERSION<\/mark><\/strong><\/code> contient le num\u00e9ro de version \u00e0 prendre en compte pendant la v\u00e9rification de la base de donn\u00e9es des vuln\u00e9rabilit\u00e9s.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">CVE_STATUS<\/mark><\/strong><\/code> contient une table <code><strong>CVE_STATUS[&lt;cve-id&gt;] = \"reason\"<\/strong><\/code> donnant la justification pour laquelle une vuln\u00e9rabilit\u00e9 connue pour ce package doit \u00eatre ignor\u00e9e.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"compilation\">3 &#8211; Compilation<\/h1>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">EXTRA_AUTORECONF<\/mark><\/strong><\/code> et <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">EXTRA_OECONF<\/mark><\/strong><\/code> sont utilis\u00e9es dans les recettes h\u00e9ritant de la classe <code>autotools<\/code> pour passer des arguments \u00e0 <code><strong>autoreconf<\/strong><\/code> et au script <code><strong>configure<\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">EXTRA_OEMAKE<\/mark><\/strong><\/code> et <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">EXTRA_OECMAKE<\/mark><\/strong><\/code> contiennent des options pour les commandes <code><strong>make<\/strong><\/code> et <code><strong>cmake<\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">TARGET_CFLAGS<\/mark><\/strong><\/code>,  <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">BUILD_CFLAGS<\/mark><\/strong><\/code> et <code><strong><mark style=\"background-color:#ffff90\" class=\"has-inline-color\">BUILDSDK_CFLAGS<\/mark><\/strong><\/code> contiennent les param\u00e8tres \u00e0 placer dans la variable <code><strong>CFLAGS<\/strong><\/code> pendant les compilations respectives pour la cible, le syst\u00e8me de <em>build<\/em> et le SDK. Le m\u00eame r\u00f4le est jou\u00e9e par les variables <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">TARGET_CXXFLAGS<\/mark><\/strong><\/code> etc. pour <code><strong>CXXFLAGS<\/strong><\/code>, et <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">TARGET_LDFLAGS<\/mark><\/strong><\/code> etc. pour <code><strong>LDFLAGS<\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">S<\/mark><\/strong><\/code> contient l&#8217;emplacement des sources \u00e0 compiler. <code>bitbake<\/code> essaye de \u00ab\u00a0deviner\u00a0\u00bb cet emplacement \u00e0 partir de l&rsquo;\u00e9tape <code>do_unpack()<\/code> mais il est souvent n\u00e9cessaire de lui ajouter des pr\u00e9cisions quand l&rsquo;arborescence extraite n&rsquo;est pas triviale (par exemple <code><strong>S=\"${WORKDIR}\/sources\"<\/strong><\/code>).<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">B<\/mark><\/strong><\/code> et <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">D<\/mark><\/strong><\/code> repr\u00e9sentent respectivement le r\u00e9pertoire de <em>build<\/em> et celui d&rsquo;installation de l&rsquo;arborescence destin\u00e9e \u00e0 la cible. On peut \u00eatre amen\u00e9 \u00e0 modifier <code><strong>B<\/strong><\/code> pour \u00e9viter les conflits avec <code><strong>S<\/strong><\/code>, en revanche on ne modifie pas <code><strong>D<\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">EXTERNALSRC_BUILD<\/mark><\/strong><\/code> doit \u00eatre renseign\u00e9e avec l&#8217;emplacement o\u00f9 stocker les r\u00e9sultats de compilation lorsque la recette h\u00e9rite de la classe <code><strong>externalsrc<\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">PACKAGES<\/mark><\/strong><\/code> contient la liste des packages binaires \u00e0 cr\u00e9er pendant la compilation. Par d\u00e9faut , <code>PACKAGES<\/code> vaut <code>\"${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}\"<\/code> mais on peut retirer <code>${PN}-dbg<\/code> par exemple si on n&rsquo;envisage pas d&rsquo;utiliser les symboles de <em>debug<\/em>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">BBCLASSEXTEND<\/mark><\/strong><\/code> est une variable qui contient la liste des extensions de packages \u00e0 compiler. On peut \u00eatre amen\u00e9s \u00e0 ins\u00e9rer dans une recette <code><strong>BBCLASSEXTEND += \"native\"<\/strong><\/code> ou <code><strong>\"nativesdk\"<\/strong><\/code> pour indiquer qu&rsquo;elle doit \u00eatre \u00e9galement compil\u00e9e pour la machine h\u00f4te ou int\u00e9gr\u00e9e dans le SDK.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"gestion-des-dependances\">4 &#8211; Gestion des d\u00e9pendances<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">D\u00e9pendances et conflits entre recettes<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">DEPENDS<\/mark><\/strong><\/code> contient la liste des d\u00e9pendances n\u00e9cessaires pour compiler la recette, <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">RDEPENDS<\/mark><\/strong><\/code> (<code>R<\/code> pour <em>runtime<\/em>) liste les d\u00e9pendances n\u00e9cessaires pour installer la recette sur la cible. Les d\u00e9pendances sont classiquement des noms de packages.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">PROVIDES<\/mark><\/strong><\/code> et <code><mark style=\"background-color:#ffff80\" class=\"has-inline-color\"><strong>RPROVIDES<\/strong><\/mark><\/code> indiquent les fonctionnalit\u00e9s offertes par une recette pendant la phase de compilation et l&rsquo;installation sur la cible. Ces fonctionnalit\u00e9s sont utilisables dans les variables <code><strong>DEPENDS<\/strong><\/code> et <code><strong>RDEPENDS<\/strong><\/code> d&rsquo;autres recettes.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">RRECOMMENDS<\/mark><\/strong><\/code> liste les packages suppl\u00e9mentaires que l&rsquo;on sugg\u00e8re d&rsquo;installer sur la cible en compl\u00e9ment de la recette courante. La variable globale <code><strong><a href=\"https:\/\/www.blaess.fr\/christophe\/2024\/09\/17\/les-variables-principales-de-bitbake-1-les-variables-globales\/#filtrage-des-recettes\" data-type=\"post\" data-id=\"6622\" target=\"_blank\" rel=\"noreferrer noopener\">BAD_RECOMMENDATIONS<\/a><\/strong><\/code> permet de refuser l&rsquo;installation automatique de certains packages conseill\u00e9s.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">RCONFLICTS<\/mark><\/strong><\/code> contient une liste de packages en conflit avec la recette. Si l&rsquo;un de ces packages est pr\u00e9sent sur la cible, le produit de la recette ne pourra pas y \u00eatre install\u00e9.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">RREPLACES<\/mark><\/strong><\/code> indique une liste de packages obsol\u00e8tes remplac\u00e9s par la recette lors d&rsquo;une \u00e9volution du syst\u00e8me.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Fonctionnalit\u00e9s de distro<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">REQUIRED_DISTRO_FEATURES<\/mark><\/strong><\/code> liste les fonctionnalit\u00e9s qui doivent toutes \u00eatre pr\u00e9sentes dans la variable globale <code><strong>DISTRO_FEATURES<\/strong><\/code> pour que la recette puisse \u00eatre compil\u00e9e. <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">ANY_OF_DISTRO_FEATURES<\/mark><\/strong><\/code> liste les fonctionnalit\u00e9s dont au moins une doit \u00eatre pr\u00e9sente dans <code><strong>DISTRO_FEATURES<\/strong><\/code>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">CONFLICT_DISTRO_FEATURES<\/mark><\/strong><\/code> liste les fonctionnalit\u00e9s de distro qui sont incompatibles avec la compilation de la recette. Cette variable refl\u00e8te souvent les antagonismes XWindow\/Wayland ou sysVinit\/systemd par exemple.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"installation-sur-la-cible\">5 &#8211; Installation sur la cible<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">Fichiers install\u00e9s<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">FILES<\/mark><\/strong><\/code> est une variable qui contient la liste des fichiers et r\u00e9pertoires install\u00e9s par une recette. Cette variable doit toujours \u00eatre utilis\u00e9e avec l&rsquo;<em>override<\/em> <code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">FILES:${PN}<\/mark><\/strong><\/code>.<\/li>\n\n\n\n<li><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">CONFFILES<\/mark><\/strong> est \u00e9galement une variable toujours utilis\u00e9e avec l&rsquo;<em>override<\/em> <code><mark style=\"background-color:#ffff80\" class=\"has-inline-color\"><strong>CONFFILES:${PN}<\/strong><\/mark><\/code>. Elle contient la liste des fichiers utilis\u00e9s pour la configuration dynamique du syst\u00e8me cible. Ces fichiers ne seront pas \u00e9cras\u00e9s dans le cas d&rsquo;une mise \u00e0 jour du <em>package<\/em> sur la cible.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">ALTERNATIVE<\/mark><\/strong><\/code> contient la liste des commandes de la recette qui sont susceptibles de se trouver \u00e9galement impl\u00e9ment\u00e9es par une autre recette. L&rsquo;exemple typique est celui de Busybox qui impl\u00e9mente de tr\u00e8s nombreuses commandes que l&rsquo;on trouve \u00e9galement dans leurs propres packages.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">ALTERNATIVE_LINK_NAME<\/mark><\/strong><\/code> est un tableau associatif qui contient le chemin du lien symbolique que <code>bitbake<\/code> doit cr\u00e9er vers une commande alternative, le format est<br><code><strong>ALTERNATIVE_LINK_NAME[&lt;command&gt;] = \"\/&lt;path&gt;\/&lt;command&gt;\"<\/strong><\/code><\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">ALTERNATIVE_PRIORITY<\/mark><\/strong><\/code> est \u00e9galement un tableau associatif index\u00e9 par le nom de commande, qui indique sa priorit\u00e9 par rapport aux impl\u00e9mentations dans d&rsquo;autres recettes. L&rsquo;impl\u00e9mentation de priorit\u00e9 la plus \u00e9lev\u00e9e est utilis\u00e9e comme cible du lien. Le format est<br><code><strong>ALTERNATIVE_PRIORITY[&lt;command&gt;] = \"&lt;value&gt;\"<\/strong><\/code><\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Lancement au <em>boot<\/em><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">INITSCRIPT_NAME<\/mark><\/strong><\/code> contient le nom du script \u00e0 ex\u00e9cuter au d\u00e9marrage lorsque le syst\u00e8me de d\u00e9marrage est du type <code>sysVinit<\/code>. La recette doit h\u00e9riter de la classe <code><strong>update-rc.d<\/strong><\/code>. Le script devra \u00eatre copi\u00e9 pendant l&rsquo;\u00e9tape <code>do_install()<\/code> dans <code><strong>${D}${sysconfdir}\/init.d<\/strong><\/code><\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">INITSCRIPT_PARAMS<\/mark><\/strong><\/code> contient dans ce cas les param\u00e8tres pour <code>update-rc.d<\/code>, c&rsquo;est-\u00e0-dire des s\u00e9quences commen\u00e7ant par <code>start<\/code> ou <code>stop<\/code> suivi du num\u00e9ro d&rsquo;ordre de d\u00e9marrage du service, des <em>runlevels<\/em> concern\u00e9s et d&rsquo;un point \u00ab\u00a0<code>.<\/code>\u00ab\u00a0.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">SYSTEMD_SERVICE<\/mark><\/strong><\/code> est une variable que l&rsquo;on utilise avec l&rsquo;<em>override<\/em> <code><strong>SYSTEMD_SERVICE:${PN}<\/strong><\/code> pour indiquer le nom du fichier de service pour <code>systemd<\/code> (qui doit \u00e9galement \u00eatre copi\u00e9 pendant l&rsquo;\u00e9tape <code>do_install()<\/code> dans <code><strong>${D}\/${systemd_system_unitdir}<\/strong><\/code>). Il faut que la recette h\u00e9rite de la classe \u00ab\u00a0<code><strong>systemd<\/strong><\/code>\u00ab\u00a0.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">SYSTEMD_AUTO_ENABLE<\/mark><\/strong><\/code> peut contenir la cha\u00eene de caract\u00e8res \u00ab\u00a0<code><strong>enable<\/strong><\/code>\u00a0\u00bb pour que le service indiqu\u00e9 ci-dessus d\u00e9marre automatiquement au <em>boot<\/em>.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"specificite-des-recettes-kernel\">6 &#8211; Sp\u00e9cificit\u00e9s des recettes <em>kernel<\/em><\/h1>\n\n\n\n<p>Une recette pour le noyau Linux doit h\u00e9riter de la classe <code><strong>kernel<\/strong><\/code>. Certaines variables pr\u00e9sent\u00e9es ci-dessous sont en r\u00e9alit\u00e9 des variables globales, mais on les d\u00e9finit toujours dans la recette du noyau.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">COMPATIBLE_HOST<\/mark><\/strong><\/code> est une variable que l&rsquo;on peut rencontrer dans n&rsquo;importe quelle recette, mais c&rsquo;est surtout dans les recettes du <em>kernel<\/em> et du <em>bootloader<\/em> qu&rsquo;elle a du sens. Il s&rsquo;agit d&rsquo;une expression rationnelle qui est compar\u00e9e avec le contenu de la variable globale <code><strong>HOST_SYS<\/strong><\/code> (remplie automatiquement avec <code><strong>${HOST_ARCH}-${HOST_VENDOR}-${HOST_OS}<\/strong><\/code>) pour savoir si la recette peut \u00eatre compil\u00e9e.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">COMPATIBLE_MACHINE<\/mark><\/strong><\/code> est une expression rationnelle qui est compar\u00e9e avec les \u00e9l\u00e9ments de la variable globale <code><strong>MACHINEOVERRIDES<\/strong><\/code> pour savoir si la recette peut \u00eatre compil\u00e9e. On utilise une notation comme&nbsp;:<br><code><strong>COMPATIBLE_MACHINE = \"^(arm|aarch64)$\"<\/strong><\/code><\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">KMACHINE<\/mark><\/strong><\/code> contient le nom de la machine pour le noyau, qui n&rsquo;est pas n\u00e9cessairement le m\u00eame nom que celui pour le reste du <em>build<\/em> (dans la variable globale <code><strong>MACHINE<\/strong><\/code>).<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">KBRANCH<\/mark><\/strong><\/code> est une variable globale configur\u00e9e dans la recette <em>kernel<\/em>, qui contient le nom de la branche \u00e0 utiliser pour les sources du <em>kernel<\/em>.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">LINUX_VERSION<\/mark><\/strong><\/code> doit contenir le num\u00e9ro officiel (par exemple <code>6.6.52<\/code>) de version du noyau utilis\u00e9.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">LINUX_VERSION_EXTENSION<\/mark><\/strong><\/code> est une cha\u00eene de caract\u00e8res ajout\u00e9 au num\u00e9ro de version du noyau. On s&rsquo;en sert parfois pour identifier la provenance du noyau sur lequel on a d\u00e9marr\u00e9, gr\u00e2ce \u00e0 la commande  \u00ab\u00a0<code><strong>uname -r<\/strong><\/code>\u00ab\u00a0.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">KBUILD_DEFCONFIG<\/mark><\/strong><\/code> contient le nom de la configuration interne au <em>kernel<\/em> \u00e0 utiliser. Le mode d&rsquo;utilisation est&nbsp;:<br><code><strong>KBUILD_DEFCONFIG:&lt;machine&gt; = \"&lt;kmachine&gt;_defconfig\"<\/strong><\/code><\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">KERNEL_DEVICETREE<\/mark><\/strong><\/code> est une variable utilis\u00e9e lorsque la recette h\u00e9rite de la classe \u00ab\u00a0<code><strong>kernel-devicetree<\/strong><\/code>\u00ab\u00a0, elle contient le nom du fichier <code><strong>.dtb<\/strong><\/code> \u00e0 produire.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">DT_FILES_PATH<\/mark><\/strong><\/code> contient l&#8217;emplacement des fichiers sources pour le <em>device tree<\/em> (<code><strong>.dts<\/strong><\/code> et <code><strong>.dtsi<\/strong><\/code>) lorsqu&rsquo;ils sont fournis en dehors des sources du noyau. La recette doit h\u00e9riter de la classe \u00ab\u00a0<code><strong>kernel-devicetree<\/strong><\/code>\u00ab\u00a0.<\/li>\n\n\n\n<li><code><strong><mark style=\"background-color:#ffff80\" class=\"has-inline-color\">KERNEL_PACKAGE_NAME<\/mark><\/strong><\/code> contient le nom de base du <em>package<\/em> du noyau (en g\u00e9n\u00e9ral \u00ab\u00a0<code><strong>kernel<\/strong><\/code>\u00ab\u00a0) pour nommer ensuite les <em>packages<\/em> des modules, l&rsquo;image binaire, etc.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Conclusion<\/h1>\n\n\n\n<p>Nous avons \u00e9tudi\u00e9 dans cette petite s\u00e9rie de trois articles plusieurs \u00e9l\u00e9ments de configuration de Yocto Project&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tout d&rsquo;abord <strong><a href=\"https:\/\/www.blaess.fr\/christophe\/2024\/09\/03\/les-fichiers-parcourus-par-bitbake\/\" data-type=\"post\" data-id=\"6232\" target=\"_blank\" rel=\"noreferrer noopener\">la liste des fichiers parcourus lors du <em>build<\/em><\/a><\/strong>, leur ordre et la logique sous-jacente. En nous concentrant sur les fichiers de configuration dans lesquels on intervient habituellement.<\/li>\n\n\n\n<li>Puis <strong><a href=\"https:\/\/www.blaess.fr\/christophe\/2024\/09\/17\/les-variables-principales-de-bitbake-1-les-variables-globales\/\" data-type=\"post\" data-id=\"6622\" target=\"_blank\" rel=\"noreferrer noopener\">une liste de variables globale<\/a><\/strong>s, disponibles pendant tout le build, en essayant de les classer logiquement en fonction de leur utilisation.<\/li>\n\n\n\n<li>Enfin des variables contextuelles utilis\u00e9es dans les recettes et dont la port\u00e9e est limit\u00e9e \u00e0 la recette o\u00f9 elles sont d\u00e9finies.<\/li>\n<\/ul>\n\n\n\n<p class=\"has-text-align-center\">&#8211;<\/p>\n\n\n\n<p>J&rsquo;esp\u00e8re que ces \u00e9l\u00e9ments sauront vous \u00eatre utiles pour \u00e9clairer certains aspects un peu obscurs du <em>build<\/em> de Yocto Project.<\/p>\n\n\n\n<p>La prochaine s\u00e9rie d&rsquo;articles, qui d\u00e9butera dans deux semaines, sera consacr\u00e9 \u00e0 un tout autre sujet&nbsp;: le syst\u00e8me d&rsquo;exploitation pour microcontr\u00f4leurs <strong>Zephyr OS<\/strong> !<\/p>\n\n\n\n<p class=\"has-text-align-center\">&#8211; <\/p>\n\n\n\n<p>Pour en savoir plus sur Yocto et Bitbake et mettre en pratique les \u00e9l\u00e9ments aper\u00e7us dans cet article, n\u2019h\u00e9sitez pas \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\u2019anime chez <a href=\"https:\/\/www.logilin.fr\/index.php\">Logilin<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Nous avons vu dans l&rsquo;article pr&eacute;c&eacute;dent qu&rsquo;il existe de nombreuses variables pour configurer le comportement de Bitbake lors d&rsquo;un build de Yocto Project. Nous avons examin&eacute; pr&eacute;c&eacute;demment les variables globales, qui sont valables durant tout le build. Nous allons &eacute;tudier &agrave; pr&eacute;sent les principales variables contextuelles (on parle aussi de variables &laquo;&nbsp;scop&eacute;es&nbsp;&raquo;) qui ne sont [&hellip;]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,8,21],"tags":[],"class_list":["post-6784","post","type-post","status-publish","format-standard","hentry","category-embarque","category-linux-2","category-yocto-project"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/6784","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=6784"}],"version-history":[{"count":54,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/6784\/revisions"}],"predecessor-version":[{"id":6979,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/6784\/revisions\/6979"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=6784"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=6784"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=6784"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}