Notre dernier article sur Yocto nous a permis de comprendre le fonctionnement de bitbake, d'explorer la notion d'environnement et de comprendre comment les variables, recettes et tâches sont analysées et comprises par cet outil de développement.

Bien sûr, le but premier de yocto n'est pas de lire des fichiers de configuration mais de les utiliser pour compiler des sources. Cet article va entrer dans les détails du fonctionnement d'une recette, comment yocto s'organise pour compiler un logiciel et générer un paquetage et les différents outils disponibles pour la mise au point.

Petit rappel sur les recettes et l'environnement

Toute commande bitbake est exécutée en deux phases : l'analyse et l'exécution.

Bitbake va d'abord relire l'ensemble des fichiers de configuration de la distribution et l'ensemble des recettes pour construire un environnement correspondant à chaque recette. Chaque environnement est un ensemble de paires clé/valeur où la valeur peut aussi bien être une chaîne de caractère (variable normale) qu'un bloc de code python ou shell (tâche). Vous pouvez voir l'environnement correspondant à une recette grâce à la commande bitbake -e <recette>
Une fois cet environnement construit, bitbake va exécuter la tâche qui lui a été demandée. Si aucune tâche n'est fournie, bitbake va exécuter une tâche par défaut, la tâche appelée build.

Pour exécuter une tâche, bitbake va d'abord rechercher une variable d'environnement appelée do_<nom de la tâche> qui contiendra le code de la tâche à exécuter (en python ou en shell). Ainsi, pour compiler une recette, yocto utilisera le code contenu dans la variable do_compile.

Mettre au point une recette yocto revient généralement à comprendre le but et les résultats de chaque tâche et comment ces tâches se coordonnent pour produire des paquetages.

 

Les étapes de la compilation

Lorsque vous demandez à yocto de générer les paquetages correspondant à une recette, bitbake va exécuter un certain nombre de tâches qui sont assez proche de celle que l'on doit réaliser pour installer manuellement un logiciel.

do_fetch

Bitbake va d’abord utiliser la variable SRC_URI pour trouver la liste des sources dont il aura besoin pour construire le paquetage. Bitbake va ensuite télécharger ces différents fichiers.

Le téléchargement des sources est géré par bitbake directement (et non par du code python). Les détails de cette étape sont donc dans la documentation de bitbake et non dans la documentation yocto.

• Bitbake va d'abord vérifier si les sources ne sont pas déjà disponibles dans le répertoire DL_DIR
• Si ce n'est pas le cas, bitbake va vérifier aux URLs spécifiées dans la variable PREMIRRORS
• Bitbake cherchera ensuite les fichiers à l'endroit spécifié dans SRC_URI. Il s'agit de la source "normale" pour les fichiers.
• Enfin, si rien n'a fonctionné, bitbake vérifiera si les sources sont disponibles aux URLs spécifiées dans la variable MIRRORS

Le mode de téléchargement, les protocoles à utiliser et de nombreux paramètres peuvent être précisés dans SRC_URI. Vous trouverez toutes ces informations nécessaires dans la documentation bitbake.

Tous les fichiers téléchargés sont placés dans DL_DIR pour pouvoir être réutilisés lors d'un futur appel à do_fetch.

do_unpack

Nous avons téléchargé les fichiers dans notre miroir local (DL_DIR) mais ce miroir n'est pas un bon endroit pour compiler notre logiciel. L'étape suivante consiste donc :

• à décompresser les archives dans notre répertoire de sources (S),
• à recopier dans notre répertoire de travail (WORKDIR) les fichiers sources qui ne sont pas des archives.

A nouveau, cette étape est gérée par bitbake et c'est la documentation de bitbake qui vous fournira tous les détails.

do_patch

Une fois que nous avons récupéré et décompressé les sources, la tâche do_patch va récupérer tous les fichiers source qui sont des patch et les appliquer sur le répertoire de source (S). Yocto applique les patchs dans l'ordre de la variable SRC_URI.

do_configure

Notre code source est maintenant prêt à être compilé. Les systèmes de build les plus courants (autotools et cmake en particulier) divisent la compilation en deux étapes.

