«« sommaire »»

II.2 – Ajout d'applications dans l'image

Christophe BLAESS - juillet 2023

Dans la séquence précédente, nous avons modifié le fichier «local.conf» que nous trouvons dans le sous-répertoire «conf/» de notre répertoire de build. Les modifications étaient assez simples : ajustement de l’emplacement des dossiers de stockage temporaire, ajout d’utilisateur et configuration de mots de passe, puis modification du nom de machine.

Dans cette séquence nous allons ajouter quelques applications sur notre système. Pour cela, nous allons commencer en modifiant à nouveau ce fichier, puis nous créerons notre propre recette d'image personnalisée.

Utilitaires présents dans Poky

Notre première possibilité est d’ajouter des packages dont les recettes sont livrées avec Poky. Regardons, par exemple les fichiers se trouvant dans les sous-répertoires «recipes*/» de l'arborescence de Poky :

[build-qemu]$ ls  ../../layers/poky/meta/recipes*
../../layers/poky/meta/recipes.txt

../../layers/poky/meta/recipes-bsp:
acpid       apmd        efivar      gnu-efi  keymaps  lrzsz    pciutils  setserial  usbinit   v86d
alsa-state  efibootmgr  formfactor  grub     libacpi  opensbi  pm-utils  u-boot     usbutils

../../layers/poky/meta/recipes-connectivity:
avahi    dhcpcd     kea          mobile-broadband-provider-info  openssh     resolvconf
bind     inetutils  libnss-mdns  neard                           openssl     socat
bluez5   iproute2   libpcap      nfs-utils                       ppp         ssh-pregen-hostkeys
connman  iw         libuv        ofono                           ppp-dialin  wpa-supplicant

../../layers/poky/meta/recipes-core:
base-files   dropbear  glibc            initscripts  musl        packagegroups  sysvinit
base-passwd  ell       glib-networking  kbd          ncurses     psplash        udev
busybox      expat     ifupdown         libcgroup    netbase     readline       update-rc.d
coreutils    fts       images           libxcrypt    newlib      seatd          util-linux
dbus         gettext   init-ifupdown    libxml       os-release  sysfsutils     volatile-binds
dbus-wait    glib-2.0  initrdscripts    meta         ovmf        systemd        zlib

../../layers/poky/meta/recipes-devtools:
apt                 devel-config   gcc               libmodulemd  opkg-utils  run-postinsts
autoconf            diffstat       gdb               librepo      orc         rust
autoconf-archive    distcc         git               libtool      patch       squashfs-tools
automake            dmidecode      glide             llvm         patchelf    strace
binutils            dnf            gnu-config        log4cplus    perl        subversion
bison               docbook-xml    go                lua          perl-cross  swig
bootchart2          dosfstools     help2man          m4           pkgconf     syslinux
btrfs-tools         dpkg           i2c-tools         make         pkgconfig   systemd-bootchart
cargo               dwarfsrcfiles  icecc-create-env  makedevs     pseudo      tcf-agent
ccache              e2fsprogs      icecc-toolchain   meson        python      tcltk
cdrtools            elfutils       intltool          mmc          qemu        unfs3
chrpath             erofs-utils    jquery            mtd          quilt       unifdef
cmake               expect         json-c            mtools       repo        vala
createrepo-c        fdisk          libcomps          nasm         rpm         valgrind
dejagnu             file           libdnf            ninja        rsync       xmlto
desktop-file-utils  flex           libedit           opkg         ruby

../../layers/poky/meta/recipes-example:
rust-hello-world

../../layers/poky/meta/recipes-extended:
acpica    cwautomacros  gzip        libnss-nis   man-pages      pbzip2        slang                 unzip
asciidoc  diffutils     hdparm      libpipeline  mc             perl          stress-ng             watchdog
at        ed            images      libsolv      mdadm          pigz          sudo                  wget
bash      ethtool       iptables    libtirpc     mingetty       procps        sysklogd              which
bc        findutils     iputils     lighttpd     minicom        psmisc        sysstat               xdg-utils
blktool   gawk          less        logrotate    msmtp          quota         tar                   xinetd
bzip2     ghostscript   libaio      lsb          net-tools      rpcbind       tcp-wrappers          xz
cpio      go-examples   libarchive  lsof         newt           rpcsvc-proto  texinfo               zip
cracklib  gperf         libidn      ltp          packagegroups  screen        texinfo-dummy-native  zstd
cronie    grep          libmnl      lzip         pam            sed           time
cups      groff         libnsl      man-db       parted         shadow        timezone

