blob: c495e4cc4168ff17ad968e91812f01f24f04d133 [file] [log] [blame]
Andrew Geisslerf0343792020-11-18 10:42:21 -06001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002
3**********************
4Yocto Project Concepts
5**********************
6
7This chapter provides explanations for Yocto Project concepts that go
8beyond the surface of "how-to" information and reference (or look-up)
9material. Concepts such as components, the :term:`OpenEmbedded Build System`
10workflow,
11cross-development toolchains, shared state cache, and so forth are
12explained.
13
14Yocto Project Components
15========================
16
17The :term:`BitBake` task executor
18together with various types of configuration files form the
19:term:`OpenEmbedded-Core (OE-Core)`. This section
20overviews these components by describing their use and how they
21interact.
22
23BitBake handles the parsing and execution of the data files. The data
24itself is of various types:
25
26- *Recipes:* Provides details about particular pieces of software.
27
28- *Class Data:* Abstracts common build information (e.g. how to build a
29 Linux kernel).
30
31- *Configuration Data:* Defines machine-specific settings, policy
32 decisions, and so forth. Configuration data acts as the glue to bind
33 everything together.
34
35BitBake knows how to combine multiple data sources together and refers
36to each data source as a layer. For information on layers, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -060037":ref:`dev-manual/common-tasks:understanding and creating layers`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -050038section of the Yocto Project Development Tasks Manual.
39
40Following are some brief details on these core components. For
41additional information on how these components interact during a build,
42see the
Andrew Geissler09209ee2020-12-13 08:44:15 -060043":ref:`overview-manual/concepts:openembedded build system concepts`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -050044section.
45
Andrew Geisslerc9f78652020-09-18 14:11:35 -050046BitBake
47-------
48
49BitBake is the tool at the heart of the :term:`OpenEmbedded Build System`
50and is responsible
51for parsing the :term:`Metadata`, generating
52a list of tasks from it, and then executing those tasks.
53
54This section briefly introduces BitBake. If you want more information on
55BitBake, see the :doc:`BitBake User Manual <bitbake:index>`.
56
57To see a list of the options BitBake supports, use either of the
Andrew Geisslerc926e172021-05-07 16:11:35 -050058following commands::
Andrew Geisslerc9f78652020-09-18 14:11:35 -050059
60 $ bitbake -h
61 $ bitbake --help
62
63The most common usage for BitBake is ``bitbake recipename``, where
64``recipename`` is the name of the recipe you want to build (referred
65to as the "target"). The target often equates to the first part of a
66recipe's filename (e.g. "foo" for a recipe named ``foo_1.3.0-r0.bb``).
67So, to process the ``matchbox-desktop_1.2.3.bb`` recipe file, you might
Andrew Geisslerc926e172021-05-07 16:11:35 -050068type the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -050069
70 $ bitbake matchbox-desktop
71
72Several different
73versions of ``matchbox-desktop`` might exist. BitBake chooses the one
74selected by the distribution configuration. You can get more details
75about how BitBake chooses between different target versions and
76providers in the
Patrick Williams213cb262021-08-07 19:21:33 -050077":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences`" section
Andrew Geisslerc9f78652020-09-18 14:11:35 -050078of the BitBake User Manual.
79
80BitBake also tries to execute any dependent tasks first. So for example,
81before building ``matchbox-desktop``, BitBake would build a cross
82compiler and ``glibc`` if they had not already been built.
83
84A useful BitBake option to consider is the ``-k`` or ``--continue``
85option. This option instructs BitBake to try and continue processing the
86job as long as possible even after encountering an error. When an error
87occurs, the target that failed and those that depend on it cannot be
88remade. However, when you use this option other dependencies can still
89be processed.
90
Andrew Geisslerc9f78652020-09-18 14:11:35 -050091Recipes
92-------
93
94Files that have the ``.bb`` suffix are "recipes" files. In general, a
95recipe contains information about a single piece of software. This
96information includes the location from which to download the unaltered
97source, any source patches to be applied to that source (if needed),
98which special configuration options to apply, how to compile the source
99files, and how to package the compiled output.
100
101The term "package" is sometimes used to refer to recipes. However, since
102the word "package" is used for the packaged output from the OpenEmbedded
103build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
104using the term "package" when referring to recipes.
105
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500106Classes
107-------
108
109Class files (``.bbclass``) contain information that is useful to share
110between recipes files. An example is the
111:ref:`autotools <ref-classes-autotools>` class,
Patrick Williams03907ee2022-05-01 06:28:52 -0500112which contains common settings for any application that is built with
Patrick Williams7784c422022-11-17 07:29:11 -0600113the :wikipedia:`GNU Autotools <GNU_Autotools>`.
Patrick Williams03907ee2022-05-01 06:28:52 -0500114The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project
115Reference Manual provides details about classes and how to use them.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500116
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500117Configurations
118--------------
119
120The configuration files (``.conf``) define various configuration
121variables that govern the OpenEmbedded build process. These files fall
122into several areas that define machine configuration options,
123distribution configuration options, compiler tuning options, general
124common configuration options, and user configuration options in
125``conf/local.conf``, which is found in the :term:`Build Directory`.
126
127
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500128Layers
129======
130
131Layers are repositories that contain related metadata (i.e. sets of
132instructions) that tell the OpenEmbedded build system how to build a
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500133target. :ref:`overview-manual/yp-intro:the yocto project layer model`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500134facilitates collaboration, sharing, customization, and reuse within the
135Yocto Project development environment. Layers logically separate
136information for your project. For example, you can use a layer to hold
137all the configurations for a particular piece of hardware. Isolating
138hardware-specific configurations allows you to share other metadata by
139using a different layer where that metadata might be common across
140several pieces of hardware.
141
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700142There are many layers working in the Yocto Project development environment. The
Patrick Williams03907ee2022-05-01 06:28:52 -0500143:yocto_home:`Yocto Project Compatible Layer Index </software-overview/layers/>`
Andrew Geisslerd1e89492021-02-12 15:35:20 -0600144and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from
145which you can use or leverage.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500146
147By convention, layers in the Yocto Project follow a specific form.
148Conforming to a known structure allows BitBake to make assumptions
149during builds on where to find types of metadata. You can find
150procedures and learn about tools (i.e. ``bitbake-layers``) for creating
151layers suitable for the Yocto Project in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600152":ref:`dev-manual/common-tasks:understanding and creating layers`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500153section of the Yocto Project Development Tasks Manual.
154
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500155OpenEmbedded Build System Concepts
156==================================
157
158This section takes a more detailed look inside the build process used by
159the :term:`OpenEmbedded Build System`,
160which is the build
161system specific to the Yocto Project. At the heart of the build system
162is BitBake, the task executor.
163
164The following diagram represents the high-level workflow of a build. The
165remainder of this section expands on the fundamental input, output,
166process, and metadata logical blocks that make up the workflow.
167
168.. image:: figures/YP-flow-diagram.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500169 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500170
171In general, the build's workflow consists of several functional areas:
172
173- *User Configuration:* metadata you can use to control the build
174 process.
175
176- *Metadata Layers:* Various layers that provide software, machine, and
177 distro metadata.
178
179- *Source Files:* Upstream releases, local projects, and SCMs.
180
181- *Build System:* Processes under the control of
182 :term:`BitBake`. This block expands
183 on how BitBake fetches source, applies patches, completes
184 compilation, analyzes output for package generation, creates and
185 tests packages, generates images, and generates cross-development
186 tools.
187
188- *Package Feeds:* Directories containing output packages (RPM, DEB or
189 IPK), which are subsequently used in the construction of an image or
190 Software Development Kit (SDK), produced by the build system. These
191 feeds can also be copied and shared using a web server or other means
192 to facilitate extending or updating existing images on devices at
193 runtime if runtime package management is enabled.
194
195- *Images:* Images produced by the workflow.
196
197- *Application Development SDK:* Cross-development tools that are
198 produced along with an image or separately with BitBake.
199
200User Configuration
201------------------
202
203User configuration helps define the build. Through user configuration,
204you can tell BitBake the target architecture for which you are building
205the image, where to store downloaded source, and other build properties.
206
207The following figure shows an expanded representation of the "User
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500208Configuration" box of the :ref:`general workflow
209figure <overview-manual/concepts:openembedded build system concepts>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500210
211.. image:: figures/user-configuration.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500212 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500213
214BitBake needs some basic configuration files in order to complete a
215build. These files are ``*.conf`` files. The minimally necessary ones
216reside as example files in the ``build/conf`` directory of the
217:term:`Source Directory`. For simplicity,
218this section refers to the Source Directory as the "Poky Directory."
219
220When you clone the :term:`Poky` Git repository
221or you download and unpack a Yocto Project release, you can set up the
222Source Directory to be named anything you want. For this discussion, the
223cloned repository uses the default name ``poky``.
224
225.. note::
226
227 The Poky repository is primarily an aggregation of existing
228 repositories. It is not a canonical upstream source.
229
230The ``meta-poky`` layer inside Poky contains a ``conf`` directory that
231has example configuration files. These example files are used as a basis
232for creating actual configuration files when you source
233:ref:`structure-core-script`, which is the
234build environment script.
235
Patrick Williams2390b1b2022-11-03 13:47:49 -0500236Sourcing the build environment script creates a :term:`Build Directory`
237if one does not already exist. BitBake uses the :term:`Build Directory`
238for all its work during builds. The Build Directory has a ``conf`` directory
239that contains default versions of your ``local.conf`` and ``bblayers.conf``
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500240configuration files. These default configuration files are created only
Patrick Williams2390b1b2022-11-03 13:47:49 -0500241if versions do not already exist in the :term:`Build Directory` at the time you
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500242source the build environment setup script.
243
244Because the Poky repository is fundamentally an aggregation of existing
245repositories, some users might be familiar with running the
246:ref:`structure-core-script` script in the context of separate
247:term:`OpenEmbedded-Core (OE-Core)` and BitBake
248repositories rather than a single Poky repository. This discussion
249assumes the script is executed from within a cloned or unpacked version
250of Poky.
251
252Depending on where the script is sourced, different sub-scripts are
Patrick Williams2390b1b2022-11-03 13:47:49 -0500253called to set up the :term:`Build Directory` (Yocto or OpenEmbedded).
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500254Specifically, the script ``scripts/oe-setup-builddir`` inside the poky
Patrick Williams2390b1b2022-11-03 13:47:49 -0500255directory sets up the :term:`Build Directory` and seeds the directory (if
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500256necessary) with configuration files appropriate for the Yocto Project
257development environment.
258
259.. note::
260
261 The
262 scripts/oe-setup-builddir
263 script uses the
264 ``$TEMPLATECONF``
265 variable to determine which sample configuration files to locate.
266
267The ``local.conf`` file provides many basic variables that define a
268build environment. Here is a list of a few. To see the default
269configurations in a ``local.conf`` file created by the build environment
270script, see the
Andrew Geissler87f5cff2022-09-30 13:13:31 -0500271:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/templates/default/local.conf.sample>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500272in the ``meta-poky`` layer:
273
274- *Target Machine Selection:* Controlled by the
275 :term:`MACHINE` variable.
276
277- *Download Directory:* Controlled by the
278 :term:`DL_DIR` variable.
279
280- *Shared State Directory:* Controlled by the
281 :term:`SSTATE_DIR` variable.
282
283- *Build Output:* Controlled by the
284 :term:`TMPDIR` variable.
285
286- *Distribution Policy:* Controlled by the
287 :term:`DISTRO` variable.
288
289- *Packaging Format:* Controlled by the
290 :term:`PACKAGE_CLASSES`
291 variable.
292
293- *SDK Target Architecture:* Controlled by the
294 :term:`SDKMACHINE` variable.
295
296- *Extra Image Packages:* Controlled by the
297 :term:`EXTRA_IMAGE_FEATURES`
298 variable.
299
300.. note::
301
Andrew Geissler9aee5002022-03-30 16:27:02 +0000302 Configurations set in the ``conf/local.conf`` file can also be set
303 in the ``conf/site.conf`` and ``conf/auto.conf`` configuration files.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500304
305The ``bblayers.conf`` file tells BitBake what layers you want considered
306during the build. By default, the layers listed in this file include
307layers minimally needed by the build system. However, you must manually
308add any custom layers you have created. You can find more information on
309working with the ``bblayers.conf`` file in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600310":ref:`dev-manual/common-tasks:enabling your layer`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500311section in the Yocto Project Development Tasks Manual.
312
313The files ``site.conf`` and ``auto.conf`` are not created by the
314environment initialization script. If you want the ``site.conf`` file,
Andrew Geisslerd5838332022-05-27 11:33:10 -0500315you need to create it yourself. The ``auto.conf`` file is typically
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500316created by an autobuilder:
317
318- *site.conf:* You can use the ``conf/site.conf`` configuration
319 file to configure multiple build directories. For example, suppose
320 you had several build environments and they shared some common
321 features. You can set these default build properties here. A good
322 example is perhaps the packaging format to use through the
Andrew Geisslerd5838332022-05-27 11:33:10 -0500323 :term:`PACKAGE_CLASSES` variable.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500324
325- *auto.conf:* The file is usually created and written to by an
326 autobuilder. The settings put into the file are typically the same as
327 you would find in the ``conf/local.conf`` or the ``conf/site.conf``
328 files.
329
330You can edit all configuration files to further define any particular
331build environment. This process is represented by the "User
332Configuration Edits" box in the figure.
333
334When you launch your build with the ``bitbake target`` command, BitBake
335sorts out the configurations to ultimately define your build
336environment. It is important to understand that the
337:term:`OpenEmbedded Build System` reads the
338configuration files in a specific order: ``site.conf``, ``auto.conf``,
339and ``local.conf``. And, the build system applies the normal assignment
340statement rules as described in the
341":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
342of the BitBake User Manual. Because the files are parsed in a specific
343order, variable assignments for the same variable could be affected. For
344example, if the ``auto.conf`` file and the ``local.conf`` set variable1
345to different values, because the build system parses ``local.conf``
346after ``auto.conf``, variable1 is assigned the value from the
347``local.conf`` file.
348
349Metadata, Machine Configuration, and Policy Configuration
350---------------------------------------------------------
351
352The previous section described the user configurations that define
353BitBake's global behavior. This section takes a closer look at the
354layers the build system uses to further control the build. These layers
355provide Metadata for the software, machine, and policies.
356
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700357In general, there are three types of layer input. You can see them below
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500358the "User Configuration" box in the `general workflow
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500359figure <overview-manual/concepts:openembedded build system concepts>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500360
361- *Metadata (.bb + Patches):* Software layers containing
362 user-supplied recipe files, patches, and append files. A good example
Andrew Geisslerd1e89492021-02-12 15:35:20 -0600363 of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>`
364 from the :oe_layerindex:`OpenEmbedded Layer Index <>`. This layer is for
365 version 5.0 of the popular `Qt <https://wiki.qt.io/About_Qt>`__
366 cross-platform application development framework for desktop, embedded and
367 mobile.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500368
369- *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e.
370 "BSP Layer" in the following figure) providing machine-specific
371 configurations. This type of information is specific to a particular
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500372 target architecture. A good example of a BSP layer from the
373 :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600374 :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500375 layer.
376
377- *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in
378 the following figure) providing top-level or general policies for the
379 images or SDKs being built for a particular distribution. For
380 example, in the Poky Reference Distribution the distro layer is the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600381 :yocto_git:`meta-poky </poky/tree/meta-poky>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500382 layer. Within the distro layer is a ``conf/distro`` directory that
383 contains distro configuration files (e.g.
Andrew Geissler09209ee2020-12-13 08:44:15 -0600384 :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500385 that contain many policy configurations for the Poky distribution.
386
387The following figure shows an expanded representation of these three
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500388layers from the :ref:`general workflow figure
389<overview-manual/concepts:openembedded build system concepts>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500390
391.. image:: figures/layer-input.png
392 :align: center
Andrew Geisslerd5838332022-05-27 11:33:10 -0500393 :width: 70%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500394
395In general, all layers have a similar structure. They all contain a
396licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed,
397a ``README`` file as good practice and especially if the layer is to be
398distributed, a configuration directory, and recipe directories. You can
399learn about the general structure for layers used with the Yocto Project
400in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600401":ref:`dev-manual/common-tasks:creating your own layer`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500402section in the
403Yocto Project Development Tasks Manual. For a general discussion on
404layers and the many layers from which you can draw, see the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500405":ref:`overview-manual/concepts:layers`" and
406":ref:`overview-manual/yp-intro:the yocto project layer model`" sections both
407earlier in this manual.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500408
409If you explored the previous links, you discovered some areas where many
Andrew Geissler09209ee2020-12-13 08:44:15 -0600410layers that work with the Yocto Project exist. The :yocto_git:`Source
411Repositories <>` also shows layers categorized under "Yocto Metadata Layers."
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500412
413.. note::
414
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700415 There are layers in the Yocto Project Source Repositories that cannot be
416 found in the OpenEmbedded Layer Index. Such layers are either
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500417 deprecated or experimental in nature.
418
419BitBake uses the ``conf/bblayers.conf`` file, which is part of the user
420configuration, to find what layers it should be using as part of the
421build.
422
423Distro Layer
424~~~~~~~~~~~~
425
426The distribution layer provides policy configurations for your
427distribution. Best practices dictate that you isolate these types of
428configurations into their own layer. Settings you provide in
429``conf/distro/distro.conf`` override similar settings that BitBake finds
Patrick Williams2390b1b2022-11-03 13:47:49 -0500430in your ``conf/local.conf`` file in the :term:`Build Directory`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500431
432The following list provides some explanation and references for what you
433typically find in the distribution layer:
434
435- *classes:* Class files (``.bbclass``) hold common functionality that
436 can be shared among recipes in the distribution. When your recipes
437 inherit a class, they take on the settings and functions for that
438 class. You can read more about class files in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600439 ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500440 Reference Manual.
441
442- *conf:* This area holds configuration files for the layer
443 (``conf/layer.conf``), the distribution
444 (``conf/distro/distro.conf``), and any distribution-wide include
445 files.
446
447- *recipes-*:* Recipes and append files that affect common
448 functionality across the distribution. This area could include
449 recipes and append files to add distribution-specific configuration,
450 initialization scripts, custom image recipes, and so forth. Examples
451 of ``recipes-*`` directories are ``recipes-core`` and
452 ``recipes-extra``. Hierarchy and contents within a ``recipes-*``
453 directory can vary. Generally, these directories contain recipe files
454 (``*.bb``), recipe append files (``*.bbappend``), directories that
455 are distro-specific for configuration files, and so forth.
456
457BSP Layer
458~~~~~~~~~
459
460The BSP Layer provides machine configurations that target specific
461hardware. Everything in this layer is specific to the machine for which
462you are building the image or the SDK. A common structure or form is
463defined for BSP layers. You can learn more about this structure in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600464:doc:`/bsp-guide/index`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500465
466.. note::
467
468 In order for a BSP layer to be considered compliant with the Yocto
469 Project, it must meet some structural requirements.
470
471The BSP Layer's configuration directory contains configuration files for
472the machine (``conf/machine/machine.conf``) and, of course, the layer
473(``conf/layer.conf``).
474
475The remainder of the layer is dedicated to specific recipes by function:
476``recipes-bsp``, ``recipes-core``, ``recipes-graphics``,
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700477``recipes-kernel``, and so forth. There can be metadata for multiple
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500478formfactors, graphics support systems, and so forth.
479
480.. note::
481
482 While the figure shows several
483 recipes-\*
484 directories, not all these directories appear in all BSP layers.
485
486Software Layer
487~~~~~~~~~~~~~~
488
489The software layer provides the Metadata for additional software
490packages used during the build. This layer does not include Metadata
491that is specific to the distribution or the machine, which are found in
492their respective layers.
493
494This layer contains any recipes, append files, and patches, that your
495project needs.
496
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500497Sources
498-------
499
500In order for the OpenEmbedded build system to create an image or any
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500501target, it must be able to access source files. The :ref:`general workflow
502figure <overview-manual/concepts:openembedded build system concepts>`
503represents source files using the "Upstream Project Releases", "Local
504Projects", and "SCMs (optional)" boxes. The figure represents mirrors,
505which also play a role in locating source files, with the "Source
506Materials" box.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500507
508The method by which source files are ultimately organized is a function
509of the project. For example, for released software, projects tend to use
510tarballs or other archived files that can capture the state of a release
511guaranteeing that it is statically represented. On the other hand, for a
512project that is more dynamic or experimental in nature, a project might
513keep source files in a repository controlled by a Source Control Manager
514(SCM) such as Git. Pulling source from a repository allows you to
515control the point in the repository (the revision) from which you want
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700516to build software. A combination of the two is also possible.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500517
518BitBake uses the :term:`SRC_URI`
519variable to point to source files regardless of their location. Each
Andrew Geissler09036742021-06-25 14:25:14 -0500520recipe must have a :term:`SRC_URI` variable that points to the source.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500521
522Another area that plays a significant role in where source files come
523from is pointed to by the
524:term:`DL_DIR` variable. This area is
525a cache that can hold previously downloaded source. You can also
526instruct the OpenEmbedded build system to create tarballs from Git
527repositories, which is not the default behavior, and store them in the
Andrew Geissler09036742021-06-25 14:25:14 -0500528:term:`DL_DIR` by using the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500529:term:`BB_GENERATE_MIRROR_TARBALLS`
530variable.
531
Andrew Geissler09036742021-06-25 14:25:14 -0500532Judicious use of a :term:`DL_DIR` directory can save the build system a trip
Patrick Williams2390b1b2022-11-03 13:47:49 -0500533across the Internet when looking for files. A good method for using a download
534directory is to have :term:`DL_DIR` point to an area outside of your
535:term:`Build Directory`. Doing so allows you to safely delete the
536:term:`Build Directory` if needed without fear of removing any downloaded
537source file.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500538
539The remainder of this section provides a deeper look into the source
540files and the mirrors. Here is a more detailed look at the source file
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500541area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system concepts>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500542
543.. image:: figures/source-input.png
544 :align: center
Andrew Geisslerd5838332022-05-27 11:33:10 -0500545 :width: 70%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500546
547Upstream Project Releases
548~~~~~~~~~~~~~~~~~~~~~~~~~
549
550Upstream project releases exist anywhere in the form of an archived file
551(e.g. tarball or zip file). These files correspond to individual
552recipes. For example, the figure uses specific releases each for
553BusyBox, Qt, and Dbus. An archive file can be for any released product
554that can be built using a recipe.
555
556Local Projects
557~~~~~~~~~~~~~~
558
559Local projects are custom bits of software the user provides. These bits
Andrew Geissler615f2f12022-07-15 14:00:58 -0500560reside somewhere local to a project --- perhaps a directory into which the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500561user checks in items (e.g. a local directory containing a development
562source tree used by the group).
563
564The canonical method through which to include a local project is to use
565the :ref:`externalsrc <ref-classes-externalsrc>`
566class to include that local project. You use either the ``local.conf``
567or a recipe's append file to override or set the recipe to point to the
568local directory on your disk to pull in the whole source tree.
569
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500570Source Control Managers (Optional)
571~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
572
573Another place from which the build system can get source files is with
Patrick Williams213cb262021-08-07 19:21:33 -0500574:ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers` employing various Source
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500575Control Managers (SCMs) such as Git or Subversion. In such cases, a
576repository is cloned or checked out. The
577:ref:`ref-tasks-fetch` task inside
578BitBake uses the :term:`SRC_URI`
579variable and the argument's prefix to determine the correct fetcher
580module.
581
582.. note::
583
584 For information on how to have the OpenEmbedded build system generate
585 tarballs for Git repositories and place them in the
586 DL_DIR
587 directory, see the :term:`BB_GENERATE_MIRROR_TARBALLS`
588 variable in the Yocto Project Reference Manual.
589
590When fetching a repository, BitBake uses the
591:term:`SRCREV` variable to determine
592the specific revision from which to build.
593
594Source Mirror(s)
595~~~~~~~~~~~~~~~~
596
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700597There are two kinds of mirrors: pre-mirrors and regular mirrors. The
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500598:term:`PREMIRRORS` and
599:term:`MIRRORS` variables point to
600these, respectively. BitBake checks pre-mirrors before looking upstream
601for any source files. Pre-mirrors are appropriate when you have a shared
602directory that is not a directory defined by the
603:term:`DL_DIR` variable. A Pre-mirror
604typically points to a shared directory that is local to your
605organization.
606
607Regular mirrors can be any site across the Internet that is used as an
608alternative location for source code should the primary site not be
609functioning for some reason or another.
610
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500611Package Feeds
612-------------
613
614When the OpenEmbedded build system generates an image or an SDK, it gets
615the packages from a package feed area located in the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500616:term:`Build Directory`. The :ref:`general workflow figure
617<overview-manual/concepts:openembedded build system concepts>`
618shows this package feeds area in the upper-right corner.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500619
620This section looks a little closer into the package feeds area used by
621the build system. Here is a more detailed look at the area:
622
623.. image:: figures/package-feeds.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500624 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500625
626Package feeds are an intermediary step in the build process. The
627OpenEmbedded build system provides classes to generate different package
628types, and you specify which classes to enable through the
629:term:`PACKAGE_CLASSES`
630variable. Before placing the packages into package feeds, the build
631process validates them with generated output quality assurance checks
632through the :ref:`insane <ref-classes-insane>`
633class.
634
Patrick Williams2390b1b2022-11-03 13:47:49 -0500635The package feed area resides in the :term:`Build Directory`. The directory the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500636build system uses to temporarily store packages is determined by a
637combination of variables and the particular package manager in use. See
638the "Package Feeds" box in the illustration and note the information to
639the right of that area. In particular, the following defines where
640package files are kept:
641
Patrick Williams2390b1b2022-11-03 13:47:49 -0500642- :term:`DEPLOY_DIR`: Defined as ``tmp/deploy`` in the :term:`Build Directory`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500643
644- ``DEPLOY_DIR_*``: Depending on the package manager used, the package
645 type sub-folder. Given RPM, IPK, or DEB packaging and tarball
646 creation, the
647 :term:`DEPLOY_DIR_RPM`,
648 :term:`DEPLOY_DIR_IPK`,
649 :term:`DEPLOY_DIR_DEB`, or
650 :term:`DEPLOY_DIR_TAR`,
651 variables are used, respectively.
652
653- :term:`PACKAGE_ARCH`: Defines
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700654 architecture-specific sub-folders. For example, packages could be
655 available for the i586 or qemux86 architectures.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500656
657BitBake uses the
658:ref:`do_package_write_* <ref-tasks-package_write_deb>`
659tasks to generate packages and place them into the package holding area
660(e.g. ``do_package_write_ipk`` for IPK packages). See the
661":ref:`ref-tasks-package_write_deb`",
662":ref:`ref-tasks-package_write_ipk`",
663":ref:`ref-tasks-package_write_rpm`",
664and
665":ref:`ref-tasks-package_write_tar`"
666sections in the Yocto Project Reference Manual for additional
667information. As an example, consider a scenario where an IPK packaging
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700668manager is being used and there is package architecture support for both
669i586 and qemux86. Packages for the i586 architecture are placed in
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500670``build/tmp/deploy/ipk/i586``, while packages for the qemux86
671architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
672
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500673BitBake Tool
674------------
675
676The OpenEmbedded build system uses
677:term:`BitBake` to produce images and
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500678Software Development Kits (SDKs). You can see from the :ref:`general workflow
679figure <overview-manual/concepts:openembedded build system concepts>`,
680the BitBake area consists of several functional areas. This section takes a
681closer look at each of those areas.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500682
683.. note::
684
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700685 Documentation for the BitBake tool is available separately. See the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500686 BitBake User Manual
687 for reference material on BitBake.
688
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500689Source Fetching
690~~~~~~~~~~~~~~~
691
692The first stages of building a recipe are to fetch and unpack the source
693code:
694
695.. image:: figures/source-fetching.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500696 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500697
Patrick Williams2390b1b2022-11-03 13:47:49 -0500698The :ref:`ref-tasks-fetch` and :ref:`ref-tasks-unpack` tasks fetch
699the source files and unpack them into the :term:`Build Directory`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500700
701.. note::
702
Patrick Williams2194f502022-10-16 14:26:09 -0500703 For every local file (e.g. ``file://``) that is part of a recipe's
704 :term:`SRC_URI` statement, the OpenEmbedded build system takes a
705 checksum of the file for the recipe and inserts the checksum into
706 the signature for the :ref:`ref-tasks-fetch` task. If any local
707 file has been modified, the :ref:`ref-tasks-fetch` task and all
708 tasks that depend on it are re-executed.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500709
Patrick Williams2390b1b2022-11-03 13:47:49 -0500710By default, everything is accomplished in the :term:`Build Directory`, which has
711a defined structure. For additional general information on the
712:term:`Build Directory`, see the ":ref:`structure-core-build`" section in
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500713the Yocto Project Reference Manual.
714
Patrick Williams2390b1b2022-11-03 13:47:49 -0500715Each recipe has an area in the :term:`Build Directory` where the unpacked
716source code resides. The :term:`S` variable points to this area for a recipe's
717unpacked source code. The name of that directory for any given recipe is
718defined from several different variables. The preceding figure and the
719following list describe the :term:`Build Directory`'s hierarchy:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500720
721- :term:`TMPDIR`: The base directory
722 where the OpenEmbedded build system performs all its work during the
723 build. The default base directory is the ``tmp`` directory.
724
725- :term:`PACKAGE_ARCH`: The
726 architecture of the built package or packages. Depending on the
727 eventual destination of the package or packages (i.e. machine
728 architecture, :term:`Build Host`, SDK, or
Andrew Geissler09036742021-06-25 14:25:14 -0500729 specific machine), :term:`PACKAGE_ARCH` varies. See the variable's
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500730 description for details.
731
732- :term:`TARGET_OS`: The operating
733 system of the target device. A typical value would be "linux" (e.g.
734 "qemux86-poky-linux").
735
736- :term:`PN`: The name of the recipe used
737 to build the package. This variable can have multiple meanings.
Andrew Geissler09036742021-06-25 14:25:14 -0500738 However, when used in the context of input files, :term:`PN` represents
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500739 the name of the recipe.
740
741- :term:`WORKDIR`: The location
742 where the OpenEmbedded build system builds a recipe (i.e. does the
743 work to create the package).
744
745 - :term:`PV`: The version of the
746 recipe used to build the package.
747
748 - :term:`PR`: The revision of the
749 recipe used to build the package.
750
751- :term:`S`: Contains the unpacked source
752 files for a given recipe.
753
754 - :term:`BPN`: The name of the recipe
Andrew Geissler09036742021-06-25 14:25:14 -0500755 used to build the package. The :term:`BPN` variable is a version of
Andrew Geissler5f350902021-07-23 13:09:54 -0400756 the :term:`PN` variable but with common prefixes and suffixes removed.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500757
758 - :term:`PV`: The version of the
759 recipe used to build the package.
760
761.. note::
762
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700763 In the previous figure, notice that there are two sample hierarchies:
764 one based on package architecture (i.e. :term:`PACKAGE_ARCH`)
765 and one based on a machine (i.e. :term:`MACHINE`).
766 The underlying structures are identical. The differentiator being
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500767 what the OpenEmbedded build system is using as a build target (e.g.
768 general architecture, a build host, an SDK, or a specific machine).
769
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500770Patching
771~~~~~~~~
772
773Once source code is fetched and unpacked, BitBake locates patch files
774and applies them to the source files:
775
776.. image:: figures/patching.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500777 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500778
779The :ref:`ref-tasks-patch` task uses a
780recipe's :term:`SRC_URI` statements
781and the :term:`FILESPATH` variable
782to locate applicable patch files.
783
784Default processing for patch files assumes the files have either
Andrew Geissler09036742021-06-25 14:25:14 -0500785``*.patch`` or ``*.diff`` file types. You can use :term:`SRC_URI` parameters
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500786to change the way the build system recognizes patch files. See the
787:ref:`ref-tasks-patch` task for more
788information.
789
790BitBake finds and applies multiple patches for a single recipe in the
Andrew Geissler09036742021-06-25 14:25:14 -0500791order in which it locates the patches. The :term:`FILESPATH` variable
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500792defines the default set of directories that the build system uses to
793search for patch files. Once found, patches are applied to the recipe's
794source files, which are located in the
795:term:`S` directory.
796
797For more information on how the source directories are created, see the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500798":ref:`overview-manual/concepts:source fetching`" section. For
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500799more information on how to create patches and how the build system
800processes patches, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600801":ref:`dev-manual/common-tasks:patching code`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500802section in the
803Yocto Project Development Tasks Manual. You can also see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600804":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500805section in the Yocto Project Application Development and the Extensible
806Software Development Kit (SDK) manual and the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600807":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500808section in the Yocto Project Linux Kernel Development Manual.
809
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500810Configuration, Compilation, and Staging
811~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
812
813After source code is patched, BitBake executes tasks that configure and
814compile the source code. Once compilation occurs, the files are copied
815to a holding area (staged) in preparation for packaging:
816
817.. image:: figures/configuration-compile-autoreconf.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500818 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500819
820This step in the build process consists of the following tasks:
821
822- :ref:`ref-tasks-prepare_recipe_sysroot`:
823 This task sets up the two sysroots in
824 ``${``\ :term:`WORKDIR`\ ``}``
825 (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that
826 during the packaging phase the sysroots can contain the contents of
827 the
828 :ref:`ref-tasks-populate_sysroot`
829 tasks of the recipes on which the recipe containing the tasks
830 depends. A sysroot exists for both the target and for the native
831 binaries, which run on the host system.
832
833- *do_configure*: This task configures the source by enabling and
834 disabling any build-time and configuration options for the software
835 being built. Configurations can come from the recipe itself as well
836 as from an inherited class. Additionally, the software itself might
837 configure itself depending on the target for which it is being built.
838
839 The configurations handled by the
840 :ref:`ref-tasks-configure` task
841 are specific to configurations for the source code being built by the
842 recipe.
843
844 If you are using the
845 :ref:`autotools <ref-classes-autotools>` class,
846 you can add additional configuration options by using the
847 :term:`EXTRA_OECONF` or
848 :term:`PACKAGECONFIG_CONFARGS`
849 variables. For information on how this variable works within that
850 class, see the
851 :ref:`autotools <ref-classes-autotools>` class
Patrick Williams975a06f2022-10-21 14:42:47 -0500852 :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500853
854- *do_compile*: Once a configuration task has been satisfied,
855 BitBake compiles the source using the
856 :ref:`ref-tasks-compile` task.
857 Compilation occurs in the directory pointed to by the
858 :term:`B` variable. Realize that the
Andrew Geissler09036742021-06-25 14:25:14 -0500859 :term:`B` directory is, by default, the same as the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500860 :term:`S` directory.
861
862- *do_install*: After compilation completes, BitBake executes the
863 :ref:`ref-tasks-install` task.
Andrew Geissler09036742021-06-25 14:25:14 -0500864 This task copies files from the :term:`B` directory and places them in a
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500865 holding area pointed to by the :term:`D`
866 variable. Packaging occurs later using files from this holding
867 directory.
868
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500869Package Splitting
870~~~~~~~~~~~~~~~~~
871
872After source code is configured, compiled, and staged, the build system
873analyzes the results and splits the output into packages:
874
875.. image:: figures/analysis-for-package-splitting.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500876 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500877
878The :ref:`ref-tasks-package` and
879:ref:`ref-tasks-packagedata`
880tasks combine to analyze the files found in the
881:term:`D` directory and split them into
882subsets based on available packages and files. Analysis involves the
883following as well as other items: splitting out debugging symbols,
884looking at shared library dependencies between packages, and looking at
885package relationships.
886
Patrick Williams2194f502022-10-16 14:26:09 -0500887The :ref:`ref-tasks-packagedata` task creates package metadata based on the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500888analysis such that the build system can generate the final packages. The
889:ref:`ref-tasks-populate_sysroot`
890task stages (copies) a subset of the files installed by the
891:ref:`ref-tasks-install` task into
892the appropriate sysroot. Working, staged, and intermediate results of
893the analysis and package splitting process use several areas:
894
895- :term:`PKGD`: The destination
896 directory (i.e. ``package``) for packages before they are split into
897 individual packages.
898
899- :term:`PKGDESTWORK`: A
Patrick Williams2194f502022-10-16 14:26:09 -0500900 temporary work area (i.e. ``pkgdata``) used by the :ref:`ref-tasks-package`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500901 task to save package metadata.
902
903- :term:`PKGDEST`: The parent
904 directory (i.e. ``packages-split``) for packages after they have been
905 split.
906
907- :term:`PKGDATA_DIR`: A shared,
908 global-state directory that holds packaging metadata generated during
909 the packaging process. The packaging process copies metadata from
Andrew Geissler09036742021-06-25 14:25:14 -0500910 :term:`PKGDESTWORK` to the :term:`PKGDATA_DIR` area where it becomes globally
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500911 available.
912
913- :term:`STAGING_DIR_HOST`:
914 The path for the sysroot for the system on which a component is built
915 to run (i.e. ``recipe-sysroot``).
916
917- :term:`STAGING_DIR_NATIVE`:
918 The path for the sysroot used when building components for the build
919 host (i.e. ``recipe-sysroot-native``).
920
921- :term:`STAGING_DIR_TARGET`:
922 The path for the sysroot used when a component that is built to
923 execute on a system and it generates code for yet another machine
924 (e.g. cross-canadian recipes).
925
926The :term:`FILES` variable defines the
927files that go into each package in
928:term:`PACKAGES`. If you want
929details on how this is accomplished, you can look at
Patrick Williams975a06f2022-10-21 14:42:47 -0500930:yocto_git:`package.bbclass </poky/tree/meta/classes-global/package.bbclass>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500931
932Depending on the type of packages being created (RPM, DEB, or IPK), the
933:ref:`do_package_write_* <ref-tasks-package_write_deb>`
934task creates the actual packages and places them in the Package Feed
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500935area, which is ``${TMPDIR}/deploy``. You can see the
936":ref:`overview-manual/concepts:package feeds`" section for more detail on
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500937that part of the build process.
938
939.. note::
940
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700941 Support for creating feeds directly from the ``deploy/*``
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500942 directories does not exist. Creating such feeds usually requires some
943 kind of feed maintenance mechanism that would upload the new packages
944 into an official package feed (e.g. the Ångström distribution). This
945 functionality is highly distribution-specific and thus is not
946 provided out of the box.
947
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500948Image Generation
949~~~~~~~~~~~~~~~~
950
951Once packages are split and stored in the Package Feeds area, the build
952system uses BitBake to generate the root filesystem image:
953
954.. image:: figures/image-generation.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500955 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500956
957The image generation process consists of several stages and depends on
958several tasks and variables. The
959:ref:`ref-tasks-rootfs` task creates
960the root filesystem (file and directory structure) for an image. This
961task uses several key variables to help create the list of packages to
962actually install:
963
964- :term:`IMAGE_INSTALL`: Lists
965 out the base set of packages from which to install from the Package
966 Feeds area.
967
968- :term:`PACKAGE_EXCLUDE`:
969 Specifies packages that should not be installed into the image.
970
971- :term:`IMAGE_FEATURES`:
972 Specifies features to include in the image. Most of these features
973 map to additional packages for installation.
974
975- :term:`PACKAGE_CLASSES`:
976 Specifies the package backend (e.g. RPM, DEB, or IPK) to use and
977 consequently helps determine where to locate packages within the
978 Package Feeds area.
979
980- :term:`IMAGE_LINGUAS`:
981 Determines the language(s) for which additional language support
982 packages are installed.
983
984- :term:`PACKAGE_INSTALL`:
985 The final list of packages passed to the package manager for
986 installation into the image.
987
988With :term:`IMAGE_ROOTFS`
989pointing to the location of the filesystem under construction and the
Andrew Geissler09036742021-06-25 14:25:14 -0500990:term:`PACKAGE_INSTALL` variable providing the final list of packages to
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500991install, the root file system is created.
992
993Package installation is under control of the package manager (e.g.
994dnf/rpm, opkg, or apt/dpkg) regardless of whether or not package
995management is enabled for the target. At the end of the process, if
996package management is not enabled for the target, the package manager's
997data files are deleted from the root filesystem. As part of the final
998stage of package installation, post installation scripts that are part
999of the packages are run. Any scripts that fail to run on the build host
1000are run on the target when the target system is first booted. If you are
Andrew Geissler87f5cff2022-09-30 13:13:31 -05001001using a
Andrew Geissler09209ee2020-12-13 08:44:15 -06001002:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001003all the post installation scripts must succeed on the build host during
1004the package installation phase since the root filesystem on the target
1005is read-only.
1006
Patrick Williams2194f502022-10-16 14:26:09 -05001007The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001008processing includes creation of a manifest file and optimizations.
1009
1010The manifest file (``.manifest``) resides in the same directory as the
1011root filesystem image. This file lists out, line-by-line, the installed
1012packages. The manifest file is useful for the
Patrick Williams975a06f2022-10-21 14:42:47 -05001013:ref:`testimage <ref-classes-testimage>` class,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001014for example, to determine whether or not to run specific tests. See the
1015:term:`IMAGE_MANIFEST`
1016variable for additional information.
1017
Andrew Geissler9aee5002022-03-30 16:27:02 +00001018Optimizing processes that are run across the image include ``mklibs``
1019and any other post-processing commands as defined by the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001020:term:`ROOTFS_POSTPROCESS_COMMAND`
Andrew Geissler9aee5002022-03-30 16:27:02 +00001021variable. The ``mklibs`` process optimizes the size of the libraries.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001022
1023After the root filesystem is built, processing begins on the image
1024through the :ref:`ref-tasks-image`
1025task. The build system runs any pre-processing commands as defined by
1026the
1027:term:`IMAGE_PREPROCESS_COMMAND`
1028variable. This variable specifies a list of functions to call before the
1029build system creates the final image output files.
1030
Patrick Williams2194f502022-10-16 14:26:09 -05001031The build system dynamically creates :ref:`do_image_* <ref-tasks-image>` tasks as needed,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001032based on the image types specified in the
1033:term:`IMAGE_FSTYPES` variable.
1034The process turns everything into an image file or a set of image files
1035and can compress the root filesystem image to reduce the overall size of
1036the image. The formats used for the root filesystem depend on the
Andrew Geissler09036742021-06-25 14:25:14 -05001037:term:`IMAGE_FSTYPES` variable. Compression depends on whether the formats
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001038support compression.
1039
1040As an example, a dynamically created task when creating a particular
Andrew Geisslerc926e172021-05-07 16:11:35 -05001041image type would take the following form::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001042
1043 do_image_type
1044
1045So, if the type
Andrew Geissler09036742021-06-25 14:25:14 -05001046as specified by the :term:`IMAGE_FSTYPES` were ``ext4``, the dynamically
Andrew Geisslerc926e172021-05-07 16:11:35 -05001047generated task would be as follows::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001048
1049 do_image_ext4
1050
1051The final task involved in image creation is the
1052:ref:`do_image_complete <ref-tasks-image-complete>`
1053task. This task completes the image by applying any image post
1054processing as defined through the
1055:term:`IMAGE_POSTPROCESS_COMMAND`
1056variable. The variable specifies a list of functions to call once the
1057build system has created the final image output files.
1058
1059.. note::
1060
1061 The entire image generation process is run under
1062 Pseudo. Running under Pseudo ensures that the files in the root filesystem
1063 have correct ownership.
1064
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001065SDK Generation
1066~~~~~~~~~~~~~~
1067
1068The OpenEmbedded build system uses BitBake to generate the Software
1069Development Kit (SDK) installer scripts for both the standard SDK and
1070the extensible SDK (eSDK):
1071
1072.. image:: figures/sdk-generation.png
Andrew Geisslerd5838332022-05-27 11:33:10 -05001073 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001074
1075.. note::
1076
1077 For more information on the cross-development toolchain generation,
Andrew Geissler09209ee2020-12-13 08:44:15 -06001078 see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001079 section. For information on advantages gained when building a
Patrick Williams2194f502022-10-16 14:26:09 -05001080 cross-development toolchain using the :ref:`ref-tasks-populate_sdk` task, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001081 ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001082 the Yocto Project Application Development and the Extensible Software
1083 Development Kit (eSDK) manual.
1084
1085Like image generation, the SDK script process consists of several stages
1086and depends on many variables. The
1087:ref:`ref-tasks-populate_sdk`
1088and
1089:ref:`ref-tasks-populate_sdk_ext`
1090tasks use these key variables to help create the list of packages to
1091actually install. For information on the variables listed in the figure,
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001092see the ":ref:`overview-manual/concepts:application development sdk`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001093section.
1094
Patrick Williams2194f502022-10-16 14:26:09 -05001095The :ref:`ref-tasks-populate_sdk` task helps create the standard SDK and handles
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001096two parts: a target part and a host part. The target part is the part
1097built for the target hardware and includes libraries and headers. The
1098host part is the part of the SDK that runs on the
1099:term:`SDKMACHINE`.
1100
Patrick Williams2194f502022-10-16 14:26:09 -05001101The :ref:`ref-tasks-populate_sdk_ext` task helps create the extensible SDK and
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001102handles host and target parts differently than its counter part does for
1103the standard SDK. For the extensible SDK, the task encapsulates the
1104build system, which includes everything needed (host and target) for the
1105SDK.
1106
1107Regardless of the type of SDK being constructed, the tasks perform some
1108cleanup after which a cross-development environment setup script and any
1109needed configuration files are created. The final output is the
1110Cross-development toolchain installation script (``.sh`` file), which
1111includes the environment setup script.
1112
1113Stamp Files and the Rerunning of Tasks
1114~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1115
1116For each task that completes successfully, BitBake writes a stamp file
1117into the :term:`STAMPS_DIR`
1118directory. The beginning of the stamp file's filename is determined by
1119the :term:`STAMP` variable, and the end
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001120of the name consists of the task's name and current :ref:`input
1121checksum <overview-manual/concepts:checksums (signatures)>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001122
1123.. note::
1124
1125 This naming scheme assumes that
1126 BB_SIGNATURE_HANDLER
1127 is "OEBasicHash", which is almost always the case in current
1128 OpenEmbedded.
1129
1130To determine if a task needs to be rerun, BitBake checks if a stamp file
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001131with a matching input checksum exists for the task. In this case,
1132the task's output is assumed to exist and still be valid. Otherwise,
1133the task is rerun.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001134
1135.. note::
1136
1137 The stamp mechanism is more general than the shared state (sstate)
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001138 cache mechanism described in the
1139 ":ref:`overview-manual/concepts:setscene tasks and shared state`" section.
1140 BitBake avoids rerunning any task that has a valid stamp file, not just
1141 tasks that can be accelerated through the sstate cache.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001142
1143 However, you should realize that stamp files only serve as a marker
1144 that some work has been done and that these files do not record task
1145 output. The actual task output would usually be somewhere in
1146 :term:`TMPDIR` (e.g. in some
1147 recipe's :term:`WORKDIR`.) What
1148 the sstate cache mechanism adds is a way to cache task output that
1149 can then be shared between build machines.
1150
Andrew Geissler09036742021-06-25 14:25:14 -05001151Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing
1152:term:`TMPDIR` will also remove :term:`STAMPS_DIR`, which means tasks will
1153properly be rerun to repopulate :term:`TMPDIR`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001154
1155If you want some task to always be considered "out of date", you can
1156mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`
1157varflag. If some other task depends on such a task, then that task will
1158also always be considered out of date, which might not be what you want.
1159
1160For details on how to view information about a task's signature, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001161":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001162section in the Yocto Project Development Tasks Manual.
1163
1164Setscene Tasks and Shared State
1165~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1166
1167The description of tasks so far assumes that BitBake needs to build
1168everything and no available prebuilt objects exist. BitBake does support
1169skipping tasks if prebuilt objects are available. These objects are
1170usually made available in the form of a shared state (sstate) cache.
1171
1172.. note::
1173
1174 For information on variables affecting sstate, see the
1175 :term:`SSTATE_DIR`
1176 and
1177 :term:`SSTATE_MIRRORS`
1178 variables.
1179
Andrew Geisslereff27472021-10-29 15:35:00 -05001180The idea of a setscene task (i.e ``do_taskname_setscene``) is a
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001181version of the task where instead of building something, BitBake can
1182skip to the end result and simply place a set of files into specific
1183locations as needed. In some cases, it makes sense to have a setscene
1184task variant (e.g. generating package files in the
1185:ref:`do_package_write_* <ref-tasks-package_write_deb>`
1186task). In other cases, it does not make sense (e.g. a
1187:ref:`ref-tasks-patch` task or a
1188:ref:`ref-tasks-unpack` task) since
1189the work involved would be equal to or greater than the underlying task.
1190
1191In the build system, the common tasks that have setscene variants are
1192:ref:`ref-tasks-package`,
Patrick Williams2194f502022-10-16 14:26:09 -05001193:ref:`do_package_write_* <ref-tasks-package_write_deb>`,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001194:ref:`ref-tasks-deploy`,
1195:ref:`ref-tasks-packagedata`, and
1196:ref:`ref-tasks-populate_sysroot`.
1197Notice that these tasks represent most of the tasks whose output is an
1198end result.
1199
1200The build system has knowledge of the relationship between these tasks
1201and other preceding tasks. For example, if BitBake runs
1202``do_populate_sysroot_setscene`` for something, it does not make sense
Patrick Williams2194f502022-10-16 14:26:09 -05001203to run any of the :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`,
1204:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if
1205:ref:`ref-tasks-package` needs to be run, BitBake needs to run those other tasks.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001206
1207It becomes more complicated if everything can come from an sstate cache
1208because some objects are simply not required at all. For example, you do
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001209not need a compiler or native tools, such as quilt, if there isn't anything
Patrick Williams2194f502022-10-16 14:26:09 -05001210to compile or patch. If the :ref:`do_package_write_* <ref-tasks-package_write_deb>` packages are available
1211from sstate, BitBake does not need the :ref:`ref-tasks-package` task data.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001212
1213To handle all these complexities, BitBake runs in two phases. The first
1214is the "setscene" stage. During this stage, BitBake first checks the
1215sstate cache for any targets it is planning to build. BitBake does a
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001216fast check to see if the object exists rather than doing a complete download.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001217If nothing exists, the second phase, which is the setscene stage,
1218completes and the main build proceeds.
1219
1220If objects are found in the sstate cache, the build system works
1221backwards from the end targets specified by the user. For example, if an
1222image is being built, the build system first looks for the packages
1223needed for that image and the tools needed to construct an image. If
1224those are available, the compiler is not needed. Thus, the compiler is
1225not even downloaded. If something was found to be unavailable, or the
1226download or setscene task fails, the build system then tries to install
1227dependencies, such as the compiler, from the cache.
1228
1229The availability of objects in the sstate cache is handled by the
Patrick Williams213cb262021-08-07 19:21:33 -05001230function specified by the :term:`BB_HASHCHECK_FUNCTION`
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001231variable and returns a list of available objects. The function specified
Patrick Williams213cb262021-08-07 19:21:33 -05001232by the :term:`BB_SETSCENE_DEPVALID`
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001233variable is the function that determines whether a given dependency
1234needs to be followed, and whether for any given relationship the
1235function needs to be passed. The function returns a True or False value.
1236
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001237Images
1238------
1239
1240The images produced by the build system are compressed forms of the root
1241filesystem and are ready to boot on a target device. You can see from
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001242the :ref:`general workflow figure
1243<overview-manual/concepts:openembedded build system concepts>` that BitBake
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001244output, in part, consists of images. This section takes a closer look at
1245this output:
1246
1247.. image:: figures/images.png
1248 :align: center
Andrew Geisslerd5838332022-05-27 11:33:10 -05001249 :width: 75%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001250
1251.. note::
1252
1253 For a list of example images that the Yocto Project provides, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001254 ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001255 Manual.
1256
Patrick Williams2390b1b2022-11-03 13:47:49 -05001257The build process writes images out to the :term:`Build Directory` inside
1258the ``tmp/deploy/images/machine/`` folder as shown in the figure. This
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001259folder contains any files expected to be loaded on the target device.
Patrick Williams2390b1b2022-11-03 13:47:49 -05001260The :term:`DEPLOY_DIR` variable points to the ``deploy`` directory, while the
1261:term:`DEPLOY_DIR_IMAGE` variable points to the appropriate directory
1262containing images for the current configuration.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001263
1264- kernel-image: A kernel binary file. The
1265 :term:`KERNEL_IMAGETYPE`
1266 variable determines the naming scheme for the kernel image file.
1267 Depending on this variable, the file could begin with a variety of
1268 naming strings. The ``deploy/images/``\ machine directory can contain
1269 multiple image files for the machine.
1270
1271- root-filesystem-image: Root filesystems for the target device (e.g.
1272 ``*.ext3`` or ``*.bz2`` files). The
1273 :term:`IMAGE_FSTYPES`
1274 variable determines the root filesystem image type. The
1275 ``deploy/images/``\ machine directory can contain multiple root
1276 filesystems for the machine.
1277
1278- kernel-modules: Tarballs that contain all the modules built for the
1279 kernel. Kernel module tarballs exist for legacy purposes and can be
1280 suppressed by setting the
1281 :term:`MODULE_TARBALL_DEPLOY`
1282 variable to "0". The ``deploy/images/``\ machine directory can
1283 contain multiple kernel module tarballs for the machine.
1284
1285- bootloaders: If applicable to the target machine, bootloaders
1286 supporting the image. The ``deploy/images/``\ machine directory can
1287 contain multiple bootloaders for the machine.
1288
1289- symlinks: The ``deploy/images/``\ machine folder contains a symbolic
1290 link that points to the most recently built file for each machine.
1291 These links might be useful for external scripts that need to obtain
1292 the latest version of each file.
1293
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001294Application Development SDK
1295---------------------------
1296
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001297In the :ref:`general workflow figure
1298<overview-manual/concepts:openembedded build system concepts>`, the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001299output labeled "Application Development SDK" represents an SDK. The SDK
1300generation process differs depending on whether you build an extensible
1301SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
1302(e.g. ``bitbake -c populate_sdk`` imagename). This section takes a
1303closer look at this output:
1304
1305.. image:: figures/sdk.png
Andrew Geisslerd5838332022-05-27 11:33:10 -05001306 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001307
1308The specific form of this output is a set of files that includes a
1309self-extracting SDK installer (``*.sh``), host and target manifest
1310files, and files used for SDK testing. When the SDK installer file is
1311run, it installs the SDK. The SDK consists of a cross-development
1312toolchain, a set of libraries and headers, and an SDK environment setup
1313script. Running this installer essentially sets up your
1314cross-development environment. You can think of the cross-toolchain as
1315the "host" part because it runs on the SDK machine. You can think of the
1316libraries and headers as the "target" part because they are built for
1317the target hardware. The environment setup script is added so that you
1318can initialize the environment before using the tools.
1319
1320.. note::
1321
1322 - The Yocto Project supports several methods by which you can set up
1323 this cross-development environment. These methods include
1324 downloading pre-built SDK installers or building and installing
1325 your own SDK installer.
1326
1327 - For background information on cross-development toolchains in the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001328 Yocto Project development environment, see the
1329 ":ref:`overview-manual/concepts:cross-development toolchain generation`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001330 section.
1331
1332 - For information on setting up a cross-development environment, see
Andrew Geissler09209ee2020-12-13 08:44:15 -06001333 the :doc:`/sdk-manual/index` manual.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001334
1335All the output files for an SDK are written to the ``deploy/sdk`` folder
Patrick Williams2390b1b2022-11-03 13:47:49 -05001336inside the :term:`Build Directory` as shown in the previous figure. Depending
1337on the type of SDK, there are several variables to configure these files.
1338Here are the variables associated with an extensible SDK:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001339
1340- :term:`DEPLOY_DIR`: Points to
1341 the ``deploy`` directory.
1342
1343- :term:`SDK_EXT_TYPE`:
1344 Controls whether or not shared state artifacts are copied into the
1345 extensible SDK. By default, all required shared state artifacts are
1346 copied into the SDK.
1347
1348- :term:`SDK_INCLUDE_PKGDATA`:
1349 Specifies whether or not packagedata is included in the extensible
1350 SDK for all recipes in the "world" target.
1351
1352- :term:`SDK_INCLUDE_TOOLCHAIN`:
1353 Specifies whether or not the toolchain is included when building the
1354 extensible SDK.
1355
Andrew Geissler9aee5002022-03-30 16:27:02 +00001356- :term:`ESDK_LOCALCONF_ALLOW`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001357 A list of variables allowed through from the build system
1358 configuration into the extensible SDK configuration.
1359
Andrew Geissler9aee5002022-03-30 16:27:02 +00001360- :term:`ESDK_LOCALCONF_REMOVE`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001361 A list of variables not allowed through from the build system
1362 configuration into the extensible SDK configuration.
1363
Andrew Geissler9aee5002022-03-30 16:27:02 +00001364- :term:`ESDK_CLASS_INHERIT_DISABLE`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001365 A list of classes to remove from the
1366 :term:`INHERIT` value globally
1367 within the extensible SDK configuration.
1368
1369This next list, shows the variables associated with a standard SDK:
1370
1371- :term:`DEPLOY_DIR`: Points to
1372 the ``deploy`` directory.
1373
1374- :term:`SDKMACHINE`: Specifies
1375 the architecture of the machine on which the cross-development tools
1376 are run to create packages for the target hardware.
1377
1378- :term:`SDKIMAGE_FEATURES`:
1379 Lists the features to include in the "target" part of the SDK.
1380
1381- :term:`TOOLCHAIN_HOST_TASK`:
1382 Lists packages that make up the host part of the SDK (i.e. the part
Andrew Geissler09036742021-06-25 14:25:14 -05001383 that runs on the :term:`SDKMACHINE`). When you use
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001384 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
1385 default packages apply. This variable allows you to add more
1386 packages.
1387
1388- :term:`TOOLCHAIN_TARGET_TASK`:
1389 Lists packages that make up the target part of the SDK (i.e. the part
1390 built for the target hardware).
1391
1392- :term:`SDKPATH`: Defines the
1393 default SDK installation path offered by the installation script.
1394
1395- :term:`SDK_HOST_MANIFEST`:
1396 Lists all the installed packages that make up the host part of the
1397 SDK. This variable also plays a minor role for extensible SDK
1398 development as well. However, it is mainly used for the standard SDK.
1399
1400- :term:`SDK_TARGET_MANIFEST`:
1401 Lists all the installed packages that make up the target part of the
1402 SDK. This variable also plays a minor role for extensible SDK
1403 development as well. However, it is mainly used for the standard SDK.
1404
1405Cross-Development Toolchain Generation
1406======================================
1407
1408The Yocto Project does most of the work for you when it comes to
Andrew Geissler09209ee2020-12-13 08:44:15 -06001409creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001410section provides some technical background on how cross-development
1411toolchains are created and used. For more information on toolchains, you
Andrew Geissler09209ee2020-12-13 08:44:15 -06001412can also see the :doc:`/sdk-manual/index` manual.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001413
1414In the Yocto Project development environment, cross-development
1415toolchains are used to build images and applications that run on the
1416target hardware. With just a few commands, the OpenEmbedded build system
1417creates these necessary toolchains for you.
1418
1419The following figure shows a high-level build environment regarding
1420toolchain construction and use.
1421
1422.. image:: figures/cross-development-toolchains.png
Andrew Geisslerd5838332022-05-27 11:33:10 -05001423 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001424
1425Most of the work occurs on the Build Host. This is the machine used to
Patrick Williams975a06f2022-10-21 14:42:47 -05001426build images and generally work within the Yocto Project
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001427environment. When you run
1428:term:`BitBake` to create an image, the
1429OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a
1430cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what
1431BitBake uses to compile source files when creating the target image. You
1432can think of ``gcc-cross`` simply as an automatically generated
1433cross-compiler that is used internally within BitBake only.
1434
1435.. note::
1436
Andrew Geissler09036742021-06-25 14:25:14 -05001437 The extensible SDK does not use ``gcc-cross-canadian``
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001438 since this SDK ships a copy of the OpenEmbedded build system and the
Andrew Geissler09036742021-06-25 14:25:14 -05001439 sysroot within it contains ``gcc-cross``.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001440
Andrew Geisslerc926e172021-05-07 16:11:35 -05001441The chain of events that occurs when the standard toolchain is bootstrapped::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001442
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001443 binutils-cross -> linux-libc-headers -> gcc-cross -> libgcc-initial -> glibc -> libgcc -> gcc-runtime
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001444
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001445- ``gcc``: The compiler, GNU Compiler Collection (GCC).
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001446
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001447- ``binutils-cross``: The binary utilities needed in order
1448 to run the ``gcc-cross`` phase of the bootstrap operation and build the
1449 headers for the C library.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001450
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001451- ``linux-libc-headers``: Headers needed for the cross-compiler and C library build.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001452
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001453- ``libgcc-initial``: An initial version of the gcc support library needed
1454 to bootstrap ``glibc``.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001455
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001456- ``libgcc``: The final version of the gcc support library which
1457 can only be built once there is a C library to link against.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001458
1459- ``glibc``: The GNU C Library.
1460
1461- ``gcc-cross``: The final stage of the bootstrap process for the
1462 cross-compiler. This stage results in the actual cross-compiler that
1463 BitBake uses when it builds an image for a targeted device.
1464
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001465 This tool is a "native" tool (i.e. it is designed to run on
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001466 the build host).
1467
1468- ``gcc-runtime``: Runtime libraries resulting from the toolchain
1469 bootstrapping process. This tool produces a binary that consists of
1470 the runtime libraries need for the targeted device.
1471
1472You can use the OpenEmbedded build system to build an installer for the
1473relocatable SDK used to develop applications. When you run the
1474installer, it installs the toolchain, which contains the development
1475tools (e.g., ``gcc-cross-canadian``, ``binutils-cross-canadian``, and
1476other ``nativesdk-*`` tools), which are tools native to the SDK (i.e.
Patrick Williams2390b1b2022-11-03 13:47:49 -05001477native to :term:`SDK_ARCH`), you need to cross-compile and test your
1478software. The figure shows the commands you use to easily build out
1479this toolchain. This cross-development toolchain is built to execute on the
1480:term:`SDKMACHINE`, which might or might not be the same machine as
1481the Build Host.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001482
1483.. note::
1484
1485 If your target architecture is supported by the Yocto Project, you
1486 can take advantage of pre-built images that ship with the Yocto
1487 Project and already contain cross-development toolchain installers.
1488
Andrew Geisslerc926e172021-05-07 16:11:35 -05001489Here is the bootstrap process for the relocatable toolchain::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001490
1491 gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian
1492
1493- ``gcc``: The build host's GNU Compiler Collection (GCC).
1494
1495- ``binutils-crosssdk``: The bare minimum binary utilities needed in
1496 order to run the ``gcc-crosssdk-initial`` phase of the bootstrap
1497 operation.
1498
1499- ``gcc-crosssdk-initial``: An early stage of the bootstrap process for
1500 creating the cross-compiler. This stage builds enough of the
1501 ``gcc-crosssdk`` and supporting pieces so that the final stage of the
1502 bootstrap process can produce the finished cross-compiler. This tool
1503 is a "native" binary that runs on the build host.
1504
1505- ``linux-libc-headers``: Headers needed for the cross-compiler.
1506
1507- ``glibc-initial``: An initial version of the Embedded GLIBC needed to
1508 bootstrap ``nativesdk-glibc``.
1509
1510- ``nativesdk-glibc``: The Embedded GLIBC needed to bootstrap the
1511 ``gcc-crosssdk``.
1512
1513- ``gcc-crosssdk``: The final stage of the bootstrap process for the
1514 relocatable cross-compiler. The ``gcc-crosssdk`` is a transitory
1515 compiler and never leaves the build host. Its purpose is to help in
1516 the bootstrap process to create the eventual ``gcc-cross-canadian``
1517 compiler, which is relocatable. This tool is also a "native" package
1518 (i.e. it is designed to run on the build host).
1519
1520- ``gcc-cross-canadian``: The final relocatable cross-compiler. When
1521 run on the :term:`SDKMACHINE`,
1522 this tool produces executable code that runs on the target device.
1523 Only one cross-canadian compiler is produced per architecture since
1524 they can be targeted at different processor optimizations using
1525 configurations passed to the compiler through the compile commands.
1526 This circumvents the need for multiple compilers and thus reduces the
1527 size of the toolchains.
1528
1529.. note::
1530
1531 For information on advantages gained when building a
1532 cross-development toolchain installer, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001533 ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001534 in the Yocto Project Application Development and the
1535 Extensible Software Development Kit (eSDK) manual.
1536
1537Shared State Cache
1538==================
1539
1540By design, the OpenEmbedded build system builds everything from scratch
1541unless :term:`BitBake` can determine
1542that parts do not need to be rebuilt. Fundamentally, building from
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001543scratch is attractive as it means all parts are built fresh and there is
1544no possibility of stale data that can cause problems. When
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001545developers hit problems, they typically default back to building from
Andrew Geissler595f6302022-01-24 19:11:47 +00001546scratch so they have a known state from the start.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001547
1548Building an image from scratch is both an advantage and a disadvantage
1549to the process. As mentioned in the previous paragraph, building from
1550scratch ensures that everything is current and starts from a known
1551state. However, building from scratch also takes much longer as it
1552generally means rebuilding things that do not necessarily need to be
1553rebuilt.
1554
1555The Yocto Project implements shared state code that supports incremental
1556builds. The implementation of the shared state code answers the
1557following questions that were fundamental roadblocks within the
1558OpenEmbedded incremental build support system:
1559
1560- What pieces of the system have changed and what pieces have not
1561 changed?
1562
1563- How are changed pieces of software removed and replaced?
1564
1565- How are pre-built components that do not need to be rebuilt from
1566 scratch used when they are available?
1567
1568For the first question, the build system detects changes in the "inputs"
1569to a given task by creating a checksum (or signature) of the task's
1570inputs. If the checksum changes, the system assumes the inputs have
1571changed and the task needs to be rerun. For the second question, the
1572shared state (sstate) code tracks which tasks add which output to the
1573build process. This means the output from a given task can be removed,
1574upgraded or otherwise manipulated. The third question is partly
1575addressed by the solution for the second question assuming the build
1576system can fetch the sstate objects from remote locations and install
1577them if they are deemed to be valid.
1578
1579.. note::
1580
1581 - The build system does not maintain
1582 :term:`PR` information as part of
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001583 the shared state packages. Consequently, there are considerations that
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001584 affect maintaining shared state feeds. For information on how the
Andrew Geissler09036742021-06-25 14:25:14 -05001585 build system works with packages and can track incrementing :term:`PR`
Andrew Geissler09209ee2020-12-13 08:44:15 -06001586 information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001587 section in the Yocto Project Development Tasks Manual.
1588
1589 - The code in the build system that supports incremental builds is
Andrew Geisslereff27472021-10-29 15:35:00 -05001590 complex. For techniques that help you work around issues
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001591 related to shared state code, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001592 ":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared state task`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001593 and
Andrew Geissler09209ee2020-12-13 08:44:15 -06001594 ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001595 sections both in the Yocto Project Development Tasks Manual.
1596
1597The rest of this section goes into detail about the overall incremental
1598build architecture, the checksums (signatures), and shared state.
1599
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001600Overall Architecture
1601--------------------
1602
1603When determining what parts of the system need to be built, BitBake
1604works on a per-task basis rather than a per-recipe basis. You might
1605wonder why using a per-task basis is preferred over a per-recipe basis.
1606To help explain, consider having the IPK packaging backend enabled and
1607then switching to DEB. In this case, the
1608:ref:`ref-tasks-install` and
1609:ref:`ref-tasks-package` task outputs
1610are still valid. However, with a per-recipe approach, the build would
1611not include the ``.deb`` files. Consequently, you would have to
1612invalidate the whole build and rerun it. Rerunning everything is not the
1613best solution. Also, in this case, the core must be "taught" much about
1614specific tasks. This methodology does not scale well and does not allow
1615users to easily add new tasks in layers or as external recipes without
1616touching the packaged-staging core.
1617
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001618Checksums (Signatures)
1619----------------------
1620
1621The shared state code uses a checksum, which is a unique signature of a
1622task's inputs, to determine if a task needs to be run again. Because it
1623is a change in a task's inputs that triggers a rerun, the process needs
1624to detect all the inputs to a given task. For shell tasks, this turns
1625out to be fairly easy because the build process generates a "run" shell
1626script for each task and it is possible to create a checksum that gives
1627you a good idea of when the task's data changes.
1628
1629To complicate the problem, there are things that should not be included
1630in the checksum. First, there is the actual specific build path of a
Andrew Geissler615f2f12022-07-15 14:00:58 -05001631given task --- the :term:`WORKDIR`. It
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001632does not matter if the work directory changes because it should not
1633affect the output for target packages. Also, the build process has the
1634objective of making native or cross packages relocatable.
1635
1636.. note::
1637
1638 Both native and cross packages run on the
1639 build host. However, cross packages generate output for the target
1640 architecture.
1641
Andrew Geissler09036742021-06-25 14:25:14 -05001642The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic
1643approach for excluding the work directory is to set :term:`WORKDIR` to some
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001644fixed value and create the checksum for the "run" script.
1645
1646Another problem results from the "run" scripts containing functions that
1647might or might not get called. The incremental build solution contains
1648code that figures out dependencies between shell functions. This code is
1649used to prune the "run" scripts down to the minimum set, thereby
1650alleviating this problem and making the "run" scripts much more readable
1651as a bonus.
1652
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001653So far, there are solutions for shell scripts. What about Python tasks? The
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001654same approach applies even though these tasks are more difficult. The
1655process needs to figure out what variables a Python function accesses
1656and what functions it calls. Again, the incremental build solution
1657contains code that first figures out the variable and function
1658dependencies, and then creates a checksum for the data used as the input
1659to the task.
1660
Andrew Geissler09036742021-06-25 14:25:14 -05001661Like the :term:`WORKDIR` case, there can be situations where dependencies should be
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001662ignored. For these situations, you can instruct the build process to
Andrew Geisslerc926e172021-05-07 16:11:35 -05001663ignore a dependency by using a line like the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001664
1665 PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
1666
1667This example ensures that the :term:`PACKAGE_ARCHS` variable
1668does not depend on the value of :term:`MACHINE`, even if it does
1669reference it.
1670
1671Equally, there are cases where you need to add dependencies BitBake is
1672not able to find. You can accomplish this by using a line like the
Andrew Geisslerc926e172021-05-07 16:11:35 -05001673following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001674
1675 PACKAGE_ARCHS[vardeps] = "MACHINE"
1676
1677This example explicitly
Andrew Geissler09036742021-06-25 14:25:14 -05001678adds the :term:`MACHINE` variable as a dependency for :term:`PACKAGE_ARCHS`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001679
1680As an example, consider a case with in-line Python where BitBake is not
1681able to figure out dependencies. When running in debug mode (i.e. using
1682``-DDD``), BitBake produces output when it discovers something for which
1683it cannot figure out dependencies. The Yocto Project team has currently
1684not managed to cover those dependencies in detail and is aware of the
1685need to fix this situation.
1686
1687Thus far, this section has limited discussion to the direct inputs into
1688a task. Information based on direct inputs is referred to as the
1689"basehash" in the code. However, the question of a task's indirect
Andrew Geissler615f2f12022-07-15 14:00:58 -05001690inputs still exits --- items already built and present in the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001691:term:`Build Directory`. The checksum (or
1692signature) for a particular task needs to add the hashes of all the
1693tasks on which the particular task depends. Choosing which dependencies
Andrew Geissler595f6302022-01-24 19:11:47 +00001694to add is a policy decision. However, the effect is to generate a
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001695checksum that combines the basehash and the hashes of the task's
1696dependencies.
1697
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001698At the code level, there are multiple ways by which both the basehash
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001699and the dependent task hashes can be influenced. Within the BitBake
1700configuration file, you can give BitBake some extra information to help
1701it construct the basehash. The following statement effectively results
1702in a list of global variable dependency excludes (i.e. variables never
Andrew Geisslerc926e172021-05-07 16:11:35 -05001703included in any checksum)::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001704
Andrew Geissler9aee5002022-03-30 16:27:02 +00001705 BB_BASEHASH_IGNORE_VARS ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \\
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001706 SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \\
1707 USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \\
1708 PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\
1709 CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
1710
Andrew Geissler595f6302022-01-24 19:11:47 +00001711The previous example does not include :term:`WORKDIR` since that variable is
1712actually constructed as a path within :term:`TMPDIR`, which is included above.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001713
1714The rules for deciding which hashes of dependent tasks to include
1715through dependency chains are more complex and are generally
1716accomplished with a Python function. The code in
1717``meta/lib/oe/sstatesig.py`` shows two examples of this and also
1718illustrates how you can insert your own policy into the system if so
1719desired. This file defines the two basic signature generators
1720:term:`OpenEmbedded-Core (OE-Core)` uses: "OEBasic" and
1721"OEBasicHash". By default, a dummy "noop" signature handler is enabled
1722in BitBake. This means that behavior is unchanged from previous
1723versions. OE-Core uses the "OEBasicHash" signature handler by default
Andrew Geisslerc926e172021-05-07 16:11:35 -05001724through this setting in the ``bitbake.conf`` file::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001725
1726 BB_SIGNATURE_HANDLER ?= "OEBasicHash"
1727
Andrew Geissler09036742021-06-25 14:25:14 -05001728The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001729as the "OEBasic" version but adds the task hash to the :ref:`stamp
1730files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
1731results in any metadata change that changes the task hash, automatically causing
1732the task to be run again. This removes the need to bump
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001733:term:`PR` values, and changes to metadata
1734automatically ripple across the build.
1735
1736It is also worth noting that the end result of these signature
1737generators is to make some dependency and hash information available to
1738the build. This information includes:
1739
Patrick Williams0ca19cc2021-08-16 14:03:13 -05001740- ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001741 recipe.
1742
1743- ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
1744 dependent task.
1745
Andrew Geissler09036742021-06-25 14:25:14 -05001746- :term:`BB_TASKHASH`: The hash of the currently running task.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001747
1748Shared State
1749------------
1750
1751Checksums and dependencies, as discussed in the previous section, solve
1752half the problem of supporting a shared state. The other half of the
1753problem is being able to use checksum information during the build and
1754being able to reuse or rebuild specific components.
1755
1756The :ref:`sstate <ref-classes-sstate>` class is a
1757relatively generic implementation of how to "capture" a snapshot of a
1758given task. The idea is that the build process does not care about the
1759source of a task's output. Output could be freshly built or it could be
1760downloaded and unpacked from somewhere. In other words, the build
1761process does not need to worry about its origin.
1762
1763Two types of output exist. One type is just about creating a directory
1764in :term:`WORKDIR`. A good example is
1765the output of either
1766:ref:`ref-tasks-install` or
1767:ref:`ref-tasks-package`. The other
1768type of output occurs when a set of data is merged into a shared
1769directory tree such as the sysroot.
1770
1771The Yocto Project team has tried to keep the details of the
Andrew Geissler595f6302022-01-24 19:11:47 +00001772implementation hidden in the :ref:`sstate <ref-classes-sstate>` class. From a user's perspective,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001773adding shared state wrapping to a task is as simple as this
1774:ref:`ref-tasks-deploy` example taken
Andrew Geisslerc926e172021-05-07 16:11:35 -05001775from the :ref:`deploy <ref-classes-deploy>` class::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001776
1777 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
1778 SSTATETASKS += "do_deploy"
1779 do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
1780 do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
1781
1782 python do_deploy_setscene () {
1783 sstate_setscene(d)
1784 }
1785 addtask do_deploy_setscene
1786 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
1787 do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"
1788
1789The following list explains the previous example:
1790
Patrick Williams2194f502022-10-16 14:26:09 -05001791- Adding ``do_deploy`` to ``SSTATETASKS`` adds some required
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001792 sstate-related processing, which is implemented in the
1793 :ref:`sstate <ref-classes-sstate>` class, to
1794 before and after the
1795 :ref:`ref-tasks-deploy` task.
1796
1797- The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
Patrick Williams2194f502022-10-16 14:26:09 -05001798 :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001799 (i.e. when not using the sstate cache). This output becomes the input
1800 to the shared state cache.
1801
1802- The ``do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"`` line
1803 causes the contents of the shared state cache to be copied to
1804 ``${DEPLOY_DIR_IMAGE}``.
1805
1806 .. note::
1807
Patrick Williams2194f502022-10-16 14:26:09 -05001808 If :ref:`ref-tasks-deploy` is not already in the shared state cache or if its input
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001809 checksum (signature) has changed from when the output was cached, the task
1810 runs to populate the shared state cache, after which the contents of the
1811 shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If
Patrick Williams2194f502022-10-16 14:26:09 -05001812 :ref:`ref-tasks-deploy` is in the shared state cache and its signature indicates
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001813 that the cached output is still valid (i.e. if no relevant task inputs
1814 have changed), then the contents of the shared state cache copies
Andrew Geissler09036742021-06-25 14:25:14 -05001815 directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
Patrick Williams2194f502022-10-16 14:26:09 -05001816 instead, skipping the :ref:`ref-tasks-deploy` task.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001817
1818- The following task definition is glue logic needed to make the
Andrew Geisslerc926e172021-05-07 16:11:35 -05001819 previous settings effective::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001820
1821 python do_deploy_setscene () {
1822 sstate_setscene(d)
1823 }
1824 addtask do_deploy_setscene
1825
Patrick Williams2194f502022-10-16 14:26:09 -05001826 ``sstate_setscene()`` takes the flags above as input and accelerates the :ref:`ref-tasks-deploy` task
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001827 through the shared state cache if possible. If the task was
1828 accelerated, ``sstate_setscene()`` returns True. Otherwise, it
Patrick Williams2194f502022-10-16 14:26:09 -05001829 returns False, and the normal :ref:`ref-tasks-deploy` task runs. For more
Patrick Williams213cb262021-08-07 19:21:33 -05001830 information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001831 section in the BitBake User Manual.
1832
1833- The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates
Patrick Williams2194f502022-10-16 14:26:09 -05001834 ``${DEPLOYDIR}`` and ``${B}`` before the :ref:`ref-tasks-deploy` task runs, and
1835 also sets the current working directory of :ref:`ref-tasks-deploy` to ``${B}``.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001836 For more information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
1837 section in the BitBake
1838 User Manual.
1839
1840 .. note::
1841
1842 In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
1843 the same, you can use ``sstate-plaindirs``. For example, to preserve the
Patrick Williams2194f502022-10-16 14:26:09 -05001844 ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the :ref:`ref-tasks-package`
Andrew Geisslerc926e172021-05-07 16:11:35 -05001845 task, use the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001846
1847 do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
1848
1849
1850- The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001851 extra metadata to the :ref:`stamp
1852 file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In
1853 this case, the metadata makes the task specific to a machine's architecture.
1854 See
Andrew Geissler09209ee2020-12-13 08:44:15 -06001855 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001856 section in the BitBake User Manual for more information on the
1857 ``stamp-extra-info`` flag.
1858
1859- ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with
1860 multiple directories. For example, the following declares
Andrew Geissler09036742021-06-25 14:25:14 -05001861 :term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories,
1862 which populates the shared state cache, and :term:`PKGDATA_DIR` and
Andrew Geisslerc926e172021-05-07 16:11:35 -05001863 ``SHLIBSDIR`` as the corresponding shared state output directories::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001864
1865 do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
1866 do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
1867
1868- These methods also include the ability to take a lockfile when
1869 manipulating shared state directory structures, for cases where file
Andrew Geisslerc926e172021-05-07 16:11:35 -05001870 additions or removals are sensitive::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001871
1872 do_package[sstate-lockfile] = "${PACKAGELOCK}"
1873
1874Behind the scenes, the shared state code works by looking in
1875:term:`SSTATE_DIR` and
1876:term:`SSTATE_MIRRORS` for
Andrew Geisslerc926e172021-05-07 16:11:35 -05001877shared state files. Here is an example::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001878
1879 SSTATE_MIRRORS ?= "\
Andrew Geissler7e0e3c02022-02-25 20:34:39 +00001880 file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
Patrick Williams93c203f2021-10-06 16:15:23 -05001881 file://.* file:///some/local/dir/sstate/PATH"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001882
1883.. note::
1884
Andrew Geissler5f350902021-07-23 13:09:54 -04001885 The shared state directory (:term:`SSTATE_DIR`) is organized into two-character
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001886 subdirectories, where the subdirectory names are based on the first two
1887 characters of the hash.
1888 If the shared state directory structure for a mirror has the same structure
Andrew Geissler09036742021-06-25 14:25:14 -05001889 as :term:`SSTATE_DIR`, you must specify "PATH" as part of the URI to enable the build
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001890 system to map to the appropriate subdirectory.
1891
1892The shared state package validity can be detected just by looking at the
1893filename since the filename contains the task checksum (or signature) as
1894described earlier in this section. If a valid shared state package is
1895found, the build process downloads it and uses it to accelerate the
1896task.
1897
1898The build processes use the ``*_setscene`` tasks for the task
1899acceleration phase. BitBake goes through this phase before the main
1900execution code and tries to accelerate any tasks for which it can find
1901shared state packages. If a shared state package for a task is
1902available, the shared state package is used. This means the task and any
1903tasks on which it is dependent are not executed.
1904
1905As a real world example, the aim is when building an IPK-based image,
1906only the
1907:ref:`ref-tasks-package_write_ipk`
1908tasks would have their shared state packages fetched and extracted.
1909Since the sysroot is not used, it would never get extracted. This is
1910another reason why a task-based approach is preferred over a
1911recipe-based approach, which would have to install the output from every
1912task.
1913
Andrew Geissler595f6302022-01-24 19:11:47 +00001914Hash Equivalence
1915----------------
1916
1917The above section explained how BitBake skips the execution of tasks
1918whose output can already be found in the Shared State cache.
1919
1920During a build, it may often be the case that the output / result of a task might
1921be unchanged despite changes in the task's input values. An example might be
1922whitespace changes in some input C code. In project terms, this is what we define
1923as "equivalence".
1924
1925To keep track of such equivalence, BitBake has to manage three hashes
1926for each task:
1927
1928- The *task hash* explained earlier: computed from the recipe metadata,
1929 the task code and the task hash values from its dependencies.
1930 When changes are made, these task hashes are therefore modified,
1931 causing the task to re-execute. The task hashes of tasks depending on this
1932 task are therefore modified too, causing the whole dependency
1933 chain to re-execute.
1934
1935- The *output hash*, a new hash computed from the output of Shared State tasks,
1936 tasks that save their resulting output to a Shared State tarball.
1937 The mapping between the task hash and its output hash is reported
1938 to a new *Hash Equivalence* server. This mapping is stored in a database
1939 by the server for future reference.
1940
1941- The *unihash*, a new hash, initially set to the task hash for the task.
1942 This is used to track the *unicity* of task output, and we will explain
1943 how its value is maintained.
1944
1945When Hash Equivalence is enabled, BitBake computes the task hash
1946for each task by using the unihash of its dependencies, instead
1947of their task hash.
1948
1949Now, imagine that a Shared State task is modified because of a change in
1950its code or metadata, or because of a change in its dependencies.
1951Since this modifies its task hash, this task will need re-executing.
1952Its output hash will therefore be computed again.
1953
1954Then, the new mapping between the new task hash and its output hash
1955will be reported to the Hash Equivalence server. The server will
1956let BitBake know whether this output hash is the same as a previously
1957reported output hash, for a different task hash.
1958
1959If the output hash is already known, BitBake will update the task's
1960unihash to match the original task hash that generated that output.
1961Thanks to this, the depending tasks will keep a previously recorded
1962task hash, and BitBake will be able to retrieve their output from
1963the Shared State cache, instead of re-executing them. Similarly, the
1964output of further downstream tasks can also be retrieved from Shared
1965Shate.
1966
1967If the output hash is unknown, a new entry will be created on the Hash
1968Equivalence server, matching the task hash to that output.
1969The depending tasks, still having a new task hash because of the
1970change, will need to re-execute as expected. The change propagates
1971to the depending tasks.
1972
1973To summarize, when Hash Equivalence is enabled, a change in one of the
1974tasks in BitBake's run queue doesn't have to propagate to all the
1975downstream tasks that depend on the output of this task, causing a
1976full rebuild of such tasks, and so on with the next depending tasks.
1977Instead, when the output of this task remains identical to previously
1978recorded output, BitBake can safely retrieve all the downstream
1979task output from the Shared State cache.
1980
1981.. note::
1982
1983 Having :doc:`/test-manual/reproducible-builds` is a key ingredient for
1984 the stability of the task's output hash. Therefore, the effectiveness
1985 of Hash Equivalence strongly depends on it.
1986
1987This applies to multiple scenarios:
1988
1989- A "trivial" change to a recipe that doesn't impact its generated output,
1990 such as whitespace changes, modifications to unused code paths or
1991 in the ordering of variables.
1992
1993- Shared library updates, for example to fix a security vulnerability.
1994 For sure, the programs using such a library should be rebuilt, but
1995 their new binaries should remain identical. The corresponding tasks should
1996 have a different output hash because of the change in the hash of their
1997 library dependency, but thanks to their output being identical, Hash
1998 Equivalence will stop the propagation down the dependency chain.
1999
2000- Native tool updates. Though the depending tasks should be rebuilt,
2001 it's likely that they will generate the same output and be marked
2002 as equivalent.
2003
2004This mechanism is enabled by default in Poky, and is controlled by three
2005variables:
2006
2007- :term:`bitbake:BB_HASHSERVE`, specifying a local or remote Hash
2008 Equivalence server to use.
2009
2010- :term:`BB_HASHSERVE_UPSTREAM`, when ``BB_HASHSERVE = "auto"``,
2011 allowing to connect the local server to an upstream one.
2012
2013- :term:`bitbake:BB_SIGNATURE_HANDLER`, which must be set to ``OEEquivHash``.
2014
2015Therefore, the default configuration in Poky corresponds to the
2016below settings::
2017
2018 BB_HASHSERVE = "auto"
2019 BB_SIGNATURE_HANDLER = "OEEquivHash"
2020
2021Rather than starting a local server, another possibility is to rely
2022on a Hash Equivalence server on a network, by setting::
2023
2024 BB_HASHSERVE = "<HOSTNAME>:<PORT>"
2025
2026.. note::
2027
2028 The shared Hash Equivalence server needs to be maintained together with the
2029 Shared State cache. Otherwise, the server could report Shared State hashes
2030 that only exist on specific clients.
2031
2032 We therefore recommend that one Hash Equivalence server be set up to
2033 correspond with a given Shared State cache, and to start this server
2034 in *read-only mode*, so that it doesn't store equivalences for
2035 Shared State caches that are local to clients.
2036
2037 See the :term:`BB_HASHSERVE` reference for details about starting
2038 a Hash Equivalence server.
2039
2040See the `video <https://www.youtube.com/watch?v=zXEdqGS62Wc>`__
2041of Joshua Watt's `Hash Equivalence and Reproducible Builds
2042<https://elinux.org/images/3/37/Hash_Equivalence_and_Reproducible_Builds.pdf>`__
2043presentation at ELC 2020 for a very synthetic introduction to the
2044Hash Equivalence implementation in the Yocto Project.
2045
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002046Automatically Added Runtime Dependencies
2047========================================
2048
2049The OpenEmbedded build system automatically adds common types of runtime
2050dependencies between packages, which means that you do not need to
2051explicitly declare the packages using
William A. Kennington IIIac69b482021-06-02 12:28:27 -07002052:term:`RDEPENDS`. There are three automatic
2053mechanisms (``shlibdeps``, ``pcdeps``, and ``depchains``) that
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002054handle shared libraries, package configuration (pkg-config) modules, and
2055``-dev`` and ``-dbg`` packages, respectively. For other types of runtime
2056dependencies, you must manually declare the dependencies.
2057
2058- ``shlibdeps``: During the
2059 :ref:`ref-tasks-package` task of
2060 each recipe, all shared libraries installed by the recipe are
2061 located. For each shared library, the package that contains the
2062 shared library is registered as providing the shared library. More
2063 specifically, the package is registered as providing the
Patrick Williams7784c422022-11-17 07:29:11 -06002064 :wikipedia:`soname <Soname>` of the library. The
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002065 resulting shared-library-to-package mapping is saved globally in
2066 :term:`PKGDATA_DIR` by the
2067 :ref:`ref-tasks-packagedata`
2068 task.
2069
2070 Simultaneously, all executables and shared libraries installed by the
2071 recipe are inspected to see what shared libraries they link against.
Andrew Geissler09036742021-06-25 14:25:14 -05002072 For each shared library dependency that is found, :term:`PKGDATA_DIR` is
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002073 queried to see if some package (likely from a different recipe)
2074 contains the shared library. If such a package is found, a runtime
2075 dependency is added from the package that depends on the shared
2076 library to the package that contains the library.
2077
2078 The automatically added runtime dependency also includes a version
2079 restriction. This version restriction specifies that at least the
2080 current version of the package that provides the shared library must
Andrew Geissler09036742021-06-25 14:25:14 -05002081 be used, as if "package (>= version)" had been added to :term:`RDEPENDS`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002082 This forces an upgrade of the package containing the shared library
2083 when installing the package that depends on the library, if needed.
2084
2085 If you want to avoid a package being registered as providing a
2086 particular shared library (e.g. because the library is for internal
2087 use only), then add the library to
2088 :term:`PRIVATE_LIBS` inside
2089 the package's recipe.
2090
Patrick Williams2194f502022-10-16 14:26:09 -05002091- ``pcdeps``: During the :ref:`ref-tasks-package` task of each recipe, all
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002092 pkg-config modules (``*.pc`` files) installed by the recipe are
2093 located. For each module, the package that contains the module is
2094 registered as providing the module. The resulting module-to-package
Andrew Geissler09036742021-06-25 14:25:14 -05002095 mapping is saved globally in :term:`PKGDATA_DIR` by the
Patrick Williams2194f502022-10-16 14:26:09 -05002096 :ref:`ref-tasks-packagedata` task.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002097
2098 Simultaneously, all pkg-config modules installed by the recipe are
2099 inspected to see what other pkg-config modules they depend on. A
2100 module is seen as depending on another module if it contains a
2101 "Requires:" line that specifies the other module. For each module
Andrew Geissler09036742021-06-25 14:25:14 -05002102 dependency, :term:`PKGDATA_DIR` is queried to see if some package
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002103 contains the module. If such a package is found, a runtime dependency
2104 is added from the package that depends on the module to the package
2105 that contains the module.
2106
2107 .. note::
2108
2109 The
2110 pcdeps
2111 mechanism most often infers dependencies between
2112 -dev
2113 packages.
2114
2115- ``depchains``: If a package ``foo`` depends on a package ``bar``,
2116 then ``foo-dev`` and ``foo-dbg`` are also made to depend on
2117 ``bar-dev`` and ``bar-dbg``, respectively. Taking the ``-dev``
2118 packages as an example, the ``bar-dev`` package might provide headers
2119 and shared library symlinks needed by ``foo-dev``, which shows the
2120 need for a dependency between the packages.
2121
2122 The dependencies added by ``depchains`` are in the form of
2123 :term:`RRECOMMENDS`.
2124
2125 .. note::
2126
Andrew Geissler5f350902021-07-23 13:09:54 -04002127 By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
Patrick Williams0ca19cc2021-08-16 14:03:13 -05002128 ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
Andrew Geisslerd5838332022-05-27 11:33:10 -05002129 ``bitbake.conf``) includes "${PN}".
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002130
2131 To ensure that the dependency chain is never broken, ``-dev`` and
2132 ``-dbg`` packages are always generated by default, even if the
2133 packages turn out to be empty. See the
2134 :term:`ALLOW_EMPTY` variable
2135 for more information.
2136
Patrick Williams2194f502022-10-16 14:26:09 -05002137The :ref:`ref-tasks-package` task depends on the :ref:`ref-tasks-packagedata` task of each
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002138recipe in :term:`DEPENDS` through use
2139of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
2140declaration, which guarantees that the required
2141shared-library/module-to-package mapping information will be available
Andrew Geissler09036742021-06-25 14:25:14 -05002142when needed as long as :term:`DEPENDS` has been correctly set.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002143
2144Fakeroot and Pseudo
2145===================
2146
2147Some tasks are easier to implement when allowed to perform certain
2148operations that are normally reserved for the root user (e.g.
2149:ref:`ref-tasks-install`,
2150:ref:`do_package_write* <ref-tasks-package_write_deb>`,
2151:ref:`ref-tasks-rootfs`, and
Patrick Williams2194f502022-10-16 14:26:09 -05002152:ref:`do_image_* <ref-tasks-image>`). For example,
2153the :ref:`ref-tasks-install` task benefits from being able to set the UID and GID
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002154of installed files to arbitrary values.
2155
2156One approach to allowing tasks to perform root-only operations would be
2157to require :term:`BitBake` to run as
2158root. However, this method is cumbersome and has security issues. The
2159approach that is actually used is to run tasks that benefit from root
2160privileges in a "fake" root environment. Within this environment, the
2161task and its child processes believe that they are running as the root
2162user, and see an internally consistent view of the filesystem. As long
2163as generating the final output (e.g. a package or an image) does not
2164require root privileges, the fact that some earlier steps ran in a fake
2165root environment does not cause problems.
2166
2167The capability to run tasks in a fake root environment is known as
2168"`fakeroot <http://man.he.net/man1/fakeroot>`__", which is derived from
2169the BitBake keyword/variable flag that requests a fake root environment
2170for a task.
2171
Andrew Geisslerd1e89492021-02-12 15:35:20 -06002172In the :term:`OpenEmbedded Build System`, the program that implements
2173fakeroot is known as :yocto_home:`Pseudo </software-item/pseudo/>`. Pseudo
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002174overrides system calls by using the environment variable ``LD_PRELOAD``,
2175which results in the illusion of running as root. To keep track of
2176"fake" file ownership and permissions resulting from operations that
2177require root permissions, Pseudo uses an SQLite 3 database. This
2178database is stored in
2179``${``\ :term:`WORKDIR`\ ``}/pseudo/files.db``
2180for individual recipes. Storing the database in a file as opposed to in
2181memory gives persistence between tasks and builds, which is not
2182accomplished using fakeroot.
2183
2184.. note::
2185
2186 If you add your own task that manipulates the same files or
2187 directories as a fakeroot task, then that task also needs to run
2188 under fakeroot. Otherwise, the task cannot run root-only operations,
2189 and cannot see the fake file ownership and permissions set by the
2190 other task. You need to also add a dependency on
Andrew Geisslerc926e172021-05-07 16:11:35 -05002191 ``virtual/fakeroot-native:do_populate_sysroot``, giving the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002192
2193 fakeroot do_mytask () {
2194 ...
2195 }
2196 do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"
2197
2198
2199For more information, see the
2200:term:`FAKEROOT* <bitbake:FAKEROOT>` variables in the
2201BitBake User Manual. You can also reference the "`Why Not
2202Fakeroot? <https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot>`__"
2203article for background information on Fakeroot and Pseudo.