• Un premier exécutable (./configure ou cmake) va générer des fichiers Makefile en détectant l'environnement d'exécution et en utilisant des paramètres passés par l'utilisateur.
• La commande make est ensuite utilisée pour faire la compilation elle-même.

La tâche do_configure de yocto couvre la première étape. Le contenu exact de cette étape dépend de l'outil de build utilisé par votre recette mais les systèmes de build les plus courants sont tous supportés via des classes que l'on peut inclure dans les recettes :

• autotools
• cmake
• scons
• qmake

Toutes ces classes ont leur propre documentation mais l'étape de configuration fournit généralement les services suivants :

• utilisation automatique du compilateur croisé
• configuration de l'outil de build pour que la commande make install respecte l’arborescence yocto
• possibilité d'ajouter des paramètres à l'étape de configuration via des variables bitbake (en particulier la variable PACKAGECONFIG)

Une fois la configuration effectuée, il est temps de compiler notre logiciel :

do_compile

L'étape de compilation est l'étape principale de la fabrication du paquet. Elle correspond à l'appel à make qui construira l'application elle-même.

Tout comme l'étape do_configure, le contenu exact de cette étape dépend de la nature de l'outil de build utilisé.

Les résultats de compilation (exécutables, fichiers .o etc...) seront générés dans le répertoire B. Il est assez courant que les répertoires S et B soient identiques (on compile directement dans le répertoire contenant les sources).

do_install

Nous venons de générer notre exécutable, il est temps de l'installer. L'installation est faite par la tâche do_install. Cette tâche va invoquer les commandes nécessaires pour installer le logiciel dans le répertoire D. Il s'agit généralement d'un appel à make install, mais il est fréquent que les recettes personnalisent cette étape (pour ajouter des fichiers de configuration, par exemple).

A l'issue de cet étape, tous les fichiers installés par notre application (et uniquement eux) sont recopiés dans D en respectant l'arborescence qu'ils devront avoir sur la cible (i.e les exécutables seront dans le répertoire D/usr/bin/).

Nous avons fini les étapes correspondant à la compilation et à l'installation normale d'une application. Nous allons maintenant voir comment yocto transforme le contenu de D en différents paquetages.

do_package

Pour chaque recette, yocto peut générer plusieurs paquetages. Les paquetages générés peuvent être une séparation logique d'application (le paquetage normal, les paquetages -dev, -doc, -dbg etc...) ou des paquetages multiples basés sur une même recette (la variable PACKAGES permet de donner les noms des différents paquetages générés par une recette).

L'étape do_package va recopier les fichiers depuis le répertoire D vers des sous-répertoires de PKGDEST. Les différentes variables FILES_<nom du paquetage> servent à déterminer quel fichier de D doit aller dans quel paquetage.

Il est important de comprendre que la variable PACKAGES ainsi que les variables FILES_* sont remplies par bitbake lors de l'analyse des recettes. De nombreuses classes sont mises à contribution pour remplir ces variables. L'étape do_package ne fait qu'utiliser ces valeurs pour recopier les fichiers vers les différents paquetages générés.

do_package_write_*

Une fois notre répertoire D réparti entre les différents sous-répertoires de PKGDEST, il est temps de créer les paquetages eux-mêmes. Les différentes tâches do_package_write_* feront les actions spécifiques au type de paquetage sélectionné pour votre distro (ipk, deb, rpm etc...).

Synthèse

Nous venons de détailler les grandes étapes de la génération d'un paquetage yocto. Yocto suit les même étapes que celles nécessaires à la compilation manuelle. Avant de voir les différents outils de mise au point de recettes, voici une petite synthèse des étapes :

• do_fetch : télécharge les fichiers de SRC_URI et les place dans DL_DIR
• do_unpack : recopie les patchs dans WORKDIR et décompresse les sources dans S
• do_patch : détecte les patchs et les applique à S
• do_configure : configure la compilation en utilisant l'environnement pour détecter les options de compilation
• do_compile : compile les source dans S, génère les artefact de compilation dans B
• do_install : installe les objets générés dans D
• do_package : sépare le contenu de D en paquetage, chaque paquetage étant installé dans PKGDIR/<package name>
• do_package_write_* : utilise le contenu de PKGDIR/<package name> pour générer le paquetage lui-même.

