summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--documentation/adt-manual/adt-command.rst4
-rw-r--r--documentation/adt-manual/adt-intro.rst14
-rw-r--r--documentation/adt-manual/adt-package.rst2
-rw-r--r--documentation/adt-manual/adt-prepare.rst29
-rw-r--r--documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst12
-rw-r--r--documentation/bsp-guide/bsp.rst30
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.rst173
-rw-r--r--documentation/dev-manual/dev-manual-qemu.rst8
-rw-r--r--documentation/dev-manual/dev-manual-start.rst7
-rw-r--r--documentation/kernel-dev/kernel-dev-common.rst31
-rw-r--r--documentation/kernel-dev/kernel-dev-concepts-appx.rst4
-rw-r--r--documentation/kernel-dev/kernel-dev-maint-appx.rst4
-rw-r--r--documentation/overview-manual/overview-manual-concepts.rst66
-rw-r--r--documentation/overview-manual/overview-manual-development-environment.rst16
-rw-r--r--documentation/overview-manual/overview-manual-yp-intro.rst27
-rw-r--r--documentation/ref-manual/faq.rst11
-rw-r--r--documentation/ref-manual/migration.rst12
-rw-r--r--documentation/ref-manual/ref-classes.rst20
-rw-r--r--documentation/ref-manual/ref-images.rst4
-rw-r--r--documentation/ref-manual/ref-release-process.rst2
-rw-r--r--documentation/ref-manual/ref-structure.rst15
-rw-r--r--documentation/ref-manual/ref-system-requirements.rst4
-rw-r--r--documentation/ref-manual/ref-tasks.rst2
-rw-r--r--documentation/ref-manual/ref-terms.rst4
-rw-r--r--documentation/ref-manual/ref-variables.rst117
-rw-r--r--documentation/sdk-manual/sdk-appendix-customizing.rst8
-rw-r--r--documentation/sdk-manual/sdk-appendix-obtain.rst8
-rw-r--r--documentation/sdk-manual/sdk-extensible.rst4
-rw-r--r--documentation/sdk-manual/sdk-intro.rst10
-rw-r--r--documentation/sdk-manual/sdk-working-projects.rst3
-rw-r--r--documentation/toaster-manual/toaster-manual-intro.rst4
-rw-r--r--documentation/toaster-manual/toaster-manual-reference.rst8
-rw-r--r--documentation/toaster-manual/toaster-manual-setup-and-use.rst8
-rw-r--r--documentation/toaster-manual/toaster-manual-start.rst4
34 files changed, 327 insertions, 348 deletions
diff --git a/documentation/adt-manual/adt-command.rst b/documentation/adt-manual/adt-command.rst
index 8b86544f19..de854772bb 100644
--- a/documentation/adt-manual/adt-command.rst
+++ b/documentation/adt-manual/adt-command.rst
@@ -6,8 +6,8 @@ Using the Command Line
6 6
7Recall that earlier the manual discussed how to use an existing 7Recall that earlier the manual discussed how to use an existing
8toolchain tarball that had been installed into the default installation 8toolchain tarball that had been installed into the default installation
9directory, ``/opt/poky/DISTRO``, which is outside of the `Build 9directory, ``/opt/poky/DISTRO``, which is outside of the :term:`Build Directory`
10Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ (see the section 10(see the section
11"`Using a Cross-Toolchain 11"`Using a Cross-Toolchain
12Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing 12Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing
13your architecture-specific environment setup script initializes a 13your architecture-specific environment setup script initializes a
diff --git a/documentation/adt-manual/adt-intro.rst b/documentation/adt-manual/adt-intro.rst
index 40612bdddf..d6228ad864 100644
--- a/documentation/adt-manual/adt-intro.rst
+++ b/documentation/adt-manual/adt-intro.rst
@@ -12,8 +12,8 @@ application.
12Fundamentally, the ADT consists of the following: 12Fundamentally, the ADT consists of the following:
13 13
14- An architecture-specific cross-toolchain and matching sysroot both 14- An architecture-specific cross-toolchain and matching sysroot both
15 built by the `OpenEmbedded build 15 built by the :term:`OpenEmbedded Build System`.
16 system <&YOCTO_DOCS_DEV_URL;#build-system-term>`__. The toolchain and 16 The toolchain and
17 sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__ 17 sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__
18 configuration and extensions, which allows you to cross-develop on 18 configuration and extensions, which allows you to cross-develop on
19 the host machine for the target hardware. 19 the host machine for the target hardware.
@@ -33,8 +33,8 @@ Toolchain <&YOCTO_DOCS_DEV_URL;#cross-development-toolchain>`__ consists
33of a cross-compiler, cross-linker, and cross-debugger that are used to 33of a cross-compiler, cross-linker, and cross-debugger that are used to
34develop user-space applications for targeted hardware. This toolchain is 34develop user-space applications for targeted hardware. This toolchain is
35created either by running the ADT Installer script, a toolchain 35created either by running the ADT Installer script, a toolchain
36installer script, or through a `Build 36installer script, or through a :term:`Build Directory`
37Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ that is based on 37that is based on
38your Metadata configuration or extension for your targeted device. The 38your Metadata configuration or extension for your targeted device. The
39cross-toolchain works with a matching target sysroot. 39cross-toolchain works with a matching target sysroot.
40 40
@@ -79,13 +79,13 @@ your application or image. QEMU is made available a number of ways:
79- If you use the ADT Installer script to install ADT, you can specify 79- If you use the ADT Installer script to install ADT, you can specify
80 whether or not to install QEMU. 80 whether or not to install QEMU.
81 81
82- If you have cloned the ``poky`` Git repository to create a `Source 82- If you have cloned the ``poky`` Git repository to create a
83 Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__ and you have 83 :term:`Source Directory` and you have
84 sourced the environment setup script, QEMU is installed and 84 sourced the environment setup script, QEMU is installed and
85 automatically available. 85 automatically available.
86 86
87- If you have downloaded a Yocto Project release and unpacked it to 87- If you have downloaded a Yocto Project release and unpacked it to
88 create a `Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__ 88 create a :term:`Source Directory`
89 and you have sourced the environment setup script, QEMU is installed 89 and you have sourced the environment setup script, QEMU is installed
90 and automatically available. 90 and automatically available.
91 91
diff --git a/documentation/adt-manual/adt-package.rst b/documentation/adt-manual/adt-package.rst
index 38823a104f..dfa62163b3 100644
--- a/documentation/adt-manual/adt-package.rst
+++ b/documentation/adt-manual/adt-package.rst
@@ -59,7 +59,7 @@ add it into a working ``opkg`` repository. Use these commands: $ bitbake
59libglade $ bitbake package-index 59libglade $ bitbake package-index
60 60
61Next, source the cross-toolchain environment setup script found in the 61Next, source the cross-toolchain environment setup script found in the
62`Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__. Follow 62:term:`Source Directory`. Follow
63that by setting up the installation destination to point to your sysroot 63that by setting up the installation destination to point to your sysroot
64as sysroot_dir. Finally, have an OPKG configuration file conf_file that 64as sysroot_dir. Finally, have an OPKG configuration file conf_file that
65corresponds to the ``opkg`` repository you have just created. The 65corresponds to the ``opkg`` repository you have just created. The
diff --git a/documentation/adt-manual/adt-prepare.rst b/documentation/adt-manual/adt-prepare.rst
index 12b1e7918c..27133d21b4 100644
--- a/documentation/adt-manual/adt-prepare.rst
+++ b/documentation/adt-manual/adt-prepare.rst
@@ -50,7 +50,7 @@ for more information.
50 other mentioned benefits had you run the ADT Installer script. 50 other mentioned benefits had you run the ADT Installer script.
51 51
52- *Use the toolchain from within the Build Directory:* If you already 52- *Use the toolchain from within the Build Directory:* If you already
53 have a `Build Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__, 53 have a :term:`Build Directory`,
54 you can build the cross-toolchain within the directory. However, like 54 you can build the cross-toolchain within the directory. However, like
55 the previous method mentioned, you only get the cross-toolchain and 55 the previous method mentioned, you only get the cross-toolchain and
56 QEMU - you do not get any of the other benefits without taking 56 QEMU - you do not get any of the other benefits without taking
@@ -79,9 +79,8 @@ the tarball using either of these methods:
79 ` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory. 79 ` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory.
80 80
81- *Build the Tarball:* You can use 81- *Build the Tarball:* You can use
82 `BitBake <&YOCTO_DOCS_DEV_URL;#bitbake-term>`__ to generate the 82 :term:`BitBake` to generate the
83 tarball inside an existing `Build 83 tarball inside an existing :term:`Build Directory`.
84 Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__.
85 84
86 If you use BitBake to generate the ADT Installer tarball, you must 85 If you use BitBake to generate the ADT Installer tarball, you must
87 ``source`` the environment setup script 86 ``source`` the environment setup script
@@ -90,8 +89,8 @@ the tarball using either of these methods:
90 located in the Source Directory before running the ``bitbake`` 89 located in the Source Directory before running the ``bitbake``
91 command that creates the tarball. 90 command that creates the tarball.
92 91
93 The following example commands establish the `Source 92 The following example commands establish the
94 Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__, check out the 93 :term:`Source Directory`, check out the
95 current release branch, set up the build environment while also 94 current release branch, set up the build environment while also
96 creating the default Build Directory, and run the ``bitbake`` command 95 creating the default Build Directory, and run the ``bitbake`` command
97 that results in the tarball 96 that results in the tarball
@@ -268,8 +267,8 @@ Using BitBake and the Build Directory
268------------------------------------- 267-------------------------------------
269 268
270A final way of making the cross-toolchain available is to use BitBake to 269A final way of making the cross-toolchain available is to use BitBake to
271generate the toolchain within an existing `Build 270generate the toolchain within an existing :term:`Build Directory`.
272Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__. This method does 271This method does
273not install the toolchain into the default ``/opt`` directory. As with 272not install the toolchain into the default ``/opt`` directory. As with
274the previous method, if you need to install the target sysroot, you must 273the previous method, if you need to install the target sysroot, you must
275do that separately as well. 274do that separately as well.
@@ -280,8 +279,7 @@ Follow these steps to generate the toolchain into the Build Directory:
280 environment setup script (i.e. 279 environment setup script (i.e.
281 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or 280 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
282 ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__) 281 ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
283 located in the `Source 282 located in the :term:`Source Directory`.
284 Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__.
285 283
2862. *Check your Local Configuration File:* At this point, you should be 2842. *Check your Local Configuration File:* At this point, you should be
287 sure that the :term:`MACHINE` 285 sure that the :term:`MACHINE`
@@ -332,8 +330,8 @@ cross-development environment by sourcing the toolchain's environment
332setup script. If you used the ADT Installer or hand-installed 330setup script. If you used the ADT Installer or hand-installed
333cross-toolchain, then you can find this script in the directory you 331cross-toolchain, then you can find this script in the directory you
334chose for installation. For this release, the default installation 332chose for installation. For this release, the default installation
335directory is ````. If you installed the toolchain in the `Build 333directory is ````. If you installed the toolchain in the
336Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__, you can find the 334:term:`Build Directory`, you can find the
337environment setup script for the toolchain in the Build Directory's 335environment setup script for the toolchain in the Build Directory's
338``tmp`` directory. 336``tmp`` directory.
339 337
@@ -432,8 +430,8 @@ this by including the ``eclipse-debug`` image feature.
432 image features. 430 image features.
433 431
434To include the ``eclipse-debug`` image feature, modify your 432To include the ``eclipse-debug`` image feature, modify your
435``local.conf`` file in the `Build 433``local.conf`` file in the :term:`Build Directory`
436Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ so that the 434so that the
437:term:`EXTRA_IMAGE_FEATURES` 435:term:`EXTRA_IMAGE_FEATURES`
438variable includes the "eclipse-debug" feature. After modifying the 436variable includes the "eclipse-debug" feature. After modifying the
439configuration file, you can rebuild the image. Once the image is 437configuration file, you can rebuild the image. Once the image is
@@ -484,8 +482,7 @@ Optionally Building a Toolchain Installer
484========================================= 482=========================================
485 483
486As an alternative to locating and downloading a toolchain installer, you 484As an alternative to locating and downloading a toolchain installer, you
487can build the toolchain installer if you have a `Build 485can build the toolchain installer if you have a :term:`Build Directory`.
488Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__.
489 486
490.. note:: 487.. note::
491 488
diff --git a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
index 712d5c7f8e..563c3f2d9a 100644
--- a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
@@ -162,10 +162,10 @@ an entire Linux distribution, including the toolchain, from source.
162 <target>' Common targets are: core-image-minimal core-image-sato 162 <target>' Common targets are: core-image-minimal core-image-sato
163 meta-toolchain meta-ide-support You can also run generated qemu 163 meta-toolchain meta-ide-support You can also run generated qemu
164 images with a command like 'runqemu qemux86-64' Among other things, 164 images with a command like 'runqemu qemux86-64' Among other things,
165 the script creates the `Build 165 the script creates the
166 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is 166 :term:`Build Directory`, which is
167 ``build`` in this case and is located in the `Source 167 ``build`` in this case and is located in the :term:`Source Directory`.
168 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the 168 After the
169 script runs, your current working directory is set to the Build 169 script runs, your current working directory is set to the Build
170 Directory. Later, when the build completes, the Build Directory 170 Directory. Later, when the build completes, the Build Directory
171 contains all the files created during the build. 171 contains all the files created during the build.
@@ -271,8 +271,8 @@ Follow these steps to add a hardware layer:
271 271
2724. *Add Your Layer to the Layer Configuration File:* Before you can use 2724. *Add Your Layer to the Layer Configuration File:* Before you can use
273 a layer during a build, you must add it to your ``bblayers.conf`` 273 a layer during a build, you must add it to your ``bblayers.conf``
274 file, which is found in the `Build 274 file, which is found in the
275 Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf`` 275 :term:`Build Directory` ``conf``
276 directory. 276 directory.
277 277
278 Use the ``bitbake-layers add-layer`` command to add the layer to the 278 Use the ``bitbake-layers add-layer`` command to add the layer to the
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index e06b1259f0..361951b592 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -74,12 +74,12 @@ section in the Yocto Project Development Tasks Manual.
74The BSP layer's base directory (``meta-bsp_root_name``) is the root 74The BSP layer's base directory (``meta-bsp_root_name``) is the root
75directory of that Layer. This directory is what you add to the 75directory of that Layer. This directory is what you add to the
76:term:`BBLAYERS` variable in the 76:term:`BBLAYERS` variable in the
77``conf/bblayers.conf`` file found in your `Build 77``conf/bblayers.conf`` file found in your
78Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is 78:term:`Build Directory`, which is
79established after you run the OpenEmbedded build environment setup 79established after you run the OpenEmbedded build environment setup
80script (i.e. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__). 80script (i.e. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__).
81Adding the root directory allows the `OpenEmbedded build 81Adding the root directory allows the :term:`OpenEmbedded Build System`
82system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ to recognize the BSP 82to recognize the BSP
83layer and from it build an image. Here is an example: BBLAYERS ?= " \\ 83layer and from it build an image. Here is an example: BBLAYERS ?= " \\
84/usr/local/src/yocto/meta \\ /usr/local/src/yocto/meta-poky \\ 84/usr/local/src/yocto/meta \\ /usr/local/src/yocto/meta-poky \\
85/usr/local/src/yocto/meta-yocto-bsp \\ /usr/local/src/yocto/meta-mylayer 85/usr/local/src/yocto/meta-yocto-bsp \\ /usr/local/src/yocto/meta-mylayer
@@ -144,8 +144,7 @@ section.
144 machine that uses CROPS. 144 machine that uses CROPS.
145 145
1462. *Clone the ``poky`` Repository:* You need to have a local copy of the 1462. *Clone the ``poky`` Repository:* You need to have a local copy of the
147 Yocto Project `Source 147 Yocto Project :term:`Source Directory` (i.e. a local
148 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local
149 ``poky`` repository). See the "`Cloning the ``poky`` 148 ``poky`` repository). See the "`Cloning the ``poky``
150 Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and 149 Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and
151 possibly the "`Checking Out by Branch in 150 possibly the "`Checking Out by Branch in
@@ -169,8 +168,7 @@ section.
169 file. 168 file.
170 169
171 1. *Navigate to Your Source Directory:* Typically, you set up the 170 1. *Navigate to Your Source Directory:* Typically, you set up the
172 ``meta-intel`` Git repository inside the `Source 171 ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g.
173 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
174 ``poky``). $ cd /home/you/poky 172 ``poky``). $ cd /home/you/poky
175 173
176 2. *Clone the Layer:* $ git clone 174 2. *Clone the Layer:* $ git clone
@@ -218,10 +216,10 @@ section.
218 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment 216 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment
219 setup script to define the OpenEmbedded build environment on your 217 setup script to define the OpenEmbedded build environment on your
220 build host. $ source OE_INIT_FILE Among other things, the script 218 build host. $ source OE_INIT_FILE Among other things, the script
221 creates the `Build 219 creates the
222 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is 220 :term:`Build Directory`, which is
223 ``build`` in this case and is located in the `Source 221 ``build`` in this case and is located in the :term:`Source Directory`.
224 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the 222 After the
225 script runs, your current working directory is set to the ``build`` 223 script runs, your current working directory is set to the ``build``
226 directory. 224 directory.
227 225
@@ -629,8 +627,8 @@ types of files although, in practice, it is likely that you would have
629one or the other. 627one or the other.
630 628
631For your BSP, you typically want to use an existing Yocto Project kernel 629For your BSP, you typically want to use an existing Yocto Project kernel
632recipe found in the `Source 630recipe found in the :term:`Source Directory`
633Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at 631at
634``meta/recipes-kernel/linux``. You can append machine-specific changes 632``meta/recipes-kernel/linux``. You can append machine-specific changes
635to the kernel recipe by using a similarly named append file, which is 633to the kernel recipe by using a similarly named append file, which is
636located in the BSP Layer for your target device (e.g. the 634located in the BSP Layer for your target device (e.g. the
@@ -848,8 +846,8 @@ Yocto Project:
848 846
849- *File System Layout:* When possible, use the same directory names in 847- *File System Layout:* When possible, use the same directory names in
850 your BSP layer as listed in the ``recipes.txt`` file, which is found 848 your BSP layer as listed in the ``recipes.txt`` file, which is found
851 in ``poky/meta`` directory of the `Source 849 in ``poky/meta`` directory of the :term:`Source Directory`
852 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ or in the 850 or in the
853 OpenEmbedded-Core Layer (``openembedded-core``) at 851 OpenEmbedded-Core Layer (``openembedded-core``) at
854 ` <http://git.openembedded.org/openembedded-core/tree/meta>`__. 852 ` <http://git.openembedded.org/openembedded-core/tree/meta>`__.
855 853
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index e1fe881437..c019057bf8 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -48,8 +48,8 @@ Follow these general steps to create your layer without using tools:
48 48
492. *Create a Directory:* Create the directory for your layer. When you 492. *Create a Directory:* Create the directory for your layer. When you
50 create the layer, be sure to create the directory in an area not 50 create the layer, be sure to create the directory in an area not
51 associated with the Yocto Project `Source 51 associated with the Yocto Project :term:`Source Directory`
52 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. the cloned 52 (e.g. the cloned
53 ``poky`` repository). 53 ``poky`` repository).
54 54
55 While not strictly required, prepend the name of the directory with 55 While not strictly required, prepend the name of the directory with
@@ -263,8 +263,7 @@ following list:
263 repository that use the ``meta-layer_name`` format. 263 repository that use the ``meta-layer_name`` format.
264 264
265- *Group Your Layers Locally:* Clone your repository alongside other 265- *Group Your Layers Locally:* Clone your repository alongside other
266 cloned ``meta`` directories from the `Source 266 cloned ``meta`` directories from the :term:`Source Directory`.
267 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__.
268 267
269Making Sure Your Layer is Compatible With Yocto Project 268Making Sure Your Layer is Compatible With Yocto Project
270------------------------------------------------------- 269-------------------------------------------------------
@@ -449,8 +448,8 @@ does not have a corresponding recipe with a matching name. See the
449variable for information on how to handle this error. 448variable for information on how to handle this error.
450 449
451As an example, consider the main formfactor recipe and a corresponding 450As an example, consider the main formfactor recipe and a corresponding
452formfactor append file both from the `Source 451formfactor append file both from the :term:`Source Directory`.
453Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Here is the main 452Here is the main
454formfactor recipe, which is named ``formfactor_0.0.bb`` and located in 453formfactor recipe, which is named ``formfactor_0.0.bb`` and located in
455the "meta" layer at ``meta/recipes-bsp/formfactor``: SUMMARY = "Device 454the "meta" layer at ``meta/recipes-bsp/formfactor``: SUMMARY = "Device
456formfactor information" SECTION = "base" LICENSE = "MIT" 455formfactor information" SECTION = "base" LICENSE = "MIT"
@@ -769,8 +768,8 @@ high-level image features by using the
769variables. Although the functions for both variables are nearly 768variables. Although the functions for both variables are nearly
770equivalent, best practices dictate using ``IMAGE_FEATURES`` from within 769equivalent, best practices dictate using ``IMAGE_FEATURES`` from within
771a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your 770a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your
772``local.conf`` file, which is found in the `Build 771``local.conf`` file, which is found in the
773Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 772:term:`Build Directory`.
774 773
775To understand how these features work, the best reference is 774To understand how these features work, the best reference is
776``meta/classes/core-image.bbclass``. This class lists out the available 775``meta/classes/core-image.bbclass``. This class lists out the available
@@ -996,8 +995,8 @@ application that builds using Autotools. Creating the base recipe using
996``recipetool`` results in a recipe that has the pre-build dependencies, 995``recipetool`` results in a recipe that has the pre-build dependencies,
997license requirements, and checksums configured. 996license requirements, and checksums configured.
998 997
999To run the tool, you just need to be in your `Build 998To run the tool, you just need to be in your
1000Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ and have sourced the 999:term:`Build Directory` and have sourced the
1001build environment setup script (i.e. 1000build environment setup script (i.e.
1002```oe-init-build-env`` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__). 1001```oe-init-build-env`` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__).
1003To get help on the tool, use the following command: $ recipetool -h 1002To get help on the tool, use the following command: $ recipetool -h
@@ -1799,8 +1798,8 @@ different ways:
1799 1798
1800 To enable a service using systemd, your recipe needs to inherit the 1799 To enable a service using systemd, your recipe needs to inherit the
1801 :ref:`systemd <ref-classes-systemd>` class. See 1800 :ref:`systemd <ref-classes-systemd>` class. See
1802 the ``systemd.bbclass`` file located in your `Source 1801 the ``systemd.bbclass`` file located in your :term:`Source Directory`
1803 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. section for 1802 section for
1804 more information. 1803 more information.
1805 1804
1806.. _new-recipe-packaging: 1805.. _new-recipe-packaging:
@@ -2251,7 +2250,7 @@ could lead to compatibility problems with ABI in the future. However,
2251sometimes you have no choice. 2250sometimes you have no choice.
2252 2251
2253The easiest solution is to create a recipe that uses the 2252The easiest solution is to create a recipe that uses the
2254```bin_package`` <&YOCTO_DOCS_REF_URL;#ref-classes-bin-package>`__ class 2253:ref:`bin_package <ref-classes-bin-package>` class
2255and to be sure that you are using default locations for build artifacts. 2254and to be sure that you are using default locations for build artifacts.
2256In most cases, the ``bin_package`` class handles "skipping" the 2255In most cases, the ``bin_package`` class handles "skipping" the
2257configure and compile steps as well as sets things up to grab packages 2256configure and compile steps as well as sets things up to grab packages
@@ -2739,7 +2738,7 @@ The following steps describe how to set up the AUH utility:
2739 your build directory. 2738 your build directory.
2740 2739
2741 - If you want to enable testing through the 2740 - If you want to enable testing through the
2742 ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ 2741 :ref:`testimage <ref-classes-testimage*>`
2743 class, which is optional, you need to have the following set in 2742 class, which is optional, you need to have the following set in
2744 your ``conf/local.conf`` file: INHERIT += "testimage" 2743 your ``conf/local.conf`` file: INHERIT += "testimage"
2745 2744
@@ -2856,8 +2855,8 @@ could add it easily using the
2856script. For example, suppose you use the ``nano.bb`` recipe from the 2855script. For example, suppose you use the ``nano.bb`` recipe from the
2857``meta-oe`` layer in the ``meta-openembedded`` repository. For this 2856``meta-oe`` layer in the ``meta-openembedded`` repository. For this
2858example, assume that the layer has been cloned into following area: 2857example, assume that the layer has been cloned into following area:
2859/home/scottrif/meta-openembedded The following command from your `Build 2858/home/scottrif/meta-openembedded The following command from your
2860Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ adds the layer to 2859:term:`Build Directory` adds the layer to
2861your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``): $ 2860your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``): $
2862bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe NOTE: 2861bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe NOTE:
2863Starting bitbake server... Parsing recipes: 100% 2862Starting bitbake server... Parsing recipes: 100%
@@ -3014,8 +3013,8 @@ You might find it helpful during development to modify the temporary
3014source code used by recipes to build packages. For example, suppose you 3013source code used by recipes to build packages. For example, suppose you
3015are developing a patch and you need to experiment a bit to figure out 3014are developing a patch and you need to experiment a bit to figure out
3016your solution. After you have initially built the package, you can 3015your solution. After you have initially built the package, you can
3017iteratively tweak the source code, which is located in the `Build 3016iteratively tweak the source code, which is located in the
3018Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, and then you can 3017:term:`Build Directory`, and then you can
3019force a re-compile and quickly test your altered code. Once you settle 3018force a re-compile and quickly test your altered code. Once you settle
3020on a solution, you can then preserve your changes in the form of 3019on a solution, you can then preserve your changes in the form of
3021patches. 3020patches.
@@ -3024,8 +3023,8 @@ During a build, the unpacked temporary source code used by recipes to
3024build packages is available in the Build Directory as defined by the 3023build packages is available in the Build Directory as defined by the
3025:term:`S` variable. Below is the default 3024:term:`S` variable. Below is the default
3026value for the ``S`` variable as defined in the 3025value for the ``S`` variable as defined in the
3027``meta/conf/bitbake.conf`` configuration file in the `Source 3026``meta/conf/bitbake.conf`` configuration file in the
3028Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: S = 3027:term:`Source Directory`: S =
3029"${WORKDIR}/${BP}" You should be aware that many recipes override the 3028"${WORKDIR}/${BP}" You should be aware that many recipes override the
3030``S`` variable. For example, recipes that fetch their source from Git 3029``S`` variable. For example, recipes that fetch their source from Git
3031usually set ``S`` to ``${WORKDIR}/git``. 3030usually set ``S`` to ``${WORKDIR}/git``.
@@ -3096,8 +3095,8 @@ form of a patch all using Quilt.
3096Follow these general steps: 3095Follow these general steps:
3097 3096
30981. *Find the Source Code:* Temporary source code used by the 30971. *Find the Source Code:* Temporary source code used by the
3099 OpenEmbedded build system is kept in the `Build 3098 OpenEmbedded build system is kept in the
3100 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. See the 3099 :term:`Build Directory`. See the
3101 "`Finding Temporary Source 3100 "`Finding Temporary Source
3102 Code <#finding-the-temporary-source-code>`__" section to learn how to 3101 Code <#finding-the-temporary-source-code>`__" section to learn how to
3103 locate the directory that has the temporary source code for a 3102 locate the directory that has the temporary source code for a
@@ -3314,8 +3313,8 @@ build host running Linux.
3314 Build <&YOCTO_DOCS_BRIEF_URL;>`__ document. 3313 Build <&YOCTO_DOCS_BRIEF_URL;>`__ document.
3315 3314
3316The build process creates an entire Linux distribution from source and 3315The build process creates an entire Linux distribution from source and
3317places it in your `Build 3316places it in your
3318Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ under 3317:term:`Build Directory` under
3319``tmp/deploy/images``. For detailed information on the build process 3318``tmp/deploy/images``. For detailed information on the build process
3320using BitBake, see the 3319using BitBake, see the
3321"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the 3320"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the
@@ -3372,8 +3371,8 @@ The following figure and list overviews the build process:
3372 3371
3373 The target is the name of the recipe you want to build. Common 3372 The target is the name of the recipe you want to build. Common
3374 targets are the images in ``meta/recipes-core/images``, 3373 targets are the images in ``meta/recipes-core/images``,
3375 ``meta/recipes-sato/images``, and so forth all found in the `Source 3374 ``meta/recipes-sato/images``, and so forth all found in the
3376 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Or, the target 3375 :term:`Source Directory`. Or, the target
3377 can be the name of a recipe for a specific piece of software such as 3376 can be the name of a recipe for a specific piece of software such as
3378 BusyBox. For more details about the images the OpenEmbedded build 3377 BusyBox. For more details about the images the OpenEmbedded build
3379 system supports, see the 3378 system supports, see the
@@ -3557,8 +3556,8 @@ Follow these steps to create an initramfs image:
3557 3556
35581. *Create the initramfs Image Recipe:* You can reference the 35571. *Create the initramfs Image Recipe:* You can reference the
3559 ``core-image-minimal-initramfs.bb`` recipe found in the 3558 ``core-image-minimal-initramfs.bb`` recipe found in the
3560 ``meta/recipes-core`` directory of the `Source 3559 ``meta/recipes-core`` directory of the :term:`Source Directory`
3561 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ as an example 3560 as an example
3562 from which to work. 3561 from which to work.
3563 3562
35642. *Decide if You Need to Bundle the initramfs Image Into the Kernel 35632. *Decide if You Need to Bundle the initramfs Image Into the Kernel
@@ -3715,8 +3714,8 @@ memory used for decompressing the kernel and for the ``__init__``
3715functions. 3714functions.
3716 3715
3717To help you see where you currently are with kernel and root filesystem 3716To help you see where you currently are with kernel and root filesystem
3718sizes, you can use two tools found in the `Source 3717sizes, you can use two tools found in the :term:`Source Directory`
3719Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the 3718in the
3720``scripts/tiny/`` directory: 3719``scripts/tiny/`` directory:
3721 3720
3722- ``ksize.py``: Reports component sizes for the kernel build objects. 3721- ``ksize.py``: Reports component sizes for the kernel build objects.
@@ -4049,8 +4048,8 @@ your tunings to best consider build times and package feed maintenance.
4049Building Software from an External Source 4048Building Software from an External Source
4050----------------------------------------- 4049-----------------------------------------
4051 4050
4052By default, the OpenEmbedded build system uses the `Build 4051By default, the OpenEmbedded build system uses the
4053Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ when building source 4052:term:`Build Directory` when building source
4054code. The build process involves fetching the source files, unpacking 4053code. The build process involves fetching the source files, unpacking
4055them, and then patching them if necessary before the build takes place. 4054them, and then patching them if necessary before the build takes place.
4056 4055
@@ -4158,8 +4157,7 @@ directory:
41582. *Start With a Clean Build:* You can start with a clean build by 41572. *Start With a Clean Build:* You can start with a clean build by
4159 removing the 4158 removing the
4160 ``${``\ :term:`TMPDIR`\ ``}`` 4159 ``${``\ :term:`TMPDIR`\ ``}``
4161 directory or using a new `Build 4160 directory or using a new :term:`Build Directory`.
4162 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
4163 4161
41643. *Build Your Target:* Use BitBake to build your target: $ bitbake 41623. *Build Your Target:* Use BitBake to build your target: $ bitbake
4165 target The build completes using the known local "snapshot" of source 4163 target The build completes using the known local "snapshot" of source
@@ -4258,7 +4256,7 @@ Following are additional factors that can affect build speed:
4258 contents could easily be rebuilt. 4256 contents could easily be rebuilt.
4259 4257
4260- Inheriting the 4258- Inheriting the
4261 ```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class: 4259 :ref:`rm_work <ref-classes-rm-work>` class:
4262 Inheriting this class has shown to speed up builds due to 4260 Inheriting this class has shown to speed up builds due to
4263 significantly lower amounts of data stored in the data cache as well 4261 significantly lower amounts of data stored in the data cache as well
4264 as on disk. Inheriting this class also makes cleanup of 4262 as on disk. Inheriting this class also makes cleanup of
@@ -4409,8 +4407,8 @@ meet your needs.
4409In order to enable Multilib, you first need to ensure your recipe is 4407In order to enable Multilib, you first need to ensure your recipe is
4410extended to support multiple libraries. Many standard recipes are 4408extended to support multiple libraries. Many standard recipes are
4411already extended and support multiple libraries. You can check in the 4409already extended and support multiple libraries. You can check in the
4412``meta/conf/multilib.conf`` configuration file in the `Source 4410``meta/conf/multilib.conf`` configuration file in the
4413Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ to see how this is 4411:term:`Source Directory` to see how this is
4414done using the 4412done using the
4415:term:`BBCLASSEXTEND` variable. 4413:term:`BBCLASSEXTEND` variable.
4416Eventually, all recipes will be covered and this list will not be 4414Eventually, all recipes will be covered and this list will not be
@@ -4436,8 +4434,8 @@ Using Multilib
4436 4434
4437After you have set up the recipes, you need to define the actual 4435After you have set up the recipes, you need to define the actual
4438combination of multiple libraries you want to build. You accomplish this 4436combination of multiple libraries you want to build. You accomplish this
4439through your ``local.conf`` configuration file in the `Build 4437through your ``local.conf`` configuration file in the
4440Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. An example 4438:term:`Build Directory`. An example
4441configuration would be as follows: MACHINE = "qemux86-64" require 4439configuration would be as follows: MACHINE = "qemux86-64" require
4442conf/multilib.conf MULTILIBS = "multilib:lib32" 4440conf/multilib.conf MULTILIBS = "multilib:lib32"
4443DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = " 4441DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = "
@@ -4936,8 +4934,8 @@ Raw Mode
4936 4934
4937Running Wic in raw mode allows you to specify all the partitions through 4935Running Wic in raw mode allows you to specify all the partitions through
4938the ``wic`` command line. The primary use for raw mode is if you have 4936the ``wic`` command line. The primary use for raw mode is if you have
4939built your kernel outside of the Yocto Project `Build 4937built your kernel outside of the Yocto Project
4940Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. In other words, you 4938:term:`Build Directory`. In other words, you
4941can point to arbitrary kernel, root filesystem locations, and so forth. 4939can point to arbitrary kernel, root filesystem locations, and so forth.
4942Contrast this behavior with cooked mode where Wic looks in the Build 4940Contrast this behavior with cooked mode where Wic looks in the Build
4943Directory (e.g. ``tmp/deploy/images/``\ machine). 4941Directory (e.g. ``tmp/deploy/images/``\ machine).
@@ -5210,8 +5208,8 @@ This next example demonstrates that through modification of the
5210As mentioned earlier, you can use the command ``wic list images`` to 5208As mentioned earlier, you can use the command ``wic list images`` to
5211show the list of existing kickstart files. The directory in which the 5209show the list of existing kickstart files. The directory in which the
5212``directdisk-gpt.wks`` file resides is 5210``directdisk-gpt.wks`` file resides is
5213``scripts/lib/image/canned-wks/``, which is located in the `Source 5211``scripts/lib/image/canned-wks/``, which is located in the
5214Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``). 5212:term:`Source Directory` (e.g. ``poky``).
5215Because available files reside in this directory, you can create and add 5213Because available files reside in this directory, you can create and add
5216your own custom files to the directory. Subsequent use of the 5214your own custom files to the directory. Subsequent use of the
5217``wic list images`` command would then include your kickstart files. 5215``wic list images`` command would then include your kickstart files.
@@ -5520,8 +5518,8 @@ Security Flags
5520 5518
5521The Yocto Project has security flags that you can enable that help make 5519The Yocto Project has security flags that you can enable that help make
5522your build output more secure. The security flags are in the 5520your build output more secure. The security flags are in the
5523``meta/conf/distro/include/security_flags.inc`` file in your `Source 5521``meta/conf/distro/include/security_flags.inc`` file in your
5524Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``). 5522:term:`Source Directory` (e.g. ``poky``).
5525 5523
5526.. note:: 5524.. note::
5527 5525
@@ -5561,7 +5559,7 @@ system to make your images more secure:
5561 :ref:`extrausers <ref-classes-extrausers>` 5559 :ref:`extrausers <ref-classes-extrausers>`
5562 class, which is the preferred method. For an example on how to set up 5560 class, which is the preferred method. For an example on how to set up
5563 both root and user passwords, see the 5561 both root and user passwords, see the
5564 "```extrausers.bbclass`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__" 5562 ":ref:`extrausers.bbclass <ref-classes-extrausers>`"
5565 section. 5563 section.
5566 5564
5567 .. note:: 5565 .. note::
@@ -5663,8 +5661,8 @@ layer. The following steps provide some more detail:
5663 limited to the list in the previous bulleted item. 5661 limited to the list in the previous bulleted item.
5664 5662
5665- *Point to Your distribution configuration file:* In your 5663- *Point to Your distribution configuration file:* In your
5666 ``local.conf`` file in the `Build 5664 ``local.conf`` file in the :term:`Build Directory`,
5667 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, set your 5665 set your
5668 :term:`DISTRO` variable to point to 5666 :term:`DISTRO` variable to point to
5669 your distribution's configuration file. For example, if your 5667 your distribution's configuration file. For example, if your
5670 distribution's configuration file is named ``mydistro.conf``, then 5668 distribution's configuration file is named ``mydistro.conf``, then
@@ -5704,8 +5702,8 @@ new build directory.
5704 5702
5705The OpenEmbedded build system uses the environment variable 5703The OpenEmbedded build system uses the environment variable
5706``TEMPLATECONF`` to locate the directory from which it gathers 5704``TEMPLATECONF`` to locate the directory from which it gathers
5707configuration information that ultimately ends up in the `Build 5705configuration information that ultimately ends up in the
5708Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf`` directory. 5706:term:`Build Directory` ``conf`` directory.
5709By default, ``TEMPLATECONF`` is set as follows in the ``poky`` 5707By default, ``TEMPLATECONF`` is set as follows in the ``poky``
5710repository: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} This is the 5708repository: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} This is the
5711directory used by the build system to find templates from which to build 5709directory used by the build system to find templates from which to build
@@ -5762,7 +5760,7 @@ the :term:`Build Directory`: INHERIT
5762+= "rm_work" Adding this statement deletes the work directory used for 5760+= "rm_work" Adding this statement deletes the work directory used for
5763building a recipe once the recipe is built. For more information on 5761building a recipe once the recipe is built. For more information on
5764"rm_work", see the 5762"rm_work", see the
5765```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class in the 5763:ref:`rm_work <ref-classes-rm-work>` class in the
5766Yocto Project Reference Manual. 5764Yocto Project Reference Manual.
5767 5765
5768Working with Packages 5766Working with Packages
@@ -5947,8 +5945,7 @@ The simplest form for a PR Service is for it to exist for a single host
5947development system that builds the package feed (building system). For 5945development system that builds the package feed (building system). For
5948this scenario, you can enable a local PR Service by setting 5946this scenario, you can enable a local PR Service by setting
5949:term:`PRSERV_HOST` in your 5947:term:`PRSERV_HOST` in your
5950``local.conf`` file in the `Build 5948``local.conf`` file in the :term:`Build Directory`: PRSERV_HOST =
5951Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: PRSERV_HOST =
5952"localhost:0" Once the service is started, packages will automatically 5949"localhost:0" Once the service is started, packages will automatically
5953get increasing ``PR`` values and BitBake takes care of starting and 5950get increasing ``PR`` values and BitBake takes care of starting and
5954stopping the server. 5951stopping the server.
@@ -6253,8 +6250,8 @@ to use. In your configuration, you use the
6253:term:`PACKAGE_CLASSES` 6250:term:`PACKAGE_CLASSES`
6254variable to specify the format: 6251variable to specify the format:
6255 6252
62561. Open the ``local.conf`` file inside your `Build 62531. Open the ``local.conf`` file inside your
6257 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (e.g. 6254 :term:`Build Directory` (e.g.
6258 ``~/poky/build/conf/local.conf``). 6255 ``~/poky/build/conf/local.conf``).
6259 6256
62602. Select the desired package format as follows: PACKAGE_CLASSES ?= 62572. Select the desired package format as follows: PACKAGE_CLASSES ?=
@@ -6582,8 +6579,8 @@ Adding ptest to Your Build
6582To add package testing to your build, add the 6579To add package testing to your build, add the
6583:term:`DISTRO_FEATURES` and 6580:term:`DISTRO_FEATURES` and
6584:term:`EXTRA_IMAGE_FEATURES` 6581:term:`EXTRA_IMAGE_FEATURES`
6585variables to your ``local.conf`` file, which is found in the `Build 6582variables to your ``local.conf`` file, which is found in the
6586Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: 6583:term:`Build Directory`:
6587DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs" 6584DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs"
6588Once your build is complete, the ptest files are installed into the 6585Once your build is complete, the ptest files are installed into the
6589``/usr/lib/package/ptest`` directory within the image, where ``package`` 6586``/usr/lib/package/ptest`` directory within the image, where ``package``
@@ -7407,8 +7404,8 @@ dependency graphs, so you can see why something was pulled into the
7407image. If you are just interested in this information and not interested 7404image. If you are just interested in this information and not interested
7408in collecting specific package or SDK information, you can enable 7405in collecting specific package or SDK information, you can enable
7409writing only image information without any history by adding the 7406writing only image information without any history by adding the
7410following to your ``conf/local.conf`` file found in the `Build 7407following to your ``conf/local.conf`` file found in the
7411Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT += 7408:term:`Build Directory`: INHERIT +=
7412"buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image" 7409"buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image"
7413Here, you set the 7410Here, you set the
7414:term:`BUILDHISTORY_FEATURES` 7411:term:`BUILDHISTORY_FEATURES`
@@ -7856,19 +7853,19 @@ You can start the tests automatically or manually:
7856 the OpenEmbedded build system successfully creates an image, first 7853 the OpenEmbedded build system successfully creates an image, first
7857 set the 7854 set the
7858 :term:`TESTIMAGE_AUTO` 7855 :term:`TESTIMAGE_AUTO`
7859 variable to "1" in your ``local.conf`` file in the `Build 7856 variable to "1" in your ``local.conf`` file in the
7860 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: TESTIMAGE_AUTO = 7857 :term:`Build Directory`: TESTIMAGE_AUTO =
7861 "1" Next, build your image. If the image successfully builds, the 7858 "1" Next, build your image. If the image successfully builds, the
7862 tests run: bitbake core-image-sato 7859 tests run: bitbake core-image-sato
7863 7860
7864- *Manually running tests:* To manually run the tests, first globally 7861- *Manually running tests:* To manually run the tests, first globally
7865 inherit the 7862 inherit the
7866 ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class 7863 :ref:`testimage <ref-classes-testimage*>` class
7867 by editing your ``local.conf`` file: INHERIT += "testimage" Next, use 7864 by editing your ``local.conf`` file: INHERIT += "testimage" Next, use
7868 BitBake to run the tests: bitbake -c testimage image 7865 BitBake to run the tests: bitbake -c testimage image
7869 7866
7870All test files reside in ``meta/lib/oeqa/runtime`` in the `Source 7867All test files reside in ``meta/lib/oeqa/runtime`` in the
7871Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. A test name maps 7868:term:`Source Directory`. A test name maps
7872directly to a Python module. Each test module may contain a number of 7869directly to a Python module. Each test module may contain a number of
7873individual tests. Tests are usually grouped together by the area tested 7870individual tests. Tests are usually grouped together by the area tested
7874(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``). 7871(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``).
@@ -7934,8 +7931,8 @@ If your image is already built, make sure the following are set in your
7934"IP-address-for-the-test-target" TEST_SERVER_IP = 7931"IP-address-for-the-test-target" TEST_SERVER_IP =
7935"IP-address-for-the-test-server" You can then export the tests with the 7932"IP-address-for-the-test-server" You can then export the tests with the
7936following BitBake command form: $ bitbake image -c testexport Exporting 7933following BitBake command form: $ bitbake image -c testexport Exporting
7937the tests places them in the `Build 7934the tests places them in the
7938Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in 7935:term:`Build Directory` in
7939``tmp/testexport/``\ image, which is controlled by the 7936``tmp/testexport/``\ image, which is controlled by the
7940``TEST_EXPORT_DIR`` variable. 7937``TEST_EXPORT_DIR`` variable.
7941 7938
@@ -8158,8 +8155,8 @@ section:
8158- "`Viewing Task Variable 8155- "`Viewing Task Variable
8159 Dependencies <#dev-viewing-task-variable-dependencies>`__" describes 8156 Dependencies <#dev-viewing-task-variable-dependencies>`__" describes
8160 how to use the ``bitbake-dumpsig`` command in conjunction with key 8157 how to use the ``bitbake-dumpsig`` command in conjunction with key
8161 subdirectories in the `Build 8158 subdirectories in the
8162 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ to determine 8159 :term:`Build Directory` to determine
8163 variable dependencies. 8160 variable dependencies.
8164 8161
8165- "`Running Specific Tasks <#dev-debugging-taskrunning>`__" describes 8162- "`Running Specific Tasks <#dev-debugging-taskrunning>`__" describes
@@ -8313,7 +8310,7 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands.
8313 8310
8314 If you want to inspect the ``${WORKDIR}/packages-split`` 8311 If you want to inspect the ``${WORKDIR}/packages-split``
8315 directory, make sure that 8312 directory, make sure that
8316 ```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ is not 8313 :ref:`rm_work <ref-classes-rm-work>` is not
8317 enabled when you build the recipe. 8314 enabled when you build the recipe.
8318 8315
8319- ``oe-pkgdata-util find-path ``\ path\ `` ...``: Lists the names of 8316- ``oe-pkgdata-util find-path ``\ path\ `` ...``: Lists the names of
@@ -8704,8 +8701,7 @@ the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
8704and ``bbfatal``. The 8701and ``bbfatal``. The
8705:ref:`logging <ref-classes-logging>` class 8702:ref:`logging <ref-classes-logging>` class
8706implements these functions. See that class in the ``meta/classes`` 8703implements these functions. See that class in the ``meta/classes``
8707folder of the `Source 8704folder of the :term:`Source Directory` for information.
8708Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ for information.
8709 8705
8710Logging With Python 8706Logging With Python
8711~~~~~~~~~~~~~~~~~~~ 8707~~~~~~~~~~~~~~~~~~~
@@ -8890,8 +8886,8 @@ to the file: tools/snep-send.$(OBJEXT): include/near/dbus.h
8890Once you have edited the file, use the ``refresh`` command to create the 8886Once you have edited the file, use the ``refresh`` command to create the
8891patch: $ quilt refresh Refreshed patch patches/parallelmake.patch Once 8887patch: $ quilt refresh Refreshed patch patches/parallelmake.patch Once
8892the patch file exists, you need to add it back to the originating recipe 8888the patch file exists, you need to add it back to the originating recipe
8893folder. Here is an example assuming a top-level `Source 8889folder. Here is an example assuming a top-level
8894Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ named ``poky``: $ 8890:term:`Source Directory` named ``poky``: $
8895cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard 8891cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
8896The final thing you need to do to implement the fix in the build is to 8892The final thing you need to do to implement the fix in the build is to
8897update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the 8893update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
@@ -9163,8 +9159,8 @@ Here are some other tips that you might find useful:
9163 virtual console (e.g. Fn+Left or Fn+Right on a Zaurus). 9159 virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
9164 9160
9165- Removing :term:`TMPDIR` (usually 9161- Removing :term:`TMPDIR` (usually
9166 ``tmp/``, within the `Build 9162 ``tmp/``, within the
9167 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__) can often fix 9163 :term:`Build Directory`) can often fix
9168 temporary build issues. Removing ``TMPDIR`` is usually a relatively 9164 temporary build issues. Removing ``TMPDIR`` is usually a relatively
9169 cheap operation, because task output will be cached in 9165 cheap operation, because task output will be cached in
9170 :term:`SSTATE_DIR` (usually 9166 :term:`SSTATE_DIR` (usually
@@ -9471,8 +9467,7 @@ repository:
9471 methods to find out: 9467 methods to find out:
9472 9468
9473 - *Maintenance File:* Examine the ``maintainers.inc`` file, which is 9469 - *Maintenance File:* Examine the ``maintainers.inc`` file, which is
9474 located in the `Source 9470 located in the :term:`Source Directory` at
9475 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at
9476 ``meta/conf/distro/include``, to see who is responsible for code. 9471 ``meta/conf/distro/include``, to see who is responsible for code.
9477 9472
9478 - *Search by File:* Using `Git <&YOCTO_DOCS_OM_URL;#git>`__, you can 9473 - *Search by File:* Using `Git <&YOCTO_DOCS_OM_URL;#git>`__, you can
@@ -9495,8 +9490,8 @@ repository:
9495 The Yocto Project provides two scripts that conveniently let you 9490 The Yocto Project provides two scripts that conveniently let you
9496 generate and send pull requests to the Yocto Project. These scripts 9491 generate and send pull requests to the Yocto Project. These scripts
9497 are ``create-pull-request`` and ``send-pull-request``. You can find 9492 are ``create-pull-request`` and ``send-pull-request``. You can find
9498 these scripts in the ``scripts`` directory within the `Source 9493 these scripts in the ``scripts`` directory within the
9499 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. 9494 :term:`Source Directory` (e.g.
9500 ``~/poky/scripts``). 9495 ``~/poky/scripts``).
9501 9496
9502 Using these scripts correctly formats the requests without 9497 Using these scripts correctly formats the requests without
@@ -9641,8 +9636,8 @@ As mentioned in the "`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__"
9641section in the Yocto Project Overview and Concepts Manual, open source 9636section in the Yocto Project Overview and Concepts Manual, open source
9642projects are open to the public and they consequently have different 9637projects are open to the public and they consequently have different
9643licensing structures in place. This section describes the mechanism by 9638licensing structures in place. This section describes the mechanism by
9644which the `OpenEmbedded build 9639which the :term:`OpenEmbedded Build System`
9645system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ tracks changes to 9640tracks changes to
9646licensing text and covers how to maintain open source license compliance 9641licensing text and covers how to maintain open source license compliance
9647during your project's lifecycle. The section also describes how to 9642during your project's lifecycle. The section also describes how to
9648enable commercially licensed recipes, which by default are disabled. 9643enable commercially licensed recipes, which by default are disabled.
@@ -9947,8 +9942,8 @@ of compliance in mind.
9947 9942
9948One way of doing this (but certainly not the only way) is to release 9943One way of doing this (but certainly not the only way) is to release
9949just the source as a tarball. You can do this by adding the following to 9944just the source as a tarball. You can do this by adding the following to
9950the ``local.conf`` file found in the `Build 9945the ``local.conf`` file found in the
9951Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT += 9946:term:`Build Directory`: INHERIT +=
9952"archiver" ARCHIVER_MODE[src] = "original" During the creation of your 9947"archiver" ARCHIVER_MODE[src] = "original" During the creation of your
9953image, the source from all recipes that deploy packages to the image is 9948image, the source from all recipes that deploy packages to the image is
9954placed within subdirectories of ``DEPLOY_DIR/sources`` based on the 9949placed within subdirectories of ``DEPLOY_DIR/sources`` based on the
@@ -10070,8 +10065,8 @@ The error reporting tool allows you to submit errors encountered during
10070builds to a central database. Outside of the build environment, you can 10065builds to a central database. Outside of the build environment, you can
10071use a web interface to browse errors, view statistics, and query for 10066use a web interface to browse errors, view statistics, and query for
10072errors. The tool works using a client-server system where the client 10067errors. The tool works using a client-server system where the client
10073portion is integrated with the installed Yocto Project `Source 10068portion is integrated with the installed Yocto Project
10074Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``). 10069:term:`Source Directory` (e.g. ``poky``).
10075The server receives the information collected and saves it in a 10070The server receives the information collected and saves it in a
10076database. 10071database.
10077 10072
@@ -10093,8 +10088,8 @@ By default, the error reporting tool is disabled. You can enable it by
10093inheriting the 10088inheriting the
10094:ref:`report-error <ref-classes-report-error>` 10089:ref:`report-error <ref-classes-report-error>`
10095class by adding the following statement to the end of your 10090class by adding the following statement to the end of your
10096``local.conf`` file in your `Build 10091``local.conf`` file in your
10097Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT += 10092:term:`Build Directory`. INHERIT +=
10098"report-error" 10093"report-error"
10099 10094
10100By default, the error reporting feature stores information in 10095By default, the error reporting feature stores information in
@@ -10155,8 +10150,8 @@ The Yocto Project provides the Wayland protocol libraries and the
10155reference 10150reference
10156`Weston <http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__ 10151`Weston <http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__
10157compositor as part of its release. You can find the integrated packages 10152compositor as part of its release. You can find the integrated packages
10158in the ``meta`` layer of the `Source 10153in the ``meta`` layer of the :term:`Source Directory`.
10159Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Specifically, you 10154Specifically, you
10160can find the recipes that build both Wayland and Weston at 10155can find the recipes that build both Wayland and Weston at
10161``meta/recipes-graphics/wayland``. 10156``meta/recipes-graphics/wayland``.
10162 10157
diff --git a/documentation/dev-manual/dev-manual-qemu.rst b/documentation/dev-manual/dev-manual-qemu.rst
index 653f90573e..d695b90202 100644
--- a/documentation/dev-manual/dev-manual-qemu.rst
+++ b/documentation/dev-manual/dev-manual-qemu.rst
@@ -100,8 +100,8 @@ available. Follow these general steps to run QEMU:
100 Here are some additional examples to help illustrate further QEMU: 100 Here are some additional examples to help illustrate further QEMU:
101 101
102 - This example starts QEMU with MACHINE set to "qemux86-64". 102 - This example starts QEMU with MACHINE set to "qemux86-64".
103 Assuming a standard `Build 103 Assuming a standard
104 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, ``runqemu`` 104 :term:`Build Directory`, ``runqemu``
105 automatically finds the ``bzImage-qemux86-64.bin`` image file and 105 automatically finds the ``bzImage-qemux86-64.bin`` image file and
106 the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4`` 106 the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4``
107 (assuming the current build created a ``core-image-minimal`` 107 (assuming the current build created a ``core-image-minimal``
@@ -232,8 +232,8 @@ be a problem when QEMU is running with KVM enabled. Specifically,
232software compiled with a certain CPU feature crashes when run on a CPU 232software compiled with a certain CPU feature crashes when run on a CPU
233under KVM that does not support that feature. To work around this 233under KVM that does not support that feature. To work around this
234problem, you can override QEMU's runtime CPU setting by changing the 234problem, you can override QEMU's runtime CPU setting by changing the
235``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the `Build 235``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the
236Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``deploy/image`` 236:term:`Build Directory` ``deploy/image``
237directory. This setting specifies a ``-cpu`` option passed into QEMU in 237directory. This setting specifies a ``-cpu`` option passed into QEMU in
238the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of 238the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
239available supported CPU types. 239available supported CPU types.
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst
index fadc0bff3e..81fa7847e6 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/dev-manual-start.rst
@@ -140,8 +140,7 @@ particular working environment and set of practices.
140 Following are some best practices for setting up machines used for 140 Following are some best practices for setting up machines used for
141 developing images: 141 developing images:
142 142
143 - Have the `OpenEmbedded build 143 - Have the :term:`OpenEmbedded Build System` available on
144 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ available on
145 the developer workstations so developers can run their own builds 144 the developer workstations so developers can run their own builds
146 and directly rebuild the software stack. 145 and directly rebuild the software stack.
147 146
@@ -740,8 +739,8 @@ Cloning and Checking Out Branches
740 739
741To use the Yocto Project for development, you need a release locally 740To use the Yocto Project for development, you need a release locally
742installed on your development system. This locally installed set of 741installed on your development system. This locally installed set of
743files is referred to as the `Source 742files is referred to as the :term:`Source Directory`
744Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the Yocto 743 in the Yocto
745Project documentation. 744Project documentation.
746 745
747The preferred method of creating your Source Directory is by using 746The preferred method of creating your Source Directory is by using
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst
index f264cea159..813f4047e2 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/kernel-dev-common.rst
@@ -24,8 +24,8 @@ host is set up to use the Yocto Project. For information on how to get
24set up, see the "`Preparing the Build 24set up, see the "`Preparing the Build
25Host <&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host>`__" section in 25Host <&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host>`__" section in
26the Yocto Project Development Tasks Manual. Part of preparing the system 26the Yocto Project Development Tasks Manual. Part of preparing the system
27is creating a local Git repository of the `Source 27is creating a local Git repository of the
28Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (``poky``) on your 28:term:`Source Directory` (``poky``) on your
29system. Follow the steps in the "`Cloning the ``poky`` 29system. Follow the steps in the "`Cloning the ``poky``
30Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" 30Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__"
31section in the Yocto Project Development Tasks Manual to set up your 31section in the Yocto Project Development Tasks Manual to set up your
@@ -76,8 +76,8 @@ section:
76 "qemux86-64", which is fine if you are building for the QEMU emulator 76 "qemux86-64", which is fine if you are building for the QEMU emulator
77 in 64-bit mode. However, if you are not, you need to set the 77 in 64-bit mode. However, if you are not, you need to set the
78 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file 78 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file
79 found in the `Build 79 found in the
80 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e. 80 :term:`Build Directory` (i.e.
81 ``~/poky/build`` in this example). 81 ``~/poky/build`` in this example).
82 82
83 Also, since you are preparing to work on the kernel image, you need 83 Also, since you are preparing to work on the kernel image, you need
@@ -240,8 +240,8 @@ section:
240 "qemux86-64", which is fine if you are building for the QEMU emulator 240 "qemux86-64", which is fine if you are building for the QEMU emulator
241 in 64-bit mode. However, if you are not, you need to set the 241 in 64-bit mode. However, if you are not, you need to set the
242 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file 242 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file
243 found in the `Build 243 found in the
244 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e. 244 :term:`Build Directory` (i.e.
245 ``~/poky/build`` in this example). 245 ``~/poky/build`` in this example).
246 246
247 Also, since you are preparing to work on the kernel image, you need 247 Also, since you are preparing to work on the kernel image, you need
@@ -289,8 +289,8 @@ section:
289 ` <&YOCTO_GIT_URL;>`__. 289 ` <&YOCTO_GIT_URL;>`__.
290 290
291 For simplicity, it is recommended that you create your copy of the 291 For simplicity, it is recommended that you create your copy of the
292 kernel Git repository outside of the `Source 292 kernel Git repository outside of the
293 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is 293 :term:`Source Directory`, which is
294 usually named ``poky``. Also, be sure you are in the 294 usually named ``poky``. Also, be sure you are in the
295 ``standard/base`` branch. 295 ``standard/base`` branch.
296 296
@@ -317,8 +317,8 @@ section:
317 317
3186. *Create a Local Copy of the Kernel Cache Git Repository:* For 3186. *Create a Local Copy of the Kernel Cache Git Repository:* For
319 simplicity, it is recommended that you create your copy of the kernel 319 simplicity, it is recommended that you create your copy of the kernel
320 cache Git repository outside of the `Source 320 cache Git repository outside of the
321 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is 321 :term:`Source Directory`, which is
322 usually named ``poky``. Also, for this example, be sure you are in 322 usually named ``poky``. Also, for this example, be sure you are in
323 the ``yocto-4.12`` branch. 323 the ``yocto-4.12`` branch.
324 324
@@ -483,8 +483,8 @@ ensure the build process uses the appropriate kernel branch.
483Although this particular example does not use it, the 483Although this particular example does not use it, the
484:term:`KERNEL_FEATURES` 484:term:`KERNEL_FEATURES`
485variable could be used to enable features specific to the kernel. The 485variable could be used to enable features specific to the kernel. The
486append file points to specific commits in the `Source 486append file points to specific commits in the
487Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ Git repository and 487:term:`Source Directory` Git repository and
488the ``meta`` Git repository branches to identify the exact kernel needed 488the ``meta`` Git repository branches to identify the exact kernel needed
489to build the BSP. 489to build the BSP.
490 490
@@ -781,8 +781,8 @@ the "`Getting Ready to Develop Using
781 781
7828. *Build the Image With Your Modified Kernel:* You can now build an 7828. *Build the Image With Your Modified Kernel:* You can now build an
783 image that includes your kernel patches. Execute the following 783 image that includes your kernel patches. Execute the following
784 command from your `Build 784 command from your
785 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in the terminal 785 :term:`Build Directory` in the terminal
786 set up to run BitBake: $ cd ~/poky/build $ bitbake core-image-minimal 786 set up to run BitBake: $ cd ~/poky/build $ bitbake core-image-minimal
787 787
788Using Traditional Kernel Development to Patch the Kernel 788Using Traditional Kernel Development to Patch the Kernel
@@ -1134,8 +1134,7 @@ build system applies fragments on top of and after applying the existing
1134defconfig file configurations. 1134defconfig file configurations.
1135 1135
1136Syntactically, the configuration statement is identical to what would 1136Syntactically, the configuration statement is identical to what would
1137appear in the ``.config`` file, which is in the `Build 1137appear in the ``.config`` file, which is in the :term:`Build Directory`.
1138Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
1139 1138
1140.. note:: 1139.. note::
1141 1140
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
index ed1486b65d..cf4c20aaeb 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
@@ -320,8 +320,8 @@ tree specific to your kernel from which to generate the new kernel
320image. 320image.
321 321
322The following figure shows the temporary file structure created on your 322The following figure shows the temporary file structure created on your
323host system when you build the kernel using Bitbake. This `Build 323host system when you build the kernel using Bitbake. This
324Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ contains all the 324:term:`Build Directory` contains all the
325source files used during the build. 325source files used during the build.
326 326
327Again, for additional information on the Yocto Project kernel's 327Again, for additional information on the Yocto Project kernel's
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.rst b/documentation/kernel-dev/kernel-dev-maint-appx.rst
index d76e789d56..c0c0bc260b 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.rst
@@ -222,7 +222,7 @@ functionality.
222This behavior means that all the generated files for a particular 222This behavior means that all the generated files for a particular
223machine or BSP are now in the build tree directory. The files include 223machine or BSP are now in the build tree directory. The files include
224the final ``.config`` file, all the ``.o`` files, the ``.a`` files, and 224the final ``.config`` file, all the ``.o`` files, the ``.a`` files, and
225so forth. Since each machine or BSP has its own separate `Build 225so forth. Since each machine or BSP has its own separate
226Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in its own separate 226:term:`Build Directory` in its own separate
227branch of the Git repository, you can easily switch between different 227branch of the Git repository, you can easily switch between different
228builds. 228builds.
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``,
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 745d2ecf91..82562bf995 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -86,8 +86,8 @@ Once your development host is set up to use the Yocto Project, several
86methods exist for you to do work in the Yocto Project environment: 86methods exist for you to do work in the Yocto Project environment:
87 87
88- *Command Lines, BitBake, and Shells:* Traditional development in the 88- *Command Lines, BitBake, and Shells:* Traditional development in the
89 Yocto Project involves using the `OpenEmbedded build 89 Yocto Project involves using the :term:`OpenEmbedded Build System`,
90 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which uses 90 which uses
91 BitBake, in a command-line environment from a shell on your 91 BitBake, in a command-line environment from a shell on your
92 development host. You can accomplish this from a host that is a 92 development host. You can accomplish this from a host that is a
93 native Linux machine or from a host that has been set up with CROPS. 93 native Linux machine or from a host that has been set up with CROPS.
@@ -162,8 +162,8 @@ these tarballs gives you a snapshot of the released files.
162 162
163.. note:: 163.. note::
164 164
165 - The recommended method for setting up the Yocto Project `Source 165 - The recommended method for setting up the Yocto Project
166 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and the files 166 :term:`Source Directory` and the files
167 for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ 167 for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__
168 to create a local copy of the upstream repositories. 168 to create a local copy of the upstream repositories.
169 169
@@ -350,8 +350,8 @@ Book <http://book.git-scm.com>`__.
350 software on which to develop. The Yocto Project has two scripts named 350 software on which to develop. The Yocto Project has two scripts named
351 ``create-pull-request`` and ``send-pull-request`` that ship with the 351 ``create-pull-request`` and ``send-pull-request`` that ship with the
352 release to facilitate this workflow. You can find these scripts in 352 release to facilitate this workflow. You can find these scripts in
353 the ``scripts`` folder of the `Source 353 the ``scripts`` folder of the
354 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For information 354 :term:`Source Directory`. For information
355 on how to use these scripts, see the "`Using Scripts to Push a Change 355 on how to use these scripts, see the "`Using Scripts to Push a Change
356 Upstream and Request a 356 Upstream and Request a
357 Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in 357 Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in
@@ -638,8 +638,8 @@ When you build an image using the Yocto Project, the build process uses
638a known list of licenses to ensure compliance. You can find this list in 638a known list of licenses to ensure compliance. You can find this list in
639the :term:`Source Directory` at 639the :term:`Source Directory` at
640``meta/files/common-licenses``. Once the build completes, the list of 640``meta/files/common-licenses``. Once the build completes, the list of
641all licenses found and used during that build are kept in the `Build 641all licenses found and used during that build are kept in the
642Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at 642:term:`Build Directory` at
643``tmp/deploy/licenses``. 643``tmp/deploy/licenses``.
644 644
645If a module requires a license that is not in the base list, the build 645If a module requires a license that is not in the base list, the build
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index b27412cb25..3f98fa939c 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -180,8 +180,8 @@ developing using the Yocto Project:
180 changes on the development system within the BitBake environment and 180 changes on the development system within the BitBake environment and
181 then deploying only the updated packages to the target. 181 then deploying only the updated packages to the target.
182 182
183 The Yocto Project `OpenEmbedded build 183 The Yocto Project :term:`OpenEmbedded Build System`
184 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ produces packages 184 produces packages
185 in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy 185 in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy
186 these packages into the running system on the target by using 186 these packages into the running system on the target by using
187 utilities on the target such as ``rpm`` or ``ipk``. 187 utilities on the target such as ``rpm`` or ``ipk``.
@@ -202,8 +202,8 @@ The Yocto Project's "Layer Model" is a development model for embedded
202and IoT Linux creation that distinguishes the Yocto Project from other 202and IoT Linux creation that distinguishes the Yocto Project from other
203simple build systems. The Layer Model simultaneously supports 203simple build systems. The Layer Model simultaneously supports
204collaboration and customization. Layers are repositories that contain 204collaboration and customization. Layers are repositories that contain
205related sets of instructions that tell the `OpenEmbedded build 205related sets of instructions that tell the :term:`OpenEmbedded Build System`
206system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to do. You can 206what to do. You can
207collaborate, share, and reuse layers. 207collaborate, share, and reuse layers.
208 208
209Layers can contain changes to previous instructions or settings at any 209Layers can contain changes to previous instructions or settings at any
@@ -292,8 +292,8 @@ The Yocto Project employs a collection of components and tools used by
292the project itself, by project developers, and by those using the Yocto 292the project itself, by project developers, and by those using the Yocto
293Project. These components and tools are open source projects and 293Project. These components and tools are open source projects and
294metadata that are separate from the reference distribution 294metadata that are separate from the reference distribution
295(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the `OpenEmbedded build 295(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the
296system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. Most of the 296:term:`OpenEmbedded Build System`. Most of the
297components and tools are downloaded separately. 297components and tools are downloaded separately.
298 298
299This section provides brief overviews of the components and tools 299This section provides brief overviews of the components and tools
@@ -367,8 +367,8 @@ The following list consists of tools that help production related
367activities using the Yocto Project: 367activities using the Yocto Project:
368 368
369- *Auto Upgrade Helper:* This utility when used in conjunction with the 369- *Auto Upgrade Helper:* This utility when used in conjunction with the
370 `OpenEmbedded build 370 :term:`OpenEmbedded Build System`
371 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ (BitBake and 371 (BitBake and
372 OE-Core) automatically generates upgrades for recipes that are based 372 OE-Core) automatically generates upgrades for recipes that are based
373 on new versions of the recipes published upstream. 373 on new versions of the recipes published upstream.
374 374
@@ -668,8 +668,8 @@ Project.
668 668
669- *Toaster:* Regardless of what your Build Host is running, you can use 669- *Toaster:* Regardless of what your Build Host is running, you can use
670 Toaster to develop software using the Yocto Project. Toaster is a web 670 Toaster to develop software using the Yocto Project. Toaster is a web
671 interface to the Yocto Project's `Open-Embedded build 671 interface to the Yocto Project's :term:`OpenEmbedded Build System`.
672 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface 672 The interface
673 enables you to configure and run your builds. Information about 673 enables you to configure and run your builds. Information about
674 builds is collected and stored in a database. You can use Toaster to 674 builds is collected and stored in a database. You can use Toaster to
675 configure and start builds on multiple remote build servers. 675 configure and start builds on multiple remote build servers.
@@ -789,8 +789,7 @@ section in the BitBake User's Manual.
789The OpenEmbedded Build System Workflow 789The OpenEmbedded Build System Workflow
790====================================== 790======================================
791 791
792The `OpenEmbedded build 792The :term:`OpenEmbedded Build System` uses a "workflow" to
793system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to
794accomplish image and SDK generation. The following figure overviews that 793accomplish image and SDK generation. The following figure overviews that
795workflow: 794workflow:
796 795
@@ -836,8 +835,8 @@ helpful for getting started:
836 835
837- *Configuration Files:* Files that hold global definitions of 836- *Configuration Files:* Files that hold global definitions of
838 variables, user-defined variables, and hardware configuration 837 variables, user-defined variables, and hardware configuration
839 information. These files tell the `Open-Embedded build 838 information. These files tell the :term:`OpenEmbedded Build System`
840 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to build and 839 what to build and
841 what to put into the image to support a particular platform. 840 what to put into the image to support a particular platform.
842 841
843- *Extensible Software Development Kit (eSDK):* A custom SDK for 842- *Extensible Software Development Kit (eSDK):* A custom SDK for
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 07244a0311..3e8127b927 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -256,8 +256,7 @@ situation changes, the team will not support spaces in pathnames.
256**A:** The toolchain configuration is very flexible and customizable. It 256**A:** The toolchain configuration is very flexible and customizable. It
257is primarily controlled with the ``TCMODE`` variable. This variable 257is primarily controlled with the ``TCMODE`` variable. This variable
258controls which ``tcmode-*.inc`` file to include from the 258controls which ``tcmode-*.inc`` file to include from the
259``meta/conf/distro/include`` directory within the `Source 259``meta/conf/distro/include`` directory within the :term:`Source Directory`.
260Directory <#source-directory>`__.
261 260
262The default value of ``TCMODE`` is "default", which tells the 261The default value of ``TCMODE`` is "default", which tells the
263OpenEmbedded build system to use its internally built toolchain (i.e. 262OpenEmbedded build system to use its internally built toolchain (i.e.
@@ -342,8 +341,8 @@ redirect requests through proxy servers.
342**A:** Yes - you can easily do this. When you use BitBake to build an 341**A:** Yes - you can easily do this. When you use BitBake to build an
343image, all the build output goes into the directory created when you run 342image, all the build output goes into the directory created when you run
344the build environment setup script (i.e. 343the build environment setup script (i.e.
345````` <#structure-core-script>`__). By default, this `Build 344````` <#structure-core-script>`__). By default, this :term:`Build Directory`
346Directory <#build-directory>`__ is named ``build`` but can be named 345is named ``build`` but can be named
347anything you want. 346anything you want.
348 347
349Within the Build Directory, is the ``tmp`` directory. To remove all the 348Within the Build Directory, is the ``tmp`` directory. To remove all the
@@ -379,8 +378,8 @@ system of that image. Thus, the build system provides a value of
379"/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so 378"/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so
380forth. 379forth.
381 380
382Meanwhile, ``DESTDIR`` is a path within the `Build 381Meanwhile, ``DESTDIR`` is a path within the :term:`Build Directory`.
383Directory <#build-directory>`__. However, when the recipe builds a 382However, when the recipe builds a
384native program (i.e. one that is intended to run on the build machine), 383native program (i.e. one that is intended to run on the build machine),
385that program is never installed directly to the build machine's root 384that program is never installed directly to the build machine's root
386file system. Consequently, the build system uses paths within the Build 385file system. Consequently, the build system uses paths within the Build
diff --git a/documentation/ref-manual/migration.rst b/documentation/ref-manual/migration.rst
index 1d4d53647f..31959b2845 100644
--- a/documentation/ref-manual/migration.rst
+++ b/documentation/ref-manual/migration.rst
@@ -731,7 +731,7 @@ Automated Image Testing
731----------------------- 731-----------------------
732 732
733A new automated image testing framework has been added through the 733A new automated image testing framework has been added through the
734```testimage.bbclass`` <#ref-classes-testimage*>`__ class. This 734:ref:`testimage.bbclass <ref-classes-testimage*>` class. This
735framework replaces the older ``imagetest-qemu`` framework. 735framework replaces the older ``imagetest-qemu`` framework.
736 736
737You can learn more about performing automated image tests in the 737You can learn more about performing automated image tests in the
@@ -1077,7 +1077,7 @@ future releases the :ref:`autotools <ref-classes-autotools>` class
1077will enable a separate build directory by default as well. Recipes 1077will enable a separate build directory by default as well. Recipes
1078building Autotools-based software that fails to build with a separate 1078building Autotools-based software that fails to build with a separate
1079build directory should be changed to inherit from the 1079build directory should be changed to inherit from the
1080```autotools-brokensep`` <#ref-classes-autotools>`__ class instead of 1080:ref:`autotools-brokensep <ref-classes-autotools>` class instead of
1081the ``autotools`` or ``autotools_stage``\ classes. 1081the ``autotools`` or ``autotools_stage``\ classes.
1082 1082
1083.. _migration-1.6-building-qemu-native: 1083.. _migration-1.6-building-qemu-native:
@@ -1305,7 +1305,7 @@ occurred:
1305 However, if the software is not capable of being built in this 1305 However, if the software is not capable of being built in this
1306 manner, you will need to either patch the software so that it can 1306 manner, you will need to either patch the software so that it can
1307 build separately, or you will need to change the recipe to inherit 1307 build separately, or you will need to change the recipe to inherit
1308 the ```autotools-brokensep`` <#ref-classes-autotools>`__ class 1308 the :ref:`autotools-brokensep <ref-classes-autotools>` class
1309 instead of the ``autotools`` or ``autotools_stage`` classes. 1309 instead of the ``autotools`` or ``autotools_stage`` classes.
1310 1310
1311- *The ``--foreign`` option is no longer passed to ``automake`` when 1311- *The ``--foreign`` option is no longer passed to ``automake`` when
@@ -2048,7 +2048,7 @@ time.
2048A minor part of this restructuring is that the post-processing 2048A minor part of this restructuring is that the post-processing
2049definitions and functions have been moved from the 2049definitions and functions have been moved from the
2050:ref:`image <ref-classes-image>` class to the 2050:ref:`image <ref-classes-image>` class to the
2051```rootfs-postcommands`` <#ref-classes-rootfs*>`__ class. Functionally, 2051:ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
2052however, they remain unchanged. 2052however, they remain unchanged.
2053 2053
2054.. _migration-2.1-removed-recipes: 2054.. _migration-2.1-removed-recipes:
@@ -3973,7 +3973,7 @@ For names of recipes removed because of this repository change, see the
3973 3973
3974Previously, it was possible for Python recipes that inherited the 3974Previously, it was possible for Python recipes that inherited the
3975:ref:`distutils <ref-classes-distutils>` and 3975:ref:`distutils <ref-classes-distutils>` and
3976```distutils3`` <#ref-classes-distutils3>`__ classes to fetch code 3976:ref:`distutils3 <ref-classes-distutils3>` classes to fetch code
3977during the :ref:`ref-tasks-configure` task to satisfy 3977during the :ref:`ref-tasks-configure` task to satisfy
3978dependencies mentioned in ``setup.py`` if those dependencies were not 3978dependencies mentioned in ``setup.py`` if those dependencies were not
3979provided in the sysroot (i.e. recipes providing the dependencies were 3979provided in the sysroot (i.e. recipes providing the dependencies were
@@ -4183,7 +4183,7 @@ This section provides information about automatic testing changes:
4183 practices now dictate that you use the 4183 practices now dictate that you use the
4184 :term:`IMAGE_CLASSES` variable rather than the 4184 :term:`IMAGE_CLASSES` variable rather than the
4185 :term:`INHERIT` variable when you inherit the 4185 :term:`INHERIT` variable when you inherit the
4186 ```testimage`` <#ref-classes-testimage*>`__ and 4186 :ref:`testimage <ref-classes-testimage*>` and
4187 :ref:`testsdk <ref-classes-testsdk>` classes used for automatic 4187 :ref:`testsdk <ref-classes-testsdk>` classes used for automatic
4188 testing. 4188 testing.
4189 4189
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index 6449b49cd4..4b4f3bac5a 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -14,8 +14,8 @@ some default behavior.
14Any :term:`Metadata` usually found in a recipe can also be 14Any :term:`Metadata` usually found in a recipe can also be
15placed in a class file. Class files are identified by the extension 15placed in a class file. Class files are identified by the extension
16``.bbclass`` and are usually placed in a ``classes/`` directory beneath 16``.bbclass`` and are usually placed in a ``classes/`` directory beneath
17the ``meta*/`` directory found in the `Source 17the ``meta*/`` directory found in the :term:`Source Directory`.
18Directory <#source-directory>`__. Class files can also be pointed to by 18Class files can also be pointed to by
19:term:`BUILDDIR` (e.g. ``build/``) in the same way as 19:term:`BUILDDIR` (e.g. ``build/``) in the same way as
20``.conf`` files in the ``conf`` directory. Class files are searched for 20``.conf`` files in the ``conf`` directory. Class files are searched for
21in :term:`BBPATH` using the same method by which ``.conf`` 21in :term:`BBPATH` using the same method by which ``.conf``
@@ -555,7 +555,7 @@ used.
555 ``distutils`` class in their recipes. 555 ``distutils`` class in their recipes.
556 556
557- Extensions that use build systems based on ``setuptools3`` require 557- Extensions that use build systems based on ``setuptools3`` require
558 the ```setuptools3`` <#ref-classes-setuptools>`__ class in their 558 the :ref:`setuptools3 <ref-classes-setuptools>` class in their
559 recipes. 559 recipes.
560 560
561The ``distutils3*`` classes either inherit their corresponding 561The ``distutils3*`` classes either inherit their corresponding
@@ -592,8 +592,8 @@ ${WORKDIR}/${BPN}/{PV}/ See these variables for more information:
592:term:`PV`, 592:term:`PV`,
593 593
594For more information on the ``externalsrc`` class, see the comments in 594For more information on the ``externalsrc`` class, see the comments in
595``meta/classes/externalsrc.bbclass`` in the `Source 595``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
596Directory <#source-directory>`__. For information on how to use the 596For information on how to use the
597``externalsrc`` class, see the "`Building Software from an External 597``externalsrc`` class, see the "`Building Software from an External
598Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" 598Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
599section in the Yocto Project Development Tasks Manual. 599section in the Yocto Project Development Tasks Manual.
@@ -1733,8 +1733,8 @@ package-specific classes:
1733 1733
1734You can control the list of resulting package formats by using the 1734You can control the list of resulting package formats by using the
1735``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf`` 1735``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf``
1736configuration file, which is located in the `Build 1736configuration file, which is located in the :term:`Build Directory`.
1737Directory <#build-directory>`__. When defining the variable, you can 1737When defining the variable, you can
1738specify one or more package types. Since images are generated from 1738specify one or more package types. Since images are generated from
1739packages, a packaging class is needed to enable image generation. The 1739packages, a packaging class is needed to enable image generation. The
1740first class listed in this variable is used for image generation. 1740first class listed in this variable is used for image generation.
@@ -2181,8 +2181,8 @@ recipe are no longer needed. However, by default, the build system
2181preserves these files for inspection and possible debugging purposes. If 2181preserves these files for inspection and possible debugging purposes. If
2182you would rather have these files deleted to save disk space as the 2182you would rather have these files deleted to save disk space as the
2183build progresses, you can enable ``rm_work`` by adding the following to 2183build progresses, you can enable ``rm_work`` by adding the following to
2184your ``local.conf`` file, which is found in the `Build 2184your ``local.conf`` file, which is found in the :term:`Build Directory`.
2185Directory <#build-directory>`__. INHERIT += "rm_work" If you are 2185INHERIT += "rm_work" If you are
2186modifying and building source code out of the work directory for a 2186modifying and building source code out of the work directory for a
2187recipe, enabling ``rm_work`` will potentially result in your changes to 2187recipe, enabling ``rm_work`` will potentially result in your changes to
2188the source being lost. To exclude some recipes from having their work 2188the source being lost. To exclude some recipes from having their work
@@ -2565,7 +2565,7 @@ Other classes use the ``terminal`` class anywhere a separate terminal
2565session needs to be started. For example, the 2565session needs to be started. For example, the
2566:ref:`patch <ref-classes-patch>` class assuming 2566:ref:`patch <ref-classes-patch>` class assuming
2567:term:`PATCHRESOLVE` is set to "user", the 2567:term:`PATCHRESOLVE` is set to "user", the
2568```cml1`` <#ref-classes-cml1>`__ class, and the 2568:ref:`cml1 <ref-classes-cml1>` class, and the
2569:ref:`devshell <ref-classes-devshell>` class all use the ``terminal`` 2569:ref:`devshell <ref-classes-devshell>` class all use the ``terminal``
2570class. 2570class.
2571 2571
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst
index 5aeaa43833..4eba5cdf16 100644
--- a/documentation/ref-manual/ref-images.rst
+++ b/documentation/ref-manual/ref-images.rst
@@ -27,8 +27,8 @@ image you want.
27 27
28 28
29From within the ``poky`` Git repository, you can use the following 29From within the ``poky`` Git repository, you can use the following
30command to display the list of directories within the `Source 30command to display the list of directories within the :term:`Source Directory`
31Directory <#source-directory>`__ that contain image recipe files: $ ls 31that contain image recipe files: $ ls
32meta*/recipes*/images/*.bb 32meta*/recipes*/images/*.bb
33 33
34Following is a list of supported recipes: 34Following is a list of supported recipes:
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index 95ec686a13..832f011918 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -117,7 +117,7 @@ consists of the following pieces:
117 an ARM target, did the build produce ARM binaries. If, for example, 117 an ARM target, did the build produce ARM binaries. If, for example,
118 the build produced PPC binaries then there is a problem. 118 the build produced PPC binaries then there is a problem.
119 119
120- ```testimage.bbclass`` <#ref-classes-testimage*>`__: This class 120- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
121 performs runtime testing of images after they are built. The tests 121 performs runtime testing of images after they are built. The tests
122 are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__ 122 are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__
123 to boot the images and check the combined runtime result boot 123 to boot the images and check the combined runtime result boot
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index c63900e604..a21c0bdd52 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -26,8 +26,7 @@ section in the Yocto Project Development Tasks Manual.
26Top-Level Core Components 26Top-Level Core Components
27========================= 27=========================
28 28
29This section describes the top-level components of the `Source 29This section describes the top-level components of the :term:`Source Directory`.
30Directory <#source-directory>`__.
31 30
32.. _structure-core-bitbake: 31.. _structure-core-bitbake:
33 32
@@ -57,8 +56,8 @@ Manual <&YOCTO_DOCS_BB_URL;>`__.
57 56
58This directory contains user configuration files and the output 57This directory contains user configuration files and the output
59generated by the OpenEmbedded build system in its standard configuration 58generated by the OpenEmbedded build system in its standard configuration
60where the source tree is combined with the output. The `Build 59where the source tree is combined with the output. The :term:`Build Directory`
61Directory <#build-directory>`__ is created initially when you ``source`` 60is created initially when you ``source``
62the OpenEmbedded build environment setup script (i.e. 61the OpenEmbedded build environment setup script (i.e.
63````` <#structure-core-script>`__). 62````` <#structure-core-script>`__).
64 63
@@ -175,8 +174,8 @@ creates the ``build/`` directory in your current working directory. If
175you provide a Build Directory argument when you ``source`` the script, 174you provide a Build Directory argument when you ``source`` the script,
176you direct the OpenEmbedded build system to create a Build Directory of 175you direct the OpenEmbedded build system to create a Build Directory of
177your choice. For example, the following command creates a Build 176your choice. For example, the following command creates a Build
178Directory named ``mybuilds/`` that is outside of the `Source 177Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:
179Directory <#source-directory>`__: $ source OE_INIT_FILE ~/mybuilds The 178$ source OE_INIT_FILE ~/mybuilds The
180OpenEmbedded build system uses the template configuration files, which 179OpenEmbedded build system uses the template configuration files, which
181are found by default in the ``meta-poky/conf/`` directory in the Source 180are found by default in the ``meta-poky/conf/`` directory in the Source
182Directory. See the "`Creating a Custom Template Configuration 181Directory. See the "`Creating a Custom Template Configuration
@@ -206,8 +205,8 @@ These files are standard top-level files.
206The Build Directory - ``build/`` 205The Build Directory - ``build/``
207================================ 206================================
208 207
209The OpenEmbedded build system creates the `Build 208The OpenEmbedded build system creates the :term:`Build Directory`
210Directory <#build-directory>`__ when you run the build environment setup 209when you run the build environment setup
211script ````` <#structure-core-script>`__. If you do not give the Build 210script ````` <#structure-core-script>`__. If you do not give the Build
212Directory a specific name when you run the setup script, the name 211Directory a specific name when you run the setup script, the name
213defaults to ``build/``. 212defaults to ``build/``.
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index 9358a168f1..3144d303f8 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -348,8 +348,8 @@ installer:
348 system. 348 system.
349 349
350 Once the build completes, you can find the ``.sh`` file that installs 350 Once the build completes, you can find the ``.sh`` file that installs
351 the tools in the ``tmp/deploy/sdk`` subdirectory of the `Build 351 the tools in the ``tmp/deploy/sdk`` subdirectory of the
352 Directory <#build-directory>`__. The installer file has the string 352 :term:`Build Directory`. The installer file has the string
353 "buildtools" (or "buildtools-extended") in the name. 353 "buildtools" (or "buildtools-extended") in the name.
354 354
3553. Transfer the ``.sh`` file from the build host to the machine that 3553. Transfer the ``.sh`` file from the build host to the machine that
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index f3c698ba98..4bcd0a2d00 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -409,7 +409,7 @@ dependencies specified by :term:`DEPENDS`). See the
409 409
410Removes work files after the OpenEmbedded build system has finished with 410Removes work files after the OpenEmbedded build system has finished with
411them. You can learn more by looking at the 411them. You can learn more by looking at the
412"```rm_work.bbclass`` <#ref-classes-rm-work>`__" section. 412":ref:`rm_work.bbclass <ref-classes-rm-work>`" section.
413 413
414.. _ref-tasks-unpack: 414.. _ref-tasks-unpack:
415 415
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 4298e04965..eacc49fc3d 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -378,8 +378,8 @@ universal, the list includes them just in case:
378 :ref:`ref-tasks-patch`, and so forth). 378 :ref:`ref-tasks-patch`, and so forth).
379 379
380 Toaster 380 Toaster
381 A web interface to the Yocto Project's `OpenEmbedded Build 381 A web interface to the Yocto Project's :term:`OpenEmbedded Build System`.
382 System <#build-system-term>`__. The interface enables you to 382 The interface enables you to
383 configure and run your builds. Information about builds is collected 383 configure and run your builds. Information about builds is collected
384 and stored in a database. For information on Toaster, see the 384 and stored in a database. For information on Toaster, see the
385 `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__. 385 `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__.
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 473b672b76..aa7f59f602 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -144,8 +144,7 @@ system and gives an overview of their function and contents.
144 = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses 144 = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses
145 recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM 145 recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM
146 package files. For information on how the variable works, see the 146 package files. For information on how the variable works, see the
147 ``meta/classes/archiver.bbclass`` file in the `Source 147 ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
148 Directory <#source-directory>`__.
149 148
150 AS 149 AS
151 Minimal command and arguments needed to run the assembler. 150 Minimal command and arguments needed to run the assembler.
@@ -583,8 +582,8 @@ system and gives an overview of their function and contents.
583 582
584 BBLAYERS 583 BBLAYERS
585 Lists the layers to enable during the build. This variable is defined 584 Lists the layers to enable during the build. This variable is defined
586 in the ``bblayers.conf`` configuration file in the `Build 585 in the ``bblayers.conf`` configuration file in the :term:`Build Directory`.
587 Directory <#build-directory>`__. Here is an example: BBLAYERS = " \\ 586 Here is an example: BBLAYERS = " \\
588 /home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\ 587 /home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\
589 /home/scottrif/poky/meta-yocto-bsp \\ 588 /home/scottrif/poky/meta-yocto-bsp \\
590 /home/scottrif/poky/meta-mykernel \\ " 589 /home/scottrif/poky/meta-mykernel \\ "
@@ -705,8 +704,8 @@ system and gives an overview of their function and contents.
705 . 704 .
706 705
707 For more information on how this variable works, see 706 For more information on how this variable works, see
708 ``meta/classes/binconfig.bbclass`` in the `Source 707 ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
709 Directory <#source-directory>`__. You can also find general 708 You can also find general
710 information on the class in the 709 information on the class in the
711 ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section. 710 ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
712 711
@@ -1042,8 +1041,8 @@ system and gives an overview of their function and contents.
1042 Bluetooth but you do not ever intend to use it. 1041 Bluetooth but you do not ever intend to use it.
1043 1042
1044 COMMON_LICENSE_DIR 1043 COMMON_LICENSE_DIR
1045 Points to ``meta/files/common-licenses`` in the `Source 1044 Points to ``meta/files/common-licenses`` in the
1046 Directory <#source-directory>`__, which is where generic license 1045 :term:`Source Directory`, which is where generic license
1047 files reside. 1046 files reside.
1048 1047
1049 COMPATIBLE_HOST 1048 COMPATIBLE_HOST
@@ -1391,8 +1390,8 @@ system and gives an overview of their function and contents.
1391 for an SDK (i.e. ``nativesdk-``) 1390 for an SDK (i.e. ``nativesdk-``)
1392 1391
1393 D 1392 D
1394 The destination directory. The location in the `Build 1393 The destination directory. The location in the :term:`Build Directory`
1395 Directory <#build-directory>`__ where components are installed by the 1394 where components are installed by the
1396 :ref:`ref-tasks-install` task. This location defaults 1395 :ref:`ref-tasks-install` task. This location defaults
1397 to: ${WORKDIR}/image 1396 to: ${WORKDIR}/image
1398 1397
@@ -1664,8 +1663,8 @@ system and gives an overview of their function and contents.
1664 file whose root name is the same as the variable's argument and whose 1663 file whose root name is the same as the variable's argument and whose
1665 filename extension is ``.conf``. For example, the distribution 1664 filename extension is ``.conf``. For example, the distribution
1666 configuration file for the Poky distribution is named ``poky.conf`` 1665 configuration file for the Poky distribution is named ``poky.conf``
1667 and resides in the ``meta-poky/conf/distro`` directory of the `Source 1666 and resides in the ``meta-poky/conf/distro`` directory of the
1668 Directory <#source-directory>`__. 1667 :term:`Source Directory`.
1669 1668
1670 Within that ``poky.conf`` file, the ``DISTRO`` variable is set as 1669 Within that ``poky.conf`` file, the ``DISTRO`` variable is set as
1671 follows: DISTRO = "poky" 1670 follows: DISTRO = "poky"
@@ -2296,8 +2295,8 @@ system and gives an overview of their function and contents.
2296 :term:`SRC_URI` statements. 2295 :term:`SRC_URI` statements.
2297 2296
2298 The default value for the ``FILESPATH`` variable is defined in the 2297 The default value for the ``FILESPATH`` variable is defined in the
2299 ``base.bbclass`` class found in ``meta/classes`` in the `Source 2298 ``base.bbclass`` class found in ``meta/classes`` in the
2300 Directory <#source-directory>`__: FILESPATH = 2299 :term:`Source Directory`: FILESPATH =
2301 "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\ 2300 "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\
2302 "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The 2301 "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The
2303 ``FILESPATH`` variable is automatically extended using the overrides 2302 ``FILESPATH`` variable is automatically extended using the overrides
@@ -2344,14 +2343,14 @@ system and gives an overview of their function and contents.
2344 packages themselves but this is not always possible. 2343 packages themselves but this is not always possible.
2345 2344
2346 By default, the OpenEmbedded build system uses the ``fs-perms.txt``, 2345 By default, the OpenEmbedded build system uses the ``fs-perms.txt``,
2347 which is located in the ``meta/files`` folder in the `Source 2346 which is located in the ``meta/files`` folder in the :term:`Source Directory`.
2348 Directory <#source-directory>`__. If you create your own file 2347 If you create your own file
2349 permissions setting table, you should place it in your layer or the 2348 permissions setting table, you should place it in your layer or the
2350 distro's layer. 2349 distro's layer.
2351 2350
2352 You define the ``FILESYSTEM_PERMS_TABLES`` variable in the 2351 You define the ``FILESYSTEM_PERMS_TABLES`` variable in the
2353 ``conf/local.conf`` file, which is found in the `Build 2352 ``conf/local.conf`` file, which is found in the :term:`Build Directory`,
2354 Directory <#build-directory>`__, to point to your custom 2353 to point to your custom
2355 ``fs-perms.txt``. You can specify more than a single file permissions 2354 ``fs-perms.txt``. You can specify more than a single file permissions
2356 setting table. The paths you specify to these files must be defined 2355 setting table. The paths you specify to these files must be defined
2357 within the :term:`BBPATH` variable. 2356 within the :term:`BBPATH` variable.
@@ -2717,8 +2716,8 @@ system and gives an overview of their function and contents.
2717 IMAGE_FEATURES 2716 IMAGE_FEATURES
2718 The primary list of features to include in an image. Typically, you 2717 The primary list of features to include in an image. Typically, you
2719 configure this variable in an image recipe. Although you can use this 2718 configure this variable in an image recipe. Although you can use this
2720 variable from your ``local.conf`` file, which is found in the `Build 2719 variable from your ``local.conf`` file, which is found in the
2721 Directory <#build-directory>`__, best practices dictate that you do 2720 :term:`Build Directory`, best practices dictate that you do
2722 not. 2721 not.
2723 2722
2724 .. note:: 2723 .. note::
@@ -2886,13 +2885,13 @@ system and gives an overview of their function and contents.
2886 class is broken and is not supported. It is recommended that you 2885 class is broken and is not supported. It is recommended that you
2887 do not use it. 2886 do not use it.
2888 2887
2889 The ```populate_sdk_*`` <#ref-classes-populate-sdk-*>`__ and 2888 The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
2890 :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE`` 2889 :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE``
2891 for packaging up images and SDKs. 2890 for packaging up images and SDKs.
2892 2891
2893 You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the 2892 You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the
2894 variable is set indirectly through the appropriate 2893 variable is set indirectly through the appropriate
2895 ```package_*`` <#ref-classes-package>`__ class using the 2894 :ref:`package_* <ref-classes-package>` class using the
2896 :term:`PACKAGE_CLASSES` variable. The 2895 :term:`PACKAGE_CLASSES` variable. The
2897 OpenEmbedded build system uses the first package type (e.g. DEB, RPM, 2896 OpenEmbedded build system uses the first package type (e.g. DEB, RPM,
2898 or IPK) that appears with the variable 2897 or IPK) that appears with the variable
@@ -2995,8 +2994,7 @@ system and gives an overview of their function and contents.
2995 wic.bz2 wic.gz wic.lzma 2994 wic.bz2 wic.gz wic.lzma
2996 2995
2997 For more information about these types of images, see 2996 For more information about these types of images, see
2998 ``meta/classes/image_types*.bbclass`` in the `Source 2997 ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
2999 Directory <#source-directory>`__.
3000 2998
3001 INC_PR 2999 INC_PR
3002 Helps define the recipe revision for recipes that share a common 3000 Helps define the recipe revision for recipes that share a common
@@ -3156,8 +3154,8 @@ system and gives an overview of their function and contents.
3156 :term:`IMAGE_FSTYPES` variable. 3154 :term:`IMAGE_FSTYPES` variable.
3157 3155
3158 The default value of this variable, which is set in the 3156 The default value of this variable, which is set in the
3159 ``meta/conf/bitbake.conf`` configuration file in the `Source 3157 ``meta/conf/bitbake.conf`` configuration file in the
3160 Directory <#source-directory>`__, is "cpio.gz". The Linux kernel's 3158 :term:`Source Directory`, is "cpio.gz". The Linux kernel's
3161 initramfs mechanism, as opposed to the initial RAM filesystem 3159 initramfs mechanism, as opposed to the initial RAM filesystem
3162 `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects 3160 `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
3163 an optionally compressed cpio archive. 3161 an optionally compressed cpio archive.
@@ -3945,8 +3943,8 @@ system and gives an overview of their function and contents.
3945 3943
3946 MACHINE 3944 MACHINE
3947 Specifies the target device for which the image is built. You define 3945 Specifies the target device for which the image is built. You define
3948 ``MACHINE`` in the ``local.conf`` file found in the `Build 3946 ``MACHINE`` in the ``local.conf`` file found in the
3949 Directory <#build-directory>`__. By default, ``MACHINE`` is set to 3947 :term:`Build Directory`. By default, ``MACHINE`` is set to
3950 "qemux86", which is an x86-based architecture machine to be emulated 3948 "qemux86", which is an x86-based architecture machine to be emulated
3951 using QEMU: MACHINE ?= "qemux86" 3949 using QEMU: MACHINE ?= "qemux86"
3952 3950
@@ -4353,8 +4351,8 @@ system and gives an overview of their function and contents.
4353 ``sysroots/`` directory so that all builds that use the script will 4351 ``sysroots/`` directory so that all builds that use the script will
4354 use the correct directories for the cross compiling layout. 4352 use the correct directories for the cross compiling layout.
4355 4353
4356 See the ``meta/classes/binconfig.bbclass`` in the `Source 4354 See the ``meta/classes/binconfig.bbclass`` in the
4357 Directory <#source-directory>`__ for details on how this class 4355 :term:`Source Directory` for details on how this class
4358 applies these additional sed command arguments. For general 4356 applies these additional sed command arguments. For general
4359 information on the ``binconfig`` class, see the 4357 information on the ``binconfig`` class, see the
4360 ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section. 4358 ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
@@ -4499,8 +4497,8 @@ system and gives an overview of their function and contents.
4499 4497
4500 PACKAGE_CLASSES 4498 PACKAGE_CLASSES
4501 This variable, which is set in the ``local.conf`` configuration file 4499 This variable, which is set in the ``local.conf`` configuration file
4502 found in the ``conf`` folder of the `Build 4500 found in the ``conf`` folder of the
4503 Directory <#build-directory>`__, specifies the package manager the 4501 :term:`Build Directory`, specifies the package manager the
4504 OpenEmbedded build system uses when packaging data. 4502 OpenEmbedded build system uses when packaging data.
4505 4503
4506 You can provide one or more of the following arguments for the 4504 You can provide one or more of the following arguments for the
@@ -5234,8 +5232,8 @@ system and gives an overview of their function and contents.
5234 5232
5235 Typically, you could add a specific server for the build system to 5233 Typically, you could add a specific server for the build system to
5236 attempt before any others by adding something like the following to 5234 attempt before any others by adding something like the following to
5237 the ``local.conf`` configuration file in the `Build 5235 the ``local.conf`` configuration file in the
5238 Directory <#build-directory>`__: PREMIRRORS_prepend = "\\ 5236 :term:`Build Directory`: PREMIRRORS_prepend = "\\
5239 git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\* 5237 git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\*
5240 http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\* 5238 http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\*
5241 http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* 5239 http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\*
@@ -5364,8 +5362,8 @@ system and gives an overview of their function and contents.
5364 5362
5365 PYTHON_ABI 5363 PYTHON_ABI
5366 When used by recipes that inherit the 5364 When used by recipes that inherit the
5367 ```distutils3`` <#ref-classes-distutils3>`__, 5365 :ref:`distutils3 <ref-classes-distutils3>`,
5368 ```setuptools3`` <#ref-classes-setuptools3>`__, 5366 :ref:`setuptools3 <ref-classes-setuptools3>`,
5369 :ref:`distutils <ref-classes-distutils>`, or 5367 :ref:`distutils <ref-classes-distutils>`, or
5370 :ref:`setuptools <ref-classes-setuptools>` classes, denotes the 5368 :ref:`setuptools <ref-classes-setuptools>` classes, denotes the
5371 Application Binary Interface (ABI) currently in use for Python. By 5369 Application Binary Interface (ABI) currently in use for Python. By
@@ -5382,8 +5380,8 @@ system and gives an overview of their function and contents.
5382 5380
5383 PYTHON_PN 5381 PYTHON_PN
5384 When used by recipes that inherit the 5382 When used by recipes that inherit the
5385 ```distutils3`` <#ref-classes-distutils3>`__, 5383 `distutils3 <ref-classes-distutils3>`,
5386 ```setuptools3`` <#ref-classes-setuptools3>`__, 5384 :ref:`setuptools3 <ref-classes-setuptools3>`,
5387 :ref:`distutils <ref-classes-distutils>`, or 5385 :ref:`distutils <ref-classes-distutils>`, or
5388 :ref:`setuptools <ref-classes-setuptools>` classes, specifies the 5386 :ref:`setuptools <ref-classes-setuptools>` classes, specifies the
5389 major Python version being built. For Python 3.x, ``PYTHON_PN`` would 5387 major Python version being built. For Python 3.x, ``PYTHON_PN`` would
@@ -5522,7 +5520,7 @@ system and gives an overview of their function and contents.
5522 RM_WORK_EXCLUDE 5520 RM_WORK_EXCLUDE
5523 With ``rm_work`` enabled, this variable specifies a list of recipes 5521 With ``rm_work`` enabled, this variable specifies a list of recipes
5524 whose work directories should not be removed. See the 5522 whose work directories should not be removed. See the
5525 "```rm_work.bbclass`` <#ref-classes-rm-work>`__" section for more 5523 ":ref:`rm_work.bbclass <ref-classes-rm-work>`" section for more
5526 details. 5524 details.
5527 5525
5528 ROOT_HOME 5526 ROOT_HOME
@@ -5731,14 +5729,14 @@ system and gives an overview of their function and contents.
5731 5729
5732 SDK_DEPLOY 5730 SDK_DEPLOY
5733 The directory set up and used by the 5731 The directory set up and used by the
5734 ```populate_sdk_base`` <#ref-classes-populate-sdk>`__ class to which 5732 :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which
5735 the SDK is deployed. The ``populate_sdk_base`` class defines 5733 the SDK is deployed. The ``populate_sdk_base`` class defines
5736 ``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk" 5734 ``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
5737 5735
5738 SDK_DIR 5736 SDK_DIR
5739 The parent directory used by the OpenEmbedded build system when 5737 The parent directory used by the OpenEmbedded build system when
5740 creating SDK output. The 5738 creating SDK output. The
5741 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class defines 5739 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class defines
5742 the variable as follows: SDK_DIR = "${WORKDIR}/sdk" 5740 the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
5743 5741
5744 .. note:: 5742 .. note::
@@ -5770,7 +5768,7 @@ system and gives an overview of their function and contents.
5770 file contains package information on a line-per-package basis as 5768 file contains package information on a line-per-package basis as
5771 follows: packagename packagearch version 5769 follows: packagename packagearch version
5772 5770
5773 The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class 5771 The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
5774 defines the manifest file as follows: SDK_HOST_MANIFEST = 5772 defines the manifest file as follows: SDK_HOST_MANIFEST =
5775 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is 5773 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is
5776 derived using the :term:`SDK_DEPLOY` and 5774 derived using the :term:`SDK_DEPLOY` and
@@ -5807,7 +5805,7 @@ system and gives an overview of their function and contents.
5807 SDK_INHERIT_BLACKLIST 5805 SDK_INHERIT_BLACKLIST
5808 A list of classes to remove from the :term:`INHERIT` 5806 A list of classes to remove from the :term:`INHERIT`
5809 value globally within the extensible SDK configuration. The 5807 value globally within the extensible SDK configuration. The
5810 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class sets the 5808 :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
5811 default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" 5809 default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
5812 5810
5813 Some classes are not generally applicable within the extensible SDK 5811 Some classes are not generally applicable within the extensible SDK
@@ -5827,7 +5825,7 @@ system and gives an overview of their function and contents.
5827 within the extensible SDK. 5825 within the extensible SDK.
5828 5826
5829 By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the 5827 By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the
5830 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class and 5828 :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
5831 excludes the following variables: 5829 excludes the following variables:
5832 :term:`CONF_VERSION` 5830 :term:`CONF_VERSION`
5833 :term:`BB_NUMBER_THREADS` 5831 :term:`BB_NUMBER_THREADS`
@@ -5848,7 +5846,7 @@ system and gives an overview of their function and contents.
5848 A list of variables allowed through from the OpenEmbedded build 5846 A list of variables allowed through from the OpenEmbedded build
5849 system configuration into the extensible SDK configuration. By 5847 system configuration into the extensible SDK configuration. By
5850 default, the list of variables is empty and is set in the 5848 default, the list of variables is empty and is set in the
5851 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class. 5849 :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
5852 5850
5853 This list overrides the variables specified using the 5851 This list overrides the variables specified using the
5854 :term:`SDK_LOCAL_CONF_BLACKLIST` 5852 :term:`SDK_LOCAL_CONF_BLACKLIST`
@@ -5877,7 +5875,7 @@ system and gives an overview of their function and contents.
5877 5875
5878 SDK_OUTPUT 5876 SDK_OUTPUT
5879 The location used by the OpenEmbedded build system when creating SDK 5877 The location used by the OpenEmbedded build system when creating SDK
5880 output. The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ 5878 output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
5881 class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk" 5879 class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
5882 SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk" 5880 SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
5883 5881
@@ -5942,7 +5940,7 @@ system and gives an overview of their function and contents.
5942 file contains package information on a line-per-package basis as 5940 file contains package information on a line-per-package basis as
5943 follows: packagename packagearch version 5941 follows: packagename packagearch version
5944 5942
5945 The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class 5943 The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
5946 defines the manifest file as follows: SDK_TARGET_MANIFEST = 5944 defines the manifest file as follows: SDK_TARGET_MANIFEST =
5947 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location 5945 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location
5948 is derived using the :term:`SDK_DEPLOY` and 5946 is derived using the :term:`SDK_DEPLOY` and
@@ -5960,7 +5958,7 @@ system and gives an overview of their function and contents.
5960 The title to be printed when running the SDK installer. By default, 5958 The title to be printed when running the SDK installer. By default,
5961 this title is based on the :term:`DISTRO_NAME` or 5959 this title is based on the :term:`DISTRO_NAME` or
5962 :term:`DISTRO` variable and is set in the 5960 :term:`DISTRO` variable and is set in the
5963 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as 5961 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
5964 follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or 5962 follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
5965 d.getVar('DISTRO')} SDK" For the default distribution "poky", 5963 d.getVar('DISTRO')} SDK" For the default distribution "poky",
5966 ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)". 5964 ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
@@ -5993,7 +5991,7 @@ system and gives an overview of their function and contents.
5993 The default installation directory for the Extensible SDK. By 5991 The default installation directory for the Extensible SDK. By
5994 default, this directory is based on the :term:`DISTRO` 5992 default, this directory is based on the :term:`DISTRO`
5995 variable and is set in the 5993 variable and is set in the
5996 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as 5994 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
5997 follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the 5995 follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the
5998 default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk". 5996 default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
5999 5997
@@ -6135,8 +6133,8 @@ system and gives an overview of their function and contents.
6135 prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``. 6133 prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``.
6136 6134
6137 To enable file removal, set the variable to "1" in your 6135 To enable file removal, set the variable to "1" in your
6138 ``conf/local.conf`` configuration file in your: `Build 6136 ``conf/local.conf`` configuration file in your:
6139 Directory <#build-directory>`__. SKIP_FILEDEPS = "1" 6137 :term:`Build Directory`. SKIP_FILEDEPS = "1"
6140 6138
6141 SOC_FAMILY 6139 SOC_FAMILY
6142 Groups together machines based upon the same family of SOC (System On 6140 Groups together machines based upon the same family of SOC (System On
@@ -7289,8 +7287,8 @@ system and gives an overview of their function and contents.
7289 7287
7290 If you want to establish this directory in a location other than the 7288 If you want to establish this directory in a location other than the
7291 default, you can uncomment and edit the following statement in the 7289 default, you can uncomment and edit the following statement in the
7292 ``conf/local.conf`` file in the `Source 7290 ``conf/local.conf`` file in the :term:`Source Directory`:
7293 Directory <#source-directory>`__: #TMPDIR = "${TOPDIR}/tmp" An 7291 #TMPDIR = "${TOPDIR}/tmp" An
7294 example use for this scenario is to set ``TMPDIR`` to a local disk, 7292 example use for this scenario is to set ``TMPDIR`` to a local disk,
7295 which does not use NFS, while having the Build Directory use NFS. 7293 which does not use NFS, while having the Build Directory use NFS.
7296 7294
@@ -7325,7 +7323,7 @@ system and gives an overview of their function and contents.
7325 7323
7326 TOOLCHAIN_OUTPUTNAME 7324 TOOLCHAIN_OUTPUTNAME
7327 This variable defines the name used for the toolchain output. The 7325 This variable defines the name used for the toolchain output. The
7328 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class sets 7326 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets
7329 the ``TOOLCHAIN_OUTPUTNAME`` variable as follows: 7327 the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:
7330 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See 7328 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See
7331 the :term:`SDK_NAME` and 7329 the :term:`SDK_NAME` and
@@ -7374,8 +7372,8 @@ system and gives an overview of their function and contents.
7374 definitions can be a single static definition, or can be dynamically 7372 definitions can be a single static definition, or can be dynamically
7375 adjusted. You can see details for a given CPU family by looking at 7373 adjusted. You can see details for a given CPU family by looking at
7376 the architecture's ``README`` file. For example, the 7374 the architecture's ``README`` file. For example, the
7377 ``meta/conf/machine/include/mips/README`` file in the `Source 7375 ``meta/conf/machine/include/mips/README`` file in the
7378 Directory <#source-directory>`__ provides information for 7376 :term:`Source Directory` provides information for
7379 ``TUNE_ARCH`` specific to the ``mips`` architecture. 7377 ``TUNE_ARCH`` specific to the ``mips`` architecture.
7380 7378
7381 ``TUNE_ARCH`` is tied closely to 7379 ``TUNE_ARCH`` is tied closely to
@@ -7510,8 +7508,8 @@ system and gives an overview of their function and contents.
7510 ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example 7508 ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example
7511 from that file: TUNEVALID[bigendian] = "Enable big-endian mode." 7509 from that file: TUNEVALID[bigendian] = "Enable big-endian mode."
7512 7510
7513 See the machine include files in the `Source 7511 See the machine include files in the :term:`Source Directory`
7514 Directory <#source-directory>`__ for these features. 7512 for these features.
7515 7513
7516 UBOOT_CONFIG 7514 UBOOT_CONFIG
7517 Configures the :term:`UBOOT_MACHINE` and can 7515 Configures the :term:`UBOOT_MACHINE` and can
@@ -7696,8 +7694,7 @@ system and gives an overview of their function and contents.
7696 7694
7697 The default list is set in your ``local.conf`` file: USER_CLASSES ?= 7695 The default list is set in your ``local.conf`` file: USER_CLASSES ?=
7698 "buildstats image-mklibs image-prelink" For more information, see 7696 "buildstats image-mklibs image-prelink" For more information, see
7699 ``meta-poky/conf/local.conf.sample`` in the `Source 7697 ``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`.
7700 Directory <#source-directory>`__.
7701 7698
7702 USERADD_ERROR_DYNAMIC 7699 USERADD_ERROR_DYNAMIC
7703 If set to ``error``, forces the OpenEmbedded build system to produce 7700 If set to ``error``, forces the OpenEmbedded build system to produce
diff --git a/documentation/sdk-manual/sdk-appendix-customizing.rst b/documentation/sdk-manual/sdk-appendix-customizing.rst
index 8169f2bed8..3bb6ef3a19 100644
--- a/documentation/sdk-manual/sdk-appendix-customizing.rst
+++ b/documentation/sdk-manual/sdk-appendix-customizing.rst
@@ -150,7 +150,7 @@ set. If the ``DISTRO_NAME`` variable is not set, the title is derived
150from the :term:`DISTRO` variable. 150from the :term:`DISTRO` variable.
151 151
152The 152The
153```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__ 153:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
154class defines the default value of the ``SDK_TITLE`` variable as 154class defines the default value of the ``SDK_TITLE`` variable as
155follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or 155follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
156d.getVar('DISTRO')} SDK" 156d.getVar('DISTRO')} SDK"
@@ -212,7 +212,7 @@ installation directory for the SDK is based on the
212:term:`DISTRO` and 212:term:`DISTRO` and
213:term:`SDKEXTPATH` variables from 213:term:`SDKEXTPATH` variables from
214within the 214within the
215```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__ 215:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
216class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can 216class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can
217change this default installation directory by specifically setting the 217change this default installation directory by specifically setting the
218``SDKEXTPATH`` variable. 218``SDKEXTPATH`` variable.
@@ -276,8 +276,8 @@ source, you need to do a number of things:
276 276
277 - Alternatively, if you just want to set the ``SSTATE_MIRRORS`` 277 - Alternatively, if you just want to set the ``SSTATE_MIRRORS``
278 variable's value for the SDK alone, create a 278 variable's value for the SDK alone, create a
279 ``conf/sdk-extra.conf`` file either in your `Build 279 ``conf/sdk-extra.conf`` file either in your
280 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ or within any 280 :term:`Build Directory` or within any
281 layer and put your ``SSTATE_MIRRORS`` setting within that file. 281 layer and put your ``SSTATE_MIRRORS`` setting within that file.
282 282
283 .. note:: 283 .. note::
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.rst b/documentation/sdk-manual/sdk-appendix-obtain.rst
index c6efdf674c..015506de01 100644
--- a/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/documentation/sdk-manual/sdk-appendix-obtain.rst
@@ -70,8 +70,8 @@ build the SDK installer. Follow these steps:
70 machine that uses CROPS. 70 machine that uses CROPS.
71 71
722. *Clone the ``poky`` Repository:* You need to have a local copy of the 722. *Clone the ``poky`` Repository:* You need to have a local copy of the
73 Yocto Project `Source 73 Yocto Project :term:`Source Directory`
74 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local 74 (i.e. a local
75 ``poky`` repository). See the "`Cloning the ``poky`` 75 ``poky`` repository). See the "`Cloning the ``poky``
76 Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and 76 Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and
77 possibly the "`Checking Out by Branch in 77 possibly the "`Checking Out by Branch in
@@ -87,8 +87,8 @@ build the SDK installer. Follow these steps:
87 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment 87 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment
88 setup script to define the OpenEmbedded build environment on your 88 setup script to define the OpenEmbedded build environment on your
89 build host. $ source OE_INIT_FILE Among other things, the script 89 build host. $ source OE_INIT_FILE Among other things, the script
90 creates the `Build 90 creates the :term:`Build Directory`,
91 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is 91 which is
92 ``build`` in this case and is located in the Source Directory. After 92 ``build`` in this case and is located in the Source Directory. After
93 the script runs, your current working directory is set to the 93 the script runs, your current working directory is set to the
94 ``build`` directory. 94 ``build`` directory.
diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/sdk-extensible.rst
index 17cd08a25c..3df2174fd9 100644
--- a/documentation/sdk-manual/sdk-extensible.rst
+++ b/documentation/sdk-manual/sdk-extensible.rst
@@ -9,8 +9,8 @@ Information covers the pieces of the SDK, how to install it, and
9presents a look at using the ``devtool`` functionality. The extensible 9presents a look at using the ``devtool`` functionality. The extensible
10SDK makes it easy to add new applications and libraries to an image, 10SDK makes it easy to add new applications and libraries to an image,
11modify the source for an existing component, test changes on the target 11modify the source for an existing component, test changes on the target
12hardware, and ease integration into the rest of the `OpenEmbedded build 12hardware, and ease integration into the rest of the
13system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. 13:term:`OpenEmbedded Build System`.
14 14
15.. note:: 15.. note::
16 16
diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
index fcb15a8592..88238d7dd4 100644
--- a/documentation/sdk-manual/sdk-intro.rst
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -39,8 +39,7 @@ All SDKs consist of the following:
39Additionally, an extensible SDK has tools that allow you to easily add 39Additionally, an extensible SDK has tools that allow you to easily add
40new applications and libraries to an image, modify the source of an 40new applications and libraries to an image, modify the source of an
41existing component, test changes on the target hardware, and easily 41existing component, test changes on the target hardware, and easily
42integrate an application into the `OpenEmbedded build 42integrate an application into the :term:`OpenEmbedded Build System`.
43system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
44 43
45You can use an SDK to independently develop and test code that is 44You can use an SDK to independently develop and test code that is
46destined to run on some target machine. SDKs are completely 45destined to run on some target machine. SDKs are completely
@@ -126,8 +125,7 @@ of a cross-compiler, cross-linker, and cross-debugger that are used to
126develop user-space applications for targeted hardware. Additionally, for 125develop user-space applications for targeted hardware. Additionally, for
127an extensible SDK, the toolchain also has built-in ``devtool`` 126an extensible SDK, the toolchain also has built-in ``devtool``
128functionality. This toolchain is created by running a SDK installer 127functionality. This toolchain is created by running a SDK installer
129script or through a `Build 128script or through a :term:`Build Directory` that is based on
130Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ that is based on
131your metadata configuration or extension for your targeted device. The 129your metadata configuration or extension for your targeted device. The
132cross-toolchain works with a matching target sysroot. 130cross-toolchain works with a matching target sysroot.
133 131
@@ -149,8 +147,8 @@ The QEMU emulator allows you to simulate your hardware while running
149your application or image. QEMU is not part of the SDK but is made 147your application or image. QEMU is not part of the SDK but is made
150available a number of different ways: 148available a number of different ways:
151 149
152- If you have cloned the ``poky`` Git repository to create a `Source 150- If you have cloned the ``poky`` Git repository to create a
153 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and you have 151 :term:`Source Directory` and you have
154 sourced the environment setup script, QEMU is installed and 152 sourced the environment setup script, QEMU is installed and
155 automatically available. 153 automatically available.
156 154
diff --git a/documentation/sdk-manual/sdk-working-projects.rst b/documentation/sdk-manual/sdk-working-projects.rst
index 63f61de66d..d18568d60a 100644
--- a/documentation/sdk-manual/sdk-working-projects.rst
+++ b/documentation/sdk-manual/sdk-working-projects.rst
@@ -14,8 +14,7 @@ Once you have a suitable `cross-development
14toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__ 14toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__
15installed, it is very easy to develop a project using the `GNU 15installed, it is very easy to develop a project using the `GNU
16Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__ 16Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__
17workflow, which is outside of the `OpenEmbedded build 17workflow, which is outside of the :term:`OpenEmbedded Build System`.
18system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
19 18
20The following figure presents a simple Autotools workflow. 19The following figure presents a simple Autotools workflow.
21 20
diff --git a/documentation/toaster-manual/toaster-manual-intro.rst b/documentation/toaster-manual/toaster-manual-intro.rst
index ec50be5a91..bc4298dfce 100644
--- a/documentation/toaster-manual/toaster-manual-intro.rst
+++ b/documentation/toaster-manual/toaster-manual-intro.rst
@@ -4,8 +4,8 @@
4Introduction 4Introduction
5************ 5************
6 6
7Toaster is a web interface to the Yocto Project's `OpenEmbedded build 7Toaster is a web interface to the Yocto Project's
8system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface 8:term:`OpenEmbedded Build System`. The interface
9enables you to configure and run your builds. Information about builds 9enables you to configure and run your builds. Information about builds
10is collected and stored in a database. You can use Toaster to configure 10is collected and stored in a database. You can use Toaster to configure
11and start builds on multiple remote build servers. 11and start builds on multiple remote build servers.
diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst
index c98a27eeb8..d799b4b99b 100644
--- a/documentation/toaster-manual/toaster-manual-reference.rst
+++ b/documentation/toaster-manual/toaster-manual-reference.rst
@@ -422,15 +422,15 @@ at the
422`Django <https://docs.djangoproject.com/en/1.7/topics/settings/>`__ 422`Django <https://docs.djangoproject.com/en/1.7/topics/settings/>`__
423site. However, several ``manage.py`` commands have been created that are 423site. However, several ``manage.py`` commands have been created that are
424specific to Toaster and are used to control configuration and back-end 424specific to Toaster and are used to control configuration and back-end
425tasks. You can locate these commands in the `Source 425tasks. You can locate these commands in the
426Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``) at 426:term:`Source Directory` (e.g. ``poky``) at
427``bitbake/lib/manage.py``. This section documents those commands. 427``bitbake/lib/manage.py``. This section documents those commands.
428 428
429.. note:: 429.. note::
430 430
431 - When using ``manage.py`` commands given a default configuration, 431 - When using ``manage.py`` commands given a default configuration,
432 you must be sure that your working directory is set to the `Build 432 you must be sure that your working directory is set to the
433 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. Using 433 :term:`Build Directory`. Using
434 ``manage.py`` commands from the Build Directory allows Toaster to 434 ``manage.py`` commands from the Build Directory allows Toaster to
435 find the ``toaster.sqlite`` file, which is located in the Build 435 find the ``toaster.sqlite`` file, which is located in the Build
436 Directory. 436 Directory.
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
index 7e715403d0..360270afbf 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
@@ -12,8 +12,8 @@ dependencies as described in the "`Preparing to Use
12Toaster <#toaster-manual-start>`__" chapter, you are ready to start 12Toaster <#toaster-manual-start>`__" chapter, you are ready to start
13Toaster. 13Toaster.
14 14
15Navigate to the root of your `Source 15Navigate to the root of your
16Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``): $ 16:term:`Source Directory` (e.g. ``poky``): $
17cd poky Once in that directory, source the build environment script: $ 17cd poky Once in that directory, source the build environment script: $
18source oe-init-build-env Next, from the build directory (e.g. 18source oe-init-build-env Next, from the build directory (e.g.
19``poky/build``), start Toaster using this command: $ source toaster 19``poky/build``), start Toaster using this command: $ source toaster
@@ -267,8 +267,8 @@ Perform the following steps to install Toaster:
267 the "`Configuring Toaster <#configuring-toaster>`__" section. 267 the "`Configuring Toaster <#configuring-toaster>`__" section.
268 268
269 This line also runs the ``checksettings`` command, which configures 269 This line also runs the ``checksettings`` command, which configures
270 the location of the Toaster `Build 270 the location of the Toaster :term:`Build Directory`.
271 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The Toaster 271 The Toaster
272 root directory ``TOASTER_DIR`` determines where the Toaster build 272 root directory ``TOASTER_DIR`` determines where the Toaster build
273 directory is created on the file system. In the example above, 273 directory is created on the file system. In the example above,
274 ``TOASTER_DIR`` is set as follows: /var/www/toaster/poky This 274 ``TOASTER_DIR`` is set as follows: /var/www/toaster/poky This
diff --git a/documentation/toaster-manual/toaster-manual-start.rst b/documentation/toaster-manual/toaster-manual-start.rst
index 439952e15e..1114c04eab 100644
--- a/documentation/toaster-manual/toaster-manual-start.rst
+++ b/documentation/toaster-manual/toaster-manual-start.rst
@@ -28,8 +28,8 @@ Establishing Toaster System Dependencies
28Toaster requires extra Python dependencies in order to run. A Toaster 28Toaster requires extra Python dependencies in order to run. A Toaster
29requirements file named ``toaster-requirements.txt`` defines the Python 29requirements file named ``toaster-requirements.txt`` defines the Python
30dependencies. The requirements file is located in the ``bitbake`` 30dependencies. The requirements file is located in the ``bitbake``
31directory, which is located in the root directory of the `Source 31directory, which is located in the root directory of the
32Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. 32:term:`Source Directory` (e.g.
33``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a 33``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a
34``pip``, install-compatible format. 34``pip``, install-compatible format.
35 35