../../layers/poky/meta/recipes-gnome:
epiphany    gi-docgen              gsettings-desktop-schemas  hicolor-icon-theme  libgudev   librsvg
gcr         gnome                  gtk+                       json-glib           libhandy   libsecret
gdk-pixbuf  gobject-introspection  gtk-doc                    libdazzle           libnotify

../../layers/poky/meta/recipes-graphics:
builder          harfbuzz       libsdl2           pango                 vulkan                     xorg-font
cairo            igt-gpu-tools  libva             piglit                waffle                     xorg-lib
cantarell-fonts  images         matchbox-session  pong-clock            wayland                    xorg-proto
drm              jpeg           matchbox-wm       shaderc               x11-common                 xorg-util
fontconfig       kmscube        menu-cache        spir                  xcursor-transparent-theme  xorg-xserver
freetype         libepoxy       mesa              startup-notification  xinput-calibrator          xrestop
glew             libfakekey     mini-x-session    ttf-fonts             xorg-app                   xwayland
glslang          libmatchbox    packagegroups     virglrenderer         xorg-driver

../../layers/poky/meta/recipes-kernel:
blktrace   dtc         kexec  linux           linux-libc-headers  make-mod-scripts      perf      systemtap
cryptodev  kern-tools  kmod   linux-firmware  lttng               modutils-initscripts  powertop  wireless-regdb

../../layers/poky/meta/recipes-multimedia:
alsa    flac       lame    libogg    libpng         libsndfile  libtiff    mpeg2dec  pulseaudio  speex  x264
ffmpeg  gstreamer  liba52  libomxil  libsamplerate  libtheora   libvorbis  mpg123    sbc         webp

../../layers/poky/meta/recipes-rt:
images  README  rt-tests

../../layers/poky/meta/recipes-sato:
images               matchbox-desktop   matchbox-terminal    pulseaudio-sato  settings-daemon
l3afpad              matchbox-keyboard  matchbox-theme-sato  puzzles          shutdown-desktop
libptytty            matchbox-panel-2   packagegroups        rxvt-unicode     webkit
matchbox-config-gtk  matchbox-sato      pcmanfm              sato-screenshot

../../layers/poky/meta/recipes-support:
apr              dos2unix               libbsd        libical           libunwind       p11-kit
argp-standalone  enchant                libcap        libjitterentropy  liburcu         pinentry
aspell           fribidi                libcap-ng     libksba           libusb          popt
atk              gdbm                   libcheck      libmd             libxslt         ptest-runner
attr             gmp                    libcroco      libmicrohttpd     libyaml         re2c
bash-completion  gnome-desktop-testing  libdaemon     libmpc            lz4             rng-tools
bmap-tools       gnupg                  libevdev      libnl             lzo             serf
boost            gnutls                 libevent      libpcre           lzop            shared-mime-info
ca-certificates  gpgme                  libexif       libproxy          mpfr            sqlite
consolekit       icu                    libffi        libpsl            nettle          taglib
curl             iso-codes              libfm         libseccomp        nghttp2         user-creation
db               itstool                libgcrypt     libsoup           npth            vim
debianutils      libassuan              libgit2       libssh2           nss-myhostname  vte
diffoscope       libatomic-ops          libgpg-error  libunistring      numactl         xxhash

La liste n’est pas évidente à lire, mais un comptage rapide avec «find ../../layers/poky/meta -name '*bb'| wc -l» nous indique la présence de près de 900 recettes livrées dans Poky. La plupart d’entre-elles sont des services ou des utilitaires bas-niveaux assez peu visibles au premier abord. Nous pouvons toutefois ajouter sur notre image un petit outil que j’aime bien : mc le Midnight Commander. Pour cela nous ajoutons simplement la ligne suivante dans local.conf :

IMAGE_INSTALL:append = " mc"

La variable «IMAGE_INSTALL» contient la liste des noms de packages à installer sur le système cible.

Le suffixe «:append» indique que la chaîne fournie en partie droite de l'affectation doit être ajoutée à la fin de la variable concernée. Nous ajoutons donc le nom du package mc précédé d'une espace qui sert de séparateur entre les éléments de la liste de packages.