Préparer son environnement pour la mise au point

Notre analyse des étapes de compilation de yocto nous permet d'entrevoir comment nous allons mettre au point une recette yocto. Néanmoins, avant de nous lancer dans le cœur  du sujet, il est important de voir certains outils de mise au point qui permettent de gagner du temps lors de l'analyse des problèmes des recettes.

La classe rm_work.bbclass

Yocto fournit un moyen sympathique de gagner de la place sur le disque : la classe rm_work.bbclass. Pour utiliser cette classe il suffit d'ajouter la ligne suivante dans votre fichier local.conf

INHERIT += "rm_work"

Inclure cette classe permet à yocto de supprimer tous les fichiers annexes de construction des paquetages lorsqu'ils ne sont plus nécessaires. Le gain de place est important et il est donc fortement recommandé de l'activer.

Bien sûr, si vous êtes en train de mettre au point une recette, la suppression des fichiers intermédiaires est problématique. Les fichiers intermédiaires sont notre principale source d'information sur les bug de mise au point.

Pour spécifier que certains paquetages ne doivent pas être nettoyés par la classe rm_work, il vous faudra positionner la variable suivante dans votre fichier local.conf :

RM_WORK_EXCLUDE = "<nom de la recette> <nom de la recette>"

Si vous avez un problème avec une recette, ajoutez son nom à la liste puis lancez les commandes suivantes :

bitbake <recette> -c cleanall
bitbake <recette>

et le répertoire de travail de votre recette contiendra tous les fichiers intermédiaires générés jusqu'à l'erreur.

Activer la gestion de paquetage dans votre distribution

Yocto génère ses images en assemblant des paquetages (rpm, ipk etc...) mais la plupart des images n'activent pas la feature package-management et ne peuvent donc pas utiliser les outils en ligne de commande pour installer, mettre à jour ou désinstaller des paquetages.

La présence des outils de gestion de paquetages est une aide précieuse à la mise au point. Cela permet entre autre :

• de tester facilement une nouvelle version d'un paquetage sans régénérer une image
• de trouver facilement quel paquetage fournit quel fichier
• de savoir quel est  le volume pris par chaque paquet
• d'ajouter temporairement des outils de mise au point sans régénérer une image

Pour activer cette feature vous devez ajouter la ligne suivante dans la définition de votre image

IMAGE_FEATURES += " package-management"

ou la ligne suivante dans votre fichier local.conf

EXTRA_IMAGE_FEATURES += " package-management"

Il faut bien comprendre la différence entre ces deux approches.

• La première approche ajoute la gestion de paquetage à votre image et ajoute donc la fonctionnalité à votre produit,
• La deuxième approche ne rajoute cette fonctionnalité que pour les images générées sur votre PC. C'est juste un outil de mise au point pour vous.

Selon la nature de votre projet, l'une ou l'autre des approches peut être souhaitable.

Je recommande également d'ajouter un serveur ssh sur la cible, si il n'est pas déjà présent. La démarche est similaire, mais avec le mot-clé server-ssh-dropbear ou server-ssh-openssh.

Diagnostiquer un problème yocto

Notre exploration du déroulement d'une compilation yocto nous permet d'être mieux armé pour aborder les erreurs qui peuvent apparaître à la compilation d'une recette. Voyons quelques cas courants...

Erreur dans l'exécution d'une tâche

Lorsque yocto exécute une tâche et que celle-ci ne se déroule pas correctement, bitbake vous affichera tous les messages générés par cette tâche avant de se terminer. Les messages sont également sauvegardés dans un fichier de log dont la position exacte est affichée par bitbake avec l'erreur elle-même. Ce fichier de log est sauvegardé dans un sous-répertoire de WORKDIR appelé T. Nous allons voir que ce répertoire peut être particulièrement utile pour diagnostiquer une erreur dans une recette.

