summaryrefslogtreecommitdiffstats
path: root/documentation/overview-manual/overview-manual-concepts.rst
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/overview-manual/overview-manual-concepts.rst')
-rw-r--r--documentation/overview-manual/overview-manual-concepts.rst66
1 files changed, 33 insertions, 33 deletions
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index 59096fbebf..9764b25b6d 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -6,8 +6,8 @@ Yocto Project Concepts
6 6
7This chapter provides explanations for Yocto Project concepts that go 7This chapter provides explanations for Yocto Project concepts that go
8beyond the surface of "how-to" information and reference (or look-up) 8beyond the surface of "how-to" information and reference (or look-up)
9material. Concepts such as components, the `OpenEmbedded build 9material. Concepts such as components, the :term:`OpenEmbedded Build System`
10system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ workflow, 10workflow,
11cross-development toolchains, shared state cache, and so forth are 11cross-development toolchains, shared state cache, and so forth are
12explained. 12explained.
13 13
@@ -48,8 +48,8 @@ Concepts <#openembedded-build-system-build-concepts>`__" section.
48BitBake 48BitBake
49------- 49-------
50 50
51BitBake is the tool at the heart of the `OpenEmbedded build 51BitBake is the tool at the heart of the :term:`OpenEmbedded Build System`
52system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible 52and is responsible
53for parsing the :term:`Metadata`, generating 53for parsing the :term:`Metadata`, generating
54a list of tasks from it, and then executing those tasks. 54a list of tasks from it, and then executing those tasks.
55 55
@@ -109,7 +109,7 @@ Class files (``.bbclass``) contain information that is useful to share
109between recipes files. An example is the 109between recipes files. An example is the
110:ref:`autotools <ref-classes-autotools>` class, 110:ref:`autotools <ref-classes-autotools>` class,
111which contains common settings for any application that Autotools uses. 111which contains common settings for any application that Autotools uses.
112The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the 112The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
113Yocto Project Reference Manual provides details about classes and how to 113Yocto Project Reference Manual provides details about classes and how to
114use them. 114use them.
115 115
@@ -123,8 +123,8 @@ variables that govern the OpenEmbedded build process. These files fall
123into several areas that define machine configuration options, 123into several areas that define machine configuration options,
124distribution configuration options, compiler tuning options, general 124distribution configuration options, compiler tuning options, general
125common configuration options, and user configuration options in 125common configuration options, and user configuration options in
126``conf/local.conf``, which is found in the `Build 126``conf/local.conf``, which is found in the :term:`Build Directory`.
127Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 127
128 128
129.. _overview-layers: 129.. _overview-layers:
130 130
@@ -164,8 +164,8 @@ OpenEmbedded Build System Concepts
164================================== 164==================================
165 165
166This section takes a more detailed look inside the build process used by 166This section takes a more detailed look inside the build process used by
167the `OpenEmbedded build 167the :term:`OpenEmbedded Build System`,
168system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which is the build 168which is the build
169system specific to the Yocto Project. At the heart of the build system 169system specific to the Yocto Project. At the heart of the build system
170is BitBake, the task executor. 170is BitBake, the task executor.
171 171
@@ -221,8 +221,8 @@ figure <#general-workflow-figure>`__:
221 221
222BitBake needs some basic configuration files in order to complete a 222BitBake needs some basic configuration files in order to complete a
223build. These files are ``*.conf`` files. The minimally necessary ones 223build. These files are ``*.conf`` files. The minimally necessary ones
224reside as example files in the ``build/conf`` directory of the `Source 224reside as example files in the ``build/conf`` directory of the
225Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For simplicity, 225:term:`Source Directory`. For simplicity,
226this section refers to the Source Directory as the "Poky Directory." 226this section refers to the Source Directory as the "Poky Directory."
227 227
228When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository 228When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository
@@ -241,8 +241,8 @@ for creating actual configuration files when you source
241````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the 241````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the
242build environment script. 242build environment script.
243 243
244Sourcing the build environment script creates a `Build 244Sourcing the build environment script creates a
245Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ if one does not 245:term:`Build Directory` if one does not
246already exist. BitBake uses the Build Directory for all its work during 246already exist. BitBake uses the Build Directory for all its work during
247builds. The Build Directory has a ``conf`` directory that contains 247builds. The Build Directory has a ``conf`` directory that contains
248default versions of your ``local.conf`` and ``bblayers.conf`` 248default versions of your ``local.conf`` and ``bblayers.conf``
@@ -357,8 +357,8 @@ Configuration Edits" box in the figure.
357 357
358When you launch your build with the ``bitbake target`` command, BitBake 358When you launch your build with the ``bitbake target`` command, BitBake
359sorts out the configurations to ultimately define your build 359sorts out the configurations to ultimately define your build
360environment. It is important to understand that the `OpenEmbedded build 360environment. It is important to understand that the
361system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ reads the 361:term:`OpenEmbedded Build System` reads the
362configuration files in a specific order: ``site.conf``, ``auto.conf``, 362configuration files in a specific order: ``site.conf``, ``auto.conf``,
363and ``local.conf``. And, the build system applies the normal assignment 363and ``local.conf``. And, the build system applies the normal assignment
364statement rules as described in the "`Syntax and 364statement rules as described in the "`Syntax and
@@ -460,7 +460,7 @@ typically find in the distribution layer:
460 can be shared among recipes in the distribution. When your recipes 460 can be shared among recipes in the distribution. When your recipes
461 inherit a class, they take on the settings and functions for that 461 inherit a class, they take on the settings and functions for that
462 class. You can read more about class files in the 462 class. You can read more about class files in the
463 "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter of the Yocto 463 ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
464 Reference Manual. 464 Reference Manual.
465 465
466- *conf:* This area holds configuration files for the layer 466- *conf:* This area holds configuration files for the layer
@@ -643,8 +643,8 @@ Package Feeds
643------------- 643-------------
644 644
645When the OpenEmbedded build system generates an image or an SDK, it gets 645When the OpenEmbedded build system generates an image or an SDK, it gets
646the packages from a package feed area located in the `Build 646the packages from a package feed area located in the
647Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The `general 647:term:`Build Directory`. The `general
648workflow figure <#general-workflow-figure>`__ shows this package feeds 648workflow figure <#general-workflow-figure>`__ shows this package feeds
649area in the upper-right corner. 649area in the upper-right corner.
650 650
@@ -687,7 +687,7 @@ package files are kept:
687 for the i586 or qemux86 architectures. 687 for the i586 or qemux86 architectures.
688 688
689BitBake uses the 689BitBake uses the
690```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ 690:ref:`do_package_write_* <ref-tasks-package_write_deb>`
691tasks to generate packages and place them into the package holding area 691tasks to generate packages and place them into the package holding area
692(e.g. ``do_package_write_ipk`` for IPK packages). See the 692(e.g. ``do_package_write_ipk`` for IPK packages). See the
693":ref:`ref-tasks-package_write_deb`", 693":ref:`ref-tasks-package_write_deb`",
@@ -733,8 +733,8 @@ code:
733 733
734The :ref:`ref-tasks-fetch` and 734The :ref:`ref-tasks-fetch` and
735:ref:`ref-tasks-unpack` tasks fetch 735:ref:`ref-tasks-unpack` tasks fetch
736the source files and unpack them into the `Build 736the source files and unpack them into the
737Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 737:term:`Build Directory`.
738 738
739.. note:: 739.. note::
740 740
@@ -984,7 +984,7 @@ details on how this is accomplished, you can look at
984```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__. 984```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__.
985 985
986Depending on the type of packages being created (RPM, DEB, or IPK), the 986Depending on the type of packages being created (RPM, DEB, or IPK), the
987```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ 987:ref:`do_package_write_* <ref-tasks-package_write_deb>`
988task creates the actual packages and places them in the Package Feed 988task creates the actual packages and places them in the Package Feed
989area, which is ``${TMPDIR}/deploy``. You can see the "`Package 989area, which is ``${TMPDIR}/deploy``. You can see the "`Package
990Feeds <#package-feeds-dev-environment>`__" section for more detail on 990Feeds <#package-feeds-dev-environment>`__" section for more detail on
@@ -1067,7 +1067,7 @@ processing includes creation of a manifest file and optimizations.
1067The manifest file (``.manifest``) resides in the same directory as the 1067The manifest file (``.manifest``) resides in the same directory as the
1068root filesystem image. This file lists out, line-by-line, the installed 1068root filesystem image. This file lists out, line-by-line, the installed
1069packages. The manifest file is useful for the 1069packages. The manifest file is useful for the
1070```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class, 1070:ref:`testimage <ref-classes-testimage*>` class,
1071for example, to determine whether or not to run specific tests. See the 1071for example, to determine whether or not to run specific tests. See the
1072:term:`IMAGE_MANIFEST` 1072:term:`IMAGE_MANIFEST`
1073variable for additional information. 1073variable for additional information.
@@ -1102,7 +1102,7 @@ as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically
1102generated task would be as follows: do_image_ext4 1102generated task would be as follows: do_image_ext4
1103 1103
1104The final task involved in image creation is the 1104The final task involved in image creation is the
1105```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__ 1105:ref:`do_image_complete <ref-tasks-image-complete>`
1106task. This task completes the image by applying any image post 1106task. This task completes the image by applying any image post
1107processing as defined through the 1107processing as defined through the
1108:term:`IMAGE_POSTPROCESS_COMMAND` 1108:term:`IMAGE_POSTPROCESS_COMMAND`
@@ -1242,7 +1242,7 @@ version of the task where instead of building something, BitBake can
1242skip to the end result and simply place a set of files into specific 1242skip to the end result and simply place a set of files into specific
1243locations as needed. In some cases, it makes sense to have a setscene 1243locations as needed. In some cases, it makes sense to have a setscene
1244task variant (e.g. generating package files in the 1244task variant (e.g. generating package files in the
1245```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ 1245:ref:`do_package_write_* <ref-tasks-package_write_deb>`
1246task). In other cases, it does not make sense (e.g. a 1246task). In other cases, it does not make sense (e.g. a
1247:ref:`ref-tasks-patch` task or a 1247:ref:`ref-tasks-patch` task or a
1248:ref:`ref-tasks-unpack` task) since 1248:ref:`ref-tasks-unpack` task) since
@@ -1317,8 +1317,8 @@ this output:
1317 Images 1317 Images
1318 " chapter in the Yocto Project Reference Manual. 1318 " chapter in the Yocto Project Reference Manual.
1319 1319
1320The build process writes images out to the `Build 1320The build process writes images out to the :term:`Build Directory`
1321Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the 1321inside the
1322``tmp/deploy/images/machine/`` folder as shown in the figure. This 1322``tmp/deploy/images/machine/`` folder as shown in the figure. This
1323folder contains any files expected to be loaded on the target device. 1323folder contains any files expected to be loaded on the target device.
1324The :term:`DEPLOY_DIR` variable 1324The :term:`DEPLOY_DIR` variable
@@ -1775,8 +1775,8 @@ need to fix this situation.
1775Thus far, this section has limited discussion to the direct inputs into 1775Thus far, this section has limited discussion to the direct inputs into
1776a task. Information based on direct inputs is referred to as the 1776a task. Information based on direct inputs is referred to as the
1777"basehash" in the code. However, the question of a task's indirect 1777"basehash" in the code. However, the question of a task's indirect
1778inputs still exits - items already built and present in the `Build 1778inputs still exits - items already built and present in the
1779Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The checksum (or 1779:term:`Build Directory`. The checksum (or
1780signature) for a particular task needs to add the hashes of all the 1780signature) for a particular task needs to add the hashes of all the
1781tasks on which the particular task depends. Choosing which dependencies 1781tasks on which the particular task depends. Choosing which dependencies
1782to add is a policy decision. However, the effect is to generate a master 1782to add is a policy decision. However, the effect is to generate a master
@@ -2117,9 +2117,9 @@ Fakeroot and Pseudo
2117Some tasks are easier to implement when allowed to perform certain 2117Some tasks are easier to implement when allowed to perform certain
2118operations that are normally reserved for the root user (e.g. 2118operations that are normally reserved for the root user (e.g.
2119:ref:`ref-tasks-install`, 2119:ref:`ref-tasks-install`,
2120```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__, 2120:ref:`do_package_write* <ref-tasks-package_write_deb>`,
2121:ref:`ref-tasks-rootfs`, and 2121:ref:`ref-tasks-rootfs`, and
2122```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example, 2122:ref:`do_image* <ref-tasks-image>`). For example,
2123the ``do_install`` task benefits from being able to set the UID and GID 2123the ``do_install`` task benefits from being able to set the UID and GID
2124of installed files to arbitrary values. 2124of installed files to arbitrary values.
2125 2125
@@ -2139,8 +2139,8 @@ The capability to run tasks in a fake root environment is known as
2139the BitBake keyword/variable flag that requests a fake root environment 2139the BitBake keyword/variable flag that requests a fake root environment
2140for a task. 2140for a task.
2141 2141
2142In the `OpenEmbedded build 2142In the :term:`OpenEmbedded Build System`,
2143system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, the program that 2143the program that
2144implements fakeroot is known as 2144implements fakeroot is known as
2145`Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo 2145`Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo
2146overrides system calls by using the environment variable ``LD_PRELOAD``, 2146overrides system calls by using the environment variable ``LD_PRELOAD``,