Nous pourrions également utiliser :

IMAGE_INSTALL:prepend = "mc "

pour ajouter la chaîne en début de variable (et en la faisant suivre de l'espace de séparation).

Plusieurs lignes de ce type peuvent se suivre pour allonger d’autant le contenu de l’image.

Après avoir regénéré «core-image-base» et nous être connectés, nous pouvons lancer la commande «mc» et retrouver l'atmosphère un peu surannée des années 1990 sur Ms-Dos (figure II.2-1). Malgré son aspect désuet aujourd'hui, cet outil peut encore s'avérer très pratique lors de la mise au point d’un système embarqué pour le confort du développement en ligne de commande.

Il existe d’autres outils dont les recettes se trouvent dans Poky que j’aime bien intégrer dans mes images embarquées afin de permettre la mise au point du système ou du code métier : dtc, valgrind, powertop, gdbserver… Nous en reparlerons dans la troisième partie, pour l’instant contentons-nous d’ajouter les lignes suivantes :

IMAGE_INSTALL:append = " mc"
IMAGE_INSTALL:append = " dtc valgrind"
IMAGE_INSTALL:append = " gdbserver powertop"

Comme on le voit, on peut aussi bien enchaîner des lignes d’ajout que regrouper les différents packages désirés dans une seule ligne.

Après recompilation de l’image, je vérifie la présence des outils ajoutés. Je ne m’intéresse pas ici à leurs fonctionnements ou leurs résultats, juste à leurs présences sur ma cible :

Poky (Yocto Project Reference Distro) 4.0.11 mybox /dev/ttyAMA0

mybox login: root
Password: (linux)

root@mybox:~# dtc --version
Version: DTC v1.6.1+

root@mybox:~# valgrind --version
valgrind-3.18.1

root@mybox:~# gdbserver --version
GNU gdbserver (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "arm-poky-linux-gnueabi"

root@mybox:~# powertop --version
PowerTOP version 2.14
root@mybox:~#

Ajout de packages hors Poky

Pendant la mise au point d’un système embarqué, on a souvent besoin d’éditer des fichiers directement sur la cible. Sur une installation «core-image-base», nous disposons bien de l’éditeur «vi», intégré dans le package busybox. Néanmoins tout le monde n’est pas familier des commandes de vi, et l’utilisation d’un outil un peu plus intuitif s’avère généralement plus reposante. Supposons que nous souhaitions installer l'éditeur «nano» par exemple, qui est plus simple d’emploi que vi.

Si nous essayons simplement d’ajouter la ligne :

IMAGE_INSTALL:append = " nano"

dans notre fichier «local.conf», bitbake va se plaindre, nous afficher une série de lignes rouges et terminer en indiquant une erreur :

ERROR: Nothing RPROVIDES 'nano' (but /home/Builds/Lab/Yocto-lab/poky/meta/recipes-core/images/core-image-base.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nano' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nano']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base', 'nano']

Summary: There were 2 ERROR messages, returning a non-zero exit code.

Clairement, bitbake n’a pas trouvé dans les recettes fournies par Poky celle permettant de construire nano.

Il va probablement nous falloir trouver un layer (un ensemble de recettes) à installer sur notre système. Pour cela, l'usage est de se rendre sur le site https://layers.openembedded.org, de cliquer sur l’onglet «recipes», de sélectionner la version de Poky qui nous concerne et de saisir le nom du package désiré dans le moteur de recherche. Nous trouvons alors une page de résultat comme celle de la figure II.2-2.

Clairement la recette qui m’intéresse est la première de la liste. Elle se trouve dans le layer indiqué dans la colonne de droite : «meta-oe». En cliquant sur ce lien je vois qu’il s’agit d’un layer appartenant à un repository nommé «meta-openembedded», et je trouve l’adresse du téléchargement à effectuer.

Rappelons que les layers sont des répertoires contenant des recettes. Les layers ont un nom qui commence par «meta-». À cet égard, «meta-openembedded» est plutôt mal nommé, car il ne s'agit pas d'un dépôt mais d'un ensemble de dépôts.

[build-qemu]$ cd ../../layers/

[layers]$ git clone  git://git.openembedded.org/meta-openembedded -b kirkstone 
Cloning into 'meta-openembedded'...
remote: Counting objects: 215649, done.
remote: Compressing objects: 100% (71199/71199), done.
remote: Total 215649 (delta 136105), reused 214313 (delta 135257)
Receiving objects: 100% (215649/215649), 51.68 MiB | 25.00 MiB/s, done.
Resolving deltas: 100% (136105/136105), done.
	
[layers]$ ls meta-openembedded/
contrib      meta              meta-gnome      meta-multimedia  meta-oe    meta-python     meta-xfce
COPYING.MIT  meta-filesystems  meta-initramfs  meta-networking  meta-perl  meta-webserver  README

[layers]$ cd ../builds/build-qemu/

[build-qemu]$ 

L’ensemble «meta-openembedded» est assez incontournable dès lors que l’on prépare un système avec Yocto. Il contient près de deux mille recettes pour de nombreux packages très utiles pour Linux embarqué.

Nous devons ajouter le layer «meta-oe» à la liste de ceux pris en compte dans notre build. C'est le rôle de la sous-commande «add-layer» de la commande «bitbake-layers» fournie par Poky.

[build-qemu]$ bitbake-layers add-layer ../../layers/meta-openembedded/meta-oe/ 
NOTE: Starting bitbake server...

[build-qemu]$ 

Nous pouvons à présent relancer notre compilation, elle se déroule normalement et nano est intégré dans notre image.

[build-qemu]$ bitbake  core-image-base
  [...]

Par exemple, sur la figure II.2-3, nous l'employons pour consulter le fichier /etc/passwd.

Utilisation des fonctionnalités d’image

Nous avons utilisé la compilation avec «core-image-base» un peu aveuglément, sans comprendre véritablement ce que cela signifie. Nous allons examiner son contenu plus en détail. Pour cela nous recherchons le fichier qui décrit «core-image-base» dans les sous-répertoires de Poky. Il s’agit d’une recette avec l’extension «.bb».

[build-qemu]$ find  ../../layers/poky/  -name  core-image-base.bb 
../../layers/poky/meta/recipes-core/images/core-image-base.bb

Lorsque nous demandons à bitbake de produire une image, il recherche un fichier d'extension «.bb» avec le nom de l'image. Ce fichier doit se trouver dans un sous-répertoire «images/» se trouvant dans un répertoire dont le nom commence par «recipes-»

Le fichier trouvé correspond bien à ces critères. Voyons son contenu.

[build-qemu]$ cat  ../../layers/poky/meta/recipes-core/images/core-image-base.bb 
SUMMARY = "A console-only image that fully supports the target device \
 hardware."

IMAGE_FEATURES += "splash"

LICENSE = "MIT"

inherit core-image

Hormis la description et la licence, deux lignes nous intéressent :

Nous voyons que Yocto nous propose ainsi ce mécanisme de features, des fonctionnalités de haut-niveau que l’on peut sélectionner sans se soucier du détail du ou des packages correspondants.

Voici les fonctionnalités proposées par la classe «core-image», qui est implémentée dans le fichier ../../layers/poky/meta/classes/core-image.bbclass.

x11Serveur X-window
x11-baseServeur X-window et environnement minimal (Matchbox)
x11-satoServeur X-window et environnement Sato pour mobile.
westonEnvironnemnt graphique Wayland et compositeur Weston.
tools-debugOutils de débogage (gdb, gdbserver, strace, gcore…)
eclipse-debugOutils de débogage distant avec Eclipse.
tools-profileOutils de profiling (perf, lttng, gprof...)
tools-testappsOutils de tests du matériel.
tools-sdkInstallation des outils de développement natifs (gcc, make...) sur la cible.
nsf-serverServeur NFS
nfs-clientClient NFS
ssh-server-dropbearServeur SSH basé sur Dropbear.
ssh-server-opensshServeur SSH basé sur Openssh
hwcodecsSupport des codecs pour l’accélération matérielle
package-managementSupport des packages sur la cible (installation des outils et base de données).
dev-pkgsInstallation des fichiers headers nécessaire pour le développement des packages présents.
dbg-pkgsTous les packages sont compilés avec les informations de débogage
doc-pkgsInstallation de la documentation associée à tous les packages
bash-completion-pkgsComplétions de la ligne de commande de Bash
read-only-rootfsSystème de fichiers en lecture-seule.
splashÉcran d’accueil pendant le boot

Nous pouvons, par exemple, ajouter dans notre fichier local.conf la ligne :

IMAGE_FEATURES += "tools-sdk"

pour intégrer dans notre image les outils nécessaires à la compilation de code directement sur la cible. La compilation ci-dessous a bien lieu sur ma cible ARM émulée par Qemu :

mybox login: root
Password: (linux)

root@mybox:~# nano my-hello.c
   #include <stdio.h>
   #include <unistd.h>

   int main(void)
   {
     char host[512];  
     gethostname(host, 512);
     printf("Hello from %s\n", host);
     return 0;
   }

root@mybox:~# gcc my-hello.c -o my-hello -Wall 

root@mybox:~# ./my-hello 
Hello from mybox

root@mybox:~# g++ --version
g++ (GCC) 11.3.0
[...]

root@mybox:~# 

Il n’est pas fréquent d’installer une chaîne de compilation native directement sur la plateforme cible, mais cela peut s’avérer intéressant pendant la phase de prototypage et de mise au point. Il s’agit d’un point sur lequel Yocto est plus puissant que son confrère Buildroot qui a renoncé à cette possibilité il y a quelques années.

Création d’une image spécifique

Jusqu’à présent nous avons utilisé l’image core-image-base en ajoutant dans local.conf des lignes «IMAGES_INSTALL:append». Cette approche est parfaitement adaptée pour les premières phases de configuration du système, mais trouve rapidement ses limites. Pour les systèmes industriels en effet, il est souvent nécessaire de gérer toute une gamme de produits différents. On est donc amenés à réaliser régulièrement des séries de builds avec peu de différences entre-eux. On préfère généralement factoriser toute la configuration commune aux différents produits dans une image particulière et ne laisser dans les fichiers local.conf que les spécificités propres à chaque build.

Autrement dit nous allons créer notre propre fichier de description d’image, et nous n’invoquerons plus «bitbake core-image-base» mais «bitbake my-image» par exemple (en situation réelle, je nomme plutôt l’image en fonction du projet de mon client).

Pour cela, nous devons commencer par créer notre propre layer. Rien de compliqué, l’outil «bitbake-layers» est là pour nous aider.

[build-qemu]$ bitbake-layers  create-layer  ../../layers/meta-my-layer
NOTE: Starting bitbake server...
Add your new layer with 'bitbake-layers add-layer ../meta-my-layer'

[build-qemu]$ ls  ../../layers
meta-my-layer  meta-openembedded  meta-raspberrypi  poky

[build-qemu]$ ls ../../layers/meta-my-layer/
conf  COPYING.MIT  README  recipes-example

[build-qemu]$

Dans le layer nouvellement créé nous trouvons un squelette de fichier `README`, un exemplaire de la license MIT, un répertoire `recipes-example` contenant un recette minimale affichant un message et un répertoire `conf` contenant un fichier `layer.conf` correspondant aux paramétrages du layer.

[build-qemu]$ cat ../../layers/meta-my-layer/conf/layer.conf
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
            ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "meta-my-layer"
BBFILE_PATTERN_meta-my-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_meta-my-layer = "6"

LAYERDEPENDS_meta-my-layer = "core"
LAYERSERIES_COMPAT_meta-my-layer = "kirkstone"

Dans ce fichier, deux variables sont particulièrement utiles :

Le layer est bien créé mais, comme «bitbake-layers» nous l’affiche de manière un peu ambiguë, il n’est pas encore intégré dans la liste des layers que bitbake parcourera lors des builds. Nous devons l’y ajouter :

[build-qemu]$ bitbake-layers  show-layers
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /home/Builds/Lab/Yocto-lab/layers/poky/meta  5
meta-poky             /home/Builds/Lab/Yocto-lab/layers/poky/meta-poky  5
meta-yocto-bsp        /home/Builds/Lab/Yocto-lab/layers/poky/meta-yocto-bsp  5
meta-oe               /home/Builds/Lab/Yocto-lab/layers/meta-openembedded/meta-oe  5

[build-qemu]$ bitbake-layers  add-layer  ../../layers/meta-my-layer/
NOTE: Starting bitbake server...

[build-qemu]$ bitbake-layers  show-layers
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /home/Builds/Lab/Yocto-lab/layers/poky/meta  5
meta-poky             /home/Builds/Lab/Yocto-lab/layers/poky/meta-poky  5
meta-yocto-bsp        /home/Builds/Lab/Yocto-lab/layers/poky/meta-yocto-bsp  5
meta-oe               /home/Builds/Lab/Yocto-lab/layers/meta-openembedded/meta-oe  5
meta-my-layer         /home/Builds/Lab/Yocto-lab/layers/meta-my-layer  6

[build-qemu]$ 

Nous créons dans notre layer un début d'arborescence pour héberger nos recettes spécifiques. Son nom doit commencer par «recipes-». Je choisis arbitrairement «recipes-custom», on rencontre souvent les recettes d'images également dans un répertoire «recipes-core».

[build-qemu]$ mkdir  ../../layers/meta-my-layer/recipes-custom/ 

Il faut ensuite y créer un sous-répertoire nommé «images» pour stocker nos recettes décrivant des images. Puis nous y copions le fichier core-image-base.bb pour avoir un point de départ.

[build-qemu]$ mkdir  ../../layers/meta-my-layer/recipes-custom/images/ 

[build-qemu]$ cp  ../../layers/poky/meta/recipes-core/images/core-image-base.bb ../../layers/meta-my-layer/recipes-custom/images/my-image.bb 

En le copiant, j'ai renommé le fichier «core-image-base.bb» en «my-image.bb». Éditons-le, pour obtenir par exemple le contenu suivant :

[build-qemu]$ nano  ../../layers/meta-my-layer/recipes-custom/images/my-image.bb

SUMMARY = "A customized image for development purposes."
LICENSE = "MIT"
inherit core-image
IMAGE_FEATURES += "splash"
IMAGE_FEATURES += "tools-debug"
IMAGE_FEATURES += "tools-profile"
IMAGE_FEATURES += "tools-sdk"
IMAGE_FEATURES += "ssh-server-dropbear"
IMAGE_INSTALL:append = " mc"
IMAGE_INSTALL:append = " nano"

Nous éditons local.conf pour supprimer toutes les lignes «IMAGE_INSTALL:append» et «IMAGE_FEATURES» que nous avions ajoutées auparavant et lançons le nouveau build avec :

[build-qemu]$ bitbake  my-image

Après compilation, nos fichiers seront disponibles dans tmp/deploy/images/qemuarm/ avec le préfixe «my-image-qemuarm-». Au lancement, runqemu utilise la configuration la plus récente. Néanmoins, il est possible de préciser le nom de l'image pour éviter toute confusion ainsi :

[build-qemu]$ runqemu  nographic  my-image

On peut noter, dans la recette d'image ci-dessus la présence de deux syntaxes différentes pour ajouter une chaîne de caractères à la fin du contenu d'une variable :

Mais la différence entre ces deux syntaxes ne se limite pas uniquement à cette histoire d'espace. Sinon nous utiliserions toujours «+=» qui semble plus simple.

Savoir quand utiliser «+=» et quand préférer «:append» n'est pas simple quand il s'agit de compléter des variables initialisées dans des recettes fournies par Poky (ou par des layers supplémentaires, notamment pour le support du matériel). Il est souvent nécessaire d'aller jeter un œil sur l'implémentation des recettes, et il est bon de se familiariser avec l'arborescence de poky/ et celle de meta-openembedded/ par exemple.

Conclusion

Nous avons vu dans cette séquence – assez longue – comment personnaliser notre image en ajoutant des applications dont les recettes sont livrées avec Poky ou référencées sur le site Open Embedded Layers Index. Nous avons également réussi à créer notre propre image, plutôt que de se limiter à enrichir core-image-base en écrivant dans local.conf.

Dans la prochaine séquence, nous verrons comment modifier le comportement d’une application existante, sans toucher aux recettes téléchargées…

Ce document est placé sous licence Creative Common CC-by-nc. Vous pouvez copier son contenu et le réemployer à votre gré pour une utilisation non-commerciale. Vous devez en outre mentionner sa provenance.

Le nom Yocto Project est une marque déposée par la Linux Foundation. Le présent document n'est en aucune façon approuvé par Yocto Project ou la Linux Foundation.

«« sommaire »»