Lorsque bitbake doit exécuter une tâche codée en shell, il crée un script d'exécution dans le répertoire T appelé run.do_<tâche>.<pid> qui peut être lancé indépendamment. Le lien run.do_<tâche> pointe sur la dernière version de ce script.

Vous pouvez relancer une tâche particulière en exécutant ce script.Par exemple la commande

run.do_compile

relancera la commande de compilation de votre recette exactement comme si elle avait été lancée par bitbake. Les variables d'environnement utilisées par bitbake sont en place et le script trouvera et utilisera le compilateur croisé de yocto.

bitbake génère également des scripts pour les tâches codées en python mais ces scripts ne peuvent pas être lancés individuellement. Ils sont néanmoins utiles pour analyser le code d'une tâche sans avoir à charger tout l'environnement de la recette.

Il manque un fichier sur la cible/Le programme ne fonctionne pas comme prévu

Lorsqu'une recette se termine correctement, le travail de l'intégrateur yocto n'est pas terminé. Il faut s'assurer que l'installation est correcte, que tout est en place et que le logiciel est configuré correctement. Voici une liste des points clés à regarder pour diagnostiquer un problème visible sur cible.

• Le code source correspond-il à ce que vous attendez ? le répertoire S contient toutes les source patchés (en supposant que do_patch se soit exécuté correctement)
• Tous les fichiers sont-ils bien installés par la recette ? vous pouvez vérifier dans D le résultat de l'étape d'installation de votre paquetage. Si un fichier manque, vous devriez ajouter des commandes à la tâche do_install
• Si le fichier se trouve bien dans D cela veut sans doute dire qu'il n'est pas mis dans le bon paquetage. Vérifiez où le fichier se trouve dans PKGDIR ainsi que le contenu des variables FILES_*
• Le paquetage correspondant est il bien installé sur la cible ? lancez opkg, rpm ou apt sur la cible pour vérifier. La variable IMAGE_INSTALL permet d'ajouter un paquetage lors de la génération d'une image

Corriger des bugs avec devtool

Une fois que l'on a diagnostiqué un problème, il faut le réparer. Yocto fournit un outil pour faciliter la mise au point des recettes. L'outil devtool permet facilement de gérer une layer de développement, d'y développer des .bbappend pour des recettes existantes et de gérer un ensemble de patch sur les sources d'une recette.

mise en place de devtool

devtool est un outil qui vous aide à gérer une layer de travail (appelée workspace). Le workspace est une layer qui vous permet de stocker facilement des .bb en cours de développement, d'ajouter des .bbappend pour n'importe quelle recette et de facilement générer des suites de patch pour celles-ci.

Pour configurer devtool, lancez la commande suivante :

devtool create-workspace [<chemin>]

il est possible de préciser le chemin vers la layer à créer. Si aucun chemin n'est précisé, devtool créera un répertoire workspace dans votre répertoire de build.

devtool ajoutera également la layer nouvellement créée à votre fichier conf/bblayers.conf

modification d'une recette existante

Avoir une layer de travaille est une bonne idée en général, mais devtool est surtout utile lorsqu'il est nécessaire de modifier le code d'une application existante. Prenons l'exemple de l'application minicom. La recette de minicom se trouve dans meta/recipes-extended/minicom/minicom_2.7.bb. C'est une recette relativement simple. L'extrait ci-dessous reproduit présente la partie intéressante

SUMMARY = "Text-based modem control and terminal emulation program"
SRC_URI = "https://alioth.debian.org/frs/download.php/latestfile/3/${BP}.tar.gz \
   file://allow.to.disable.lockdev.patch \
   file://0001-fix-minicom-h-v-return-value-is-not-0.patch \
"

Nous constatons que le code source est récupéré à partir des archives debian et qu'un certain nombre de patchs sont ajoutés.
devtool va nous permettre d'extraire les sources de minicom, de les modifier, d'utiliser la version modifiée pour générer le paquetage yocto et de facilement régénérer les patchs correspondant à nos modifications. Pour cela il faut tout d'abord dire à devtool que nous allons modifier la recette de minicom

