blob: 75eb872b32202313afd5e0d43479594b8d38dfe6 [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
113the `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__.
114The ":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
236Sourcing the build environment script creates a
237:term:`Build Directory` if one does not
238already exist. BitBake uses the Build Directory for all its work during
239builds. The Build Directory has a ``conf`` directory that contains
240default versions of your ``local.conf`` and ``bblayers.conf``
241configuration files. These default configuration files are created only
242if versions do not already exist in the Build Directory at the time you
243source the build environment setup script.
244
245Because the Poky repository is fundamentally an aggregation of existing
246repositories, some users might be familiar with running the
247:ref:`structure-core-script` script in the context of separate
248:term:`OpenEmbedded-Core (OE-Core)` and BitBake
249repositories rather than a single Poky repository. This discussion
250assumes the script is executed from within a cloned or unpacked version
251of Poky.
252
253Depending on where the script is sourced, different sub-scripts are
254called to set up the Build Directory (Yocto or OpenEmbedded).
255Specifically, the script ``scripts/oe-setup-builddir`` inside the poky
256directory sets up the Build Directory and seeds the directory (if
257necessary) with configuration files appropriate for the Yocto Project
258development environment.
259
260.. note::
261
262 The
263 scripts/oe-setup-builddir
264 script uses the
265 ``$TEMPLATECONF``
266 variable to determine which sample configuration files to locate.
267
268The ``local.conf`` file provides many basic variables that define a
269build environment. Here is a list of a few. To see the default
270configurations in a ``local.conf`` file created by the build environment
271script, see the
Andrew Geissler87f5cff2022-09-30 13:13:31 -0500272:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/templates/default/local.conf.sample>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500273in the ``meta-poky`` layer:
274
275- *Target Machine Selection:* Controlled by the
276 :term:`MACHINE` variable.
277
278- *Download Directory:* Controlled by the
279 :term:`DL_DIR` variable.
280
281- *Shared State Directory:* Controlled by the
282 :term:`SSTATE_DIR` variable.
283
284- *Build Output:* Controlled by the
285 :term:`TMPDIR` variable.
286
287- *Distribution Policy:* Controlled by the
288 :term:`DISTRO` variable.
289
290- *Packaging Format:* Controlled by the
291 :term:`PACKAGE_CLASSES`
292 variable.
293
294- *SDK Target Architecture:* Controlled by the
295 :term:`SDKMACHINE` variable.
296
297- *Extra Image Packages:* Controlled by the
298 :term:`EXTRA_IMAGE_FEATURES`
299 variable.
300
301.. note::
302
Andrew Geissler9aee5002022-03-30 16:27:02 +0000303 Configurations set in the ``conf/local.conf`` file can also be set
304 in the ``conf/site.conf`` and ``conf/auto.conf`` configuration files.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500305
306The ``bblayers.conf`` file tells BitBake what layers you want considered
307during the build. By default, the layers listed in this file include
308layers minimally needed by the build system. However, you must manually
309add any custom layers you have created. You can find more information on
310working with the ``bblayers.conf`` file in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600311":ref:`dev-manual/common-tasks:enabling your layer`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500312section in the Yocto Project Development Tasks Manual.
313
314The files ``site.conf`` and ``auto.conf`` are not created by the
315environment initialization script. If you want the ``site.conf`` file,
Andrew Geisslerd5838332022-05-27 11:33:10 -0500316you need to create it yourself. The ``auto.conf`` file is typically
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500317created by an autobuilder:
318
319- *site.conf:* You can use the ``conf/site.conf`` configuration
320 file to configure multiple build directories. For example, suppose
321 you had several build environments and they shared some common
322 features. You can set these default build properties here. A good
323 example is perhaps the packaging format to use through the
Andrew Geisslerd5838332022-05-27 11:33:10 -0500324 :term:`PACKAGE_CLASSES` variable.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500325
326- *auto.conf:* The file is usually created and written to by an
327 autobuilder. The settings put into the file are typically the same as
328 you would find in the ``conf/local.conf`` or the ``conf/site.conf``
329 files.
330
331You can edit all configuration files to further define any particular
332build environment. This process is represented by the "User
333Configuration Edits" box in the figure.
334
335When you launch your build with the ``bitbake target`` command, BitBake
336sorts out the configurations to ultimately define your build
337environment. It is important to understand that the
338:term:`OpenEmbedded Build System` reads the
339configuration files in a specific order: ``site.conf``, ``auto.conf``,
340and ``local.conf``. And, the build system applies the normal assignment
341statement rules as described in the
342":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
343of the BitBake User Manual. Because the files are parsed in a specific
344order, variable assignments for the same variable could be affected. For
345example, if the ``auto.conf`` file and the ``local.conf`` set variable1
346to different values, because the build system parses ``local.conf``
347after ``auto.conf``, variable1 is assigned the value from the
348``local.conf`` file.
349
350Metadata, Machine Configuration, and Policy Configuration
351---------------------------------------------------------
352
353The previous section described the user configurations that define
354BitBake's global behavior. This section takes a closer look at the
355layers the build system uses to further control the build. These layers
356provide Metadata for the software, machine, and policies.
357
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700358In general, there are three types of layer input. You can see them below
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500359the "User Configuration" box in the `general workflow
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500360figure <overview-manual/concepts:openembedded build system concepts>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500361
362- *Metadata (.bb + Patches):* Software layers containing
363 user-supplied recipe files, patches, and append files. A good example
Andrew Geisslerd1e89492021-02-12 15:35:20 -0600364 of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>`
365 from the :oe_layerindex:`OpenEmbedded Layer Index <>`. This layer is for
366 version 5.0 of the popular `Qt <https://wiki.qt.io/About_Qt>`__
367 cross-platform application development framework for desktop, embedded and
368 mobile.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500369
370- *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e.
371 "BSP Layer" in the following figure) providing machine-specific
372 configurations. This type of information is specific to a particular
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500373 target architecture. A good example of a BSP layer from the
374 :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600375 :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500376 layer.
377
378- *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in
379 the following figure) providing top-level or general policies for the
380 images or SDKs being built for a particular distribution. For
381 example, in the Poky Reference Distribution the distro layer is the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600382 :yocto_git:`meta-poky </poky/tree/meta-poky>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500383 layer. Within the distro layer is a ``conf/distro`` directory that
384 contains distro configuration files (e.g.
Andrew Geissler09209ee2020-12-13 08:44:15 -0600385 :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500386 that contain many policy configurations for the Poky distribution.
387
388The following figure shows an expanded representation of these three
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500389layers from the :ref:`general workflow figure
390<overview-manual/concepts:openembedded build system concepts>`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500391
392.. image:: figures/layer-input.png
393 :align: center
Andrew Geisslerd5838332022-05-27 11:33:10 -0500394 :width: 70%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500395
396In general, all layers have a similar structure. They all contain a
397licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed,
398a ``README`` file as good practice and especially if the layer is to be
399distributed, a configuration directory, and recipe directories. You can
400learn about the general structure for layers used with the Yocto Project
401in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600402":ref:`dev-manual/common-tasks:creating your own layer`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500403section in the
404Yocto Project Development Tasks Manual. For a general discussion on
405layers and the many layers from which you can draw, see the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500406":ref:`overview-manual/concepts:layers`" and
407":ref:`overview-manual/yp-intro:the yocto project layer model`" sections both
408earlier in this manual.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500409
410If you explored the previous links, you discovered some areas where many
Andrew Geissler09209ee2020-12-13 08:44:15 -0600411layers that work with the Yocto Project exist. The :yocto_git:`Source
412Repositories <>` also shows layers categorized under "Yocto Metadata Layers."
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500413
414.. note::
415
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700416 There are layers in the Yocto Project Source Repositories that cannot be
417 found in the OpenEmbedded Layer Index. Such layers are either
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500418 deprecated or experimental in nature.
419
420BitBake uses the ``conf/bblayers.conf`` file, which is part of the user
421configuration, to find what layers it should be using as part of the
422build.
423
424Distro Layer
425~~~~~~~~~~~~
426
427The distribution layer provides policy configurations for your
428distribution. Best practices dictate that you isolate these types of
429configurations into their own layer. Settings you provide in
430``conf/distro/distro.conf`` override similar settings that BitBake finds
431in your ``conf/local.conf`` file in the Build Directory.
432
433The following list provides some explanation and references for what you
434typically find in the distribution layer:
435
436- *classes:* Class files (``.bbclass``) hold common functionality that
437 can be shared among recipes in the distribution. When your recipes
438 inherit a class, they take on the settings and functions for that
439 class. You can read more about class files in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600440 ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500441 Reference Manual.
442
443- *conf:* This area holds configuration files for the layer
444 (``conf/layer.conf``), the distribution
445 (``conf/distro/distro.conf``), and any distribution-wide include
446 files.
447
448- *recipes-*:* Recipes and append files that affect common
449 functionality across the distribution. This area could include
450 recipes and append files to add distribution-specific configuration,
451 initialization scripts, custom image recipes, and so forth. Examples
452 of ``recipes-*`` directories are ``recipes-core`` and
453 ``recipes-extra``. Hierarchy and contents within a ``recipes-*``
454 directory can vary. Generally, these directories contain recipe files
455 (``*.bb``), recipe append files (``*.bbappend``), directories that
456 are distro-specific for configuration files, and so forth.
457
458BSP Layer
459~~~~~~~~~
460
461The BSP Layer provides machine configurations that target specific
462hardware. Everything in this layer is specific to the machine for which
463you are building the image or the SDK. A common structure or form is
464defined for BSP layers. You can learn more about this structure in the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600465:doc:`/bsp-guide/index`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500466
467.. note::
468
469 In order for a BSP layer to be considered compliant with the Yocto
470 Project, it must meet some structural requirements.
471
472The BSP Layer's configuration directory contains configuration files for
473the machine (``conf/machine/machine.conf``) and, of course, the layer
474(``conf/layer.conf``).
475
476The remainder of the layer is dedicated to specific recipes by function:
477``recipes-bsp``, ``recipes-core``, ``recipes-graphics``,
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700478``recipes-kernel``, and so forth. There can be metadata for multiple
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500479formfactors, graphics support systems, and so forth.
480
481.. note::
482
483 While the figure shows several
484 recipes-\*
485 directories, not all these directories appear in all BSP layers.
486
487Software Layer
488~~~~~~~~~~~~~~
489
490The software layer provides the Metadata for additional software
491packages used during the build. This layer does not include Metadata
492that is specific to the distribution or the machine, which are found in
493their respective layers.
494
495This layer contains any recipes, append files, and patches, that your
496project needs.
497
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500498Sources
499-------
500
501In order for the OpenEmbedded build system to create an image or any
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500502target, it must be able to access source files. The :ref:`general workflow
503figure <overview-manual/concepts:openembedded build system concepts>`
504represents source files using the "Upstream Project Releases", "Local
505Projects", and "SCMs (optional)" boxes. The figure represents mirrors,
506which also play a role in locating source files, with the "Source
507Materials" box.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500508
509The method by which source files are ultimately organized is a function
510of the project. For example, for released software, projects tend to use
511tarballs or other archived files that can capture the state of a release
512guaranteeing that it is statically represented. On the other hand, for a
513project that is more dynamic or experimental in nature, a project might
514keep source files in a repository controlled by a Source Control Manager
515(SCM) such as Git. Pulling source from a repository allows you to
516control the point in the repository (the revision) from which you want
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700517to build software. A combination of the two is also possible.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500518
519BitBake uses the :term:`SRC_URI`
520variable to point to source files regardless of their location. Each
Andrew Geissler09036742021-06-25 14:25:14 -0500521recipe must have a :term:`SRC_URI` variable that points to the source.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500522
523Another area that plays a significant role in where source files come
524from is pointed to by the
525:term:`DL_DIR` variable. This area is
526a cache that can hold previously downloaded source. You can also
527instruct the OpenEmbedded build system to create tarballs from Git
528repositories, which is not the default behavior, and store them in the
Andrew Geissler09036742021-06-25 14:25:14 -0500529:term:`DL_DIR` by using the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500530:term:`BB_GENERATE_MIRROR_TARBALLS`
531variable.
532
Andrew Geissler09036742021-06-25 14:25:14 -0500533Judicious use of a :term:`DL_DIR` directory can save the build system a trip
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500534across the Internet when looking for files. A good method for using a
Andrew Geissler09036742021-06-25 14:25:14 -0500535download directory is to have :term:`DL_DIR` point to an area outside of
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500536your Build Directory. Doing so allows you to safely delete the Build
537Directory if needed without fear of removing any downloaded source file.
538
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
635The package feed area resides in the Build Directory. The directory the
636build 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
642- :term:`DEPLOY_DIR`: Defined as
643 ``tmp/deploy`` in the Build Directory.
644
645- ``DEPLOY_DIR_*``: Depending on the package manager used, the package
646 type sub-folder. Given RPM, IPK, or DEB packaging and tarball
647 creation, the
648 :term:`DEPLOY_DIR_RPM`,
649 :term:`DEPLOY_DIR_IPK`,
650 :term:`DEPLOY_DIR_DEB`, or
651 :term:`DEPLOY_DIR_TAR`,
652 variables are used, respectively.
653
654- :term:`PACKAGE_ARCH`: Defines
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700655 architecture-specific sub-folders. For example, packages could be
656 available for the i586 or qemux86 architectures.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500657
658BitBake uses the
659:ref:`do_package_write_* <ref-tasks-package_write_deb>`
660tasks to generate packages and place them into the package holding area
661(e.g. ``do_package_write_ipk`` for IPK packages). See the
662":ref:`ref-tasks-package_write_deb`",
663":ref:`ref-tasks-package_write_ipk`",
664":ref:`ref-tasks-package_write_rpm`",
665and
666":ref:`ref-tasks-package_write_tar`"
667sections in the Yocto Project Reference Manual for additional
668information. As an example, consider a scenario where an IPK packaging
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700669manager is being used and there is package architecture support for both
670i586 and qemux86. Packages for the i586 architecture are placed in
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500671``build/tmp/deploy/ipk/i586``, while packages for the qemux86
672architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
673
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500674BitBake Tool
675------------
676
677The OpenEmbedded build system uses
678:term:`BitBake` to produce images and
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500679Software Development Kits (SDKs). You can see from the :ref:`general workflow
680figure <overview-manual/concepts:openembedded build system concepts>`,
681the BitBake area consists of several functional areas. This section takes a
682closer look at each of those areas.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500683
684.. note::
685
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700686 Documentation for the BitBake tool is available separately. See the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500687 BitBake User Manual
688 for reference material on BitBake.
689
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500690Source Fetching
691~~~~~~~~~~~~~~~
692
693The first stages of building a recipe are to fetch and unpack the source
694code:
695
696.. image:: figures/source-fetching.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500697 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500698
699The :ref:`ref-tasks-fetch` and
700:ref:`ref-tasks-unpack` tasks fetch
701the source files and unpack them into the
702:term:`Build Directory`.
703
704.. note::
705
Patrick Williams2194f502022-10-16 14:26:09 -0500706 For every local file (e.g. ``file://``) that is part of a recipe's
707 :term:`SRC_URI` statement, the OpenEmbedded build system takes a
708 checksum of the file for the recipe and inserts the checksum into
709 the signature for the :ref:`ref-tasks-fetch` task. If any local
710 file has been modified, the :ref:`ref-tasks-fetch` task and all
711 tasks that depend on it are re-executed.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500712
713By default, everything is accomplished in the Build Directory, which has
714a defined structure. For additional general information on the Build
715Directory, see the ":ref:`structure-core-build`" section in
716the Yocto Project Reference Manual.
717
718Each recipe has an area in the Build Directory where the unpacked source
719code resides. The :term:`S` variable points
720to this area for a recipe's unpacked source code. The name of that
721directory for any given recipe is defined from several different
722variables. The preceding figure and the following list describe the
723Build Directory's hierarchy:
724
725- :term:`TMPDIR`: The base directory
726 where the OpenEmbedded build system performs all its work during the
727 build. The default base directory is the ``tmp`` directory.
728
729- :term:`PACKAGE_ARCH`: The
730 architecture of the built package or packages. Depending on the
731 eventual destination of the package or packages (i.e. machine
732 architecture, :term:`Build Host`, SDK, or
Andrew Geissler09036742021-06-25 14:25:14 -0500733 specific machine), :term:`PACKAGE_ARCH` varies. See the variable's
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500734 description for details.
735
736- :term:`TARGET_OS`: The operating
737 system of the target device. A typical value would be "linux" (e.g.
738 "qemux86-poky-linux").
739
740- :term:`PN`: The name of the recipe used
741 to build the package. This variable can have multiple meanings.
Andrew Geissler09036742021-06-25 14:25:14 -0500742 However, when used in the context of input files, :term:`PN` represents
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500743 the name of the recipe.
744
745- :term:`WORKDIR`: The location
746 where the OpenEmbedded build system builds a recipe (i.e. does the
747 work to create the package).
748
749 - :term:`PV`: The version of the
750 recipe used to build the package.
751
752 - :term:`PR`: The revision of the
753 recipe used to build the package.
754
755- :term:`S`: Contains the unpacked source
756 files for a given recipe.
757
758 - :term:`BPN`: The name of the recipe
Andrew Geissler09036742021-06-25 14:25:14 -0500759 used to build the package. The :term:`BPN` variable is a version of
Andrew Geissler5f350902021-07-23 13:09:54 -0400760 the :term:`PN` variable but with common prefixes and suffixes removed.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500761
762 - :term:`PV`: The version of the
763 recipe used to build the package.
764
765.. note::
766
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700767 In the previous figure, notice that there are two sample hierarchies:
768 one based on package architecture (i.e. :term:`PACKAGE_ARCH`)
769 and one based on a machine (i.e. :term:`MACHINE`).
770 The underlying structures are identical. The differentiator being
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500771 what the OpenEmbedded build system is using as a build target (e.g.
772 general architecture, a build host, an SDK, or a specific machine).
773
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500774Patching
775~~~~~~~~
776
777Once source code is fetched and unpacked, BitBake locates patch files
778and applies them to the source files:
779
780.. image:: figures/patching.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500781 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500782
783The :ref:`ref-tasks-patch` task uses a
784recipe's :term:`SRC_URI` statements
785and the :term:`FILESPATH` variable
786to locate applicable patch files.
787
788Default processing for patch files assumes the files have either
Andrew Geissler09036742021-06-25 14:25:14 -0500789``*.patch`` or ``*.diff`` file types. You can use :term:`SRC_URI` parameters
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500790to change the way the build system recognizes patch files. See the
791:ref:`ref-tasks-patch` task for more
792information.
793
794BitBake finds and applies multiple patches for a single recipe in the
Andrew Geissler09036742021-06-25 14:25:14 -0500795order in which it locates the patches. The :term:`FILESPATH` variable
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500796defines the default set of directories that the build system uses to
797search for patch files. Once found, patches are applied to the recipe's
798source files, which are located in the
799:term:`S` directory.
800
801For more information on how the source directories are created, see the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500802":ref:`overview-manual/concepts:source fetching`" section. For
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500803more information on how to create patches and how the build system
804processes patches, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600805":ref:`dev-manual/common-tasks:patching code`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500806section in the
807Yocto Project Development Tasks Manual. You can also see the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600808":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500809section in the Yocto Project Application Development and the Extensible
810Software Development Kit (SDK) manual and the
Andrew Geissler09209ee2020-12-13 08:44:15 -0600811":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500812section in the Yocto Project Linux Kernel Development Manual.
813
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500814Configuration, Compilation, and Staging
815~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
816
817After source code is patched, BitBake executes tasks that configure and
818compile the source code. Once compilation occurs, the files are copied
819to a holding area (staged) in preparation for packaging:
820
821.. image:: figures/configuration-compile-autoreconf.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500822 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500823
824This step in the build process consists of the following tasks:
825
826- :ref:`ref-tasks-prepare_recipe_sysroot`:
827 This task sets up the two sysroots in
828 ``${``\ :term:`WORKDIR`\ ``}``
829 (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that
830 during the packaging phase the sysroots can contain the contents of
831 the
832 :ref:`ref-tasks-populate_sysroot`
833 tasks of the recipes on which the recipe containing the tasks
834 depends. A sysroot exists for both the target and for the native
835 binaries, which run on the host system.
836
837- *do_configure*: This task configures the source by enabling and
838 disabling any build-time and configuration options for the software
839 being built. Configurations can come from the recipe itself as well
840 as from an inherited class. Additionally, the software itself might
841 configure itself depending on the target for which it is being built.
842
843 The configurations handled by the
844 :ref:`ref-tasks-configure` task
845 are specific to configurations for the source code being built by the
846 recipe.
847
848 If you are using the
849 :ref:`autotools <ref-classes-autotools>` class,
850 you can add additional configuration options by using the
851 :term:`EXTRA_OECONF` or
852 :term:`PACKAGECONFIG_CONFARGS`
853 variables. For information on how this variable works within that
854 class, see the
855 :ref:`autotools <ref-classes-autotools>` class
Patrick Williams975a06f2022-10-21 14:42:47 -0500856 :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500857
858- *do_compile*: Once a configuration task has been satisfied,
859 BitBake compiles the source using the
860 :ref:`ref-tasks-compile` task.
861 Compilation occurs in the directory pointed to by the
862 :term:`B` variable. Realize that the
Andrew Geissler09036742021-06-25 14:25:14 -0500863 :term:`B` directory is, by default, the same as the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500864 :term:`S` directory.
865
866- *do_install*: After compilation completes, BitBake executes the
867 :ref:`ref-tasks-install` task.
Andrew Geissler09036742021-06-25 14:25:14 -0500868 This task copies files from the :term:`B` directory and places them in a
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500869 holding area pointed to by the :term:`D`
870 variable. Packaging occurs later using files from this holding
871 directory.
872
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500873Package Splitting
874~~~~~~~~~~~~~~~~~
875
876After source code is configured, compiled, and staged, the build system
877analyzes the results and splits the output into packages:
878
879.. image:: figures/analysis-for-package-splitting.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500880 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500881
882The :ref:`ref-tasks-package` and
883:ref:`ref-tasks-packagedata`
884tasks combine to analyze the files found in the
885:term:`D` directory and split them into
886subsets based on available packages and files. Analysis involves the
887following as well as other items: splitting out debugging symbols,
888looking at shared library dependencies between packages, and looking at
889package relationships.
890
Patrick Williams2194f502022-10-16 14:26:09 -0500891The :ref:`ref-tasks-packagedata` task creates package metadata based on the
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500892analysis such that the build system can generate the final packages. The
893:ref:`ref-tasks-populate_sysroot`
894task stages (copies) a subset of the files installed by the
895:ref:`ref-tasks-install` task into
896the appropriate sysroot. Working, staged, and intermediate results of
897the analysis and package splitting process use several areas:
898
899- :term:`PKGD`: The destination
900 directory (i.e. ``package``) for packages before they are split into
901 individual packages.
902
903- :term:`PKGDESTWORK`: A
Patrick Williams2194f502022-10-16 14:26:09 -0500904 temporary work area (i.e. ``pkgdata``) used by the :ref:`ref-tasks-package`
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500905 task to save package metadata.
906
907- :term:`PKGDEST`: The parent
908 directory (i.e. ``packages-split``) for packages after they have been
909 split.
910
911- :term:`PKGDATA_DIR`: A shared,
912 global-state directory that holds packaging metadata generated during
913 the packaging process. The packaging process copies metadata from
Andrew Geissler09036742021-06-25 14:25:14 -0500914 :term:`PKGDESTWORK` to the :term:`PKGDATA_DIR` area where it becomes globally
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500915 available.
916
917- :term:`STAGING_DIR_HOST`:
918 The path for the sysroot for the system on which a component is built
919 to run (i.e. ``recipe-sysroot``).
920
921- :term:`STAGING_DIR_NATIVE`:
922 The path for the sysroot used when building components for the build
923 host (i.e. ``recipe-sysroot-native``).
924
925- :term:`STAGING_DIR_TARGET`:
926 The path for the sysroot used when a component that is built to
927 execute on a system and it generates code for yet another machine
928 (e.g. cross-canadian recipes).
929
930The :term:`FILES` variable defines the
931files that go into each package in
932:term:`PACKAGES`. If you want
933details on how this is accomplished, you can look at
Patrick Williams975a06f2022-10-21 14:42:47 -0500934:yocto_git:`package.bbclass </poky/tree/meta/classes-global/package.bbclass>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500935
936Depending on the type of packages being created (RPM, DEB, or IPK), the
937:ref:`do_package_write_* <ref-tasks-package_write_deb>`
938task creates the actual packages and places them in the Package Feed
Andrew Geissler3b8a17c2021-04-15 15:55:55 -0500939area, which is ``${TMPDIR}/deploy``. You can see the
940":ref:`overview-manual/concepts:package feeds`" section for more detail on
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500941that part of the build process.
942
943.. note::
944
William A. Kennington IIIac69b482021-06-02 12:28:27 -0700945 Support for creating feeds directly from the ``deploy/*``
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500946 directories does not exist. Creating such feeds usually requires some
947 kind of feed maintenance mechanism that would upload the new packages
948 into an official package feed (e.g. the Ångström distribution). This
949 functionality is highly distribution-specific and thus is not
950 provided out of the box.
951
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500952Image Generation
953~~~~~~~~~~~~~~~~
954
955Once packages are split and stored in the Package Feeds area, the build
956system uses BitBake to generate the root filesystem image:
957
958.. image:: figures/image-generation.png
Andrew Geisslerd5838332022-05-27 11:33:10 -0500959 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500960
961The image generation process consists of several stages and depends on
962several tasks and variables. The
963:ref:`ref-tasks-rootfs` task creates
964the root filesystem (file and directory structure) for an image. This
965task uses several key variables to help create the list of packages to
966actually install:
967
968- :term:`IMAGE_INSTALL`: Lists
969 out the base set of packages from which to install from the Package
970 Feeds area.
971
972- :term:`PACKAGE_EXCLUDE`:
973 Specifies packages that should not be installed into the image.
974
975- :term:`IMAGE_FEATURES`:
976 Specifies features to include in the image. Most of these features
977 map to additional packages for installation.
978
979- :term:`PACKAGE_CLASSES`:
980 Specifies the package backend (e.g. RPM, DEB, or IPK) to use and
981 consequently helps determine where to locate packages within the
982 Package Feeds area.
983
984- :term:`IMAGE_LINGUAS`:
985 Determines the language(s) for which additional language support
986 packages are installed.
987
988- :term:`PACKAGE_INSTALL`:
989 The final list of packages passed to the package manager for
990 installation into the image.
991
992With :term:`IMAGE_ROOTFS`
993pointing to the location of the filesystem under construction and the
Andrew Geissler09036742021-06-25 14:25:14 -0500994:term:`PACKAGE_INSTALL` variable providing the final list of packages to
Andrew Geisslerc9f78652020-09-18 14:11:35 -0500995install, the root file system is created.
996
997Package installation is under control of the package manager (e.g.
998dnf/rpm, opkg, or apt/dpkg) regardless of whether or not package
999management is enabled for the target. At the end of the process, if
1000package management is not enabled for the target, the package manager's
1001data files are deleted from the root filesystem. As part of the final
1002stage of package installation, post installation scripts that are part
1003of the packages are run. Any scripts that fail to run on the build host
1004are run on the target when the target system is first booted. If you are
Andrew Geissler87f5cff2022-09-30 13:13:31 -05001005using a
Andrew Geissler09209ee2020-12-13 08:44:15 -06001006:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001007all the post installation scripts must succeed on the build host during
1008the package installation phase since the root filesystem on the target
1009is read-only.
1010
Patrick Williams2194f502022-10-16 14:26:09 -05001011The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001012processing includes creation of a manifest file and optimizations.
1013
1014The manifest file (``.manifest``) resides in the same directory as the
1015root filesystem image. This file lists out, line-by-line, the installed
1016packages. The manifest file is useful for the
Patrick Williams975a06f2022-10-21 14:42:47 -05001017:ref:`testimage <ref-classes-testimage>` class,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001018for example, to determine whether or not to run specific tests. See the
1019:term:`IMAGE_MANIFEST`
1020variable for additional information.
1021
Andrew Geissler9aee5002022-03-30 16:27:02 +00001022Optimizing processes that are run across the image include ``mklibs``
1023and any other post-processing commands as defined by the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001024:term:`ROOTFS_POSTPROCESS_COMMAND`
Andrew Geissler9aee5002022-03-30 16:27:02 +00001025variable. The ``mklibs`` process optimizes the size of the libraries.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001026
1027After the root filesystem is built, processing begins on the image
1028through the :ref:`ref-tasks-image`
1029task. The build system runs any pre-processing commands as defined by
1030the
1031:term:`IMAGE_PREPROCESS_COMMAND`
1032variable. This variable specifies a list of functions to call before the
1033build system creates the final image output files.
1034
Patrick Williams2194f502022-10-16 14:26:09 -05001035The build system dynamically creates :ref:`do_image_* <ref-tasks-image>` tasks as needed,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001036based on the image types specified in the
1037:term:`IMAGE_FSTYPES` variable.
1038The process turns everything into an image file or a set of image files
1039and can compress the root filesystem image to reduce the overall size of
1040the image. The formats used for the root filesystem depend on the
Andrew Geissler09036742021-06-25 14:25:14 -05001041:term:`IMAGE_FSTYPES` variable. Compression depends on whether the formats
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001042support compression.
1043
1044As an example, a dynamically created task when creating a particular
Andrew Geisslerc926e172021-05-07 16:11:35 -05001045image type would take the following form::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001046
1047 do_image_type
1048
1049So, if the type
Andrew Geissler09036742021-06-25 14:25:14 -05001050as specified by the :term:`IMAGE_FSTYPES` were ``ext4``, the dynamically
Andrew Geisslerc926e172021-05-07 16:11:35 -05001051generated task would be as follows::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001052
1053 do_image_ext4
1054
1055The final task involved in image creation is the
1056:ref:`do_image_complete <ref-tasks-image-complete>`
1057task. This task completes the image by applying any image post
1058processing as defined through the
1059:term:`IMAGE_POSTPROCESS_COMMAND`
1060variable. The variable specifies a list of functions to call once the
1061build system has created the final image output files.
1062
1063.. note::
1064
1065 The entire image generation process is run under
1066 Pseudo. Running under Pseudo ensures that the files in the root filesystem
1067 have correct ownership.
1068
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001069SDK Generation
1070~~~~~~~~~~~~~~
1071
1072The OpenEmbedded build system uses BitBake to generate the Software
1073Development Kit (SDK) installer scripts for both the standard SDK and
1074the extensible SDK (eSDK):
1075
1076.. image:: figures/sdk-generation.png
Andrew Geisslerd5838332022-05-27 11:33:10 -05001077 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001078
1079.. note::
1080
1081 For more information on the cross-development toolchain generation,
Andrew Geissler09209ee2020-12-13 08:44:15 -06001082 see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001083 section. For information on advantages gained when building a
Patrick Williams2194f502022-10-16 14:26:09 -05001084 cross-development toolchain using the :ref:`ref-tasks-populate_sdk` task, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001085 ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001086 the Yocto Project Application Development and the Extensible Software
1087 Development Kit (eSDK) manual.
1088
1089Like image generation, the SDK script process consists of several stages
1090and depends on many variables. The
1091:ref:`ref-tasks-populate_sdk`
1092and
1093:ref:`ref-tasks-populate_sdk_ext`
1094tasks use these key variables to help create the list of packages to
1095actually install. For information on the variables listed in the figure,
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001096see the ":ref:`overview-manual/concepts:application development sdk`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001097section.
1098
Patrick Williams2194f502022-10-16 14:26:09 -05001099The :ref:`ref-tasks-populate_sdk` task helps create the standard SDK and handles
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001100two parts: a target part and a host part. The target part is the part
1101built for the target hardware and includes libraries and headers. The
1102host part is the part of the SDK that runs on the
1103:term:`SDKMACHINE`.
1104
Patrick Williams2194f502022-10-16 14:26:09 -05001105The :ref:`ref-tasks-populate_sdk_ext` task helps create the extensible SDK and
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001106handles host and target parts differently than its counter part does for
1107the standard SDK. For the extensible SDK, the task encapsulates the
1108build system, which includes everything needed (host and target) for the
1109SDK.
1110
1111Regardless of the type of SDK being constructed, the tasks perform some
1112cleanup after which a cross-development environment setup script and any
1113needed configuration files are created. The final output is the
1114Cross-development toolchain installation script (``.sh`` file), which
1115includes the environment setup script.
1116
1117Stamp Files and the Rerunning of Tasks
1118~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1119
1120For each task that completes successfully, BitBake writes a stamp file
1121into the :term:`STAMPS_DIR`
1122directory. The beginning of the stamp file's filename is determined by
1123the :term:`STAMP` variable, and the end
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001124of the name consists of the task's name and current :ref:`input
1125checksum <overview-manual/concepts:checksums (signatures)>`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001126
1127.. note::
1128
1129 This naming scheme assumes that
1130 BB_SIGNATURE_HANDLER
1131 is "OEBasicHash", which is almost always the case in current
1132 OpenEmbedded.
1133
1134To determine if a task needs to be rerun, BitBake checks if a stamp file
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001135with a matching input checksum exists for the task. In this case,
1136the task's output is assumed to exist and still be valid. Otherwise,
1137the task is rerun.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001138
1139.. note::
1140
1141 The stamp mechanism is more general than the shared state (sstate)
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001142 cache mechanism described in the
1143 ":ref:`overview-manual/concepts:setscene tasks and shared state`" section.
1144 BitBake avoids rerunning any task that has a valid stamp file, not just
1145 tasks that can be accelerated through the sstate cache.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001146
1147 However, you should realize that stamp files only serve as a marker
1148 that some work has been done and that these files do not record task
1149 output. The actual task output would usually be somewhere in
1150 :term:`TMPDIR` (e.g. in some
1151 recipe's :term:`WORKDIR`.) What
1152 the sstate cache mechanism adds is a way to cache task output that
1153 can then be shared between build machines.
1154
Andrew Geissler09036742021-06-25 14:25:14 -05001155Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing
1156:term:`TMPDIR` will also remove :term:`STAMPS_DIR`, which means tasks will
1157properly be rerun to repopulate :term:`TMPDIR`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001158
1159If you want some task to always be considered "out of date", you can
1160mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`
1161varflag. If some other task depends on such a task, then that task will
1162also always be considered out of date, which might not be what you want.
1163
1164For details on how to view information about a task's signature, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001165":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001166section in the Yocto Project Development Tasks Manual.
1167
1168Setscene Tasks and Shared State
1169~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1170
1171The description of tasks so far assumes that BitBake needs to build
1172everything and no available prebuilt objects exist. BitBake does support
1173skipping tasks if prebuilt objects are available. These objects are
1174usually made available in the form of a shared state (sstate) cache.
1175
1176.. note::
1177
1178 For information on variables affecting sstate, see the
1179 :term:`SSTATE_DIR`
1180 and
1181 :term:`SSTATE_MIRRORS`
1182 variables.
1183
Andrew Geisslereff27472021-10-29 15:35:00 -05001184The idea of a setscene task (i.e ``do_taskname_setscene``) is a
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001185version of the task where instead of building something, BitBake can
1186skip to the end result and simply place a set of files into specific
1187locations as needed. In some cases, it makes sense to have a setscene
1188task variant (e.g. generating package files in the
1189:ref:`do_package_write_* <ref-tasks-package_write_deb>`
1190task). In other cases, it does not make sense (e.g. a
1191:ref:`ref-tasks-patch` task or a
1192:ref:`ref-tasks-unpack` task) since
1193the work involved would be equal to or greater than the underlying task.
1194
1195In the build system, the common tasks that have setscene variants are
1196:ref:`ref-tasks-package`,
Patrick Williams2194f502022-10-16 14:26:09 -05001197:ref:`do_package_write_* <ref-tasks-package_write_deb>`,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001198:ref:`ref-tasks-deploy`,
1199:ref:`ref-tasks-packagedata`, and
1200:ref:`ref-tasks-populate_sysroot`.
1201Notice that these tasks represent most of the tasks whose output is an
1202end result.
1203
1204The build system has knowledge of the relationship between these tasks
1205and other preceding tasks. For example, if BitBake runs
1206``do_populate_sysroot_setscene`` for something, it does not make sense
Patrick Williams2194f502022-10-16 14:26:09 -05001207to run any of the :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`,
1208:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if
1209:ref:`ref-tasks-package` needs to be run, BitBake needs to run those other tasks.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001210
1211It becomes more complicated if everything can come from an sstate cache
1212because some objects are simply not required at all. For example, you do
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001213not need a compiler or native tools, such as quilt, if there isn't anything
Patrick Williams2194f502022-10-16 14:26:09 -05001214to compile or patch. If the :ref:`do_package_write_* <ref-tasks-package_write_deb>` packages are available
1215from sstate, BitBake does not need the :ref:`ref-tasks-package` task data.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001216
1217To handle all these complexities, BitBake runs in two phases. The first
1218is the "setscene" stage. During this stage, BitBake first checks the
1219sstate cache for any targets it is planning to build. BitBake does a
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001220fast check to see if the object exists rather than doing a complete download.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001221If nothing exists, the second phase, which is the setscene stage,
1222completes and the main build proceeds.
1223
1224If objects are found in the sstate cache, the build system works
1225backwards from the end targets specified by the user. For example, if an
1226image is being built, the build system first looks for the packages
1227needed for that image and the tools needed to construct an image. If
1228those are available, the compiler is not needed. Thus, the compiler is
1229not even downloaded. If something was found to be unavailable, or the
1230download or setscene task fails, the build system then tries to install
1231dependencies, such as the compiler, from the cache.
1232
1233The availability of objects in the sstate cache is handled by the
Patrick Williams213cb262021-08-07 19:21:33 -05001234function specified by the :term:`BB_HASHCHECK_FUNCTION`
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001235variable and returns a list of available objects. The function specified
Patrick Williams213cb262021-08-07 19:21:33 -05001236by the :term:`BB_SETSCENE_DEPVALID`
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001237variable is the function that determines whether a given dependency
1238needs to be followed, and whether for any given relationship the
1239function needs to be passed. The function returns a True or False value.
1240
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001241Images
1242------
1243
1244The images produced by the build system are compressed forms of the root
1245filesystem and are ready to boot on a target device. You can see from
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001246the :ref:`general workflow figure
1247<overview-manual/concepts:openembedded build system concepts>` that BitBake
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001248output, in part, consists of images. This section takes a closer look at
1249this output:
1250
1251.. image:: figures/images.png
1252 :align: center
Andrew Geisslerd5838332022-05-27 11:33:10 -05001253 :width: 75%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001254
1255.. note::
1256
1257 For a list of example images that the Yocto Project provides, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001258 ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001259 Manual.
1260
1261The build process writes images out to the :term:`Build Directory`
1262inside the
1263``tmp/deploy/images/machine/`` folder as shown in the figure. This
1264folder contains any files expected to be loaded on the target device.
1265The :term:`DEPLOY_DIR` variable
1266points to the ``deploy`` directory, while the
1267:term:`DEPLOY_DIR_IMAGE`
1268variable points to the appropriate directory containing images for the
1269current configuration.
1270
1271- kernel-image: A kernel binary file. The
1272 :term:`KERNEL_IMAGETYPE`
1273 variable determines the naming scheme for the kernel image file.
1274 Depending on this variable, the file could begin with a variety of
1275 naming strings. The ``deploy/images/``\ machine directory can contain
1276 multiple image files for the machine.
1277
1278- root-filesystem-image: Root filesystems for the target device (e.g.
1279 ``*.ext3`` or ``*.bz2`` files). The
1280 :term:`IMAGE_FSTYPES`
1281 variable determines the root filesystem image type. The
1282 ``deploy/images/``\ machine directory can contain multiple root
1283 filesystems for the machine.
1284
1285- kernel-modules: Tarballs that contain all the modules built for the
1286 kernel. Kernel module tarballs exist for legacy purposes and can be
1287 suppressed by setting the
1288 :term:`MODULE_TARBALL_DEPLOY`
1289 variable to "0". The ``deploy/images/``\ machine directory can
1290 contain multiple kernel module tarballs for the machine.
1291
1292- bootloaders: If applicable to the target machine, bootloaders
1293 supporting the image. The ``deploy/images/``\ machine directory can
1294 contain multiple bootloaders for the machine.
1295
1296- symlinks: The ``deploy/images/``\ machine folder contains a symbolic
1297 link that points to the most recently built file for each machine.
1298 These links might be useful for external scripts that need to obtain
1299 the latest version of each file.
1300
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001301Application Development SDK
1302---------------------------
1303
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001304In the :ref:`general workflow figure
1305<overview-manual/concepts:openembedded build system concepts>`, the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001306output labeled "Application Development SDK" represents an SDK. The SDK
1307generation process differs depending on whether you build an extensible
1308SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
1309(e.g. ``bitbake -c populate_sdk`` imagename). This section takes a
1310closer look at this output:
1311
1312.. image:: figures/sdk.png
Andrew Geisslerd5838332022-05-27 11:33:10 -05001313 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001314
1315The specific form of this output is a set of files that includes a
1316self-extracting SDK installer (``*.sh``), host and target manifest
1317files, and files used for SDK testing. When the SDK installer file is
1318run, it installs the SDK. The SDK consists of a cross-development
1319toolchain, a set of libraries and headers, and an SDK environment setup
1320script. Running this installer essentially sets up your
1321cross-development environment. You can think of the cross-toolchain as
1322the "host" part because it runs on the SDK machine. You can think of the
1323libraries and headers as the "target" part because they are built for
1324the target hardware. The environment setup script is added so that you
1325can initialize the environment before using the tools.
1326
1327.. note::
1328
1329 - The Yocto Project supports several methods by which you can set up
1330 this cross-development environment. These methods include
1331 downloading pre-built SDK installers or building and installing
1332 your own SDK installer.
1333
1334 - For background information on cross-development toolchains in the
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001335 Yocto Project development environment, see the
1336 ":ref:`overview-manual/concepts:cross-development toolchain generation`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001337 section.
1338
1339 - For information on setting up a cross-development environment, see
Andrew Geissler09209ee2020-12-13 08:44:15 -06001340 the :doc:`/sdk-manual/index` manual.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001341
1342All the output files for an SDK are written to the ``deploy/sdk`` folder
1343inside the :term:`Build Directory` as
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001344shown in the previous figure. Depending on the type of SDK, there are
1345several variables to configure these files. Here are the variables
1346associated with an extensible SDK:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001347
1348- :term:`DEPLOY_DIR`: Points to
1349 the ``deploy`` directory.
1350
1351- :term:`SDK_EXT_TYPE`:
1352 Controls whether or not shared state artifacts are copied into the
1353 extensible SDK. By default, all required shared state artifacts are
1354 copied into the SDK.
1355
1356- :term:`SDK_INCLUDE_PKGDATA`:
1357 Specifies whether or not packagedata is included in the extensible
1358 SDK for all recipes in the "world" target.
1359
1360- :term:`SDK_INCLUDE_TOOLCHAIN`:
1361 Specifies whether or not the toolchain is included when building the
1362 extensible SDK.
1363
Andrew Geissler9aee5002022-03-30 16:27:02 +00001364- :term:`ESDK_LOCALCONF_ALLOW`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001365 A list of variables allowed through from the build system
1366 configuration into the extensible SDK configuration.
1367
Andrew Geissler9aee5002022-03-30 16:27:02 +00001368- :term:`ESDK_LOCALCONF_REMOVE`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001369 A list of variables not allowed through from the build system
1370 configuration into the extensible SDK configuration.
1371
Andrew Geissler9aee5002022-03-30 16:27:02 +00001372- :term:`ESDK_CLASS_INHERIT_DISABLE`:
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001373 A list of classes to remove from the
1374 :term:`INHERIT` value globally
1375 within the extensible SDK configuration.
1376
1377This next list, shows the variables associated with a standard SDK:
1378
1379- :term:`DEPLOY_DIR`: Points to
1380 the ``deploy`` directory.
1381
1382- :term:`SDKMACHINE`: Specifies
1383 the architecture of the machine on which the cross-development tools
1384 are run to create packages for the target hardware.
1385
1386- :term:`SDKIMAGE_FEATURES`:
1387 Lists the features to include in the "target" part of the SDK.
1388
1389- :term:`TOOLCHAIN_HOST_TASK`:
1390 Lists packages that make up the host part of the SDK (i.e. the part
Andrew Geissler09036742021-06-25 14:25:14 -05001391 that runs on the :term:`SDKMACHINE`). When you use
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001392 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
1393 default packages apply. This variable allows you to add more
1394 packages.
1395
1396- :term:`TOOLCHAIN_TARGET_TASK`:
1397 Lists packages that make up the target part of the SDK (i.e. the part
1398 built for the target hardware).
1399
1400- :term:`SDKPATH`: Defines the
1401 default SDK installation path offered by the installation script.
1402
1403- :term:`SDK_HOST_MANIFEST`:
1404 Lists all the installed packages that make up the host part of the
1405 SDK. This variable also plays a minor role for extensible SDK
1406 development as well. However, it is mainly used for the standard SDK.
1407
1408- :term:`SDK_TARGET_MANIFEST`:
1409 Lists all the installed packages that make up the target part of the
1410 SDK. This variable also plays a minor role for extensible SDK
1411 development as well. However, it is mainly used for the standard SDK.
1412
1413Cross-Development Toolchain Generation
1414======================================
1415
1416The Yocto Project does most of the work for you when it comes to
Andrew Geissler09209ee2020-12-13 08:44:15 -06001417creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001418section provides some technical background on how cross-development
1419toolchains are created and used. For more information on toolchains, you
Andrew Geissler09209ee2020-12-13 08:44:15 -06001420can also see the :doc:`/sdk-manual/index` manual.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001421
1422In the Yocto Project development environment, cross-development
1423toolchains are used to build images and applications that run on the
1424target hardware. With just a few commands, the OpenEmbedded build system
1425creates these necessary toolchains for you.
1426
1427The following figure shows a high-level build environment regarding
1428toolchain construction and use.
1429
1430.. image:: figures/cross-development-toolchains.png
Andrew Geisslerd5838332022-05-27 11:33:10 -05001431 :width: 100%
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001432
1433Most of the work occurs on the Build Host. This is the machine used to
Patrick Williams975a06f2022-10-21 14:42:47 -05001434build images and generally work within the Yocto Project
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001435environment. When you run
1436:term:`BitBake` to create an image, the
1437OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a
1438cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what
1439BitBake uses to compile source files when creating the target image. You
1440can think of ``gcc-cross`` simply as an automatically generated
1441cross-compiler that is used internally within BitBake only.
1442
1443.. note::
1444
Andrew Geissler09036742021-06-25 14:25:14 -05001445 The extensible SDK does not use ``gcc-cross-canadian``
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001446 since this SDK ships a copy of the OpenEmbedded build system and the
Andrew Geissler09036742021-06-25 14:25:14 -05001447 sysroot within it contains ``gcc-cross``.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001448
Andrew Geisslerc926e172021-05-07 16:11:35 -05001449The chain of events that occurs when the standard toolchain is bootstrapped::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001450
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001451 binutils-cross -> linux-libc-headers -> gcc-cross -> libgcc-initial -> glibc -> libgcc -> gcc-runtime
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001452
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001453- ``gcc``: The compiler, GNU Compiler Collection (GCC).
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001454
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001455- ``binutils-cross``: The binary utilities needed in order
1456 to run the ``gcc-cross`` phase of the bootstrap operation and build the
1457 headers for the C library.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001458
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001459- ``linux-libc-headers``: Headers needed for the cross-compiler and C library build.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001460
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001461- ``libgcc-initial``: An initial version of the gcc support library needed
1462 to bootstrap ``glibc``.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001463
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001464- ``libgcc``: The final version of the gcc support library which
1465 can only be built once there is a C library to link against.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001466
1467- ``glibc``: The GNU C Library.
1468
1469- ``gcc-cross``: The final stage of the bootstrap process for the
1470 cross-compiler. This stage results in the actual cross-compiler that
1471 BitBake uses when it builds an image for a targeted device.
1472
Andrew Geissler6ce62a22020-11-30 19:58:47 -06001473 This tool is a "native" tool (i.e. it is designed to run on
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001474 the build host).
1475
1476- ``gcc-runtime``: Runtime libraries resulting from the toolchain
1477 bootstrapping process. This tool produces a binary that consists of
1478 the runtime libraries need for the targeted device.
1479
1480You can use the OpenEmbedded build system to build an installer for the
1481relocatable SDK used to develop applications. When you run the
1482installer, it installs the toolchain, which contains the development
1483tools (e.g., ``gcc-cross-canadian``, ``binutils-cross-canadian``, and
1484other ``nativesdk-*`` tools), which are tools native to the SDK (i.e.
1485native to :term:`SDK_ARCH`), you
1486need to cross-compile and test your software. The figure shows the
1487commands you use to easily build out this toolchain. This
1488cross-development toolchain is built to execute on the
1489:term:`SDKMACHINE`, which might or
1490might not be the same machine as the Build Host.
1491
1492.. note::
1493
1494 If your target architecture is supported by the Yocto Project, you
1495 can take advantage of pre-built images that ship with the Yocto
1496 Project and already contain cross-development toolchain installers.
1497
Andrew Geisslerc926e172021-05-07 16:11:35 -05001498Here is the bootstrap process for the relocatable toolchain::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001499
1500 gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian
1501
1502- ``gcc``: The build host's GNU Compiler Collection (GCC).
1503
1504- ``binutils-crosssdk``: The bare minimum binary utilities needed in
1505 order to run the ``gcc-crosssdk-initial`` phase of the bootstrap
1506 operation.
1507
1508- ``gcc-crosssdk-initial``: An early stage of the bootstrap process for
1509 creating the cross-compiler. This stage builds enough of the
1510 ``gcc-crosssdk`` and supporting pieces so that the final stage of the
1511 bootstrap process can produce the finished cross-compiler. This tool
1512 is a "native" binary that runs on the build host.
1513
1514- ``linux-libc-headers``: Headers needed for the cross-compiler.
1515
1516- ``glibc-initial``: An initial version of the Embedded GLIBC needed to
1517 bootstrap ``nativesdk-glibc``.
1518
1519- ``nativesdk-glibc``: The Embedded GLIBC needed to bootstrap the
1520 ``gcc-crosssdk``.
1521
1522- ``gcc-crosssdk``: The final stage of the bootstrap process for the
1523 relocatable cross-compiler. The ``gcc-crosssdk`` is a transitory
1524 compiler and never leaves the build host. Its purpose is to help in
1525 the bootstrap process to create the eventual ``gcc-cross-canadian``
1526 compiler, which is relocatable. This tool is also a "native" package
1527 (i.e. it is designed to run on the build host).
1528
1529- ``gcc-cross-canadian``: The final relocatable cross-compiler. When
1530 run on the :term:`SDKMACHINE`,
1531 this tool produces executable code that runs on the target device.
1532 Only one cross-canadian compiler is produced per architecture since
1533 they can be targeted at different processor optimizations using
1534 configurations passed to the compiler through the compile commands.
1535 This circumvents the need for multiple compilers and thus reduces the
1536 size of the toolchains.
1537
1538.. note::
1539
1540 For information on advantages gained when building a
1541 cross-development toolchain installer, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001542 ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001543 in the Yocto Project Application Development and the
1544 Extensible Software Development Kit (eSDK) manual.
1545
1546Shared State Cache
1547==================
1548
1549By design, the OpenEmbedded build system builds everything from scratch
1550unless :term:`BitBake` can determine
1551that parts do not need to be rebuilt. Fundamentally, building from
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001552scratch is attractive as it means all parts are built fresh and there is
1553no possibility of stale data that can cause problems. When
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001554developers hit problems, they typically default back to building from
Andrew Geissler595f6302022-01-24 19:11:47 +00001555scratch so they have a known state from the start.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001556
1557Building an image from scratch is both an advantage and a disadvantage
1558to the process. As mentioned in the previous paragraph, building from
1559scratch ensures that everything is current and starts from a known
1560state. However, building from scratch also takes much longer as it
1561generally means rebuilding things that do not necessarily need to be
1562rebuilt.
1563
1564The Yocto Project implements shared state code that supports incremental
1565builds. The implementation of the shared state code answers the
1566following questions that were fundamental roadblocks within the
1567OpenEmbedded incremental build support system:
1568
1569- What pieces of the system have changed and what pieces have not
1570 changed?
1571
1572- How are changed pieces of software removed and replaced?
1573
1574- How are pre-built components that do not need to be rebuilt from
1575 scratch used when they are available?
1576
1577For the first question, the build system detects changes in the "inputs"
1578to a given task by creating a checksum (or signature) of the task's
1579inputs. If the checksum changes, the system assumes the inputs have
1580changed and the task needs to be rerun. For the second question, the
1581shared state (sstate) code tracks which tasks add which output to the
1582build process. This means the output from a given task can be removed,
1583upgraded or otherwise manipulated. The third question is partly
1584addressed by the solution for the second question assuming the build
1585system can fetch the sstate objects from remote locations and install
1586them if they are deemed to be valid.
1587
1588.. note::
1589
1590 - The build system does not maintain
1591 :term:`PR` information as part of
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001592 the shared state packages. Consequently, there are considerations that
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001593 affect maintaining shared state feeds. For information on how the
Andrew Geissler09036742021-06-25 14:25:14 -05001594 build system works with packages and can track incrementing :term:`PR`
Andrew Geissler09209ee2020-12-13 08:44:15 -06001595 information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001596 section in the Yocto Project Development Tasks Manual.
1597
1598 - The code in the build system that supports incremental builds is
Andrew Geisslereff27472021-10-29 15:35:00 -05001599 complex. For techniques that help you work around issues
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001600 related to shared state code, see the
Andrew Geissler09209ee2020-12-13 08:44:15 -06001601 ":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 -05001602 and
Andrew Geissler09209ee2020-12-13 08:44:15 -06001603 ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001604 sections both in the Yocto Project Development Tasks Manual.
1605
1606The rest of this section goes into detail about the overall incremental
1607build architecture, the checksums (signatures), and shared state.
1608
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001609Overall Architecture
1610--------------------
1611
1612When determining what parts of the system need to be built, BitBake
1613works on a per-task basis rather than a per-recipe basis. You might
1614wonder why using a per-task basis is preferred over a per-recipe basis.
1615To help explain, consider having the IPK packaging backend enabled and
1616then switching to DEB. In this case, the
1617:ref:`ref-tasks-install` and
1618:ref:`ref-tasks-package` task outputs
1619are still valid. However, with a per-recipe approach, the build would
1620not include the ``.deb`` files. Consequently, you would have to
1621invalidate the whole build and rerun it. Rerunning everything is not the
1622best solution. Also, in this case, the core must be "taught" much about
1623specific tasks. This methodology does not scale well and does not allow
1624users to easily add new tasks in layers or as external recipes without
1625touching the packaged-staging core.
1626
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001627Checksums (Signatures)
1628----------------------
1629
1630The shared state code uses a checksum, which is a unique signature of a
1631task's inputs, to determine if a task needs to be run again. Because it
1632is a change in a task's inputs that triggers a rerun, the process needs
1633to detect all the inputs to a given task. For shell tasks, this turns
1634out to be fairly easy because the build process generates a "run" shell
1635script for each task and it is possible to create a checksum that gives
1636you a good idea of when the task's data changes.
1637
1638To complicate the problem, there are things that should not be included
1639in the checksum. First, there is the actual specific build path of a
Andrew Geissler615f2f12022-07-15 14:00:58 -05001640given task --- the :term:`WORKDIR`. It
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001641does not matter if the work directory changes because it should not
1642affect the output for target packages. Also, the build process has the
1643objective of making native or cross packages relocatable.
1644
1645.. note::
1646
1647 Both native and cross packages run on the
1648 build host. However, cross packages generate output for the target
1649 architecture.
1650
Andrew Geissler09036742021-06-25 14:25:14 -05001651The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic
1652approach for excluding the work directory is to set :term:`WORKDIR` to some
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001653fixed value and create the checksum for the "run" script.
1654
1655Another problem results from the "run" scripts containing functions that
1656might or might not get called. The incremental build solution contains
1657code that figures out dependencies between shell functions. This code is
1658used to prune the "run" scripts down to the minimum set, thereby
1659alleviating this problem and making the "run" scripts much more readable
1660as a bonus.
1661
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001662So far, there are solutions for shell scripts. What about Python tasks? The
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001663same approach applies even though these tasks are more difficult. The
1664process needs to figure out what variables a Python function accesses
1665and what functions it calls. Again, the incremental build solution
1666contains code that first figures out the variable and function
1667dependencies, and then creates a checksum for the data used as the input
1668to the task.
1669
Andrew Geissler09036742021-06-25 14:25:14 -05001670Like the :term:`WORKDIR` case, there can be situations where dependencies should be
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001671ignored. For these situations, you can instruct the build process to
Andrew Geisslerc926e172021-05-07 16:11:35 -05001672ignore a dependency by using a line like the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001673
1674 PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
1675
1676This example ensures that the :term:`PACKAGE_ARCHS` variable
1677does not depend on the value of :term:`MACHINE`, even if it does
1678reference it.
1679
1680Equally, there are cases where you need to add dependencies BitBake is
1681not able to find. You can accomplish this by using a line like the
Andrew Geisslerc926e172021-05-07 16:11:35 -05001682following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001683
1684 PACKAGE_ARCHS[vardeps] = "MACHINE"
1685
1686This example explicitly
Andrew Geissler09036742021-06-25 14:25:14 -05001687adds the :term:`MACHINE` variable as a dependency for :term:`PACKAGE_ARCHS`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001688
1689As an example, consider a case with in-line Python where BitBake is not
1690able to figure out dependencies. When running in debug mode (i.e. using
1691``-DDD``), BitBake produces output when it discovers something for which
1692it cannot figure out dependencies. The Yocto Project team has currently
1693not managed to cover those dependencies in detail and is aware of the
1694need to fix this situation.
1695
1696Thus far, this section has limited discussion to the direct inputs into
1697a task. Information based on direct inputs is referred to as the
1698"basehash" in the code. However, the question of a task's indirect
Andrew Geissler615f2f12022-07-15 14:00:58 -05001699inputs still exits --- items already built and present in the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001700:term:`Build Directory`. The checksum (or
1701signature) for a particular task needs to add the hashes of all the
1702tasks on which the particular task depends. Choosing which dependencies
Andrew Geissler595f6302022-01-24 19:11:47 +00001703to add is a policy decision. However, the effect is to generate a
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001704checksum that combines the basehash and the hashes of the task's
1705dependencies.
1706
William A. Kennington IIIac69b482021-06-02 12:28:27 -07001707At the code level, there are multiple ways by which both the basehash
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001708and the dependent task hashes can be influenced. Within the BitBake
1709configuration file, you can give BitBake some extra information to help
1710it construct the basehash. The following statement effectively results
1711in a list of global variable dependency excludes (i.e. variables never
Andrew Geisslerc926e172021-05-07 16:11:35 -05001712included in any checksum)::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001713
Andrew Geissler9aee5002022-03-30 16:27:02 +00001714 BB_BASEHASH_IGNORE_VARS ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \\
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001715 SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \\
1716 USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \\
1717 PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\
1718 CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
1719
Andrew Geissler595f6302022-01-24 19:11:47 +00001720The previous example does not include :term:`WORKDIR` since that variable is
1721actually constructed as a path within :term:`TMPDIR`, which is included above.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001722
1723The rules for deciding which hashes of dependent tasks to include
1724through dependency chains are more complex and are generally
1725accomplished with a Python function. The code in
1726``meta/lib/oe/sstatesig.py`` shows two examples of this and also
1727illustrates how you can insert your own policy into the system if so
1728desired. This file defines the two basic signature generators
1729:term:`OpenEmbedded-Core (OE-Core)` uses: "OEBasic" and
1730"OEBasicHash". By default, a dummy "noop" signature handler is enabled
1731in BitBake. This means that behavior is unchanged from previous
1732versions. OE-Core uses the "OEBasicHash" signature handler by default
Andrew Geisslerc926e172021-05-07 16:11:35 -05001733through this setting in the ``bitbake.conf`` file::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001734
1735 BB_SIGNATURE_HANDLER ?= "OEBasicHash"
1736
Andrew Geissler09036742021-06-25 14:25:14 -05001737The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001738as the "OEBasic" version but adds the task hash to the :ref:`stamp
1739files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
1740results in any metadata change that changes the task hash, automatically causing
1741the task to be run again. This removes the need to bump
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001742:term:`PR` values, and changes to metadata
1743automatically ripple across the build.
1744
1745It is also worth noting that the end result of these signature
1746generators is to make some dependency and hash information available to
1747the build. This information includes:
1748
Patrick Williams0ca19cc2021-08-16 14:03:13 -05001749- ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001750 recipe.
1751
1752- ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
1753 dependent task.
1754
Andrew Geissler09036742021-06-25 14:25:14 -05001755- :term:`BB_TASKHASH`: The hash of the currently running task.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001756
1757Shared State
1758------------
1759
1760Checksums and dependencies, as discussed in the previous section, solve
1761half the problem of supporting a shared state. The other half of the
1762problem is being able to use checksum information during the build and
1763being able to reuse or rebuild specific components.
1764
1765The :ref:`sstate <ref-classes-sstate>` class is a
1766relatively generic implementation of how to "capture" a snapshot of a
1767given task. The idea is that the build process does not care about the
1768source of a task's output. Output could be freshly built or it could be
1769downloaded and unpacked from somewhere. In other words, the build
1770process does not need to worry about its origin.
1771
1772Two types of output exist. One type is just about creating a directory
1773in :term:`WORKDIR`. A good example is
1774the output of either
1775:ref:`ref-tasks-install` or
1776:ref:`ref-tasks-package`. The other
1777type of output occurs when a set of data is merged into a shared
1778directory tree such as the sysroot.
1779
1780The Yocto Project team has tried to keep the details of the
Andrew Geissler595f6302022-01-24 19:11:47 +00001781implementation hidden in the :ref:`sstate <ref-classes-sstate>` class. From a user's perspective,
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001782adding shared state wrapping to a task is as simple as this
1783:ref:`ref-tasks-deploy` example taken
Andrew Geisslerc926e172021-05-07 16:11:35 -05001784from the :ref:`deploy <ref-classes-deploy>` class::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001785
1786 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
1787 SSTATETASKS += "do_deploy"
1788 do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
1789 do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
1790
1791 python do_deploy_setscene () {
1792 sstate_setscene(d)
1793 }
1794 addtask do_deploy_setscene
1795 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
1796 do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"
1797
1798The following list explains the previous example:
1799
Patrick Williams2194f502022-10-16 14:26:09 -05001800- Adding ``do_deploy`` to ``SSTATETASKS`` adds some required
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001801 sstate-related processing, which is implemented in the
1802 :ref:`sstate <ref-classes-sstate>` class, to
1803 before and after the
1804 :ref:`ref-tasks-deploy` task.
1805
1806- The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
Patrick Williams2194f502022-10-16 14:26:09 -05001807 :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001808 (i.e. when not using the sstate cache). This output becomes the input
1809 to the shared state cache.
1810
1811- The ``do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"`` line
1812 causes the contents of the shared state cache to be copied to
1813 ``${DEPLOY_DIR_IMAGE}``.
1814
1815 .. note::
1816
Patrick Williams2194f502022-10-16 14:26:09 -05001817 If :ref:`ref-tasks-deploy` is not already in the shared state cache or if its input
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001818 checksum (signature) has changed from when the output was cached, the task
1819 runs to populate the shared state cache, after which the contents of the
1820 shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If
Patrick Williams2194f502022-10-16 14:26:09 -05001821 :ref:`ref-tasks-deploy` is in the shared state cache and its signature indicates
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001822 that the cached output is still valid (i.e. if no relevant task inputs
1823 have changed), then the contents of the shared state cache copies
Andrew Geissler09036742021-06-25 14:25:14 -05001824 directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
Patrick Williams2194f502022-10-16 14:26:09 -05001825 instead, skipping the :ref:`ref-tasks-deploy` task.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001826
1827- The following task definition is glue logic needed to make the
Andrew Geisslerc926e172021-05-07 16:11:35 -05001828 previous settings effective::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001829
1830 python do_deploy_setscene () {
1831 sstate_setscene(d)
1832 }
1833 addtask do_deploy_setscene
1834
Patrick Williams2194f502022-10-16 14:26:09 -05001835 ``sstate_setscene()`` takes the flags above as input and accelerates the :ref:`ref-tasks-deploy` task
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001836 through the shared state cache if possible. If the task was
1837 accelerated, ``sstate_setscene()`` returns True. Otherwise, it
Patrick Williams2194f502022-10-16 14:26:09 -05001838 returns False, and the normal :ref:`ref-tasks-deploy` task runs. For more
Patrick Williams213cb262021-08-07 19:21:33 -05001839 information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001840 section in the BitBake User Manual.
1841
1842- The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates
Patrick Williams2194f502022-10-16 14:26:09 -05001843 ``${DEPLOYDIR}`` and ``${B}`` before the :ref:`ref-tasks-deploy` task runs, and
1844 also sets the current working directory of :ref:`ref-tasks-deploy` to ``${B}``.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001845 For more information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
1846 section in the BitBake
1847 User Manual.
1848
1849 .. note::
1850
1851 In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
1852 the same, you can use ``sstate-plaindirs``. For example, to preserve the
Patrick Williams2194f502022-10-16 14:26:09 -05001853 ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the :ref:`ref-tasks-package`
Andrew Geisslerc926e172021-05-07 16:11:35 -05001854 task, use the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001855
1856 do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
1857
1858
1859- The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends
Andrew Geissler3b8a17c2021-04-15 15:55:55 -05001860 extra metadata to the :ref:`stamp
1861 file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In
1862 this case, the metadata makes the task specific to a machine's architecture.
1863 See
Andrew Geissler09209ee2020-12-13 08:44:15 -06001864 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001865 section in the BitBake User Manual for more information on the
1866 ``stamp-extra-info`` flag.
1867
1868- ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with
1869 multiple directories. For example, the following declares
Andrew Geissler09036742021-06-25 14:25:14 -05001870 :term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories,
1871 which populates the shared state cache, and :term:`PKGDATA_DIR` and
Andrew Geisslerc926e172021-05-07 16:11:35 -05001872 ``SHLIBSDIR`` as the corresponding shared state output directories::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001873
1874 do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
1875 do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
1876
1877- These methods also include the ability to take a lockfile when
1878 manipulating shared state directory structures, for cases where file
Andrew Geisslerc926e172021-05-07 16:11:35 -05001879 additions or removals are sensitive::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001880
1881 do_package[sstate-lockfile] = "${PACKAGELOCK}"
1882
1883Behind the scenes, the shared state code works by looking in
1884:term:`SSTATE_DIR` and
1885:term:`SSTATE_MIRRORS` for
Andrew Geisslerc926e172021-05-07 16:11:35 -05001886shared state files. Here is an example::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001887
1888 SSTATE_MIRRORS ?= "\
Andrew Geissler7e0e3c02022-02-25 20:34:39 +00001889 file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
Patrick Williams93c203f2021-10-06 16:15:23 -05001890 file://.* file:///some/local/dir/sstate/PATH"
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001891
1892.. note::
1893
Andrew Geissler5f350902021-07-23 13:09:54 -04001894 The shared state directory (:term:`SSTATE_DIR`) is organized into two-character
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001895 subdirectories, where the subdirectory names are based on the first two
1896 characters of the hash.
1897 If the shared state directory structure for a mirror has the same structure
Andrew Geissler09036742021-06-25 14:25:14 -05001898 as :term:`SSTATE_DIR`, you must specify "PATH" as part of the URI to enable the build
Andrew Geisslerc9f78652020-09-18 14:11:35 -05001899 system to map to the appropriate subdirectory.
1900
1901The shared state package validity can be detected just by looking at the
1902filename since the filename contains the task checksum (or signature) as
1903described earlier in this section. If a valid shared state package is
1904found, the build process downloads it and uses it to accelerate the
1905task.
1906
1907The build processes use the ``*_setscene`` tasks for the task
1908acceleration phase. BitBake goes through this phase before the main
1909execution code and tries to accelerate any tasks for which it can find
1910shared state packages. If a shared state package for a task is
1911available, the shared state package is used. This means the task and any
1912tasks on which it is dependent are not executed.
1913
1914As a real world example, the aim is when building an IPK-based image,
1915only the
1916:ref:`ref-tasks-package_write_ipk`
1917tasks would have their shared state packages fetched and extracted.
1918Since the sysroot is not used, it would never get extracted. This is
1919another reason why a task-based approach is preferred over a
1920recipe-based approach, which would have to install the output from every
1921task.
1922
Andrew Geissler595f6302022-01-24 19:11:47 +00001923Hash Equivalence
1924----------------
1925
1926The above section explained how BitBake skips the execution of tasks
1927whose output can already be found in the Shared State cache.
1928
1929During a build, it may often be the case that the output / result of a task might
1930be unchanged despite changes in the task's input values. An example might be
1931whitespace changes in some input C code. In project terms, this is what we define
1932as "equivalence".
1933
1934To keep track of such equivalence, BitBake has to manage three hashes
1935for each task:
1936
1937- The *task hash* explained earlier: computed from the recipe metadata,
1938 the task code and the task hash values from its dependencies.
1939 When changes are made, these task hashes are therefore modified,
1940 causing the task to re-execute. The task hashes of tasks depending on this
1941 task are therefore modified too, causing the whole dependency
1942 chain to re-execute.
1943
1944- The *output hash*, a new hash computed from the output of Shared State tasks,
1945 tasks that save their resulting output to a Shared State tarball.
1946 The mapping between the task hash and its output hash is reported
1947 to a new *Hash Equivalence* server. This mapping is stored in a database
1948 by the server for future reference.
1949
1950- The *unihash*, a new hash, initially set to the task hash for the task.
1951 This is used to track the *unicity* of task output, and we will explain
1952 how its value is maintained.
1953
1954When Hash Equivalence is enabled, BitBake computes the task hash
1955for each task by using the unihash of its dependencies, instead
1956of their task hash.
1957
1958Now, imagine that a Shared State task is modified because of a change in
1959its code or metadata, or because of a change in its dependencies.
1960Since this modifies its task hash, this task will need re-executing.
1961Its output hash will therefore be computed again.
1962
1963Then, the new mapping between the new task hash and its output hash
1964will be reported to the Hash Equivalence server. The server will
1965let BitBake know whether this output hash is the same as a previously
1966reported output hash, for a different task hash.
1967
1968If the output hash is already known, BitBake will update the task's
1969unihash to match the original task hash that generated that output.
1970Thanks to this, the depending tasks will keep a previously recorded
1971task hash, and BitBake will be able to retrieve their output from
1972the Shared State cache, instead of re-executing them. Similarly, the
1973output of further downstream tasks can also be retrieved from Shared
1974Shate.
1975
1976If the output hash is unknown, a new entry will be created on the Hash
1977Equivalence server, matching the task hash to that output.
1978The depending tasks, still having a new task hash because of the
1979change, will need to re-execute as expected. The change propagates
1980to the depending tasks.
1981
1982To summarize, when Hash Equivalence is enabled, a change in one of the
1983tasks in BitBake's run queue doesn't have to propagate to all the
1984downstream tasks that depend on the output of this task, causing a
1985full rebuild of such tasks, and so on with the next depending tasks.
1986Instead, when the output of this task remains identical to previously
1987recorded output, BitBake can safely retrieve all the downstream
1988task output from the Shared State cache.
1989
1990.. note::
1991
1992 Having :doc:`/test-manual/reproducible-builds` is a key ingredient for
1993 the stability of the task's output hash. Therefore, the effectiveness
1994 of Hash Equivalence strongly depends on it.
1995
1996This applies to multiple scenarios:
1997
1998- A "trivial" change to a recipe that doesn't impact its generated output,
1999 such as whitespace changes, modifications to unused code paths or
2000 in the ordering of variables.
2001
2002- Shared library updates, for example to fix a security vulnerability.
2003 For sure, the programs using such a library should be rebuilt, but
2004 their new binaries should remain identical. The corresponding tasks should
2005 have a different output hash because of the change in the hash of their
2006 library dependency, but thanks to their output being identical, Hash
2007 Equivalence will stop the propagation down the dependency chain.
2008
2009- Native tool updates. Though the depending tasks should be rebuilt,
2010 it's likely that they will generate the same output and be marked
2011 as equivalent.
2012
2013This mechanism is enabled by default in Poky, and is controlled by three
2014variables:
2015
2016- :term:`bitbake:BB_HASHSERVE`, specifying a local or remote Hash
2017 Equivalence server to use.
2018
2019- :term:`BB_HASHSERVE_UPSTREAM`, when ``BB_HASHSERVE = "auto"``,
2020 allowing to connect the local server to an upstream one.
2021
2022- :term:`bitbake:BB_SIGNATURE_HANDLER`, which must be set to ``OEEquivHash``.
2023
2024Therefore, the default configuration in Poky corresponds to the
2025below settings::
2026
2027 BB_HASHSERVE = "auto"
2028 BB_SIGNATURE_HANDLER = "OEEquivHash"
2029
2030Rather than starting a local server, another possibility is to rely
2031on a Hash Equivalence server on a network, by setting::
2032
2033 BB_HASHSERVE = "<HOSTNAME>:<PORT>"
2034
2035.. note::
2036
2037 The shared Hash Equivalence server needs to be maintained together with the
2038 Shared State cache. Otherwise, the server could report Shared State hashes
2039 that only exist on specific clients.
2040
2041 We therefore recommend that one Hash Equivalence server be set up to
2042 correspond with a given Shared State cache, and to start this server
2043 in *read-only mode*, so that it doesn't store equivalences for
2044 Shared State caches that are local to clients.
2045
2046 See the :term:`BB_HASHSERVE` reference for details about starting
2047 a Hash Equivalence server.
2048
2049See the `video <https://www.youtube.com/watch?v=zXEdqGS62Wc>`__
2050of Joshua Watt's `Hash Equivalence and Reproducible Builds
2051<https://elinux.org/images/3/37/Hash_Equivalence_and_Reproducible_Builds.pdf>`__
2052presentation at ELC 2020 for a very synthetic introduction to the
2053Hash Equivalence implementation in the Yocto Project.
2054
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002055Automatically Added Runtime Dependencies
2056========================================
2057
2058The OpenEmbedded build system automatically adds common types of runtime
2059dependencies between packages, which means that you do not need to
2060explicitly declare the packages using
William A. Kennington IIIac69b482021-06-02 12:28:27 -07002061:term:`RDEPENDS`. There are three automatic
2062mechanisms (``shlibdeps``, ``pcdeps``, and ``depchains``) that
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002063handle shared libraries, package configuration (pkg-config) modules, and
2064``-dev`` and ``-dbg`` packages, respectively. For other types of runtime
2065dependencies, you must manually declare the dependencies.
2066
2067- ``shlibdeps``: During the
2068 :ref:`ref-tasks-package` task of
2069 each recipe, all shared libraries installed by the recipe are
2070 located. For each shared library, the package that contains the
2071 shared library is registered as providing the shared library. More
2072 specifically, the package is registered as providing the
2073 `soname <https://en.wikipedia.org/wiki/Soname>`__ of the library. The
2074 resulting shared-library-to-package mapping is saved globally in
2075 :term:`PKGDATA_DIR` by the
2076 :ref:`ref-tasks-packagedata`
2077 task.
2078
2079 Simultaneously, all executables and shared libraries installed by the
2080 recipe are inspected to see what shared libraries they link against.
Andrew Geissler09036742021-06-25 14:25:14 -05002081 For each shared library dependency that is found, :term:`PKGDATA_DIR` is
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002082 queried to see if some package (likely from a different recipe)
2083 contains the shared library. If such a package is found, a runtime
2084 dependency is added from the package that depends on the shared
2085 library to the package that contains the library.
2086
2087 The automatically added runtime dependency also includes a version
2088 restriction. This version restriction specifies that at least the
2089 current version of the package that provides the shared library must
Andrew Geissler09036742021-06-25 14:25:14 -05002090 be used, as if "package (>= version)" had been added to :term:`RDEPENDS`.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002091 This forces an upgrade of the package containing the shared library
2092 when installing the package that depends on the library, if needed.
2093
2094 If you want to avoid a package being registered as providing a
2095 particular shared library (e.g. because the library is for internal
2096 use only), then add the library to
2097 :term:`PRIVATE_LIBS` inside
2098 the package's recipe.
2099
Patrick Williams2194f502022-10-16 14:26:09 -05002100- ``pcdeps``: During the :ref:`ref-tasks-package` task of each recipe, all
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002101 pkg-config modules (``*.pc`` files) installed by the recipe are
2102 located. For each module, the package that contains the module is
2103 registered as providing the module. The resulting module-to-package
Andrew Geissler09036742021-06-25 14:25:14 -05002104 mapping is saved globally in :term:`PKGDATA_DIR` by the
Patrick Williams2194f502022-10-16 14:26:09 -05002105 :ref:`ref-tasks-packagedata` task.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002106
2107 Simultaneously, all pkg-config modules installed by the recipe are
2108 inspected to see what other pkg-config modules they depend on. A
2109 module is seen as depending on another module if it contains a
2110 "Requires:" line that specifies the other module. For each module
Andrew Geissler09036742021-06-25 14:25:14 -05002111 dependency, :term:`PKGDATA_DIR` is queried to see if some package
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002112 contains the module. If such a package is found, a runtime dependency
2113 is added from the package that depends on the module to the package
2114 that contains the module.
2115
2116 .. note::
2117
2118 The
2119 pcdeps
2120 mechanism most often infers dependencies between
2121 -dev
2122 packages.
2123
2124- ``depchains``: If a package ``foo`` depends on a package ``bar``,
2125 then ``foo-dev`` and ``foo-dbg`` are also made to depend on
2126 ``bar-dev`` and ``bar-dbg``, respectively. Taking the ``-dev``
2127 packages as an example, the ``bar-dev`` package might provide headers
2128 and shared library symlinks needed by ``foo-dev``, which shows the
2129 need for a dependency between the packages.
2130
2131 The dependencies added by ``depchains`` are in the form of
2132 :term:`RRECOMMENDS`.
2133
2134 .. note::
2135
Andrew Geissler5f350902021-07-23 13:09:54 -04002136 By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
Patrick Williams0ca19cc2021-08-16 14:03:13 -05002137 ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
Andrew Geisslerd5838332022-05-27 11:33:10 -05002138 ``bitbake.conf``) includes "${PN}".
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002139
2140 To ensure that the dependency chain is never broken, ``-dev`` and
2141 ``-dbg`` packages are always generated by default, even if the
2142 packages turn out to be empty. See the
2143 :term:`ALLOW_EMPTY` variable
2144 for more information.
2145
Patrick Williams2194f502022-10-16 14:26:09 -05002146The :ref:`ref-tasks-package` task depends on the :ref:`ref-tasks-packagedata` task of each
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002147recipe in :term:`DEPENDS` through use
2148of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
2149declaration, which guarantees that the required
2150shared-library/module-to-package mapping information will be available
Andrew Geissler09036742021-06-25 14:25:14 -05002151when needed as long as :term:`DEPENDS` has been correctly set.
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002152
2153Fakeroot and Pseudo
2154===================
2155
2156Some tasks are easier to implement when allowed to perform certain
2157operations that are normally reserved for the root user (e.g.
2158:ref:`ref-tasks-install`,
2159:ref:`do_package_write* <ref-tasks-package_write_deb>`,
2160:ref:`ref-tasks-rootfs`, and
Patrick Williams2194f502022-10-16 14:26:09 -05002161:ref:`do_image_* <ref-tasks-image>`). For example,
2162the :ref:`ref-tasks-install` task benefits from being able to set the UID and GID
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002163of installed files to arbitrary values.
2164
2165One approach to allowing tasks to perform root-only operations would be
2166to require :term:`BitBake` to run as
2167root. However, this method is cumbersome and has security issues. The
2168approach that is actually used is to run tasks that benefit from root
2169privileges in a "fake" root environment. Within this environment, the
2170task and its child processes believe that they are running as the root
2171user, and see an internally consistent view of the filesystem. As long
2172as generating the final output (e.g. a package or an image) does not
2173require root privileges, the fact that some earlier steps ran in a fake
2174root environment does not cause problems.
2175
2176The capability to run tasks in a fake root environment is known as
2177"`fakeroot <http://man.he.net/man1/fakeroot>`__", which is derived from
2178the BitBake keyword/variable flag that requests a fake root environment
2179for a task.
2180
Andrew Geisslerd1e89492021-02-12 15:35:20 -06002181In the :term:`OpenEmbedded Build System`, the program that implements
2182fakeroot is known as :yocto_home:`Pseudo </software-item/pseudo/>`. Pseudo
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002183overrides system calls by using the environment variable ``LD_PRELOAD``,
2184which results in the illusion of running as root. To keep track of
2185"fake" file ownership and permissions resulting from operations that
2186require root permissions, Pseudo uses an SQLite 3 database. This
2187database is stored in
2188``${``\ :term:`WORKDIR`\ ``}/pseudo/files.db``
2189for individual recipes. Storing the database in a file as opposed to in
2190memory gives persistence between tasks and builds, which is not
2191accomplished using fakeroot.
2192
2193.. note::
2194
2195 If you add your own task that manipulates the same files or
2196 directories as a fakeroot task, then that task also needs to run
2197 under fakeroot. Otherwise, the task cannot run root-only operations,
2198 and cannot see the fake file ownership and permissions set by the
2199 other task. You need to also add a dependency on
Andrew Geisslerc926e172021-05-07 16:11:35 -05002200 ``virtual/fakeroot-native:do_populate_sysroot``, giving the following::
Andrew Geisslerc9f78652020-09-18 14:11:35 -05002201
2202 fakeroot do_mytask () {
2203 ...
2204 }
2205 do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"
2206
2207
2208For more information, see the
2209:term:`FAKEROOT* <bitbake:FAKEROOT>` variables in the
2210BitBake User Manual. You can also reference the "`Why Not
2211Fakeroot? <https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot>`__"
2212article for background information on Fakeroot and Pseudo.