devtool modify -x minicom <répertoire des sources>

le répertoire des source doit être un répertoire vide. J'utilise un sous-répertoire de mon workspace, mais n'importe quel répertoire vide fera l'affaire.

devtool va d'abord récupérer les sources et les extraire dans le répertoire spécifié. Devtool va ensuite initialiser un dépôt git dans ce répertoire Une fois le dépôt git créé, devtool va appliquer les patch existants en faisant un nouveau commit à chaque étape.

l'historique du dépôt contient donc trois commits : l'archive initiale et les deux patchs inclus dans SRC_URI.

* 5949abc (HEAD -> devtool, tag: devtool-patched) fix minicom -h/-v return value is not 0
* 8980a4b Upstream-Status: Pending
* fba6a67 (tag: devtool-base, master) Initial commit from upstream at version 2.7

devtool va ensuite créer un .bbappend pour minicom dans le répertoire <workspace>/appends/. Ce fichier est présenté ci-dessous :

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
inherit externalsrc
# NOTE: We use pn- overrides here to avoid affecting multiple variants in the case where the recipe uses BBCLASSEXTEND
EXTERNALSRC_pn-minicom = "<répertoire des sources>"

# initial_rev: fba6a672eff451ec8c6b8927d122d0ecad05bbcd
# commit: 8980a4b855b6461cd494da3e1bb882f253627614
# commit: 5949abcd792cbf40c3f2c578f251d0456714913e

La classe externalsrc permet de dire à yocto d'ignorer complètement la variable SRC_URI ainsi que les tâches do_fetch, do_unpack et do_patch. Le répertoire pointé par EXTERNALSRC sera utilisé comme répertoire de source.

Il peut être intéressant de modifier le WORKDIR pour que celui-ci soit contenu dans votre workspace. Ce n'est pas nécessaire, mais c'est assez confortable. Il suffit d'ajouter la ligne suivante dans le .bbappend

WORKDIR = "<répertoire de travail souhaité>"

Gestion des patchs avec devtool

Résumons la situation :

• nous avons un répertoire contenant les sources de minicom, déjà patchés et dont les modifications sont suivi grâce à git,
• yocto utilisera ce répertoire directement plutôt que d'aller chercher les sources sur internet et les modifier.

Modifier les sources de minicom et recompiler la recette est donc particulièrement simple. Yocto ne se met plus dans notre chemin, il suffit de modifier notre répertoire de source puis d'invoquer devtool build minicom. Cette commande est équivalente à bitbake -c populate_sysroot minicom mais peut être lancée depuis n'importe quel répertoire. populate_sysroot dépend de do_install. Notre recette sera donc correctement recompilée.

Lorsque nous appliquons de nouveaux patchs à minicom ou lorsque nous modifions nous mêmes le source, il est important de faire des modifications simples et les sauvegarder sous formes de commits sous git. Devtool a déjà créé un dépôt git pour les sources de minicom qui nous permet de gérer proprement nos modifications.

Nous avons ajouté deux commit aux sources de minicom. Notre historique git est reproduit ci-dessous :

* af62cd9 (HEAD -> devtool) deuxième modification
* 3ba6e2c premiere modification
* 5949abc (tag: devtool-patched) fix minicom -h/-v return value is not 0
* 8980a4b Upstream-Status: Pending
* fba6a67 (tag: devtool-base, master) Initial commit from upstream at version 2.7

Il est temps de consolider nos changements dans la recette minicom de départ. Devtool peut être utilisé pour régénérer automatiquement les patch à appliquer par la recette

devtool update-recipe minicom

Et nous constatons que devtool modifie la recette de minicom pour intégrer nos deux commit sous forme de patchs :

• les nouveaux patchs ont été ajoutés à la variable SRC_URI du fichier meta/recipes-extended/minicom_2.7.bb
• les fichiers .patch ont été créés dans le répertoire meta/recipes-extended/minicom/minicom

Il est parfaitement possible d'appeler cette commande plusieurs fois. Il est également possible d'utiliser les commandes git pour réorganiser/modifier/supprimer les commits du répertoire source. Devtool régénérera l'ensemble des patch  pour refléter nos modifications.

Une fois que vous êtes satisfait de vos modifications vous pouvez utiliser la commande

devtool reset minicom

pour enlever le fichier .bbappend de votre workspace. Le répertoire contenant les sources sera conservé mais il ne sera plus utilisé pour les builds.

Tester une recette avec devtool

Lorsque vous testez des paquetages yocto, vous devez soit les ajouter à la génération de l'image, soit les installer manuellement via votre gestionnaire de paquet. Ces manipulations sont longues et sont une source d'erreur. devtool vous permet de rapidement déployer une recette sur n'importe quelle cible disposant d'un serveur ssh.

pour déployer une recette sur une machine, utilisez la commande suivante :

devtool deploy-target <recette> <user@cible>

Notons que nous déployons une recette et non un paquet. devtool utilisera ssh pour envoyer tout le contenu de D vers la cible. Le découpage de la recette en paquetages n'est pas pris en compte. Cet envoi ne nécessite pas que l'option package-management soit présente sur l'image.

Une fois votre mise au point terminée vous pouvez utiliser devtool undeploy-target pour supprimer tous les fichiers ajoutés par votre recette...

Créer une nouvelle recette avec devtool

L'approche que nous venons de voir est parfaite pour modifier un logiciel dont on ne maîtrise pas les sources amont. Nous pouvons gérer une suite de patch spécifiques sur une version publiée d'un logiciel.

L'intégration yocto ne se limite pas à ce cas. Lorsqu'il est possible de remonter directement nos contributions (en particulier lorsque nous avons développé le logiciel nous-mêmes) la recette yocto doit simplement pointer vers le bon commit via la variable SRCREV. L'outil devtool est également capable de gérer ce cas correctement.

devtool permet également de créer une recette à partir d'un template et d'initialiser un fichier .bbappend pour utiliser la classe externalsrc correctement.

Pour créer une nouvelle recette,  il faut tout d'abord cloner le code à intégrer dans un répertoire. Nous utilisons ensuite devtool pour générer un template de recette initial :

devtool add <nom de la recette> <répertoire des sources>

devtool mettra en place un fichier .bbappend similaire à celui que nous avons vu précédemment mais il créera également un fichier <workspace>/recipes/<recette>.bb qu'il faudra compléter. Ce template contient une variable SRC_URI vide. Nous devons la positionner à une valeur valide (généralement une URL git://) et positionner également la variable SRCREV (généralement il faut lui donner un nom de branche).

Lorsqu'une variable SRCREV est présente et que SRC_URI est correctement rempli, la commande devtool update-recipe ne générera pas de patch. Elle modifiera la variable SRCREV pour pointer sur la révision utilisée dans votre répertoire source.

Synthèse : comment utiliser devtool

devtool permet d'éviter des manœuvres fastidieuses mais il est important de comprendre comment cet outil fonctionne.

Préparation

• initialisez votre workspace : devtool create-workspace
• préparez des recettes existantes pour la modification : devtool modify -x <recette> <repertoire où sauvegarder les sources>
• ajoutez de nouvelles recettes :
  • devtool add <recette> <répertoire contenant déjà les sources>
  • modifiez SRC_URI et SRCREV
• personalisez le fichier .bbappend selon vos goûts

Utilisation

votre cycle de développement devrait être le suivant :

• modifiez le code dans le répertoire source
• compilez votre recette : devtool build <recette>
• installez sur votre cible : devtool deploy-recipe <recette> <cible>
• testez et recommencez si nécessaire

pour sauvegarder votre travail :

• exportez vos modifications : devtool update-recipe <recette>
• vérifiez puis commitez vos modifications dans le dépot d'origine de la recette

Finalisation

lorsque vous avez finalisé votre recette :

• désinstallez votre recette de la cible devtool undeploy-recipe <recett> <cible>
• exportez une dernière fois vos modifications : devtool update-recipe <recette>
• si il s'agit d'une nouvelle recette, déplacez le fichier .bb à sa place finale
• supprimez le fichier .bbappend : devtool reset <recette>
• testez et commitez vos modification

Conclusion

Comprendre le fonctionnement d'une recette yocto, maîtriser les différentes étapes et optimiser ses méthodes de travaille grâce à devtool demande quelques efforts, mais ce sont des efforts qui paient. Le fonctionnement de yocto suit une logique très simple qui ne demande qu'à être explicitée et comprise. Les outils sont efficaces pour les cas les plus courants, une fois la periode d'apprentissage passée, ils sont une aide précieuse pour la mise au point.

Les principales variables utilisées dans cet article

SRC_URI

Cette variable contient la liste des fichiers, archives ou URL à télécharger pour construire la recette. Yocto utilise cette liste pour télécharger les fichiers nécessaires ainsi que pour déterminer quel fichier est un patch, une archive ou autre. La syntaxe de cette variable est détaillée ici et ici

SRCREV

Le commit ou la référence git à utiliser lorsque SRC_URI contient une URL de type git:// cette variable peut être mise automatiquement à jour par devtool.

DL_DIR

Un répertoire dans lequel bitbake stock les fichiers téléchargés pour ne pas avoir à les retélécharger lors des prochains build. Cette variable est initialisée à TOPDIR/downloads par yocto. Si vous ne la modifiez pas, les téléchargements seront donc stockés dans un sous répertoire downloads de votre répertoire de build.

WORKDIR

Le répertoire de base dans lequel yocto stoque tous les fichiers intermédiaires générés lors de la construction d'une recette (code source, patchs, binaires, etc...). Ce répertoire sert (par défaut) de racine aux répertoires S, B, D, T PKGDEST et quelques autres.

La position exacte de WORKDIR dépend de votre recette (en particulier si votre recette est architecture-indépendante) mais sera généralement située dans un sous-répertoire de TOPDIR/work/<architecture>/<recette>

S

Le répertoire contenant les sources de la recette avant compilation. Yocto décompresse les archives dans ce répertoire et y applique également les patchs. Il s'agit d'un sous-répertoire de WORKDIR basé sur la version de la recette (PV et PN).

B

Le répertoire dans lequel le système de build de la recette doit stoquer les résultats de compilation avant qu'ils soient installés (i.e le répertoire où la commande make génère les .o). Tous les systèmes de build ne sont pas capable de générer les binaires dans un répertoire spécifié par yocto, il est donc courant que le répertoire B soit le même que le répertoire S.

D

Le répertoire dans lequel le système de build de la recette doit installer les résultats de compilation. Ce répertoire n'est pas rempli directement par yocto mais par la tâche do_install de la recette (qui invoque généralement make install). Tous les fichiers installés par le logiciel doivent apparaître dans D (pages de man, fichiers include, bibliothèques, binaires...). Le contenu du répertoire D sera ensuite réparti entre différents paquetages.

Ce répertoire est généralement nommé WORKDIR/image

PKGDEST

Le répertoire dans leque le contenu de D est réparti. Ce répertoire contient un sous-répertoire par paquetage généré par la recette (<recette>, <recette>-dev, <recette>-doc etc...). Chacun de ces sous-répertoires contient les fichiers qui seront contenus dans le paquetage correspondant.

Ce répertoire est généralement nommé WORKDIR/packages-split

T

Le répertoire dans lequel yocto sauvegarde les script shell ou python correspondant aux différentes tâches exécutées. Yocto y sauvegarde également les log d'eexécution des tâches.

PACKAGES

La liste des paquetages que notre recette doit générer. Par défaut une recette générera des paquetages basés sur le nom de la recette mais il est possible de découper une recette selon ses spécificités en modifiant cette variable.

FILES_<paquetage>

Pour chaque paquetage généré par la recette, une variable FILES_<paquetage> contient la liste des fichiers que ce paquetage doit contenir. Cette variable sert de base pour distribuer les fichiers contenu dans D vers les différents sous-répertoires de PKGDEST.