summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorQuentin Schulz <foss@0leil.net>2021-05-27 20:41:17 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2021-06-19 16:54:01 +0100
commit7d3f57cfd2e4322bcd96d67d330124f221a9aedd (patch)
tree5d07321b7c8bc59bb7fcc0372fab8b7a1966cf06 /documentation
parent7a9b74e9d2a5cf3b1fb3ac7565c50eae6e0d4632 (diff)
downloadpoky-7d3f57cfd2e4322bcd96d67d330124f221a9aedd.tar.gz
docs: replace ``FOO`` by :term:`FOO` where possible
If a variable has a glossary entry and some rST files write about those variables, it's better to point to the glossary entry instead of just highlighting it by surrounding it with two tick quotes. This was automated by the following python script: """ import re from pathlib import Path with open('objects.inv.txt', 'r') as f: objects = f.readlines() with open('bitbake-objects.inv.txt', 'r') as f: objects = objects + f.readlines() re_term = re.compile(r'variables.html#term-([A-Z_0-9]*)') terms = [] for obj in objects: match = re_term.search(obj) if match and match.group(1): terms.append(match.group(1)) for rst in Path('.').rglob('*.rst'): with open(rst, 'r') as f: content = "".joing(f.readlines()) for term in terms: content = re.sub(r'``({})``(?!.*\s*[~-]+)'.format(term), r':term:`\1`', content) with open(rst, 'w') as f: f.write(content) """ (From yocto-docs rev: ba49d9babfcb84bc5c26a68c8c3880a1d9c236d3) Signed-off-by: Quentin Schulz <foss@0leil.net> Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/brief-yoctoprojectqs/index.rst2
-rw-r--r--documentation/bsp-guide/bsp.rst16
-rw-r--r--documentation/dev-manual/common-tasks.rst386
-rw-r--r--documentation/kernel-dev/advanced.rst56
-rw-r--r--documentation/kernel-dev/common.rst52
-rw-r--r--documentation/kernel-dev/faq.rst2
-rw-r--r--documentation/kernel-dev/maint-appx.rst2
-rw-r--r--documentation/migration-guides/migration-1.3.rst4
-rw-r--r--documentation/migration-guides/migration-1.4.rst14
-rw-r--r--documentation/migration-guides/migration-1.5.rst22
-rw-r--r--documentation/migration-guides/migration-1.6.rst12
-rw-r--r--documentation/migration-guides/migration-1.7.rst4
-rw-r--r--documentation/migration-guides/migration-1.8.rst4
-rw-r--r--documentation/migration-guides/migration-2.0.rst4
-rw-r--r--documentation/migration-guides/migration-2.1.rst8
-rw-r--r--documentation/migration-guides/migration-2.2.rst6
-rw-r--r--documentation/migration-guides/migration-2.3.rst20
-rw-r--r--documentation/migration-guides/migration-2.4.rst4
-rw-r--r--documentation/migration-guides/migration-2.5.rst2
-rw-r--r--documentation/migration-guides/migration-2.6.rst22
-rw-r--r--documentation/migration-guides/migration-2.7.rst2
-rw-r--r--documentation/migration-guides/migration-3.1.rst2
-rw-r--r--documentation/migration-guides/migration-3.2.rst6
-rw-r--r--documentation/overview-manual/concepts.rst72
-rw-r--r--documentation/ref-manual/classes.rst74
-rw-r--r--documentation/ref-manual/faq.rst16
-rw-r--r--documentation/ref-manual/features.rst22
-rw-r--r--documentation/ref-manual/qa-checks.rst26
-rw-r--r--documentation/ref-manual/structure.rst16
-rw-r--r--documentation/ref-manual/tasks.rst12
-rw-r--r--documentation/ref-manual/terms.rst6
-rw-r--r--documentation/ref-manual/variables.rst1184
-rw-r--r--documentation/sdk-manual/appendix-customizing-standard.rst4
-rw-r--r--documentation/sdk-manual/appendix-customizing.rst24
-rw-r--r--documentation/sdk-manual/extensible.rst50
-rw-r--r--documentation/sdk-manual/working-projects.rst12
-rw-r--r--documentation/toaster-manual/setup-and-use.rst2
-rw-r--r--documentation/transitioning-to-a-custom-environment.rst2
38 files changed, 1087 insertions, 1087 deletions
diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index 7ae4526c42..b92b0d33d9 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -332,7 +332,7 @@ Follow these steps to add a hardware layer:
332#. **Change the Configuration to Build for a Specific Machine:** The 332#. **Change the Configuration to Build for a Specific Machine:** The
333 :term:`MACHINE` variable in the 333 :term:`MACHINE` variable in the
334 ``local.conf`` file specifies the machine for the build. For this 334 ``local.conf`` file specifies the machine for the build. For this
335 example, set the ``MACHINE`` variable to ``cyclone5``. These 335 example, set the :term:`MACHINE` variable to ``cyclone5``. These
336 configurations are used: 336 configurations are used:
337 https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf. 337 https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf.
338 338
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index b46773dedd..5c43f53d0c 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -95,11 +95,11 @@ layer and from it build an image. Here is an example::
95 95
96.. note:: 96.. note::
97 97
98 Ordering and :term:`BBFILE_PRIORITY` for the layers listed in ``BBLAYERS`` 98 Ordering and :term:`BBFILE_PRIORITY` for the layers listed in :term:`BBLAYERS`
99 matter. For example, if multiple layers define a machine configuration, the 99 matter. For example, if multiple layers define a machine configuration, the
100 OpenEmbedded build system uses the last layer searched given similar layer 100 OpenEmbedded build system uses the last layer searched given similar layer
101 priorities. The build system works from the top-down through the layers 101 priorities. The build system works from the top-down through the layers
102 listed in ``BBLAYERS``. 102 listed in :term:`BBLAYERS`.
103 103
104Some BSPs require or depend on additional layers beyond the BSP's root 104Some BSPs require or depend on additional layers beyond the BSP's root
105layer in order to be functional. In this case, you need to specify these 105layer in order to be functional. In this case, you need to specify these
@@ -685,7 +685,7 @@ statements as follows::
685 685
686.. note:: 686.. note::
687 687
688 When the preferred provider is assumed by default, the ``PREFERRED_PROVIDER`` 688 When the preferred provider is assumed by default, the :term:`PREFERRED_PROVIDER`
689 statement does not appear in the ``"bsp_root_name".conf`` file. 689 statement does not appear in the ``"bsp_root_name".conf`` file.
690 690
691You would use the ``linux-yocto_4.4.bbappend`` file to append specific 691You would use the ``linux-yocto_4.4.bbappend`` file to append specific
@@ -1121,15 +1121,15 @@ list describes them in order of preference:
1121 how to use these variables. 1121 how to use these variables.
1122 1122
1123 If you build as you normally would, without specifying any recipes in 1123 If you build as you normally would, without specifying any recipes in
1124 the ``LICENSE_FLAGS_WHITELIST``, the build stops and provides you 1124 the :term:`LICENSE_FLAGS_WHITELIST`, the build stops and provides you
1125 with the list of recipes that you have tried to include in the image 1125 with the list of recipes that you have tried to include in the image
1126 that need entries in the ``LICENSE_FLAGS_WHITELIST``. Once you enter 1126 that need entries in the :term:`LICENSE_FLAGS_WHITELIST`. Once you enter
1127 the appropriate license flags into the whitelist, restart the build 1127 the appropriate license flags into the whitelist, restart the build
1128 to continue where it left off. During the build, the prompt will not 1128 to continue where it left off. During the build, the prompt will not
1129 appear again since you have satisfied the requirement. 1129 appear again since you have satisfied the requirement.
1130 1130
1131 Once the appropriate license flags are on the white list in the 1131 Once the appropriate license flags are on the white list in the
1132 ``LICENSE_FLAGS_WHITELIST`` variable, you can build the encumbered 1132 :term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered
1133 image with no change at all to the normal build process. 1133 image with no change at all to the normal build process.
1134 1134
1135#. *Get a Pre-Built Version of the BSP:* You can get this type of BSP by 1135#. *Get a Pre-Built Version of the BSP:* You can get this type of BSP by
@@ -1142,7 +1142,7 @@ list describes them in order of preference:
1142 click-through license agreements presented by the website. If you 1142 click-through license agreements presented by the website. If you
1143 want to build the image yourself using the recipes contained within 1143 want to build the image yourself using the recipes contained within
1144 the BSP tarball, you will still need to create an appropriate 1144 the BSP tarball, you will still need to create an appropriate
1145 ``LICENSE_FLAGS_WHITELIST`` to match the encumbered recipes in the 1145 :term:`LICENSE_FLAGS_WHITELIST` to match the encumbered recipes in the
1146 BSP. 1146 BSP.
1147 1147
1148.. note:: 1148.. note::
@@ -1405,7 +1405,7 @@ Project Reference Manual.
1405 1405
1406 The BeagleBone development board requires an SPL to boot and that SPL 1406 The BeagleBone development board requires an SPL to boot and that SPL
1407 file type must be MLO. Consequently, the machine configuration needs 1407 file type must be MLO. Consequently, the machine configuration needs
1408 to define ``SPL_BINARY`` as ``MLO``. 1408 to define :term:`SPL_BINARY` as ``MLO``.
1409 1409
1410 .. note:: 1410 .. note::
1411 1411
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 1307341730..762636a17c 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -94,10 +94,10 @@ Follow these general steps to create your layer without using tools:
94 94
95 - :term:`BBPATH`: Adds the layer's 95 - :term:`BBPATH`: Adds the layer's
96 root directory to BitBake's search path. Through the use of the 96 root directory to BitBake's search path. Through the use of the
97 ``BBPATH`` variable, BitBake locates class files (``.bbclass``), 97 :term:`BBPATH` variable, BitBake locates class files (``.bbclass``),
98 configuration files, and files that are included with ``include`` 98 configuration files, and files that are included with ``include``
99 and ``require`` statements. For these cases, BitBake uses the 99 and ``require`` statements. For these cases, BitBake uses the
100 first file that matches the name found in ``BBPATH``. This is 100 first file that matches the name found in :term:`BBPATH`. This is
101 similar to the way the ``PATH`` variable is used for binaries. It 101 similar to the way the ``PATH`` variable is used for binaries. It
102 is recommended, therefore, that you use unique class and 102 is recommended, therefore, that you use unique class and
103 configuration filenames in your custom layer. 103 configuration filenames in your custom layer.
@@ -205,7 +205,7 @@ following list:
205 ``foo``. 205 ``foo``.
206 206
207 To make sure your changes apply only when building machine "one", 207 To make sure your changes apply only when building machine "one",
208 use a machine override with the ``DEPENDS`` statement:: 208 use a machine override with the :term:`DEPENDS` statement::
209 209
210 DEPENDS_one = "foo" 210 DEPENDS_one = "foo"
211 211
@@ -255,7 +255,7 @@ following list:
255 are building for a different machine and the ``bblayers.conf`` 255 are building for a different machine and the ``bblayers.conf``
256 file includes the ``meta-one`` layer and the location of your 256 file includes the ``meta-one`` layer and the location of your
257 machine-specific file is the first location where that file is 257 machine-specific file is the first location where that file is
258 found according to ``FILESPATH``, builds for all machines will 258 found according to :term:`FILESPATH`, builds for all machines will
259 also use that machine-specific file. 259 also use that machine-specific file.
260 260
261 You can make sure that a machine-specific file is used for a 261 You can make sure that a machine-specific file is used for a
@@ -420,7 +420,7 @@ Enabling Your Layer
420 420
421Before the OpenEmbedded build system can use your new layer, you need to 421Before the OpenEmbedded build system can use your new layer, you need to
422enable it. To enable your layer, simply add your layer's path to the 422enable it. To enable your layer, simply add your layer's path to the
423``BBLAYERS`` variable in your ``conf/bblayers.conf`` file, which is 423:term:`BBLAYERS` variable in your ``conf/bblayers.conf`` file, which is
424found in the :term:`Build Directory`. 424found in the :term:`Build Directory`.
425The following example shows how to enable a layer named 425The following example shows how to enable a layer named
426``meta-mylayer``:: 426``meta-mylayer``::
@@ -438,7 +438,7 @@ The following example shows how to enable a layer named
438 " 438 "
439 439
440BitBake parses each ``conf/layer.conf`` file from the top down as 440BitBake parses each ``conf/layer.conf`` file from the top down as
441specified in the ``BBLAYERS`` variable within the ``conf/bblayers.conf`` 441specified in the :term:`BBLAYERS` variable within the ``conf/bblayers.conf``
442file. During the processing of each ``conf/layer.conf`` file, BitBake 442file. During the processing of each ``conf/layer.conf`` file, BitBake
443adds the recipes, classes and configurations contained within the 443adds the recipes, classes and configurations contained within the
444particular layer to the source directory. 444particular layer to the source directory.
@@ -531,19 +531,19 @@ have the supporting directory structure set up that will contain any
531files or patches you will be including from the layer. 531files or patches you will be including from the layer.
532 532
533Using the immediate expansion assignment operator ``:=`` is important 533Using the immediate expansion assignment operator ``:=`` is important
534because of the reference to ``THISDIR``. The trailing colon character is 534because of the reference to :term:`THISDIR`. The trailing colon character is
535important as it ensures that items in the list remain colon-separated. 535important as it ensures that items in the list remain colon-separated.
536 536
537.. note:: 537.. note::
538 538
539 BitBake automatically defines the ``THISDIR`` variable. You should 539 BitBake automatically defines the :term:`THISDIR` variable. You should
540 never set this variable yourself. Using "_prepend" as part of the 540 never set this variable yourself. Using "_prepend" as part of the
541 ``FILESEXTRAPATHS`` ensures your path will be searched prior to other 541 :term:`FILESEXTRAPATHS` ensures your path will be searched prior to other
542 paths in the final list. 542 paths in the final list.
543 543
544 Also, not all append files add extra files. Many append files simply 544 Also, not all append files add extra files. Many append files simply
545 allow to add build options (e.g. ``systemd``). For these cases, your 545 allow to add build options (e.g. ``systemd``). For these cases, your
546 append file would not even use the ``FILESEXTRAPATHS`` statement. 546 append file would not even use the :term:`FILESEXTRAPATHS` statement.
547 547
548Prioritizing Your Layer 548Prioritizing Your Layer
549----------------------- 549-----------------------
@@ -830,7 +830,7 @@ variable changes are in effect for every build and consequently affect
830all images, which might not be what you require. 830all images, which might not be what you require.
831 831
832To add a package to your image using the local configuration file, use 832To add a package to your image using the local configuration file, use
833the ``IMAGE_INSTALL`` variable with the ``_append`` operator:: 833the :term:`IMAGE_INSTALL` variable with the ``_append`` operator::
834 834
835 IMAGE_INSTALL_append = " strace" 835 IMAGE_INSTALL_append = " strace"
836 836
@@ -855,7 +855,7 @@ to a specific image only. Here is an example::
855This example adds ``strace`` to the ``core-image-minimal`` image only. 855This example adds ``strace`` to the ``core-image-minimal`` image only.
856 856
857You can add packages using a similar approach through the 857You can add packages using a similar approach through the
858``CORE_IMAGE_EXTRA_INSTALL`` variable. If you use this variable, only 858:term:`CORE_IMAGE_EXTRA_INSTALL` variable. If you use this variable, only
859``core-image-*`` images are affected. 859``core-image-*`` images are affected.
860 860
861Customizing Images Using Custom ``IMAGE_FEATURES`` and ``EXTRA_IMAGE_FEATURES`` 861Customizing Images Using Custom ``IMAGE_FEATURES`` and ``EXTRA_IMAGE_FEATURES``
@@ -866,18 +866,18 @@ high-level image features by using the
866:term:`IMAGE_FEATURES` and 866:term:`IMAGE_FEATURES` and
867:term:`EXTRA_IMAGE_FEATURES` 867:term:`EXTRA_IMAGE_FEATURES`
868variables. Although the functions for both variables are nearly 868variables. Although the functions for both variables are nearly
869equivalent, best practices dictate using ``IMAGE_FEATURES`` from within 869equivalent, best practices dictate using :term:`IMAGE_FEATURES` from within
870a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your 870a recipe and using :term:`EXTRA_IMAGE_FEATURES` from within your
871``local.conf`` file, which is found in the 871``local.conf`` file, which is found in the
872:term:`Build Directory`. 872:term:`Build Directory`.
873 873
874To understand how these features work, the best reference is 874To understand how these features work, the best reference is
875``meta/classes/core-image.bbclass``. This class lists out the available 875``meta/classes/core-image.bbclass``. This class lists out the available
876``IMAGE_FEATURES`` of which most map to package groups while some, such 876:term:`IMAGE_FEATURES` of which most map to package groups while some, such
877as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general 877as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general
878configuration settings. 878configuration settings.
879 879
880In summary, the file looks at the contents of the ``IMAGE_FEATURES`` 880In summary, the file looks at the contents of the :term:`IMAGE_FEATURES`
881variable and then maps or configures the feature accordingly. Based on 881variable and then maps or configures the feature accordingly. Based on
882this information, the build system automatically adds the appropriate 882this information, the build system automatically adds the appropriate
883packages or configurations to the 883packages or configurations to the
@@ -885,11 +885,11 @@ packages or configurations to the
885Effectively, you are enabling extra features by extending the class or 885Effectively, you are enabling extra features by extending the class or
886creating a custom class for use with specialized image ``.bb`` files. 886creating a custom class for use with specialized image ``.bb`` files.
887 887
888Use the ``EXTRA_IMAGE_FEATURES`` variable from within your local 888Use the :term:`EXTRA_IMAGE_FEATURES` variable from within your local
889configuration file. Using a separate area from which to enable features 889configuration file. Using a separate area from which to enable features
890with this variable helps you avoid overwriting the features in the image 890with this variable helps you avoid overwriting the features in the image
891recipe that are enabled with ``IMAGE_FEATURES``. The value of 891recipe that are enabled with :term:`IMAGE_FEATURES`. The value of
892``EXTRA_IMAGE_FEATURES`` is added to ``IMAGE_FEATURES`` within 892:term:`EXTRA_IMAGE_FEATURES` is added to :term:`IMAGE_FEATURES` within
893``meta/conf/bitbake.conf``. 893``meta/conf/bitbake.conf``.
894 894
895To illustrate how you can use these variables to modify your image, 895To illustrate how you can use these variables to modify your image,
@@ -903,8 +903,8 @@ images both include OpenSSH. The ``core-image-minimal`` image does not
903contain an SSH server. 903contain an SSH server.
904 904
905You can customize your image and change these defaults. Edit the 905You can customize your image and change these defaults. Edit the
906``IMAGE_FEATURES`` variable in your recipe or use the 906:term:`IMAGE_FEATURES` variable in your recipe or use the
907``EXTRA_IMAGE_FEATURES`` in your ``local.conf`` file so that it 907:term:`EXTRA_IMAGE_FEATURES` in your ``local.conf`` file so that it
908configures the image you are working with to include 908configures the image you are working with to include
909``ssh-server-dropbear`` or ``ssh-server-openssh``. 909``ssh-server-dropbear`` or ``ssh-server-openssh``.
910 910
@@ -926,7 +926,7 @@ the form for the two lines you need::
926 926
927Defining the software using a custom recipe gives you total control over 927Defining the software using a custom recipe gives you total control over
928the contents of the image. It is important to use the correct names of 928the contents of the image. It is important to use the correct names of
929packages in the ``IMAGE_INSTALL`` variable. You must use the 929packages in the :term:`IMAGE_INSTALL` variable. You must use the
930OpenEmbedded notation and not the Debian notation for the names (e.g. 930OpenEmbedded notation and not the Debian notation for the names (e.g.
931``glibc-dev`` instead of ``libc6-dev``). 931``glibc-dev`` instead of ``libc6-dev``).
932 932
@@ -946,25 +946,25 @@ to create a custom package group recipe that is used to build the image
946or images. A good example of a package group recipe is 946or images. A good example of a package group recipe is
947``meta/recipes-core/packagegroups/packagegroup-base.bb``. 947``meta/recipes-core/packagegroups/packagegroup-base.bb``.
948 948
949If you examine that recipe, you see that the ``PACKAGES`` variable lists 949If you examine that recipe, you see that the :term:`PACKAGES` variable lists
950the package group packages to produce. The ``inherit packagegroup`` 950the package group packages to produce. The ``inherit packagegroup``
951statement sets appropriate default values and automatically adds 951statement sets appropriate default values and automatically adds
952``-dev``, ``-dbg``, and ``-ptest`` complementary packages for each 952``-dev``, ``-dbg``, and ``-ptest`` complementary packages for each
953package specified in the ``PACKAGES`` statement. 953package specified in the :term:`PACKAGES` statement.
954 954
955.. note:: 955.. note::
956 956
957 The ``inherit packagegroup`` line should be located near the top of the 957 The ``inherit packagegroup`` line should be located near the top of the
958 recipe, certainly before the ``PACKAGES`` statement. 958 recipe, certainly before the :term:`PACKAGES` statement.
959 959
960For each package you specify in ``PACKAGES``, you can use ``RDEPENDS`` 960For each package you specify in :term:`PACKAGES`, you can use :term:`RDEPENDS`
961and ``RRECOMMENDS`` entries to provide a list of packages the parent 961and :term:`RRECOMMENDS` entries to provide a list of packages the parent
962task package should contain. You can see examples of these further down 962task package should contain. You can see examples of these further down
963in the ``packagegroup-base.bb`` recipe. 963in the ``packagegroup-base.bb`` recipe.
964 964
965Here is a short, fabricated example showing the same basic pieces for a 965Here is a short, fabricated example showing the same basic pieces for a
966hypothetical packagegroup defined in ``packagegroup-custom.bb``, where 966hypothetical packagegroup defined in ``packagegroup-custom.bb``, where
967the variable ``PN`` is the standard way to abbreviate the reference to 967the variable :term:`PN` is the standard way to abbreviate the reference to
968the full packagegroup name ``packagegroup-custom``:: 968the full packagegroup name ``packagegroup-custom``::
969 969
970 DESCRIPTION = "My Custom Package Groups" 970 DESCRIPTION = "My Custom Package Groups"
@@ -994,7 +994,7 @@ their dependencies and their recommended package dependencies listed:
994``packagegroup-custom-apps``, and ``packagegroup-custom-tools``. To 994``packagegroup-custom-apps``, and ``packagegroup-custom-tools``. To
995build an image using these package group packages, you need to add 995build an image using these package group packages, you need to add
996``packagegroup-custom-apps`` and/or ``packagegroup-custom-tools`` to 996``packagegroup-custom-apps`` and/or ``packagegroup-custom-tools`` to
997``IMAGE_INSTALL``. For other forms of image dependencies see the other 997:term:`IMAGE_INSTALL`. For other forms of image dependencies see the other
998areas of this section. 998areas of this section.
999 999
1000Customizing an Image Hostname 1000Customizing an Image Hostname
@@ -1142,7 +1142,7 @@ Following are some syntax examples:
1142 1142
1143 - Use this syntax to generate a recipe using code that 1143 - Use this syntax to generate a recipe using code that
1144 you extract from source. The extracted code is placed in its own layer 1144 you extract from source. The extracted code is placed in its own layer
1145 defined by ``EXTERNALSRC``. 1145 defined by :term:`EXTERNALSRC`.
1146 :: 1146 ::
1147 1147
1148 recipetool create -o OUTFILE -x EXTERNALSRC source 1148 recipetool create -o OUTFILE -x EXTERNALSRC source
@@ -1288,22 +1288,22 @@ Fetching Code
1288The first thing your recipe must do is specify how to fetch the source 1288The first thing your recipe must do is specify how to fetch the source
1289files. Fetching is controlled mainly through the 1289files. Fetching is controlled mainly through the
1290:term:`SRC_URI` variable. Your recipe 1290:term:`SRC_URI` variable. Your recipe
1291must have a ``SRC_URI`` variable that points to where the source is 1291must have a :term:`SRC_URI` variable that points to where the source is
1292located. For a graphical representation of source locations, see the 1292located. For a graphical representation of source locations, see the
1293":ref:`overview-manual/concepts:sources`" section in 1293":ref:`overview-manual/concepts:sources`" section in
1294the Yocto Project Overview and Concepts Manual. 1294the Yocto Project Overview and Concepts Manual.
1295 1295
1296The :ref:`ref-tasks-fetch` task uses 1296The :ref:`ref-tasks-fetch` task uses
1297the prefix of each entry in the ``SRC_URI`` variable value to determine 1297the prefix of each entry in the :term:`SRC_URI` variable value to determine
1298which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to get your 1298which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to get your
1299source files. It is the ``SRC_URI`` variable that triggers the fetcher. 1299source files. It is the :term:`SRC_URI` variable that triggers the fetcher.
1300The :ref:`ref-tasks-patch` task uses 1300The :ref:`ref-tasks-patch` task uses
1301the variable after source is fetched to apply patches. The OpenEmbedded 1301the variable after source is fetched to apply patches. The OpenEmbedded
1302build system uses 1302build system uses
1303:term:`FILESOVERRIDES` for 1303:term:`FILESOVERRIDES` for
1304scanning directory locations for local files in ``SRC_URI``. 1304scanning directory locations for local files in :term:`SRC_URI`.
1305 1305
1306The ``SRC_URI`` variable in your recipe must define each unique location 1306The :term:`SRC_URI` variable in your recipe must define each unique location
1307for your source files. It is good practice to not hard-code version 1307for your source files. It is good practice to not hard-code version
1308numbers in a URL used in ``SRC_URI``. Rather than hard-code these 1308numbers in a URL used in ``SRC_URI``. Rather than hard-code these
1309values, use ``${``\ :term:`PV`\ ``}``, 1309values, use ``${``\ :term:`PV`\ ``}``,
@@ -1319,7 +1319,7 @@ comes from a single tarball. Notice the use of the
1319 1319
1320 SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \ 1320 SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
1321 1321
1322Files mentioned in ``SRC_URI`` whose names end in a typical archive 1322Files mentioned in :term:`SRC_URI` whose names end in a typical archive
1323extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so 1323extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so
1324forth), are automatically extracted during the 1324forth), are automatically extracted during the
1325:ref:`ref-tasks-unpack` task. For 1325:ref:`ref-tasks-unpack` task. For
@@ -1341,17 +1341,17 @@ is an example from the recipe
1341 SRC_URI = "git://git.kernel.dk/blktrace.git \ 1341 SRC_URI = "git://git.kernel.dk/blktrace.git \
1342 file://ldflags.patch" 1342 file://ldflags.patch"
1343 1343
1344If your ``SRC_URI`` statement includes URLs pointing to individual files 1344If your :term:`SRC_URI` statement includes URLs pointing to individual files
1345fetched from a remote server other than a version control system, 1345fetched from a remote server other than a version control system,
1346BitBake attempts to verify the files against checksums defined in your 1346BitBake attempts to verify the files against checksums defined in your
1347recipe to ensure they have not been tampered with or otherwise modified 1347recipe to ensure they have not been tampered with or otherwise modified
1348since the recipe was written. Two checksums are used: 1348since the recipe was written. Two checksums are used:
1349``SRC_URI[md5sum]`` and ``SRC_URI[sha256sum]``. 1349``SRC_URI[md5sum]`` and ``SRC_URI[sha256sum]``.
1350 1350
1351If your ``SRC_URI`` variable points to more than a single URL (excluding 1351If your :term:`SRC_URI` variable points to more than a single URL (excluding
1352SCM URLs), you need to provide the ``md5`` and ``sha256`` checksums for 1352SCM URLs), you need to provide the ``md5`` and ``sha256`` checksums for
1353each URL. For these cases, you provide a name for each URL as part of 1353each URL. For these cases, you provide a name for each URL as part of
1354the ``SRC_URI`` and then reference that name in the subsequent checksum 1354the :term:`SRC_URI` and then reference that name in the subsequent checksum
1355statements. Here is an example combining lines from the files 1355statements. Here is an example combining lines from the files
1356``git.inc`` and ``git_2.24.1.bb``:: 1356``git.inc`` and ``git_2.24.1.bb``::
1357 1357
@@ -1369,7 +1369,7 @@ with other signatures on the download page for the upstream source (e.g.
1369OpenEmbedded build system only deals with ``sha256sum`` and ``md5sum``, 1369OpenEmbedded build system only deals with ``sha256sum`` and ``md5sum``,
1370you should verify all the signatures you find by hand. 1370you should verify all the signatures you find by hand.
1371 1371
1372If no ``SRC_URI`` checksums are specified when you attempt to build the 1372If no :term:`SRC_URI` checksums are specified when you attempt to build the
1373recipe, or you provide an incorrect checksum, the build will produce an 1373recipe, or you provide an incorrect checksum, the build will produce an
1374error for each missing or incorrect checksum. As part of the error 1374error for each missing or incorrect checksum. As part of the error
1375message, the build system provides the checksum string corresponding to 1375message, the build system provides the checksum string corresponding to
@@ -1385,7 +1385,7 @@ paste them into your recipe and then run the build again to continue.
1385 1385
1386This final example is a bit more complicated and is from the 1386This final example is a bit more complicated and is from the
1387``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The 1387``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
1388example's ``SRC_URI`` statement identifies multiple files as the source 1388example's :term:`SRC_URI` statement identifies multiple files as the source
1389files for the recipe: a tarball, a patch file, a desktop file, and an 1389files for the recipe: a tarball, a patch file, a desktop file, and an
1390icon. 1390icon.
1391:: 1391::
@@ -1424,9 +1424,9 @@ If you are fetching your source files from an upstream source archived
1424tarball and the tarball's internal structure matches the common 1424tarball and the tarball's internal structure matches the common
1425convention of a top-level subdirectory named 1425convention of a top-level subdirectory named
1426``${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``, 1426``${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
1427then you do not need to set ``S``. However, if ``SRC_URI`` specifies to 1427then you do not need to set :term:`S`. However, if :term:`SRC_URI` specifies to
1428fetch source from an archive that does not use this convention, or from 1428fetch source from an archive that does not use this convention, or from
1429an SCM like Git or Subversion, your recipe needs to define ``S``. 1429an SCM like Git or Subversion, your recipe needs to define :term:`S`.
1430 1430
1431If processing your recipe using BitBake successfully unpacks the source 1431If processing your recipe using BitBake successfully unpacks the source
1432files, you need to be sure that the directory pointed to by ``${S}`` 1432files, you need to be sure that the directory pointed to by ``${S}``
@@ -1436,7 +1436,7 @@ Patching Code
1436------------- 1436-------------
1437 1437
1438Sometimes it is necessary to patch code after it has been fetched. Any 1438Sometimes it is necessary to patch code after it has been fetched. Any
1439files mentioned in ``SRC_URI`` whose names end in ``.patch`` or 1439files mentioned in :term:`SRC_URI` whose names end in ``.patch`` or
1440``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz`` are 1440``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz`` are
1441treated as patches. The 1441treated as patches. The
1442:ref:`ref-tasks-patch` task 1442:ref:`ref-tasks-patch` task
@@ -1445,7 +1445,7 @@ automatically applies these patches.
1445The build system should be able to apply patches with the "-p1" option 1445The build system should be able to apply patches with the "-p1" option
1446(i.e. one directory level in the path will be stripped off). If your 1446(i.e. one directory level in the path will be stripped off). If your
1447patch needs to have more directory levels stripped off, specify the 1447patch needs to have more directory levels stripped off, specify the
1448number of levels using the "striplevel" option in the ``SRC_URI`` entry 1448number of levels using the "striplevel" option in the :term:`SRC_URI` entry
1449for the patch. Alternatively, if your patch needs to be applied in a 1449for the patch. Alternatively, if your patch needs to be applied in a
1450specific subdirectory that is not specified in the patch file, use the 1450specific subdirectory that is not specified in the patch file, use the
1451"patchdir" option in the entry. 1451"patchdir" option in the entry.
@@ -1465,24 +1465,24 @@ Your recipe needs to have both the
1465:term:`LIC_FILES_CHKSUM` 1465:term:`LIC_FILES_CHKSUM`
1466variables: 1466variables:
1467 1467
1468- ``LICENSE``: This variable specifies the license for the software. 1468- :term:`LICENSE`: This variable specifies the license for the software.
1469 If you do not know the license under which the software you are 1469 If you do not know the license under which the software you are
1470 building is distributed, you should go to the source code and look 1470 building is distributed, you should go to the source code and look
1471 for that information. Typical files containing this information 1471 for that information. Typical files containing this information
1472 include ``COPYING``, ``LICENSE``, and ``README`` files. You could 1472 include ``COPYING``, :term:`LICENSE`, and ``README`` files. You could
1473 also find the information near the top of a source file. For example, 1473 also find the information near the top of a source file. For example,
1474 given a piece of software licensed under the GNU General Public 1474 given a piece of software licensed under the GNU General Public
1475 License version 2, you would set ``LICENSE`` as follows:: 1475 License version 2, you would set :term:`LICENSE` as follows::
1476 1476
1477 LICENSE = "GPLv2" 1477 LICENSE = "GPLv2"
1478 1478
1479 The licenses you specify within ``LICENSE`` can have any name as long 1479 The licenses you specify within :term:`LICENSE` can have any name as long
1480 as you do not use spaces, since spaces are used as separators between 1480 as you do not use spaces, since spaces are used as separators between
1481 license names. For standard licenses, use the names of the files in 1481 license names. For standard licenses, use the names of the files in
1482 ``meta/files/common-licenses/`` or the ``SPDXLICENSEMAP`` flag names 1482 ``meta/files/common-licenses/`` or the :term:`SPDXLICENSEMAP` flag names
1483 defined in ``meta/conf/licenses.conf``. 1483 defined in ``meta/conf/licenses.conf``.
1484 1484
1485- ``LIC_FILES_CHKSUM``: The OpenEmbedded build system uses this 1485- :term:`LIC_FILES_CHKSUM`: The OpenEmbedded build system uses this
1486 variable to make sure the license text has not changed. If it has, 1486 variable to make sure the license text has not changed. If it has,
1487 the build produces an error and it affords you the chance to figure 1487 the build produces an error and it affords you the chance to figure
1488 it out and correct the problem. 1488 it out and correct the problem.
@@ -1492,11 +1492,11 @@ variables:
1492 the checksums of the files to be sure the text has not changed. Any 1492 the checksums of the files to be sure the text has not changed. Any
1493 differences result in an error with the message containing the 1493 differences result in an error with the message containing the
1494 current checksum. For more explanation and examples of how to set the 1494 current checksum. For more explanation and examples of how to set the
1495 ``LIC_FILES_CHKSUM`` variable, see the 1495 :term:`LIC_FILES_CHKSUM` variable, see the
1496 ":ref:`dev-manual/common-tasks:tracking license changes`" section. 1496 ":ref:`dev-manual/common-tasks:tracking license changes`" section.
1497 1497
1498 To determine the correct checksum string, you can list the 1498 To determine the correct checksum string, you can list the
1499 appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect 1499 appropriate files in the :term:`LIC_FILES_CHKSUM` variable with incorrect
1500 md5 strings, attempt to build the software, and then note the 1500 md5 strings, attempt to build the software, and then note the
1501 resulting error messages that will report the correct md5 strings. 1501 resulting error messages that will report the correct md5 strings.
1502 See the ":ref:`dev-manual/common-tasks:fetching code`" section for 1502 See the ":ref:`dev-manual/common-tasks:fetching code`" section for
@@ -1522,7 +1522,7 @@ installed on the target in order for the software to run.
1522 1522
1523Within a recipe, you specify build-time dependencies using the 1523Within a recipe, you specify build-time dependencies using the
1524:term:`DEPENDS` variable. Although there are nuances, 1524:term:`DEPENDS` variable. Although there are nuances,
1525items specified in ``DEPENDS`` should be names of other 1525items specified in :term:`DEPENDS` should be names of other
1526recipes. It is important that you specify all build-time dependencies 1526recipes. It is important that you specify all build-time dependencies
1527explicitly. 1527explicitly.
1528 1528
@@ -1639,12 +1639,12 @@ your software is built:
1639Once configuration succeeds, it is always good practice to look at the 1639Once configuration succeeds, it is always good practice to look at the
1640``log.do_configure`` file to ensure that the appropriate options have 1640``log.do_configure`` file to ensure that the appropriate options have
1641been enabled and no additional build-time dependencies need to be added 1641been enabled and no additional build-time dependencies need to be added
1642to ``DEPENDS``. For example, if the configure script reports that it 1642to :term:`DEPENDS`. For example, if the configure script reports that it
1643found something not mentioned in ``DEPENDS``, or that it did not find 1643found something not mentioned in :term:`DEPENDS`, or that it did not find
1644something that it needed for some desired optional functionality, then 1644something that it needed for some desired optional functionality, then
1645you would need to add those to ``DEPENDS``. Looking at the log might 1645you would need to add those to :term:`DEPENDS`. Looking at the log might
1646also reveal items being checked for, enabled, or both that you do not 1646also reveal items being checked for, enabled, or both that you do not
1647want, or items not being found that are in ``DEPENDS``, in which case 1647want, or items not being found that are in :term:`DEPENDS`, in which case
1648you would need to look at passing extra options to the configure script 1648you would need to look at passing extra options to the configure script
1649as needed. For reference information on configure options specific to 1649as needed. For reference information on configure options specific to
1650the software you are building, you can consult the output of the 1650the software you are building, you can consult the output of the
@@ -1762,13 +1762,13 @@ Here are some common issues that cause failures.
1762 compilation process notes that files could not be found. In these 1762 compilation process notes that files could not be found. In these
1763 cases, you need to go back and add additional options to the 1763 cases, you need to go back and add additional options to the
1764 configure script as well as possibly add additional build-time 1764 configure script as well as possibly add additional build-time
1765 dependencies to ``DEPENDS``. 1765 dependencies to :term:`DEPENDS`.
1766 1766
1767 Occasionally, it is necessary to apply a patch to the source to 1767 Occasionally, it is necessary to apply a patch to the source to
1768 ensure the correct paths are used. If you need to specify paths to 1768 ensure the correct paths are used. If you need to specify paths to
1769 find files staged into the sysroot from other recipes, use the 1769 find files staged into the sysroot from other recipes, use the
1770 variables that the OpenEmbedded build system provides (e.g. 1770 variables that the OpenEmbedded build system provides (e.g.
1771 ``STAGING_BINDIR``, ``STAGING_INCDIR``, ``STAGING_DATADIR``, and so 1771 :term:`STAGING_BINDIR`, :term:`STAGING_INCDIR`, :term:`STAGING_DATADIR`, and so
1772 forth). 1772 forth).
1773 1773
1774Installing 1774Installing
@@ -2022,7 +2022,7 @@ the list of directories within a recipe::
2022 2022
2023 The `/sysroot-only` is to be used by recipes that generate artifacts 2023 The `/sysroot-only` is to be used by recipes that generate artifacts
2024 that are not included in the target filesystem, allowing them to share 2024 that are not included in the target filesystem, allowing them to share
2025 these artifacts without needing to use the ``DEPLOY_DIR``. 2025 these artifacts without needing to use the :term:`DEPLOY_DIR`.
2026 2026
2027For a more complete description of the :ref:`ref-tasks-populate_sysroot` 2027For a more complete description of the :ref:`ref-tasks-populate_sysroot`
2028task and its associated functions, see the 2028task and its associated functions, see the
@@ -2048,7 +2048,7 @@ statement that essentially identifies itself as being able to provide
2048 PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }" 2048 PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }"
2049 2049
2050Any recipe that inherits the ``kernel`` class is 2050Any recipe that inherits the ``kernel`` class is
2051going to utilize a ``PROVIDES`` statement that identifies that recipe as 2051going to utilize a :term:`PROVIDES` statement that identifies that recipe as
2052being able to provide the ``virtual/kernel`` item. 2052being able to provide the ``virtual/kernel`` item.
2053 2053
2054Now comes the time to actually build an image and you need a kernel 2054Now comes the time to actually build an image and you need a kernel
@@ -2072,7 +2072,7 @@ build is dependent on ``virtual/kernel`` for example::
2072 2072
2073During the build, the OpenEmbedded build system picks 2073During the build, the OpenEmbedded build system picks
2074the correct recipe needed for the ``virtual/kernel`` dependency based on 2074the correct recipe needed for the ``virtual/kernel`` dependency based on
2075the ``PREFERRED_PROVIDER`` variable. If you want to use the small kernel 2075the :term:`PREFERRED_PROVIDER` variable. If you want to use the small kernel
2076mentioned at the beginning of this section, configure your build as 2076mentioned at the beginning of this section, configure your build as
2077follows:: 2077follows::
2078 2078
@@ -2080,8 +2080,8 @@ follows::
2080 2080
2081.. note:: 2081.. note::
2082 2082
2083 Any recipe that ``PROVIDES`` a ``virtual/*`` item that is ultimately not 2083 Any recipe that :term:`PROVIDES` a ``virtual/*`` item that is ultimately not
2084 selected through ``PREFERRED_PROVIDER`` does not get built. Preventing these 2084 selected through :term:`PREFERRED_PROVIDER` does not get built. Preventing these
2085 recipes from building is usually the desired behavior since this mechanism's 2085 recipes from building is usually the desired behavior since this mechanism's
2086 purpose is to select between mutually exclusive alternative providers. 2086 purpose is to select between mutually exclusive alternative providers.
2087 2087
@@ -2221,8 +2221,8 @@ Single .c File Package (Hello World!)
2221 2221
2222Building an application from a single file that is stored locally (e.g. 2222Building an application from a single file that is stored locally (e.g.
2223under ``files``) requires a recipe that has the file listed in the 2223under ``files``) requires a recipe that has the file listed in the
2224``SRC_URI`` variable. Additionally, you need to manually write the 2224:term:`SRC_URI` variable. Additionally, you need to manually write the
2225``do_compile`` and ``do_install`` tasks. The ``S`` variable defines the 2225``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the
2226directory containing the source code, which is set to 2226directory containing the source code, which is set to
2227:term:`WORKDIR` in this case - the 2227:term:`WORKDIR` in this case - the
2228directory BitBake uses for the build. 2228directory BitBake uses for the build.
@@ -2256,7 +2256,7 @@ Autotooled Package
2256~~~~~~~~~~~~~~~~~~ 2256~~~~~~~~~~~~~~~~~~
2257 2257
2258Applications that use Autotools such as ``autoconf`` and ``automake`` 2258Applications that use Autotools such as ``autoconf`` and ``automake``
2259require a recipe that has a source archive listed in ``SRC_URI`` and 2259require a recipe that has a source archive listed in :term:`SRC_URI` and
2260also inherit the 2260also inherit the
2261:ref:`autotools <ref-classes-autotools>` class, 2261:ref:`autotools <ref-classes-autotools>` class,
2262which contains the definitions of all the steps needed to build an 2262which contains the definitions of all the steps needed to build an
@@ -2275,7 +2275,7 @@ Following is one example: (``hello_2.3.bb``)
2275 2275
2276 inherit autotools gettext 2276 inherit autotools gettext
2277 2277
2278The variable ``LIC_FILES_CHKSUM`` is used to track source license 2278The variable :term:`LIC_FILES_CHKSUM` is used to track source license
2279changes as described in the 2279changes as described in the
2280":ref:`dev-manual/common-tasks:tracking license changes`" section in 2280":ref:`dev-manual/common-tasks:tracking license changes`" section in
2281the Yocto Project Overview and Concepts Manual. You can quickly create 2281the Yocto Project Overview and Concepts Manual. You can quickly create
@@ -2285,7 +2285,7 @@ Makefile-Based Package
2285~~~~~~~~~~~~~~~~~~~~~~ 2285~~~~~~~~~~~~~~~~~~~~~~
2286 2286
2287Applications that use GNU ``make`` also require a recipe that has the 2287Applications that use GNU ``make`` also require a recipe that has the
2288source archive listed in ``SRC_URI``. You do not need to add a 2288source archive listed in :term:`SRC_URI`. You do not need to add a
2289``do_compile`` step since by default BitBake starts the ``make`` command 2289``do_compile`` step since by default BitBake starts the ``make`` command
2290to compile the application. If you need additional ``make`` options, you 2290to compile the application. If you need additional ``make`` options, you
2291should store them in the 2291should store them in the
@@ -2297,7 +2297,7 @@ Otherwise, BitBake runs an empty ``do_install`` task by default.
2297 2297
2298Some applications might require extra parameters to be passed to the 2298Some applications might require extra parameters to be passed to the
2299compiler. For example, the application might need an additional header 2299compiler. For example, the application might need an additional header
2300path. You can accomplish this by adding to the ``CFLAGS`` variable. The 2300path. You can accomplish this by adding to the :term:`CFLAGS` variable. The
2301following example shows this:: 2301following example shows this::
2302 2302
2303 CFLAGS_prepend = "-I ${S}/include " 2303 CFLAGS_prepend = "-I ${S}/include "
@@ -2341,7 +2341,7 @@ In the following example, ``mtd-utils`` is a makefile-based package::
2341Splitting an Application into Multiple Packages 2341Splitting an Application into Multiple Packages
2342~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2342~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2343 2343
2344You can use the variables ``PACKAGES`` and ``FILES`` to split an 2344You can use the variables :term:`PACKAGES` and :term:`FILES` to split an
2345application into multiple packages. 2345application into multiple packages.
2346 2346
2347Following is an example that uses the ``libxpm`` recipe. By default, 2347Following is an example that uses the ``libxpm`` recipe. By default,
@@ -2365,12 +2365,12 @@ into separate packages::
2365 2365
2366In the previous example, we want to ship the ``sxpm`` and ``cxpm`` 2366In the previous example, we want to ship the ``sxpm`` and ``cxpm``
2367binaries in separate packages. Since ``bindir`` would be packaged into 2367binaries in separate packages. Since ``bindir`` would be packaged into
2368the main ``PN`` package by default, we prepend the ``PACKAGES`` variable 2368the main :term:`PN` package by default, we prepend the :term:`PACKAGES` variable
2369so additional package names are added to the start of list. This results 2369so additional package names are added to the start of list. This results
2370in the extra ``FILES_*`` variables then containing information that 2370in the extra ``FILES_*`` variables then containing information that
2371define which files and directories go into which packages. Files 2371define which files and directories go into which packages. Files
2372included by earlier packages are skipped by latter packages. Thus, the 2372included by earlier packages are skipped by latter packages. Thus, the
2373main ``PN`` package does not include the above listed files. 2373main :term:`PN` package does not include the above listed files.
2374 2374
2375Packaging Externally Produced Binaries 2375Packaging Externally Produced Binaries
2376~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2376~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2415,12 +2415,12 @@ Reference Manual's variable glossary.
2415 - Using :term:`DEPENDS` is a good 2415 - Using :term:`DEPENDS` is a good
2416 idea even for components distributed in binary form, and is often 2416 idea even for components distributed in binary form, and is often
2417 necessary for shared libraries. For a shared library, listing the 2417 necessary for shared libraries. For a shared library, listing the
2418 library dependencies in ``DEPENDS`` makes sure that the libraries 2418 library dependencies in :term:`DEPENDS` makes sure that the libraries
2419 are available in the staging sysroot when other recipes link 2419 are available in the staging sysroot when other recipes link
2420 against the library, which might be necessary for successful 2420 against the library, which might be necessary for successful
2421 linking. 2421 linking.
2422 2422
2423 - Using ``DEPENDS`` also allows runtime dependencies between 2423 - Using :term:`DEPENDS` also allows runtime dependencies between
2424 packages to be added automatically. See the 2424 packages to be added automatically. See the
2425 ":ref:`overview-manual/concepts:automatically added runtime dependencies`" 2425 ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
2426 section in the Yocto Project Overview and Concepts Manual for more 2426 section in the Yocto Project Overview and Concepts Manual for more
@@ -2747,7 +2747,7 @@ file or include from a lower-level configuration file are as follows:
2747 2747
2748- ``PREFERRED_PROVIDER_virtual/kernel`` 2748- ``PREFERRED_PROVIDER_virtual/kernel``
2749 2749
2750- ``MACHINE_FEATURES`` (e.g. "apm screen wifi") 2750- :term:`MACHINE_FEATURES` (e.g. "apm screen wifi")
2751 2751
2752You might also need these variables: 2752You might also need these variables:
2753 2753
@@ -2755,7 +2755,7 @@ You might also need these variables:
2755 2755
2756- ``KERNEL_IMAGETYPE`` (e.g. "zImage") 2756- ``KERNEL_IMAGETYPE`` (e.g. "zImage")
2757 2757
2758- ``IMAGE_FSTYPES`` (e.g. "tar.gz jffs2") 2758- :term:`IMAGE_FSTYPES` (e.g. "tar.gz jffs2")
2759 2759
2760You can find full details on these variables in the reference section. 2760You can find full details on these variables in the reference section.
2761You can leverage existing machine ``.conf`` files from 2761You can leverage existing machine ``.conf`` files from
@@ -2771,8 +2771,8 @@ examples in the Source Directory at ``meta/recipes-kernel/linux`` that
2771you can use as references. 2771you can use as references.
2772 2772
2773If you are creating a new kernel recipe, normal recipe-writing rules 2773If you are creating a new kernel recipe, normal recipe-writing rules
2774apply for setting up a ``SRC_URI``. Thus, you need to specify any 2774apply for setting up a :term:`SRC_URI`. Thus, you need to specify any
2775necessary patches and set ``S`` to point at the source code. You need to 2775necessary patches and set :term:`S` to point at the source code. You need to
2776create a ``do_configure`` task that configures the unpacked kernel with 2776create a ``do_configure`` task that configures the unpacked kernel with
2777a ``defconfig`` file. You can do this by using a ``make defconfig`` 2777a ``defconfig`` file. You can do this by using a ``make defconfig``
2778command or, more commonly, by copying in a suitable ``defconfig`` file 2778command or, more commonly, by copying in a suitable ``defconfig`` file
@@ -2785,8 +2785,8 @@ If you are extending an existing kernel recipe, it is usually a matter
2785of adding a suitable ``defconfig`` file. The file needs to be added into 2785of adding a suitable ``defconfig`` file. The file needs to be added into
2786a location similar to ``defconfig`` files used for other machines in a 2786a location similar to ``defconfig`` files used for other machines in a
2787given kernel recipe. A possible way to do this is by listing the file in 2787given kernel recipe. A possible way to do this is by listing the file in
2788the ``SRC_URI`` and adding the machine to the expression in 2788the :term:`SRC_URI` and adding the machine to the expression in
2789``COMPATIBLE_MACHINE``:: 2789:term:`COMPATIBLE_MACHINE`::
2790 2790
2791 COMPATIBLE_MACHINE = '(qemux86|qemumips)' 2791 COMPATIBLE_MACHINE = '(qemux86|qemumips)'
2792 2792
@@ -3178,9 +3178,9 @@ To manually upgrade recipe versions, follow these general steps:
31781. *Change the Version:* Rename the recipe such that the version (i.e. 31781. *Change the Version:* Rename the recipe such that the version (i.e.
3179 the :term:`PV` part of the recipe name) 3179 the :term:`PV` part of the recipe name)
3180 changes appropriately. If the version is not part of the recipe name, 3180 changes appropriately. If the version is not part of the recipe name,
3181 change the value as it is set for ``PV`` within the recipe itself. 3181 change the value as it is set for :term:`PV` within the recipe itself.
3182 3182
31832. *Update* ``SRCREV`` *if Needed*: If the source code your recipe builds 31832. *Update* :term:`SRCREV` *if Needed*: If the source code your recipe builds
3184 is fetched from Git or some other version control system, update 3184 is fetched from Git or some other version control system, update
3185 :term:`SRCREV` to point to the 3185 :term:`SRCREV` to point to the
3186 commit hash that matches the new version. 3186 commit hash that matches the new version.
@@ -3241,15 +3241,15 @@ patches.
3241During a build, the unpacked temporary source code used by recipes to 3241During a build, the unpacked temporary source code used by recipes to
3242build packages is available in the Build Directory as defined by the 3242build packages is available in the Build Directory as defined by the
3243:term:`S` variable. Below is the default 3243:term:`S` variable. Below is the default
3244value for the ``S`` variable as defined in the 3244value for the :term:`S` variable as defined in the
3245``meta/conf/bitbake.conf`` configuration file in the 3245``meta/conf/bitbake.conf`` configuration file in the
3246:term:`Source Directory`:: 3246:term:`Source Directory`::
3247 3247
3248 S = "${WORKDIR}/${BP}" 3248 S = "${WORKDIR}/${BP}"
3249 3249
3250You should be aware that many recipes override the 3250You should be aware that many recipes override the
3251``S`` variable. For example, recipes that fetch their source from Git 3251:term:`S` variable. For example, recipes that fetch their source from Git
3252usually set ``S`` to ``${WORKDIR}/git``. 3252usually set :term:`S` to ``${WORKDIR}/git``.
3253 3253
3254.. note:: 3254.. note::
3255 3255
@@ -3369,13 +3369,13 @@ Follow these general steps:
3369 ``file2.c``, and ``file3.c`` files. 3369 ``file2.c``, and ``file3.c`` files.
3370 3370
3371 You can find the resulting patch file in the ``patches/`` 3371 You can find the resulting patch file in the ``patches/``
3372 subdirectory of the source (``S``) directory. 3372 subdirectory of the source (:term:`S`) directory.
3373 3373
33748. *Copy the Patch File:* For simplicity, copy the patch file into a 33748. *Copy the Patch File:* For simplicity, copy the patch file into a
3375 directory named ``files``, which you can create in the same directory 3375 directory named ``files``, which you can create in the same directory
3376 that holds the recipe (``.bb``) file or the append (``.bbappend``) 3376 that holds the recipe (``.bb``) file or the append (``.bbappend``)
3377 file. Placing the patch here guarantees that the OpenEmbedded build 3377 file. Placing the patch here guarantees that the OpenEmbedded build
3378 system will find the patch. Next, add the patch into the ``SRC_URI`` 3378 system will find the patch. Next, add the patch into the :term:`SRC_URI`
3379 of the recipe. Here is an example:: 3379 of the recipe. Here is an example::
3380 3380
3381 SRC_URI += "file://my_changes.patch" 3381 SRC_URI += "file://my_changes.patch"
@@ -3454,7 +3454,7 @@ terminal window.
3454 use the full compiler name such as ``arm-poky-linux-gnueabi-gcc`` 3454 use the full compiler name such as ``arm-poky-linux-gnueabi-gcc``
3455 instead of just using ``gcc``. The same applies to other 3455 instead of just using ``gcc``. The same applies to other
3456 applications such as ``binutils``, ``libtool`` and so forth. 3456 applications such as ``binutils``, ``libtool`` and so forth.
3457 BitBake sets up environment variables such as ``CC`` to assist 3457 BitBake sets up environment variables such as :term:`CC` to assist
3458 applications, such as ``make`` to find the correct tools. 3458 applications, such as ``make`` to find the correct tools.
3459 3459
3460 - It is also worth noting that ``devshell`` still works over X11 3460 - It is also worth noting that ``devshell`` still works over X11
@@ -3573,7 +3573,7 @@ The following figure and list overviews the build process:
3573 ``conf/local.conf`` configuration file, which is found in the Build 3573 ``conf/local.conf`` configuration file, which is found in the Build
3574 Directory, is set up how you want it. This file defines many aspects 3574 Directory, is set up how you want it. This file defines many aspects
3575 of the build environment including the target machine architecture 3575 of the build environment including the target machine architecture
3576 through the ``MACHINE`` variable, the packaging format used during 3576 through the :term:`MACHINE` variable, the packaging format used during
3577 the build 3577 the build
3578 (:term:`PACKAGE_CLASSES`), 3578 (:term:`PACKAGE_CLASSES`),
3579 and a centralized tarball download directory through the 3579 and a centralized tarball download directory through the
@@ -3646,7 +3646,7 @@ Follow these steps to set up and execute multiple configuration builds:
3646 consider a scenario with two different multiconfigs for the same 3646 consider a scenario with two different multiconfigs for the same
3647 :term:`MACHINE`: "qemux86" built 3647 :term:`MACHINE`: "qemux86" built
3648 for two distributions such as "poky" and "poky-lsb". In this case, 3648 for two distributions such as "poky" and "poky-lsb". In this case,
3649 you might want to use the same ``TMPDIR``. 3649 you might want to use the same :term:`TMPDIR`.
3650 3650
3651 Here is an example showing the minimal statements needed in a 3651 Here is an example showing the minimal statements needed in a
3652 configuration file for a "qemux86" target whose temporary build 3652 configuration file for a "qemux86" target whose temporary build
@@ -3663,7 +3663,7 @@ Follow these steps to set up and execute multiple configuration builds:
3663 .. image:: figures/multiconfig_files.png 3663 .. image:: figures/multiconfig_files.png
3664 :align: center 3664 :align: center
3665 3665
3666 The reason for this required file hierarchy is because the ``BBPATH`` 3666 The reason for this required file hierarchy is because the :term:`BBPATH`
3667 variable is not constructed until the layers are parsed. 3667 variable is not constructed until the layers are parsed.
3668 Consequently, using the configuration file as a pre-configuration 3668 Consequently, using the configuration file as a pre-configuration
3669 file is not possible unless it is located in the current working 3669 file is not possible unless it is located in the current working
@@ -3674,7 +3674,7 @@ Follow these steps to set up and execute multiple configuration builds:
3674 :term:`BBMULTICONFIG` 3674 :term:`BBMULTICONFIG`
3675 variable in your ``conf/local.conf`` configuration file to specify 3675 variable in your ``conf/local.conf`` configuration file to specify
3676 each multiconfig. Continuing with the example from the previous 3676 each multiconfig. Continuing with the example from the previous
3677 figure, the ``BBMULTICONFIG`` variable needs to enable two 3677 figure, the :term:`BBMULTICONFIG` variable needs to enable two
3678 multiconfigs: "x86" and "arm" by specifying each configuration file:: 3678 multiconfigs: "x86" and "arm" by specifying each configuration file::
3679 3679
3680 BBMULTICONFIG = "x86 arm" 3680 BBMULTICONFIG = "x86 arm"
@@ -3708,7 +3708,7 @@ Follow these steps to set up and execute multiple configuration builds:
3708 Support for multiple configuration builds in the Yocto Project &DISTRO; 3708 Support for multiple configuration builds in the Yocto Project &DISTRO;
3709 (&DISTRO_NAME;) Release does not include Shared State (sstate) 3709 (&DISTRO_NAME;) Release does not include Shared State (sstate)
3710 optimizations. Consequently, if a build uses the same object twice 3710 optimizations. Consequently, if a build uses the same object twice
3711 in, for example, two different ``TMPDIR`` 3711 in, for example, two different :term:`TMPDIR`
3712 directories, the build either loads from an existing sstate cache for 3712 directories, the build either loads from an existing sstate cache for
3713 that build at the start or builds the object fresh. 3713 that build at the start or builds the object fresh.
3714 3714
@@ -3806,7 +3806,7 @@ Follow these steps to create an initramfs image:
3806 recipe and the initramfs recipe should the initramfs image include 3806 recipe and the initramfs recipe should the initramfs image include
3807 kernel modules. 3807 kernel modules.
3808 3808
3809 Setting the ``INITRAMFS_IMAGE_BUNDLE`` flag causes the initramfs 3809 Setting the :term:`INITRAMFS_IMAGE_BUNDLE` flag causes the initramfs
3810 image to be unpacked into the ``${B}/usr/`` directory. The unpacked 3810 image to be unpacked into the ``${B}/usr/`` directory. The unpacked
3811 initramfs image is then passed to the kernel's ``Makefile`` using the 3811 initramfs image is then passed to the kernel's ``Makefile`` using the
3812 :term:`CONFIG_INITRAMFS_SOURCE` 3812 :term:`CONFIG_INITRAMFS_SOURCE`
@@ -3828,7 +3828,7 @@ Follow these steps to create an initramfs image:
3828 :term:`PACKAGE_INSTALL` 3828 :term:`PACKAGE_INSTALL`
3829 rather than 3829 rather than
3830 :term:`IMAGE_INSTALL`. 3830 :term:`IMAGE_INSTALL`.
3831 ``PACKAGE_INSTALL`` gives more direct control of what is added to the 3831 :term:`PACKAGE_INSTALL` gives more direct control of what is added to the
3832 image as compared to the defaults you might not necessarily want that 3832 image as compared to the defaults you might not necessarily want that
3833 are set by the :ref:`image <ref-classes-image>` 3833 are set by the :ref:`image <ref-classes-image>`
3834 or :ref:`core-image <ref-classes-core-image>` 3834 or :ref:`core-image <ref-classes-core-image>`
@@ -3912,7 +3912,7 @@ your own distribution that are likely modeled after ``poky-tiny``.
3912 3912
3913.. note:: 3913.. note::
3914 3914
3915 To use ``poky-tiny`` in your build, set the ``DISTRO`` variable in your 3915 To use ``poky-tiny`` in your build, set the :term:`DISTRO` variable in your
3916 ``local.conf`` file to "poky-tiny" as described in the 3916 ``local.conf`` file to "poky-tiny" as described in the
3917 ":ref:`dev-manual/common-tasks:creating your own distribution`" 3917 ":ref:`dev-manual/common-tasks:creating your own distribution`"
3918 section. 3918 section.
@@ -4156,17 +4156,17 @@ your tunings to best consider build times and package feed maintenance.
4156 :term:`TMPDIR` across builds. The 4156 :term:`TMPDIR` across builds. The
4157 Yocto Project supports switching between different 4157 Yocto Project supports switching between different
4158 :term:`MACHINE` values in the same 4158 :term:`MACHINE` values in the same
4159 ``TMPDIR``. This practice is well supported and regularly used by 4159 :term:`TMPDIR`. This practice is well supported and regularly used by
4160 developers when building for multiple machines. When you use the same 4160 developers when building for multiple machines. When you use the same
4161 ``TMPDIR`` for multiple machine builds, the OpenEmbedded build system 4161 :term:`TMPDIR` for multiple machine builds, the OpenEmbedded build system
4162 can reuse the existing native and often cross-recipes for multiple 4162 can reuse the existing native and often cross-recipes for multiple
4163 machines. Thus, build time decreases. 4163 machines. Thus, build time decreases.
4164 4164
4165 .. note:: 4165 .. note::
4166 4166
4167 If :term:`DISTRO` settings change or fundamental configuration settings 4167 If :term:`DISTRO` settings change or fundamental configuration settings
4168 such as the filesystem layout, you need to work with a clean ``TMPDIR``. 4168 such as the filesystem layout, you need to work with a clean :term:`TMPDIR`.
4169 Sharing ``TMPDIR`` under these circumstances might work but since it is 4169 Sharing :term:`TMPDIR` under these circumstances might work but since it is
4170 not guaranteed, you should use a clean ``TMPDIR``. 4170 not guaranteed, you should use a clean ``TMPDIR``.
4171 4171
4172- *Enable the Appropriate Package Architecture:* By default, the 4172- *Enable the Appropriate Package Architecture:* By default, the
@@ -4304,7 +4304,7 @@ your ``local.conf`` file::
4304 EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree" 4304 EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
4305 4305
4306This next example shows how to accomplish the same thing by setting 4306This next example shows how to accomplish the same thing by setting
4307``EXTERNALSRC`` in the recipe itself or in the recipe's append file:: 4307:term:`EXTERNALSRC` in the recipe itself or in the recipe's append file::
4308 4308
4309 EXTERNALSRC = "path" 4309 EXTERNALSRC = "path"
4310 EXTERNALSRC_BUILD = "path" 4310 EXTERNALSRC_BUILD = "path"
@@ -4340,7 +4340,7 @@ Follow these steps to populate your Downloads directory:
43401. *Create a Clean Downloads Directory:* Start with an empty downloads 43401. *Create a Clean Downloads Directory:* Start with an empty downloads
4341 directory (:term:`DL_DIR`). You 4341 directory (:term:`DL_DIR`). You
4342 start with an empty downloads directory by either removing the files 4342 start with an empty downloads directory by either removing the files
4343 in the existing directory or by setting ``DL_DIR`` to point to either 4343 in the existing directory or by setting :term:`DL_DIR` to point to either
4344 an empty location or one that does not yet exist. 4344 an empty location or one that does not yet exist.
4345 4345
43462. *Generate Tarballs of the Source Git Repositories:* Edit your 43462. *Generate Tarballs of the Source Git Repositories:* Edit your
@@ -4351,7 +4351,7 @@ Follow these steps to populate your Downloads directory:
4351 4351
4352 During 4352 During
4353 the fetch process in the next step, BitBake gathers the source files 4353 the fetch process in the next step, BitBake gathers the source files
4354 and creates tarballs in the directory pointed to by ``DL_DIR``. See 4354 and creates tarballs in the directory pointed to by :term:`DL_DIR`. See
4355 the 4355 the
4356 :term:`BB_GENERATE_MIRROR_TARBALLS` 4356 :term:`BB_GENERATE_MIRROR_TARBALLS`
4357 variable for more information. 4357 variable for more information.
@@ -4394,7 +4394,7 @@ directory:
4394 4394
4395 The ``SOURCE_MIRROR_URL`` and ``own-mirror`` 4395 The ``SOURCE_MIRROR_URL`` and ``own-mirror``
4396 class set up the system to use the downloads directory as your "own 4396 class set up the system to use the downloads directory as your "own
4397 mirror". Using the ``BB_NO_NETWORK`` variable makes sure that 4397 mirror". Using the :term:`BB_NO_NETWORK` variable makes sure that
4398 BitBake's fetching process in step 3 stays local, which means files 4398 BitBake's fetching process in step 3 stays local, which means files
4399 from your "own-mirror" are used. 4399 from your "own-mirror" are used.
4400 4400
@@ -4420,27 +4420,27 @@ directory:
4420 4420
4421 SRCREV = "${AUTOREV}" 4421 SRCREV = "${AUTOREV}"
4422 4422
4423 When a recipe sets ``SRCREV`` to 4423 When a recipe sets :term:`SRCREV` to
4424 ``${AUTOREV}``, the build system accesses the network in an 4424 ``${AUTOREV}``, the build system accesses the network in an
4425 attempt to determine the latest version of software from the SCM. 4425 attempt to determine the latest version of software from the SCM.
4426 Typically, recipes that use ``AUTOREV`` are custom or modified 4426 Typically, recipes that use :term:`AUTOREV` are custom or modified
4427 recipes. Recipes that reside in public repositories usually do not 4427 recipes. Recipes that reside in public repositories usually do not
4428 use ``AUTOREV``. 4428 use :term:`AUTOREV`.
4429 4429
4430 If you do have recipes that use ``AUTOREV``, you can take steps to 4430 If you do have recipes that use :term:`AUTOREV`, you can take steps to
4431 still use the recipes in an offline build. Do the following: 4431 still use the recipes in an offline build. Do the following:
4432 4432
4433 1. Use a configuration generated by enabling :ref:`build 4433 1. Use a configuration generated by enabling :ref:`build
4434 history <dev-manual/common-tasks:maintaining build output quality>`. 4434 history <dev-manual/common-tasks:maintaining build output quality>`.
4435 4435
4436 2. Use the ``buildhistory-collect-srcrevs`` command to collect the 4436 2. Use the ``buildhistory-collect-srcrevs`` command to collect the
4437 stored ``SRCREV`` values from the build's history. For more 4437 stored :term:`SRCREV` values from the build's history. For more
4438 information on collecting these values, see the 4438 information on collecting these values, see the
4439 ":ref:`dev-manual/common-tasks:build history package information`" 4439 ":ref:`dev-manual/common-tasks:build history package information`"
4440 section. 4440 section.
4441 4441
4442 3. Once you have the correct source revisions, you can modify 4442 3. Once you have the correct source revisions, you can modify
4443 those recipes to set ``SRCREV`` to specific versions of the 4443 those recipes to set :term:`SRCREV` to specific versions of the
4444 software. 4444 software.
4445 4445
4446Speeding Up a Build 4446Speeding Up a Build
@@ -4580,7 +4580,7 @@ the built library.
4580The :term:`PACKAGES` and 4580The :term:`PACKAGES` and
4581:term:`FILES_* <FILES>` variables in the 4581:term:`FILES_* <FILES>` variables in the
4582``meta/conf/bitbake.conf`` configuration file define how files installed 4582``meta/conf/bitbake.conf`` configuration file define how files installed
4583by the ``do_install`` task are packaged. By default, the ``PACKAGES`` 4583by the ``do_install`` task are packaged. By default, the :term:`PACKAGES`
4584variable includes ``${PN}-staticdev``, which represents all static 4584variable includes ``${PN}-staticdev``, which represents all static
4585library files. 4585library files.
4586 4586
@@ -5943,7 +5943,7 @@ system to make your images more secure:
5943 EXTRA_IMAGE_FEATURES = "debug-tweaks" 5943 EXTRA_IMAGE_FEATURES = "debug-tweaks"
5944 5944
5945 To disable that feature, simply comment out that line in your 5945 To disable that feature, simply comment out that line in your
5946 ``local.conf`` file, or make sure ``IMAGE_FEATURES`` does not contain 5946 ``local.conf`` file, or make sure :term:`IMAGE_FEATURES` does not contain
5947 "debug-tweaks" before producing your final image. Among other things, 5947 "debug-tweaks" before producing your final image. Among other things,
5948 leaving this in place sets the root password as blank, which makes 5948 leaving this in place sets the root password as blank, which makes
5949 logging in for debugging or inspection easy during development but 5949 logging in for debugging or inspection easy during development but
@@ -6248,20 +6248,20 @@ the following:
6248 .. note:: 6248 .. note::
6249 6249
6250 Technically, a third component, the "epoch" (i.e. :term:`PE`) is involved 6250 Technically, a third component, the "epoch" (i.e. :term:`PE`) is involved
6251 but this discussion for the most part ignores ``PE``. 6251 but this discussion for the most part ignores :term:`PE`.
6252 6252
6253 The version and revision are taken from the 6253 The version and revision are taken from the
6254 :term:`PV` and 6254 :term:`PV` and
6255 :term:`PR` variables, respectively. 6255 :term:`PR` variables, respectively.
6256 6256
6257- ``PV``: The recipe version. ``PV`` represents the version of the 6257- :term:`PV`: The recipe version. :term:`PV` represents the version of the
6258 software being packaged. Do not confuse ``PV`` with the binary 6258 software being packaged. Do not confuse :term:`PV` with the binary
6259 package version. 6259 package version.
6260 6260
6261- ``PR``: The recipe revision. 6261- ``PR``: The recipe revision.
6262 6262
6263- :term:`SRCPV`: The OpenEmbedded 6263- :term:`SRCPV`: The OpenEmbedded
6264 build system uses this string to help define the value of ``PV`` when 6264 build system uses this string to help define the value of :term:`PV` when
6265 the source code revision needs to be included in it. 6265 the source code revision needs to be included in it.
6266 6266
6267- :yocto_wiki:`PR Service </PR_Service>`: A 6267- :yocto_wiki:`PR Service </PR_Service>`: A
@@ -6271,12 +6271,12 @@ the following:
6271 6271
6272Whenever the binary package content changes, the binary package version 6272Whenever the binary package content changes, the binary package version
6273must change. Changing the binary package version is accomplished by 6273must change. Changing the binary package version is accomplished by
6274changing or "bumping" the ``PR`` and/or ``PV`` values. Increasing these 6274changing or "bumping" the :term:`PR` and/or :term:`PV` values. Increasing these
6275values occurs one of two ways: 6275values occurs one of two ways:
6276 6276
6277- Automatically using a Package Revision Service (PR Service). 6277- Automatically using a Package Revision Service (PR Service).
6278 6278
6279- Manually incrementing the ``PR`` and/or ``PV`` variables. 6279- Manually incrementing the :term:`PR` and/or :term:`PV` variables.
6280 6280
6281Given a primary challenge of any build system and its users is how to 6281Given a primary challenge of any build system and its users is how to
6282maintain a package feed that is compatible with existing package manager 6282maintain a package feed that is compatible with existing package manager
@@ -6290,7 +6290,7 @@ package revisioning remains linear, see the
6290section. 6290section.
6291 6291
6292The following three sections provide related information on the PR 6292The following three sections provide related information on the PR
6293Service, the manual method for "bumping" ``PR`` and/or ``PV``, and on 6293Service, the manual method for "bumping" :term:`PR` and/or :term:`PV`, and on
6294how to ensure binary package revisioning remains linear. 6294how to ensure binary package revisioning remains linear.
6295 6295
6296Working With a PR Service 6296Working With a PR Service
@@ -6320,20 +6320,20 @@ Because the OpenEmbedded build system uses
6320unique to a given build, the build system knows when to rebuild 6320unique to a given build, the build system knows when to rebuild
6321packages. All the inputs into a given task are represented by a 6321packages. All the inputs into a given task are represented by a
6322signature, which can trigger a rebuild when different. Thus, the build 6322signature, which can trigger a rebuild when different. Thus, the build
6323system itself does not rely on the ``PR``, ``PV``, and ``PE`` numbers to 6323system itself does not rely on the :term:`PR`, :term:`PV`, and :term:`PE` numbers to
6324trigger a rebuild. The signatures, however, can be used to generate 6324trigger a rebuild. The signatures, however, can be used to generate
6325these values. 6325these values.
6326 6326
6327The PR Service works with both ``OEBasic`` and ``OEBasicHash`` 6327The PR Service works with both ``OEBasic`` and ``OEBasicHash``
6328generators. The value of ``PR`` bumps when the checksum changes and the 6328generators. The value of :term:`PR` bumps when the checksum changes and the
6329different generator mechanisms change signatures under different 6329different generator mechanisms change signatures under different
6330circumstances. 6330circumstances.
6331 6331
6332As implemented, the build system includes values from the PR Service 6332As implemented, the build system includes values from the PR Service
6333into the ``PR`` field as an addition using the form "``.x``" so ``r0`` 6333into the :term:`PR` field as an addition using the form "``.x``" so ``r0``
6334becomes ``r0.1``, ``r0.2`` and so forth. This scheme allows existing 6334becomes ``r0.1``, ``r0.2`` and so forth. This scheme allows existing
6335``PR`` values to be used for whatever reasons, which include manual 6335:term:`PR` values to be used for whatever reasons, which include manual
6336``PR`` bumps, should it be necessary. 6336:term:`PR` bumps, should it be necessary.
6337 6337
6338By default, the PR Service is not enabled or running. Thus, the packages 6338By default, the PR Service is not enabled or running. Thus, the packages
6339generated are just "self consistent". The build system adds and removes 6339generated are just "self consistent". The build system adds and removes
@@ -6349,7 +6349,7 @@ this scenario, you can enable a local PR Service by setting
6349 PRSERV_HOST = "localhost:0" 6349 PRSERV_HOST = "localhost:0"
6350 6350
6351Once the service is started, packages will automatically 6351Once the service is started, packages will automatically
6352get increasing ``PR`` values and BitBake takes care of starting and 6352get increasing :term:`PR` values and BitBake takes care of starting and
6353stopping the server. 6353stopping the server.
6354 6354
6355If you have a more complex setup where multiple host development systems 6355If you have a more complex setup where multiple host development systems
@@ -6379,7 +6379,7 @@ history, see the
6379 6379
6380.. note:: 6380.. note::
6381 6381
6382 The OpenEmbedded build system does not maintain ``PR`` information as 6382 The OpenEmbedded build system does not maintain :term:`PR` information as
6383 part of the shared state (sstate) packages. If you maintain an sstate 6383 part of the shared state (sstate) packages. If you maintain an sstate
6384 feed, it's expected that either all your building systems that 6384 feed, it's expected that either all your building systems that
6385 contribute to the sstate feed use a shared PR Service, or you do not 6385 contribute to the sstate feed use a shared PR Service, or you do not
@@ -6398,27 +6398,27 @@ The alternative to setting up a PR Service is to manually "bump" the
6398 6398
6399If a committed change results in changing the package output, then the 6399If a committed change results in changing the package output, then the
6400value of the PR variable needs to be increased (or "bumped") as part of 6400value of the PR variable needs to be increased (or "bumped") as part of
6401that commit. For new recipes you should add the ``PR`` variable and set 6401that commit. For new recipes you should add the :term:`PR` variable and set
6402its initial value equal to "r0", which is the default. Even though the 6402its initial value equal to "r0", which is the default. Even though the
6403default value is "r0", the practice of adding it to a new recipe makes 6403default value is "r0", the practice of adding it to a new recipe makes
6404it harder to forget to bump the variable when you make changes to the 6404it harder to forget to bump the variable when you make changes to the
6405recipe in future. 6405recipe in future.
6406 6406
6407If you are sharing a common ``.inc`` file with multiple recipes, you can 6407If you are sharing a common ``.inc`` file with multiple recipes, you can
6408also use the ``INC_PR`` variable to ensure that the recipes sharing the 6408also use the :term:`INC_PR` variable to ensure that the recipes sharing the
6409``.inc`` file are rebuilt when the ``.inc`` file itself is changed. The 6409``.inc`` file are rebuilt when the ``.inc`` file itself is changed. The
6410``.inc`` file must set ``INC_PR`` (initially to "r0"), and all recipes 6410``.inc`` file must set :term:`INC_PR` (initially to "r0"), and all recipes
6411referring to it should set ``PR`` to "${INC_PR}.0" initially, 6411referring to it should set :term:`PR` to "${INC_PR}.0" initially,
6412incrementing the last number when the recipe is changed. If the ``.inc`` 6412incrementing the last number when the recipe is changed. If the ``.inc``
6413file is changed then its ``INC_PR`` should be incremented. 6413file is changed then its :term:`INC_PR` should be incremented.
6414 6414
6415When upgrading the version of a binary package, assuming the ``PV`` 6415When upgrading the version of a binary package, assuming the :term:`PV`
6416changes, the ``PR`` variable should be reset to "r0" (or "${INC_PR}.0" 6416changes, the :term:`PR` variable should be reset to "r0" (or "${INC_PR}.0"
6417if you are using ``INC_PR``). 6417if you are using :term:`INC_PR`).
6418 6418
6419Usually, version increases occur only to binary packages. However, if 6419Usually, version increases occur only to binary packages. However, if
6420for some reason ``PV`` changes but does not increase, you can increase 6420for some reason :term:`PV` changes but does not increase, you can increase
6421the ``PE`` variable (Package Epoch). The ``PE`` variable defaults to 6421the :term:`PE` variable (Package Epoch). The :term:`PE` variable defaults to
6422"0". 6422"0".
6423 6423
6424Binary package version numbering strives to follow the `Debian Version 6424Binary package version numbering strives to follow the `Debian Version
@@ -6433,20 +6433,20 @@ Automatically Incrementing a Package Version Number
6433When fetching a repository, BitBake uses the 6433When fetching a repository, BitBake uses the
6434:term:`SRCREV` variable to determine 6434:term:`SRCREV` variable to determine
6435the specific source code revision from which to build. You set the 6435the specific source code revision from which to build. You set the
6436``SRCREV`` variable to 6436:term:`SRCREV` variable to
6437:term:`AUTOREV` to cause the 6437:term:`AUTOREV` to cause the
6438OpenEmbedded build system to automatically use the latest revision of 6438OpenEmbedded build system to automatically use the latest revision of
6439the software:: 6439the software::
6440 6440
6441 SRCREV = "${AUTOREV}" 6441 SRCREV = "${AUTOREV}"
6442 6442
6443Furthermore, you need to reference ``SRCPV`` in ``PV`` in order to 6443Furthermore, you need to reference :term:`SRCPV` in :term:`PV` in order to
6444automatically update the version whenever the revision of the source 6444automatically update the version whenever the revision of the source
6445code changes. Here is an example:: 6445code changes. Here is an example::
6446 6446
6447 PV = "1.0+git${SRCPV}" 6447 PV = "1.0+git${SRCPV}"
6448 6448
6449The OpenEmbedded build system substitutes ``SRCPV`` with the following: 6449The OpenEmbedded build system substitutes :term:`SRCPV` with the following:
6450 6450
6451.. code-block:: none 6451.. code-block:: none
6452 6452
@@ -6479,7 +6479,7 @@ with a number. The number used depends on the state of the PR Service:
6479 6479
6480In summary, the OpenEmbedded build system does not track the history of 6480In summary, the OpenEmbedded build system does not track the history of
6481binary package versions for this purpose. ``AUTOINC``, in this case, is 6481binary package versions for this purpose. ``AUTOINC``, in this case, is
6482comparable to ``PR``. If PR server is not enabled, ``AUTOINC`` in the 6482comparable to :term:`PR`. If PR server is not enabled, ``AUTOINC`` in the
6483package version is simply replaced by "0". If PR server is enabled, the 6483package version is simply replaced by "0". If PR server is enabled, the
6484build system keeps track of the package versions and bumps the number 6484build system keeps track of the package versions and bumps the number
6485when the package revision changes. 6485when the package revision changes.
@@ -6654,7 +6654,7 @@ ensure that any :term:`RDEPENDS` and
6654:term:`RRECOMMENDS` on a package 6654:term:`RRECOMMENDS` on a package
6655name starting with the prefix are satisfied during build time. If you 6655name starting with the prefix are satisfied during build time. If you
6656are using ``do_split_packages`` as described in the previous section, 6656are using ``do_split_packages`` as described in the previous section,
6657the value you put in ``PACKAGES_DYNAMIC`` should correspond to the name 6657the value you put in :term:`PACKAGES_DYNAMIC` should correspond to the name
6658pattern specified in the call to ``do_split_packages``. 6658pattern specified in the call to ``do_split_packages``.
6659 6659
6660Using Runtime Package Management 6660Using Runtime Package Management
@@ -6822,7 +6822,7 @@ From within the build directory where you have built an image based on
6822your packaging choice (i.e. the 6822your packaging choice (i.e. the
6823:term:`PACKAGE_CLASSES` 6823:term:`PACKAGE_CLASSES`
6824setting), simply start the server. The following example assumes a build 6824setting), simply start the server. The following example assumes a build
6825directory of ``poky/build/tmp/deploy/rpm`` and a ``PACKAGE_CLASSES`` 6825directory of ``poky/build/tmp/deploy/rpm`` and a :term:`PACKAGE_CLASSES`
6826setting of "package_rpm":: 6826setting of "package_rpm"::
6827 6827
6828 $ cd poky/build/tmp/deploy/rpm 6828 $ cd poky/build/tmp/deploy/rpm
@@ -7360,7 +7360,7 @@ command::
7360 7360
7361The 7361The
7362recipe this command generates is very similar to the recipe created in 7362recipe this command generates is very similar to the recipe created in
7363the previous section. However, the ``SRC_URI`` looks like the following:: 7363the previous section. However, the :term:`SRC_URI` looks like the following::
7364 7364
7365 SRC_URI = " \ 7365 SRC_URI = " \
7366 git://github.com/martinaglv/cute-files.git;protocol=https \ 7366 git://github.com/martinaglv/cute-files.git;protocol=https \
@@ -7394,7 +7394,7 @@ of precedence is the same as this list:
7394 7394
7395- ``PACKAGE_ADD_METADATA_<PN>`` 7395- ``PACKAGE_ADD_METADATA_<PN>``
7396 7396
7397- ``PACKAGE_ADD_METADATA`` 7397- :term:`PACKAGE_ADD_METADATA`
7398 7398
7399`<PKGTYPE>` is a parameter and expected to be a distinct name of specific 7399`<PKGTYPE>` is a parameter and expected to be a distinct name of specific
7400package type: 7400package type:
@@ -7587,7 +7587,7 @@ variable defines the Device Table to use and should be set in the
7587machine or distro configuration file. Alternatively, you can set this 7587machine or distro configuration file. Alternatively, you can set this
7588variable in your ``local.conf`` configuration file. 7588variable in your ``local.conf`` configuration file.
7589 7589
7590If you do not define the ``IMAGE_DEVICE_TABLES`` variable, the default 7590If you do not define the :term:`IMAGE_DEVICE_TABLES` variable, the default
7591``device_table-minimal.txt`` is used:: 7591``device_table-minimal.txt`` is used::
7592 7592
7593 IMAGE_DEVICE_TABLES = "device_table-mymachine.txt" 7593 IMAGE_DEVICE_TABLES = "device_table-mymachine.txt"
@@ -7713,13 +7713,13 @@ Creating the Root Filesystem
7713To create the read-only root filesystem, simply add the 7713To create the read-only root filesystem, simply add the
7714"read-only-rootfs" feature to your image, normally in one of two ways. 7714"read-only-rootfs" feature to your image, normally in one of two ways.
7715The first way is to add the "read-only-rootfs" image feature in the 7715The first way is to add the "read-only-rootfs" image feature in the
7716image's recipe file via the ``IMAGE_FEATURES`` variable:: 7716image's recipe file via the :term:`IMAGE_FEATURES` variable::
7717 7717
7718 IMAGE_FEATURES += "read-only-rootfs" 7718 IMAGE_FEATURES += "read-only-rootfs"
7719 7719
7720As an alternative, you can add the same feature 7720As an alternative, you can add the same feature
7721from within your build directory's ``local.conf`` file with the 7721from within your build directory's ``local.conf`` file with the
7722associated ``EXTRA_IMAGE_FEATURES`` variable, as in:: 7722associated :term:`EXTRA_IMAGE_FEATURES` variable, as in::
7723 7723
7724 EXTRA_IMAGE_FEATURES = "read-only-rootfs" 7724 EXTRA_IMAGE_FEATURES = "read-only-rootfs"
7725 7725
@@ -7813,7 +7813,7 @@ Enabling and Disabling Build History
7813------------------------------------ 7813------------------------------------
7814 7814
7815Build history is disabled by default. To enable it, add the following 7815Build history is disabled by default. To enable it, add the following
7816``INHERIT`` statement and set the 7816:term:`INHERIT` statement and set the
7817:term:`BUILDHISTORY_COMMIT` 7817:term:`BUILDHISTORY_COMMIT`
7818variable to "1" at the end of your ``conf/local.conf`` file found in the 7818variable to "1" at the end of your ``conf/local.conf`` file found in the
7819:term:`Build Directory`:: 7819:term:`Build Directory`::
@@ -7913,10 +7913,10 @@ example assuming
7913 7913
7914You can use the 7914You can use the
7915``buildhistory-collect-srcrevs`` command with the ``-a`` option to 7915``buildhistory-collect-srcrevs`` command with the ``-a`` option to
7916collect the stored ``SRCREV`` values from build history and report them 7916collect the stored :term:`SRCREV` values from build history and report them
7917in a format suitable for use in global configuration (e.g., 7917in a format suitable for use in global configuration (e.g.,
7918``local.conf`` or a distro include file) to override floating 7918``local.conf`` or a distro include file) to override floating
7919``AUTOREV`` values to a fixed set of revisions. Here is some example 7919:term:`AUTOREV` values to a fixed set of revisions. Here is some example
7920output from this command:: 7920output from this command::
7921 7921
7922 $ buildhistory-collect-srcrevs -a 7922 $ buildhistory-collect-srcrevs -a
@@ -7945,7 +7945,7 @@ output from this command::
7945 7945
7946 Here are some notes on using the ``buildhistory-collect-srcrevs`` command: 7946 Here are some notes on using the ``buildhistory-collect-srcrevs`` command:
7947 7947
7948 - By default, only values where the ``SRCREV`` was not hardcoded 7948 - By default, only values where the :term:`SRCREV` was not hardcoded
7949 (usually when ``AUTOREV`` is used) are reported. Use the ``-a`` 7949 (usually when ``AUTOREV`` is used) are reported. Use the ``-a``
7950 option to see all ``SRCREV`` values. 7950 option to see all ``SRCREV`` values.
7951 7951
@@ -8276,7 +8276,7 @@ Once you start running the tests, the following happens:
8276 tests run. The full boot log is written to 8276 tests run. The full boot log is written to
8277 ``${WORKDIR}/testimage/qemu_boot_log``. 8277 ``${WORKDIR}/testimage/qemu_boot_log``.
8278 8278
82795. Each test module loads in the order found in ``TEST_SUITES``. You can 82795. Each test module loads in the order found in :term:`TEST_SUITES`. You can
8280 find the full output of the commands run over SSH in 8280 find the full output of the commands run over SSH in
8281 ``${WORKDIR}/testimgage/ssh_target_log``. 8281 ``${WORKDIR}/testimgage/ssh_target_log``.
8282 8282
@@ -8310,7 +8310,7 @@ addresses written into the image, or set the image to use DHCP and have
8310your DHCP server on the test network assign a known IP address based on 8310your DHCP server on the test network assign a known IP address based on
8311the MAC address of the device. 8311the MAC address of the device.
8312 8312
8313In order to run tests on hardware, you need to set ``TEST_TARGET`` to an 8313In order to run tests on hardware, you need to set :term:`TEST_TARGET` to an
8314appropriate value. For QEMU, you do not have to change anything, the 8314appropriate value. For QEMU, you do not have to change anything, the
8315default value is "qemu". For running tests on hardware, the following 8315default value is "qemu". For running tests on hardware, the following
8316options are available: 8316options are available:
@@ -8359,14 +8359,14 @@ options are available:
8359Selecting SystemdbootTarget 8359Selecting SystemdbootTarget
8360~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8360~~~~~~~~~~~~~~~~~~~~~~~~~~~
8361 8361
8362If you did not set ``TEST_TARGET`` to "SystemdbootTarget", then you do 8362If you did not set :term:`TEST_TARGET` to "SystemdbootTarget", then you do
8363not need any information in this section. You can skip down to the 8363not need any information in this section. You can skip down to the
8364":ref:`dev-manual/common-tasks:running tests`" section. 8364":ref:`dev-manual/common-tasks:running tests`" section.
8365 8365
8366If you did set ``TEST_TARGET`` to "SystemdbootTarget", you also need to 8366If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to
8367perform a one-time setup of your master image by doing the following: 8367perform a one-time setup of your master image by doing the following:
8368 8368
83691. *Set EFI_PROVIDER:* Be sure that ``EFI_PROVIDER`` is as follows:: 83691. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows::
8370 8370
8371 EFI_PROVIDER = "systemd-boot" 8371 EFI_PROVIDER = "systemd-boot"
8372 8372
@@ -8400,7 +8400,7 @@ perform a one-time setup of your master image by doing the following:
84003. *Install image:* Install the image that you just built on the target 84003. *Install image:* Install the image that you just built on the target
8401 system. 8401 system.
8402 8402
8403The final thing you need to do when setting ``TEST_TARGET`` to 8403The final thing you need to do when setting :term:`TEST_TARGET` to
8404"SystemdbootTarget" is to set up the test image: 8404"SystemdbootTarget" is to set up the test image:
8405 8405
84061. *Set up your local.conf file:* Make sure you have the following 84061. *Set up your local.conf file:* Make sure you have the following
@@ -8421,8 +8421,8 @@ Power Control
8421For most hardware targets other than "simpleremote", you can control 8421For most hardware targets other than "simpleremote", you can control
8422power: 8422power:
8423 8423
8424- You can use ``TEST_POWERCONTROL_CMD`` together with 8424- You can use :term:`TEST_POWERCONTROL_CMD` together with
8425 ``TEST_POWERCONTROL_EXTRA_ARGS`` as a command that runs on the host 8425 :term:`TEST_POWERCONTROL_EXTRA_ARGS` as a command that runs on the host
8426 and does power cycling. The test code passes one argument to that 8426 and does power cycling. The test code passes one argument to that
8427 command: off, on or cycle (off then on). Here is an example that 8427 command: off, on or cycle (off then on). Here is an example that
8428 could appear in your ``local.conf`` file:: 8428 could appear in your ``local.conf`` file::
@@ -8441,8 +8441,8 @@ power:
8441 8441
8442 .. note:: 8442 .. note::
8443 8443
8444 You need to customize ``TEST_POWERCONTROL_CMD`` and 8444 You need to customize :term:`TEST_POWERCONTROL_CMD` and
8445 ``TEST_POWERCONTROL_EXTRA_ARGS`` for your own setup. The one requirement 8445 :term:`TEST_POWERCONTROL_EXTRA_ARGS` for your own setup. The one requirement
8446 is that it accepts "on", "off", and "cycle" as the last argument. 8446 is that it accepts "on", "off", and "cycle" as the last argument.
8447 8447
8448- When no command is defined, it connects to the device over SSH and 8448- When no command is defined, it connects to the device over SSH and
@@ -8540,14 +8540,14 @@ the ``local.conf`` file as normal. Be sure that tests reside in
8540 8540
8541You can change the set of tests run by appending or overriding 8541You can change the set of tests run by appending or overriding
8542:term:`TEST_SUITES` variable in 8542:term:`TEST_SUITES` variable in
8543``local.conf``. Each name in ``TEST_SUITES`` represents a required test 8543``local.conf``. Each name in :term:`TEST_SUITES` represents a required test
8544for the image. Test modules named within ``TEST_SUITES`` cannot be 8544for the image. Test modules named within :term:`TEST_SUITES` cannot be
8545skipped even if a test is not suitable for an image (e.g. running the 8545skipped even if a test is not suitable for an image (e.g. running the
8546RPM tests on an image without ``rpm``). Appending "auto" to 8546RPM tests on an image without ``rpm``). Appending "auto" to
8547``TEST_SUITES`` causes the build system to try to run all tests that are 8547:term:`TEST_SUITES` causes the build system to try to run all tests that are
8548suitable for the image (i.e. each test module may elect to skip itself). 8548suitable for the image (i.e. each test module may elect to skip itself).
8549 8549
8550The order you list tests in ``TEST_SUITES`` is important and influences 8550The order you list tests in :term:`TEST_SUITES` is important and influences
8551test dependencies. Consequently, tests that depend on other tests should 8551test dependencies. Consequently, tests that depend on other tests should
8552be added after the test on which they depend. For example, since the 8552be added after the test on which they depend. For example, since the
8553``ssh`` test depends on the ``ping`` test, "ssh" needs to come after 8553``ssh`` test depends on the ``ping`` test, "ssh" needs to come after
@@ -8599,7 +8599,7 @@ following BitBake command form::
8599Exporting the tests places them in the 8599Exporting the tests places them in the
8600:term:`Build Directory` in 8600:term:`Build Directory` in
8601``tmp/testexport/``\ image, which is controlled by the 8601``tmp/testexport/``\ image, which is controlled by the
8602``TEST_EXPORT_DIR`` variable. 8602:term:`TEST_EXPORT_DIR` variable.
8603 8603
8604You can now run the tests outside of the build environment:: 8604You can now run the tests outside of the build environment::
8605 8605
@@ -9558,7 +9558,7 @@ So the first thing to do is build "neard" locally. Before you start the
9558build, set the 9558build, set the
9559:term:`PARALLEL_MAKE` variable 9559:term:`PARALLEL_MAKE` variable
9560in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a 9560in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a
9561high value for ``PARALLEL_MAKE`` increases the chances of the race 9561high value for :term:`PARALLEL_MAKE` increases the chances of the race
9562condition showing up:: 9562condition showing up::
9563 9563
9564 $ bitbake neard 9564 $ bitbake neard
@@ -9631,7 +9631,7 @@ The final thing you need to do to implement the fix in the build is to
9631update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the 9631update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
9632:term:`SRC_URI` statement includes 9632:term:`SRC_URI` statement includes
9633the patch file. The recipe file is in the folder above the patch. Here 9633the patch file. The recipe file is in the folder above the patch. Here
9634is what the edited ``SRC_URI`` statement would look like:: 9634is what the edited :term:`SRC_URI` statement would look like::
9635 9635
9636 SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \ 9636 SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \
9637 file://neard.in \ 9637 file://neard.in \
@@ -9640,7 +9640,7 @@ is what the edited ``SRC_URI`` statement would look like::
9640 " 9640 "
9641 9641
9642With the patch complete and moved to the correct folder and the 9642With the patch complete and moved to the correct folder and the
9643``SRC_URI`` statement updated, you can exit the ``devshell``:: 9643:term:`SRC_URI` statement updated, you can exit the ``devshell``::
9644 9644
9645 $ exit 9645 $ exit
9646 9646
@@ -9985,14 +9985,14 @@ Here are some other tips that you might find useful:
9985- Removing :term:`TMPDIR` (usually 9985- Removing :term:`TMPDIR` (usually
9986 ``tmp/``, within the 9986 ``tmp/``, within the
9987 :term:`Build Directory`) can often fix 9987 :term:`Build Directory`) can often fix
9988 temporary build issues. Removing ``TMPDIR`` is usually a relatively 9988 temporary build issues. Removing :term:`TMPDIR` is usually a relatively
9989 cheap operation, because task output will be cached in 9989 cheap operation, because task output will be cached in
9990 :term:`SSTATE_DIR` (usually 9990 :term:`SSTATE_DIR` (usually
9991 ``sstate-cache/``, which is also in the Build Directory). 9991 ``sstate-cache/``, which is also in the Build Directory).
9992 9992
9993 .. note:: 9993 .. note::
9994 9994
9995 Removing ``TMPDIR`` might be a workaround rather than a fix. 9995 Removing :term:`TMPDIR` might be a workaround rather than a fix.
9996 Consequently, trying to determine the underlying cause of an issue before 9996 Consequently, trying to determine the underlying cause of an issue before
9997 removing the directory is a good idea. 9997 removing the directory is a good idea.
9998 9998
@@ -10585,9 +10585,9 @@ build will fail.
10585Specifying the ``LIC_FILES_CHKSUM`` Variable 10585Specifying the ``LIC_FILES_CHKSUM`` Variable
10586~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10586~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10587 10587
10588The ``LIC_FILES_CHKSUM`` variable contains checksums of the license text 10588The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text
10589in the source code for the recipe. Following is an example of how to 10589in the source code for the recipe. Following is an example of how to
10590specify ``LIC_FILES_CHKSUM``:: 10590specify :term:`LIC_FILES_CHKSUM`::
10591 10591
10592 LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \ 10592 LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
10593 file://licfile1.txt;beginline=5;endline=29;md5=yyyy \ 10593 file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
@@ -10607,7 +10607,7 @@ specify ``LIC_FILES_CHKSUM``::
10607 10607
10608The build system uses the :term:`S` 10608The build system uses the :term:`S`
10609variable as the default directory when searching files listed in 10609variable as the default directory when searching files listed in
10610``LIC_FILES_CHKSUM``. The previous example employs the default 10610:term:`LIC_FILES_CHKSUM`. The previous example employs the default
10611directory. 10611directory.
10612 10612
10613Consider this next example:: 10613Consider this next example::
@@ -10620,13 +10620,13 @@ The first line locates a file in ``${S}/src/ls.c`` and isolates lines
10620five through 16 as license text. The second line refers to a file in 10620five through 16 as license text. The second line refers to a file in
10621:term:`WORKDIR`. 10621:term:`WORKDIR`.
10622 10622
10623Note that ``LIC_FILES_CHKSUM`` variable is mandatory for all recipes, 10623Note that :term:`LIC_FILES_CHKSUM` variable is mandatory for all recipes,
10624unless the ``LICENSE`` variable is set to "CLOSED". 10624unless the :term:`LICENSE` variable is set to "CLOSED".
10625 10625
10626Explanation of Syntax 10626Explanation of Syntax
10627~~~~~~~~~~~~~~~~~~~~~ 10627~~~~~~~~~~~~~~~~~~~~~
10628 10628
10629As mentioned in the previous section, the ``LIC_FILES_CHKSUM`` variable 10629As mentioned in the previous section, the :term:`LIC_FILES_CHKSUM` variable
10630lists all the important files that contain the license text for the 10630lists all the important files that contain the license text for the
10631source code. It is possible to specify a checksum for an entire file, or 10631source code. It is possible to specify a checksum for an entire file, or
10632a specific section of a file (specified by beginning and ending line 10632a specific section of a file (specified by beginning and ending line
@@ -10646,7 +10646,7 @@ build, the correct md5 checksum is placed in the build log and can be
10646easily copied to the recipe. 10646easily copied to the recipe.
10647 10647
10648There is no limit to how many files you can specify using the 10648There is no limit to how many files you can specify using the
10649``LIC_FILES_CHKSUM`` variable. Generally, however, every project 10649:term:`LIC_FILES_CHKSUM` variable. Generally, however, every project
10650requires a few specifications for license tracking. Many projects have a 10650requires a few specifications for license tracking. Many projects have a
10651"COPYING" file that stores the license information for all the source 10651"COPYING" file that stores the license information for all the source
10652code files. This practice allows you to just track the "COPYING" file as 10652code files. This practice allows you to just track the "COPYING" file as
@@ -10683,16 +10683,16 @@ name and version (after variable expansion)::
10683 LICENSE_FLAGS = "license_${PN}_${PV}" 10683 LICENSE_FLAGS = "license_${PN}_${PV}"
10684 10684
10685In order for a component restricted by a 10685In order for a component restricted by a
10686``LICENSE_FLAGS`` definition to be enabled and included in an image, it 10686:term:`LICENSE_FLAGS` definition to be enabled and included in an image, it
10687needs to have a matching entry in the global 10687needs to have a matching entry in the global
10688:term:`LICENSE_FLAGS_WHITELIST` 10688:term:`LICENSE_FLAGS_WHITELIST`
10689variable, which is a variable typically defined in your ``local.conf`` 10689variable, which is a variable typically defined in your ``local.conf``
10690file. For example, to enable the 10690file. For example, to enable the
10691``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you 10691``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you
10692could add either the string "commercial_gst-plugins-ugly" or the more 10692could add either the string "commercial_gst-plugins-ugly" or the more
10693general string "commercial" to ``LICENSE_FLAGS_WHITELIST``. See the 10693general string "commercial" to :term:`LICENSE_FLAGS_WHITELIST`. See the
10694":ref:`dev-manual/common-tasks:license flag matching`" section for a full 10694":ref:`dev-manual/common-tasks:license flag matching`" section for a full
10695explanation of how ``LICENSE_FLAGS`` matching works. Here is the 10695explanation of how :term:`LICENSE_FLAGS` matching works. Here is the
10696example:: 10696example::
10697 10697
10698 LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly" 10698 LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
@@ -10723,8 +10723,8 @@ License Flag Matching
10723 10723
10724License flag matching allows you to control what recipes the 10724License flag matching allows you to control what recipes the
10725OpenEmbedded build system includes in the build. Fundamentally, the 10725OpenEmbedded build system includes in the build. Fundamentally, the
10726build system attempts to match ``LICENSE_FLAGS`` strings found in 10726build system attempts to match :term:`LICENSE_FLAGS` strings found in
10727recipes against ``LICENSE_FLAGS_WHITELIST`` strings found in the 10727recipes against :term:`LICENSE_FLAGS_WHITELIST` strings found in the
10728whitelist. A match causes the build system to include a recipe in the 10728whitelist. A match causes the build system to include a recipe in the
10729build, while failure to find a match causes the build system to exclude 10729build, while failure to find a match causes the build system to exclude
10730a recipe. 10730a recipe.
@@ -10734,14 +10734,14 @@ concepts will help you correctly and effectively use matching.
10734 10734
10735Before a flag defined by a particular recipe is tested against the 10735Before a flag defined by a particular recipe is tested against the
10736contents of the whitelist, the expanded string ``_${PN}`` is appended to 10736contents of the whitelist, the expanded string ``_${PN}`` is appended to
10737the flag. This expansion makes each ``LICENSE_FLAGS`` value 10737the flag. This expansion makes each :term:`LICENSE_FLAGS` value
10738recipe-specific. After expansion, the string is then matched against the 10738recipe-specific. After expansion, the string is then matched against the
10739whitelist. Thus, specifying ``LICENSE_FLAGS = "commercial"`` in recipe 10739whitelist. Thus, specifying ``LICENSE_FLAGS = "commercial"`` in recipe
10740"foo", for example, results in the string ``"commercial_foo"``. And, to 10740"foo", for example, results in the string ``"commercial_foo"``. And, to
10741create a match, that string must appear in the whitelist. 10741create a match, that string must appear in the whitelist.
10742 10742
10743Judicious use of the ``LICENSE_FLAGS`` strings and the contents of the 10743Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the
10744``LICENSE_FLAGS_WHITELIST`` variable allows you a lot of flexibility for 10744:term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for
10745including or excluding recipes based on licensing. For example, you can 10745including or excluding recipes based on licensing. For example, you can
10746broaden the matching capabilities by using license flags string subsets 10746broaden the matching capabilities by using license flags string subsets
10747in the whitelist. 10747in the whitelist.
@@ -10753,7 +10753,7 @@ in the whitelist.
10753 ``usethispart_1.3``, ``usethispart_1.4``, and so forth). 10753 ``usethispart_1.3``, ``usethispart_1.4``, and so forth).
10754 10754
10755For example, simply specifying the string "commercial" in the whitelist 10755For example, simply specifying the string "commercial" in the whitelist
10756matches any expanded ``LICENSE_FLAGS`` definition that starts with the 10756matches any expanded :term:`LICENSE_FLAGS` definition that starts with the
10757string "commercial" such as "commercial_foo" and "commercial_bar", which 10757string "commercial" such as "commercial_foo" and "commercial_bar", which
10758are the strings the build system automatically generates for 10758are the strings the build system automatically generates for
10759hypothetical recipes named "foo" and "bar" assuming those recipes simply 10759hypothetical recipes named "foo" and "bar" assuming those recipes simply
@@ -10767,7 +10767,7 @@ only specific recipes into the image, or you can use a string subset
10767that causes a broader range of matches to allow a range of recipes into 10767that causes a broader range of matches to allow a range of recipes into
10768the image. 10768the image.
10769 10769
10770This scheme works even if the ``LICENSE_FLAGS`` string already has 10770This scheme works even if the :term:`LICENSE_FLAGS` string already has
10771``_${PN}`` appended. For example, the build system turns the license 10771``_${PN}`` appended. For example, the build system turns the license
10772flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match 10772flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match
10773both the general "commercial" and the specific "commercial_1.2_foo" 10773both the general "commercial" and the specific "commercial_1.2_foo"
@@ -10814,14 +10814,14 @@ file::
10814 10814
10815Of course, you could also create a matching whitelist for those 10815Of course, you could also create a matching whitelist for those
10816components using the more general "commercial" in the whitelist, but 10816components using the more general "commercial" in the whitelist, but
10817that would also enable all the other packages with ``LICENSE_FLAGS`` 10817that would also enable all the other packages with :term:`LICENSE_FLAGS`
10818containing "commercial", which you may or may not want:: 10818containing "commercial", which you may or may not want::
10819 10819
10820 LICENSE_FLAGS_WHITELIST = "commercial" 10820 LICENSE_FLAGS_WHITELIST = "commercial"
10821 10821
10822Specifying audio and video plugins as part of the 10822Specifying audio and video plugins as part of the
10823``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements 10823``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements
10824(along with the enabling ``LICENSE_FLAGS_WHITELIST``) includes the 10824(along with the enabling :term:`LICENSE_FLAGS_WHITELIST`) includes the
10825plugins or components into built images, thus adding support for media 10825plugins or components into built images, thus adding support for media
10826formats or components. 10826formats or components.
10827 10827
@@ -10887,7 +10887,7 @@ accidental release of proprietary software. The Yocto Project provides
10887an :ref:`archiver <ref-classes-archiver>` class to 10887an :ref:`archiver <ref-classes-archiver>` class to
10888help avoid some of these concerns. 10888help avoid some of these concerns.
10889 10889
10890Before you employ ``DL_DIR`` or the ``archiver`` class, you need to 10890Before you employ :term:`DL_DIR` or the ``archiver`` class, you need to
10891decide how you choose to provide source. The source ``archiver`` class 10891decide how you choose to provide source. The source ``archiver`` class
10892can generate tarballs and SRPMs and can create them with various levels 10892can generate tarballs and SRPMs and can create them with various levels
10893of compliance in mind. 10893of compliance in mind.
diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst
index 0e745c375d..871ec8ae7b 100644
--- a/documentation/kernel-dev/advanced.rst
+++ b/documentation/kernel-dev/advanced.rst
@@ -46,15 +46,15 @@ linux-yocto recipe.
46 46
47Every linux-yocto style recipe must define the 47Every linux-yocto style recipe must define the
48:term:`KMACHINE` variable. This 48:term:`KMACHINE` variable. This
49variable is typically set to the same value as the ``MACHINE`` variable, 49variable is typically set to the same value as the :term:`MACHINE` variable,
50which is used by :term:`BitBake`. 50which is used by :term:`BitBake`.
51However, in some cases, the variable might instead refer to the 51However, in some cases, the variable might instead refer to the
52underlying platform of the ``MACHINE``. 52underlying platform of the :term:`MACHINE`.
53 53
54Multiple BSPs can reuse the same ``KMACHINE`` name if they are built 54Multiple BSPs can reuse the same :term:`KMACHINE` name if they are built
55using the same BSP description. Multiple Corei7-based BSPs could share 55using the same BSP description. Multiple Corei7-based BSPs could share
56the same "intel-corei7-64" value for ``KMACHINE``. It is important to 56the same "intel-corei7-64" value for :term:`KMACHINE`. It is important to
57realize that ``KMACHINE`` is just for kernel mapping, while ``MACHINE`` 57realize that :term:`KMACHINE` is just for kernel mapping, while :term:`MACHINE`
58is the machine type within a BSP Layer. Even with this distinction, 58is the machine type within a BSP Layer. Even with this distinction,
59however, these two variables can hold the same value. See the 59however, these two variables can hold the same value. See the
60":ref:`kernel-dev/advanced:bsp descriptions`" section for more information. 60":ref:`kernel-dev/advanced:bsp descriptions`" section for more information.
@@ -66,7 +66,7 @@ to indicate the branch.
66 66
67.. note:: 67.. note::
68 68
69 You can use the ``KBRANCH`` value to define an alternate branch typically 69 You can use the :term:`KBRANCH` value to define an alternate branch typically
70 with a machine override as shown here from the ``meta-yocto-bsp`` layer:: 70 with a machine override as shown here from the ``meta-yocto-bsp`` layer::
71 71
72 KBRANCH_edgerouter = "standard/edgerouter" 72 KBRANCH_edgerouter = "standard/edgerouter"
@@ -81,8 +81,8 @@ variables:
81 81
82:term:`LINUX_KERNEL_TYPE` 82:term:`LINUX_KERNEL_TYPE`
83defines the kernel type to be used in assembling the configuration. If 83defines the kernel type to be used in assembling the configuration. If
84you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard". 84you do not specify a :term:`LINUX_KERNEL_TYPE`, it defaults to "standard".
85Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search 85Together with :term:`KMACHINE`, :term:`LINUX_KERNEL_TYPE` defines the search
86arguments used by the kernel tools to find the appropriate description 86arguments used by the kernel tools to find the appropriate description
87within the kernel Metadata with which to build out the sources and 87within the kernel Metadata with which to build out the sources and
88configuration. The linux-yocto recipes define "standard", "tiny", and 88configuration. The linux-yocto recipes define "standard", "tiny", and
@@ -90,21 +90,21 @@ configuration. The linux-yocto recipes define "standard", "tiny", and
90section for more information on kernel types. 90section for more information on kernel types.
91 91
92During the build, the kern-tools search for the BSP description file 92During the build, the kern-tools search for the BSP description file
93that most closely matches the ``KMACHINE`` and ``LINUX_KERNEL_TYPE`` 93that most closely matches the :term:`KMACHINE` and :term:`LINUX_KERNEL_TYPE`
94variables passed in from the recipe. The tools use the first BSP 94variables passed in from the recipe. The tools use the first BSP
95description they find that matches both variables. If the tools cannot find 95description they find that matches both variables. If the tools cannot find
96a match, they issue a warning. 96a match, they issue a warning.
97 97
98The tools first search for the ``KMACHINE`` and then for the 98The tools first search for the :term:`KMACHINE` and then for the
99``LINUX_KERNEL_TYPE``. If the tools cannot find a partial match, they 99:term:`LINUX_KERNEL_TYPE`. If the tools cannot find a partial match, they
100will use the sources from the ``KBRANCH`` and any configuration 100will use the sources from the :term:`KBRANCH` and any configuration
101specified in the :term:`SRC_URI`. 101specified in the :term:`SRC_URI`.
102 102
103You can use the 103You can use the
104:term:`KERNEL_FEATURES` 104:term:`KERNEL_FEATURES`
105variable to include features (configuration fragments, patches, or both) 105variable to include features (configuration fragments, patches, or both)
106that are not already included by the ``KMACHINE`` and 106that are not already included by the :term:`KMACHINE` and
107``LINUX_KERNEL_TYPE`` variable combination. For example, to include a 107:term:`LINUX_KERNEL_TYPE` variable combination. For example, to include a
108feature specified as "features/netfilter/netfilter.scc", specify:: 108feature specified as "features/netfilter/netfilter.scc", specify::
109 109
110 KERNEL_FEATURES += "features/netfilter/netfilter.scc" 110 KERNEL_FEATURES += "features/netfilter/netfilter.scc"
@@ -116,7 +116,7 @@ specify::
116 KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc" 116 KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
117 117
118The value of 118The value of
119the entries in ``KERNEL_FEATURES`` are dependent on their location 119the entries in :term:`KERNEL_FEATURES` are dependent on their location
120within the kernel Metadata itself. The examples here are taken from the 120within the kernel Metadata itself. The examples here are taken from the
121``yocto-kernel-cache`` repository. Each branch of this repository 121``yocto-kernel-cache`` repository. Each branch of this repository
122contains "features" and "cfg" subdirectories at the top-level. For more 122contains "features" and "cfg" subdirectories at the top-level. For more
@@ -344,7 +344,7 @@ as how an additional feature description file is included with the
344 344
345Typically, features are less granular than configuration fragments and 345Typically, features are less granular than configuration fragments and
346are more likely than configuration fragments and patches to be the types 346are more likely than configuration fragments and patches to be the types
347of things you want to specify in the ``KERNEL_FEATURES`` variable of the 347of things you want to specify in the :term:`KERNEL_FEATURES` variable of the
348Linux kernel recipe. See the 348Linux kernel recipe. See the
349":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier 349":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier
350in the manual. 350in the manual.
@@ -509,12 +509,12 @@ description as meeting the criteria set by the recipe being built. This
509example supports the "beaglebone" machine for the "standard" kernel and 509example supports the "beaglebone" machine for the "standard" kernel and
510the "arm" architecture. 510the "arm" architecture.
511 511
512Be aware that there is no hard link between the ``KTYPE`` variable and a kernel 512Be aware that there is no hard link between the :term:`KTYPE` variable and a kernel
513type description file. Thus, if you do not have the 513type description file. Thus, if you do not have the
514kernel type defined in your kernel Metadata as it is here, you only need 514kernel type defined in your kernel Metadata as it is here, you only need
515to ensure that the 515to ensure that the
516:term:`LINUX_KERNEL_TYPE` 516:term:`LINUX_KERNEL_TYPE`
517variable in the kernel recipe and the ``KTYPE`` variable in the BSP 517variable in the kernel recipe and the :term:`KTYPE` variable in the BSP
518description file match. 518description file match.
519 519
520To separate your kernel policy from your hardware configuration, you 520To separate your kernel policy from your hardware configuration, you
@@ -657,7 +657,7 @@ Notice again the three critical variables:
657:term:`KMACHINE`, 657:term:`KMACHINE`,
658:term:`KTYPE`, and 658:term:`KTYPE`, and
659:term:`KARCH`. Of these variables, only 659:term:`KARCH`. Of these variables, only
660``KTYPE`` has changed to specify the "tiny" kernel type. 660:term:`KTYPE` has changed to specify the "tiny" kernel type.
661 661
662Kernel Metadata Location 662Kernel Metadata Location
663======================== 663========================
@@ -693,7 +693,7 @@ directory hierarchy below
693a linux-yocto recipe or for a Linux kernel recipe derived by copying and 693a linux-yocto recipe or for a Linux kernel recipe derived by copying and
694modifying 694modifying
695``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to 695``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
696a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to 696a recipe in your layer, :term:`FILESEXTRAPATHS` is typically set to
697``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``. 697``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
698See the ":ref:`kernel-dev/common:modifying an existing recipe`" 698See the ":ref:`kernel-dev/common:modifying an existing recipe`"
699section for more information. 699section for more information.
@@ -718,10 +718,10 @@ and fetches any files referenced in the ``.scc`` files by the
718``include``, ``patch``, or ``kconf`` commands. Because of this, it is 718``include``, ``patch``, or ``kconf`` commands. Because of this, it is
719necessary to bump the recipe :term:`PR` 719necessary to bump the recipe :term:`PR`
720value when changing the content of files not explicitly listed in the 720value when changing the content of files not explicitly listed in the
721``SRC_URI``. 721:term:`SRC_URI`.
722 722
723If the BSP description is in recipe space, you cannot simply list the 723If the BSP description is in recipe space, you cannot simply list the
724``*.scc`` in the ``SRC_URI`` statement. You need to use the following 724``*.scc`` in the :term:`SRC_URI` statement. You need to use the following
725form from your kernel append file:: 725form from your kernel append file::
726 726
727 SRC_URI_append_myplatform = " \ 727 SRC_URI_append_myplatform = " \
@@ -735,7 +735,7 @@ When stored outside of the recipe-space, the kernel Metadata files
735reside in a separate repository. The OpenEmbedded build system adds the 735reside in a separate repository. The OpenEmbedded build system adds the
736Metadata to the build as a "type=kmeta" repository through the 736Metadata to the build as a "type=kmeta" repository through the
737:term:`SRC_URI` variable. As an 737:term:`SRC_URI` variable. As an
738example, consider the following ``SRC_URI`` statement from the 738example, consider the following :term:`SRC_URI` statement from the
739``linux-yocto_4.12.bb`` kernel recipe:: 739``linux-yocto_4.12.bb`` kernel recipe::
740 740
741 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \ 741 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \
@@ -744,20 +744,20 @@ example, consider the following ``SRC_URI`` statement from the
744 744
745``${KMETA}``, in this context, is simply used to name the directory into 745``${KMETA}``, in this context, is simply used to name the directory into
746which the Git fetcher places the Metadata. This behavior is no different 746which the Git fetcher places the Metadata. This behavior is no different
747than any multi-repository ``SRC_URI`` statement used in a recipe (e.g. 747than any multi-repository :term:`SRC_URI` statement used in a recipe (e.g.
748see the previous section). 748see the previous section).
749 749
750You can keep kernel Metadata in a "kernel-cache", which is a directory 750You can keep kernel Metadata in a "kernel-cache", which is a directory
751containing configuration fragments. As with any Metadata kept outside 751containing configuration fragments. As with any Metadata kept outside
752the recipe-space, you simply need to use the ``SRC_URI`` statement with 752the recipe-space, you simply need to use the :term:`SRC_URI` statement with
753the "type=kmeta" attribute. Doing so makes the kernel Metadata available 753the "type=kmeta" attribute. Doing so makes the kernel Metadata available
754during the configuration phase. 754during the configuration phase.
755 755
756If you modify the Metadata, you must not forget to update the ``SRCREV`` 756If you modify the Metadata, you must not forget to update the :term:`SRCREV`
757statements in the kernel's recipe. In particular, you need to update the 757statements in the kernel's recipe. In particular, you need to update the
758``SRCREV_meta`` variable to match the commit in the ``KMETA`` branch you 758``SRCREV_meta`` variable to match the commit in the ``KMETA`` branch you
759wish to use. Changing the data in these branches and not updating the 759wish to use. Changing the data in these branches and not updating the
760``SRCREV`` statements to match will cause the build to fetch an older 760:term:`SRCREV` statements to match will cause the build to fetch an older
761commit. 761commit.
762 762
763Organizing Your Source 763Organizing Your Source
@@ -820,7 +820,7 @@ patches into a feature.
820 820
821Once you have a new branch, you can set up your kernel Metadata to use 821Once you have a new branch, you can set up your kernel Metadata to use
822the branch a couple different ways. In the recipe, you can specify the 822the branch a couple different ways. In the recipe, you can specify the
823new branch as the ``KBRANCH`` to use for the board as follows:: 823new branch as the :term:`KBRANCH` to use for the board as follows::
824 824
825 KBRANCH = "mynewbranch" 825 KBRANCH = "mynewbranch"
826 826
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index f64cbab56c..de62df5b1f 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -70,7 +70,7 @@ section:
70 :term:`MACHINE` variable is set to 70 :term:`MACHINE` variable is set to
71 "qemux86-64", which is fine if you are building for the QEMU emulator 71 "qemux86-64", which is fine if you are building for the QEMU emulator
72 in 64-bit mode. However, if you are not, you need to set the 72 in 64-bit mode. However, if you are not, you need to set the
73 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file 73 :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
74 found in the 74 found in the
75 :term:`Build Directory` (i.e. 75 :term:`Build Directory` (i.e.
76 ``poky/build`` in this example). 76 ``poky/build`` in this example).
@@ -248,7 +248,7 @@ section:
248 :term:`MACHINE` variable is set to 248 :term:`MACHINE` variable is set to
249 "qemux86-64", which is fine if you are building for the QEMU emulator 249 "qemux86-64", which is fine if you are building for the QEMU emulator
250 in 64-bit mode. However, if you are not, you need to set the 250 in 64-bit mode. However, if you are not, you need to set the
251 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file 251 :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
252 found in the 252 found in the
253 :term:`Build Directory` (i.e. 253 :term:`Build Directory` (i.e.
254 ``poky/build`` in this example). 254 ``poky/build`` in this example).
@@ -474,7 +474,7 @@ variable as follows::
474The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}`` 474The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
475expands to "linux-yocto" in the current directory for this example. If 475expands to "linux-yocto" in the current directory for this example. If
476you add any new files that modify the kernel recipe and you have 476you add any new files that modify the kernel recipe and you have
477extended ``FILESPATH`` as described above, you must place the files in 477extended :term:`FILESPATH` as described above, you must place the files in
478your layer in the following area:: 478your layer in the following area::
479 479
480 your-layer/recipes-kernel/linux/linux-yocto/ 480 your-layer/recipes-kernel/linux/linux-yocto/
@@ -553,7 +553,7 @@ the append file.
553 553
554For example, suppose you had some configuration options in a file called 554For example, suppose you had some configuration options in a file called
555``network_configs.cfg``. You can place that file inside a directory 555``network_configs.cfg``. You can place that file inside a directory
556named ``linux-yocto`` and then add a ``SRC_URI`` statement such as the 556named ``linux-yocto`` and then add a :term:`SRC_URI` statement such as the
557following to the append file. When the OpenEmbedded build system builds 557following to the append file. When the OpenEmbedded build system builds
558the kernel, the configuration options are picked up and applied. 558the kernel, the configuration options are picked up and applied.
559:: 559::
@@ -563,7 +563,7 @@ the kernel, the configuration options are picked up and applied.
563To group related configurations into multiple files, you perform a 563To group related configurations into multiple files, you perform a
564similar procedure. Here is an example that groups separate 564similar procedure. Here is an example that groups separate
565configurations specifically for Ethernet and graphics into their own 565configurations specifically for Ethernet and graphics into their own
566files and adds the configurations by using a ``SRC_URI`` statement like 566files and adds the configurations by using a :term:`SRC_URI` statement like
567the following in your append file:: 567the following in your append file::
568 568
569 SRC_URI += "file://myconfig.cfg \ 569 SRC_URI += "file://myconfig.cfg \
@@ -643,7 +643,7 @@ following lines to the linux-yocto ``.bbappend`` file in your layer::
643 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 643 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
644 SRC_URI += "file://defconfig" 644 SRC_URI += "file://defconfig"
645 645
646The ``SRC_URI`` tells the build system how to search 646The :term:`SRC_URI` tells the build system how to search
647for the file, while the 647for the file, while the
648:term:`FILESEXTRAPATHS` 648:term:`FILESEXTRAPATHS`
649extends the :term:`FILESPATH` 649extends the :term:`FILESPATH`
@@ -684,7 +684,7 @@ with the following content (without indentation)::
684 CONFIG_SERIAL_CORE_CONSOLE=y 684 CONFIG_SERIAL_CORE_CONSOLE=y
685 685
686Next, include this 686Next, include this
687configuration fragment and extend the ``FILESPATH`` variable in your 687configuration fragment and extend the :term:`FILESPATH` variable in your
688``.bbappend`` file:: 688``.bbappend`` file::
689 689
690 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 690 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -722,7 +722,7 @@ form::
722 KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file" 722 KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
723 723
724Here is an example 724Here is an example
725that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2" 725that assigns the :term:`KBUILD_DEFCONFIG` variable based on "raspberrypi2"
726and provides the path to the "in-tree" ``defconfig`` file to be used for 726and provides the path to the "in-tree" ``defconfig`` file to be used for
727a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset:: 727a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
728 728
@@ -734,7 +734,7 @@ Aside from modifying your kernel recipe and providing your own
734a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the 734a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the
735build system detects a statement that identifies an "out-of-tree" 735build system detects a statement that identifies an "out-of-tree"
736``defconfig`` file, that statement will override your 736``defconfig`` file, that statement will override your
737``KBUILD_DEFCONFIG`` variable. 737:term:`KBUILD_DEFCONFIG` variable.
738 738
739See the 739See the
740:term:`KBUILD_DEFCONFIG` 740:term:`KBUILD_DEFCONFIG`
@@ -1349,10 +1349,10 @@ be picked up and applied when the kernel is built::
1349 SRC_URI += "file://myconfig.cfg" 1349 SRC_URI += "file://myconfig.cfg"
1350 1350
1351As mentioned earlier, you can group related configurations into multiple 1351As mentioned earlier, you can group related configurations into multiple
1352files and name them all in the ``SRC_URI`` statement as well. For 1352files and name them all in the :term:`SRC_URI` statement as well. For
1353example, you could group separate configurations specifically for 1353example, you could group separate configurations specifically for
1354Ethernet and graphics into their own files and add those by using a 1354Ethernet and graphics into their own files and add those by using a
1355``SRC_URI`` statement like the following in your append file:: 1355:term:`SRC_URI` statement like the following in your append file::
1356 1356
1357 SRC_URI += "file://myconfig.cfg \ 1357 SRC_URI += "file://myconfig.cfg \
1358 file://eth.cfg \ 1358 file://eth.cfg \
@@ -1628,11 +1628,11 @@ Here are some basic steps you can use to work with your own sources:
1628 appropriate for your project: 1628 appropriate for your project:
1629 1629
1630 - :term:`SRC_URI`: The 1630 - :term:`SRC_URI`: The
1631 ``SRC_URI`` should specify a Git repository that uses one of the 1631 :term:`SRC_URI` should specify a Git repository that uses one of the
1632 supported Git fetcher protocols (i.e. ``file``, ``git``, ``http``, 1632 supported Git fetcher protocols (i.e. ``file``, ``git``, ``http``,
1633 and so forth). The ``SRC_URI`` variable should also specify either 1633 and so forth). The :term:`SRC_URI` variable should also specify either
1634 a ``defconfig`` file or some configuration fragment files. The 1634 a ``defconfig`` file or some configuration fragment files. The
1635 skeleton recipe provides an example ``SRC_URI`` as a syntax 1635 skeleton recipe provides an example :term:`SRC_URI` as a syntax
1636 reference. 1636 reference.
1637 1637
1638 - :term:`LINUX_VERSION`: 1638 - :term:`LINUX_VERSION`:
@@ -1650,16 +1650,16 @@ Here are some basic steps you can use to work with your own sources:
1650 indicate to the OpenEmbedded build system that the recipe has 1650 indicate to the OpenEmbedded build system that the recipe has
1651 changed. 1651 changed.
1652 1652
1653 - :term:`PV`: The default ``PV`` 1653 - :term:`PV`: The default :term:`PV`
1654 assignment is typically adequate. It combines the 1654 assignment is typically adequate. It combines the
1655 ``LINUX_VERSION`` with the Source Control Manager (SCM) revision 1655 :term:`LINUX_VERSION` with the Source Control Manager (SCM) revision
1656 as derived from the :term:`SRCPV` 1656 as derived from the :term:`SRCPV`
1657 variable. The combined results are a string with the following 1657 variable. The combined results are a string with the following
1658 form:: 1658 form::
1659 1659
1660 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 1660 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
1661 1661
1662 While lengthy, the extra verbosity in ``PV`` helps ensure you are 1662 While lengthy, the extra verbosity in :term:`PV` helps ensure you are
1663 using the exact sources from which you intend to build. 1663 using the exact sources from which you intend to build.
1664 1664
1665 - :term:`COMPATIBLE_MACHINE`: 1665 - :term:`COMPATIBLE_MACHINE`:
@@ -1773,7 +1773,7 @@ information to build modules. If your module ``Makefile`` uses a
1773different variable, you might want to override the 1773different variable, you might want to override the
1774:ref:`ref-tasks-compile` step, or 1774:ref:`ref-tasks-compile` step, or
1775create a patch to the ``Makefile`` to work with the more typical 1775create a patch to the ``Makefile`` to work with the more typical
1776``KERNEL_SRC`` or ``KERNEL_PATH`` variables. 1776:term:`KERNEL_SRC` or :term:`KERNEL_PATH` variables.
1777 1777
1778After you have prepared your recipe, you will likely want to include the 1778After you have prepared your recipe, you will likely want to include the
1779module in your images. To do this, see the documentation for the 1779module in your images. To do this, see the documentation for the
@@ -1886,23 +1886,23 @@ build stops. Kernel features are the last elements processed for
1886configuring and patching the kernel. Therefore, adding features in this 1886configuring and patching the kernel. Therefore, adding features in this
1887manner is a way to enforce specific features are present and enabled 1887manner is a way to enforce specific features are present and enabled
1888without needing to do a full audit of any other layer's additions to the 1888without needing to do a full audit of any other layer's additions to the
1889``SRC_URI`` statement. 1889:term:`SRC_URI` statement.
1890 1890
1891You add a kernel feature by providing the feature as part of the 1891You add a kernel feature by providing the feature as part of the
1892``KERNEL_FEATURES`` variable and by providing the path to the feature's 1892:term:`KERNEL_FEATURES` variable and by providing the path to the feature's
1893``.scc`` file, which is relative to the root of the kernel Metadata. The 1893``.scc`` file, which is relative to the root of the kernel Metadata. The
1894OpenEmbedded build system searches all forms of kernel Metadata on the 1894OpenEmbedded build system searches all forms of kernel Metadata on the
1895``SRC_URI`` statement regardless of whether the Metadata is in the 1895:term:`SRC_URI` statement regardless of whether the Metadata is in the
1896"kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e. 1896"kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
1897part of the kernel recipe). See the 1897part of the kernel recipe). See the
1898":ref:`kernel-dev/advanced:kernel metadata location`" section for 1898":ref:`kernel-dev/advanced:kernel metadata location`" section for
1899additional information. 1899additional information.
1900 1900
1901When you specify the feature's ``.scc`` file on the ``SRC_URI`` 1901When you specify the feature's ``.scc`` file on the :term:`SRC_URI`
1902statement, the OpenEmbedded build system adds the directory of that 1902statement, the OpenEmbedded build system adds the directory of that
1903``.scc`` file along with all its subdirectories to the kernel feature 1903``.scc`` file along with all its subdirectories to the kernel feature
1904search path. Because subdirectories are searched, you can reference a 1904search path. Because subdirectories are searched, you can reference a
1905single ``.scc`` file in the ``SRC_URI`` statement to reference multiple 1905single ``.scc`` file in the :term:`SRC_URI` statement to reference multiple
1906kernel features. 1906kernel features.
1907 1907
1908Consider the following example that adds the "test.scc" feature to the 1908Consider the following example that adds the "test.scc" feature to the
@@ -1910,7 +1910,7 @@ build.
1910 1910
19111. *Create the Feature File:* Create a ``.scc`` file and locate it just 19111. *Create the Feature File:* Create a ``.scc`` file and locate it just
1912 as you would any other patch file, ``.cfg`` file, or fetcher item you 1912 as you would any other patch file, ``.cfg`` file, or fetcher item you
1913 specify in the ``SRC_URI`` statement. 1913 specify in the :term:`SRC_URI` statement.
1914 1914
1915 .. note:: 1915 .. note::
1916 1916
@@ -1937,7 +1937,7 @@ build.
1937 a similarly named configuration fragment file ``test.cfg``. 1937 a similarly named configuration fragment file ``test.cfg``.
1938 1938
19392. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the 19392. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the
1940 recipe's ``SRC_URI`` statement:: 1940 recipe's :term:`SRC_URI` statement::
1941 1941
1942 SRC_URI_append = " file://test.scc" 1942 SRC_URI_append = " file://test.scc"
1943 1943
@@ -1945,7 +1945,7 @@ build.
1945 appended to the existing path. 1945 appended to the existing path.
1946 1946
19473. *Specify the Feature as a Kernel Feature:* Use the 19473. *Specify the Feature as a Kernel Feature:* Use the
1948 ``KERNEL_FEATURES`` statement to specify the feature as a kernel 1948 :term:`KERNEL_FEATURES` statement to specify the feature as a kernel
1949 feature:: 1949 feature::
1950 1950
1951 KERNEL_FEATURES_append = " test.scc" 1951 KERNEL_FEATURES_append = " test.scc"
diff --git a/documentation/kernel-dev/faq.rst b/documentation/kernel-dev/faq.rst
index cffd1c4330..f0a7af37bb 100644
--- a/documentation/kernel-dev/faq.rst
+++ b/documentation/kernel-dev/faq.rst
@@ -68,7 +68,7 @@ How do I change the Linux kernel command line?
68---------------------------------------------- 68----------------------------------------------
69 69
70The Linux kernel command line is 70The Linux kernel command line is
71typically specified in the machine config using the ``APPEND`` variable. 71typically specified in the machine config using the :term:`APPEND` variable.
72For example, you can add some helpful debug information doing the 72For example, you can add some helpful debug information doing the
73following:: 73following::
74 74
diff --git a/documentation/kernel-dev/maint-appx.rst b/documentation/kernel-dev/maint-appx.rst
index 3354de5f0c..d968c856f6 100644
--- a/documentation/kernel-dev/maint-appx.rst
+++ b/documentation/kernel-dev/maint-appx.rst
@@ -104,7 +104,7 @@ patch, or BSP:
104 repository organized under the "Yocto Linux Kernel" heading in the 104 repository organized under the "Yocto Linux Kernel" heading in the
105 :yocto_git:`Yocto Project Source Repositories <>`. 105 :yocto_git:`Yocto Project Source Repositories <>`.
106 106
107 - Areas pointed to by ``SRC_URI`` statements found in kernel recipes. 107 - Areas pointed to by :term:`SRC_URI` statements found in kernel recipes.
108 108
109 For a typical build, the target of the search is a feature 109 For a typical build, the target of the search is a feature
110 description in an ``.scc`` file whose name follows this format (e.g. 110 description in an ``.scc`` file whose name follows this format (e.g.
diff --git a/documentation/migration-guides/migration-1.3.rst b/documentation/migration-guides/migration-1.3.rst
index db5333ccd7..afb868e7cb 100644
--- a/documentation/migration-guides/migration-1.3.rst
+++ b/documentation/migration-guides/migration-1.3.rst
@@ -125,7 +125,7 @@ Image recipes that previously included ``apps-console-core`` in
125:term:`IMAGE_FEATURES` should now include ``splash`` 125:term:`IMAGE_FEATURES` should now include ``splash``
126instead to enable the boot-up splash screen. Retaining 126instead to enable the boot-up splash screen. Retaining
127``apps-console-core`` will still include the splash screen but generates a 127``apps-console-core`` will still include the splash screen but generates a
128warning. The ``apps-x11-core`` and ``apps-x11-games`` ``IMAGE_FEATURES`` 128warning. The ``apps-x11-core`` and ``apps-x11-games`` :term:`IMAGE_FEATURES`
129features have been removed. 129features have been removed.
130 130
131.. _migration-1.3-removed-recipes: 131.. _migration-1.3-removed-recipes:
@@ -185,7 +185,7 @@ include :term:`PE` as part of the filename::
185 185
186 KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}" 186 KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
187 187
188Because the ``PE`` variable is not set by default, these binary files 188Because the :term:`PE` variable is not set by default, these binary files
189could result with names that include two dash characters. Here is an 189could result with names that include two dash characters. Here is an
190example:: 190example::
191 191
diff --git a/documentation/migration-guides/migration-1.4.rst b/documentation/migration-guides/migration-1.4.rst
index 07dd93b761..3f980915cf 100644
--- a/documentation/migration-guides/migration-1.4.rst
+++ b/documentation/migration-guides/migration-1.4.rst
@@ -28,7 +28,7 @@ Differences include the following:
28 and uninstall script functions ``pkg_preinst``, ``pkg_postinst``, 28 and uninstall script functions ``pkg_preinst``, ``pkg_postinst``,
29 ``pkg_prerm``, and ``pkg_postrm`` should always have a package name 29 ``pkg_prerm``, and ``pkg_postrm`` should always have a package name
30 override. For example, use ``RDEPENDS_${PN}`` for the main package 30 override. For example, use ``RDEPENDS_${PN}`` for the main package
31 instead of ``RDEPENDS``. BitBake uses more strict checks when it 31 instead of :term:`RDEPENDS`. BitBake uses more strict checks when it
32 parses recipes. 32 parses recipes.
33 33
34.. _migration-1.4-build-behavior: 34.. _migration-1.4-build-behavior:
@@ -53,10 +53,10 @@ Differences include the following:
53 :term:`SRC_URI`, the build system now uses 53 :term:`SRC_URI`, the build system now uses
54 :term:`FILESOVERRIDES` instead of 54 :term:`FILESOVERRIDES` instead of
55 :term:`OVERRIDES` for the directory names. In 55 :term:`OVERRIDES` for the directory names. In
56 general, the values previously in ``OVERRIDES`` are now in 56 general, the values previously in :term:`OVERRIDES` are now in
57 ``FILESOVERRIDES`` as well. However, if you relied upon an additional 57 :term:`FILESOVERRIDES` as well. However, if you relied upon an additional
58 value you previously added to ``OVERRIDES``, you might now need to 58 value you previously added to :term:`OVERRIDES`, you might now need to
59 add it to ``FILESOVERRIDES`` unless you are already adding it through 59 add it to :term:`FILESOVERRIDES` unless you are already adding it through
60 the :term:`MACHINEOVERRIDES` or 60 the :term:`MACHINEOVERRIDES` or
61 :term:`DISTROOVERRIDES` variables, as 61 :term:`DISTROOVERRIDES` variables, as
62 appropriate. For more related changes, see the 62 appropriate. For more related changes, see the
@@ -105,7 +105,7 @@ Variables
105 105
106The following variables have changed: 106The following variables have changed:
107 107
108- ``SANITY_TESTED_DISTROS``: This variable now uses a distribution 108- :term:`SANITY_TESTED_DISTROS`: This variable now uses a distribution
109 ID, which is composed of the host distributor ID followed by the 109 ID, which is composed of the host distributor ID followed by the
110 release. Previously, 110 release. Previously,
111 :term:`SANITY_TESTED_DISTROS` was 111 :term:`SANITY_TESTED_DISTROS` was
@@ -114,7 +114,7 @@ The following variables have changed:
114 you are not specifically setting this variable, or if you are 114 you are not specifically setting this variable, or if you are
115 specifically setting it to "". 115 specifically setting it to "".
116 116
117- ``SRC_URI``: The ``${``\ :term:`PN`\ ``}``, 117- :term:`SRC_URI`: The ``${``\ :term:`PN`\ ``}``,
118 ``${``\ :term:`PF`\ ``}``, 118 ``${``\ :term:`PF`\ ``}``,
119 ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories 119 ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories
120 have been dropped from the default value of the 120 have been dropped from the default value of the
diff --git a/documentation/migration-guides/migration-1.5.rst b/documentation/migration-guides/migration-1.5.rst
index f6bd118c9d..e956d9fffa 100644
--- a/documentation/migration-guides/migration-1.5.rst
+++ b/documentation/migration-guides/migration-1.5.rst
@@ -68,7 +68,7 @@ The following changes have been made that relate to BitBake:
68- ``${``\ :term:`P`\ ``}`` and 68- ``${``\ :term:`P`\ ``}`` and
69 ``${``\ :term:`PF`\ ``}`` are no longer added to 69 ``${``\ :term:`PF`\ ``}`` are no longer added to
70 :term:`PROVIDES` by default in ``bitbake.conf``. 70 :term:`PROVIDES` by default in ``bitbake.conf``.
71 These version-specific ``PROVIDES`` items were seldom used. 71 These version-specific :term:`PROVIDES` items were seldom used.
72 Attempting to use them could result in two versions being built 72 Attempting to use them could result in two versions being built
73 simultaneously rather than just one version due to the way BitBake 73 simultaneously rather than just one version due to the way BitBake
74 resolves dependencies. 74 resolves dependencies.
@@ -84,9 +84,9 @@ The following changes have been made to the package QA checks:
84 :term:`WARN_QA` values in your configuration, check 84 :term:`WARN_QA` values in your configuration, check
85 that they contain all of the issues that you wish to be reported. 85 that they contain all of the issues that you wish to be reported.
86 Previous Yocto Project versions contained a bug that meant that any 86 Previous Yocto Project versions contained a bug that meant that any
87 item not mentioned in ``ERROR_QA`` or ``WARN_QA`` would be treated as 87 item not mentioned in :term:`ERROR_QA` or :term:`WARN_QA` would be treated as
88 a warning. Consequently, several important items were not already in 88 a warning. Consequently, several important items were not already in
89 the default value of ``WARN_QA``. All of the possible QA checks are 89 the default value of :term:`WARN_QA`. All of the possible QA checks are
90 now documented in the ":ref:`insane.bbclass <ref-classes-insane>`" 90 now documented in the ":ref:`insane.bbclass <ref-classes-insane>`"
91 section. 91 section.
92 92
@@ -97,7 +97,7 @@ The following changes have been made to the package QA checks:
97 97
98- If you are using the ``buildhistory`` class, the check for the package 98- If you are using the ``buildhistory`` class, the check for the package
99 version going backwards is now controlled using a standard QA check. 99 version going backwards is now controlled using a standard QA check.
100 Thus, if you have customized your ``ERROR_QA`` or ``WARN_QA`` values 100 Thus, if you have customized your :term:`ERROR_QA` or :term:`WARN_QA` values
101 and still wish to have this check performed, you should add 101 and still wish to have this check performed, you should add
102 "version-going-backwards" to your value for one or the other 102 "version-going-backwards" to your value for one or the other
103 variables depending on how you wish it to be handled. See the 103 variables depending on how you wish it to be handled. See the
@@ -129,7 +129,7 @@ The following directory changes exist:
129- When buildhistory is enabled, its output is now written under the 129- When buildhistory is enabled, its output is now written under the
130 :term:`Build Directory` rather than 130 :term:`Build Directory` rather than
131 :term:`TMPDIR`. Doing so makes it easier to delete 131 :term:`TMPDIR`. Doing so makes it easier to delete
132 ``TMPDIR`` and preserve the build history. Additionally, data for 132 :term:`TMPDIR` and preserve the build history. Additionally, data for
133 produced SDKs is now split by :term:`IMAGE_NAME`. 133 produced SDKs is now split by :term:`IMAGE_NAME`.
134 134
135- The ``pkgdata`` directory produced as part of the packaging process 135- The ``pkgdata`` directory produced as part of the packaging process
@@ -157,20 +157,20 @@ major issue in the way the values are used.
157The following changes have been made that relate to 157The following changes have been made that relate to
158:term:`IMAGE_FEATURES`: 158:term:`IMAGE_FEATURES`:
159 159
160- The value of ``IMAGE_FEATURES`` is now validated to ensure invalid 160- The value of :term:`IMAGE_FEATURES` is now validated to ensure invalid
161 feature items are not added. Some users mistakenly add package names 161 feature items are not added. Some users mistakenly add package names
162 to this variable instead of using 162 to this variable instead of using
163 :term:`IMAGE_INSTALL` in order to have the 163 :term:`IMAGE_INSTALL` in order to have the
164 package added to the image, which does not work. This change is 164 package added to the image, which does not work. This change is
165 intended to catch those kinds of situations. Valid ``IMAGE_FEATURES`` 165 intended to catch those kinds of situations. Valid :term:`IMAGE_FEATURES`
166 are drawn from ``PACKAGE_GROUP`` definitions, 166 are drawn from ``PACKAGE_GROUP`` definitions,
167 :term:`COMPLEMENTARY_GLOB` and a new 167 :term:`COMPLEMENTARY_GLOB` and a new
168 "validitems" varflag on ``IMAGE_FEATURES``. The "validitems" varflag 168 "validitems" varflag on :term:`IMAGE_FEATURES`. The "validitems" varflag
169 change allows additional features to be added if they are not 169 change allows additional features to be added if they are not
170 provided using the previous two mechanisms. 170 provided using the previous two mechanisms.
171 171
172- The previously deprecated "apps-console-core" ``IMAGE_FEATURES`` item 172- The previously deprecated "apps-console-core" :term:`IMAGE_FEATURES` item
173 is no longer supported. Add "splash" to ``IMAGE_FEATURES`` if you 173 is no longer supported. Add "splash" to :term:`IMAGE_FEATURES` if you
174 wish to have the splash screen enabled, since this is all that 174 wish to have the splash screen enabled, since this is all that
175 apps-console-core was doing. 175 apps-console-core was doing.
176 176
@@ -285,7 +285,7 @@ Following are changes to ``udev``:
285 ``udev-extraconf`` to your image. 285 ``udev-extraconf`` to your image.
286 286
287- ``udev`` no longer brings in ``pciutils-ids`` or ``usbutils-ids`` 287- ``udev`` no longer brings in ``pciutils-ids`` or ``usbutils-ids``
288 through ``RRECOMMENDS``. These are not needed by ``udev`` itself and 288 through :term:`RRECOMMENDS`. These are not needed by ``udev`` itself and
289 removing them saves around 350KB. 289 removing them saves around 350KB.
290 290
291.. _migration-1.5-removed-renamed-recipes: 291.. _migration-1.5-removed-renamed-recipes:
diff --git a/documentation/migration-guides/migration-1.6.rst b/documentation/migration-guides/migration-1.6.rst
index 1408e12c23..eea3d17676 100644
--- a/documentation/migration-guides/migration-1.6.rst
+++ b/documentation/migration-guides/migration-1.6.rst
@@ -61,7 +61,7 @@ If you do not specify a branch, BitBake looks in the default "master" branch.
61 61
62Alternatively, if you need to bypass this check (e.g. if you are 62Alternatively, if you need to bypass this check (e.g. if you are
63fetching a revision corresponding to a tag that is not on any branch), 63fetching a revision corresponding to a tag that is not on any branch),
64you can add ";nobranch=1" to the end of the URL within ``SRC_URI``. 64you can add ";nobranch=1" to the end of the URL within :term:`SRC_URI`.
65 65
66.. _migration-1.6-bitbake-deps: 66.. _migration-1.6-bitbake-deps:
67 67
@@ -134,9 +134,9 @@ OpenEmbedded build system variables, see the ":doc:`/ref-manual/variables`" Chap
134 134
135:term:`TMPDIR` can no longer be on an NFS mount. NFS does 135:term:`TMPDIR` can no longer be on an NFS mount. NFS does
136not offer full POSIX locking and inode consistency and can cause 136not offer full POSIX locking and inode consistency and can cause
137unexpected issues if used to store ``TMPDIR``. 137unexpected issues if used to store :term:`TMPDIR`.
138 138
139The check for this occurs on startup. If ``TMPDIR`` is detected on an 139The check for this occurs on startup. If :term:`TMPDIR` is detected on an
140NFS mount, an error occurs. 140NFS mount, an error occurs.
141 141
142.. _migration-1.6-variable-changes-PRINC: 142.. _migration-1.6-variable-changes-PRINC:
@@ -274,7 +274,7 @@ In addition to ``core-image-basic`` being renamed,
274Licensing 274Licensing
275--------- 275---------
276 276
277The top-level ``LICENSE`` file has been changed to better describe the 277The top-level :term:`LICENSE` file has been changed to better describe the
278license of the various components of :term:`OpenEmbedded-Core (OE-Core)`. However, 278license of the various components of :term:`OpenEmbedded-Core (OE-Core)`. However,
279the licensing itself remains unchanged. 279the licensing itself remains unchanged.
280 280
@@ -284,7 +284,7 @@ recipes point to this file within
284``${COREBASE}/LICENSE``) and thus the accompanying checksum must be 284``${COREBASE}/LICENSE``) and thus the accompanying checksum must be
285changed from 3f40d7994397109285ec7b81fdeb3b58 to 285changed from 3f40d7994397109285ec7b81fdeb3b58 to
2864d92cd373abda3937c2bc47fbc49d690. A better alternative is to have 2864d92cd373abda3937c2bc47fbc49d690. A better alternative is to have
287``LIC_FILES_CHKSUM`` point to a file describing the license that is 287:term:`LIC_FILES_CHKSUM` point to a file describing the license that is
288distributed with the source that the recipe is building, if possible, 288distributed with the source that the recipe is building, if possible,
289rather than pointing to ``${COREBASE}/LICENSE``. 289rather than pointing to ``${COREBASE}/LICENSE``.
290 290
@@ -297,7 +297,7 @@ The "-fpermissive" option has been removed from the default
297:term:`CFLAGS` value. You need to take action on 297:term:`CFLAGS` value. You need to take action on
298individual recipes that fail when building with this option. You need to 298individual recipes that fail when building with this option. You need to
299either patch the recipes to fix the issues reported by the compiler, or 299either patch the recipes to fix the issues reported by the compiler, or
300you need to add "-fpermissive" to ``CFLAGS`` in the recipes. 300you need to add "-fpermissive" to :term:`CFLAGS` in the recipes.
301 301
302.. _migration-1.6-custom-images: 302.. _migration-1.6-custom-images:
303 303
diff --git a/documentation/migration-guides/migration-1.7.rst b/documentation/migration-guides/migration-1.7.rst
index 999f11a12b..c3a50eec88 100644
--- a/documentation/migration-guides/migration-1.7.rst
+++ b/documentation/migration-guides/migration-1.7.rst
@@ -140,9 +140,9 @@ part of the variable name. This change not only simplifies usage but
140also allows the values of these variables to be appropriately 140also allows the values of these variables to be appropriately
141incorporated into task signatures and thus trigger the appropriate tasks 141incorporated into task signatures and thus trigger the appropriate tasks
142to re-execute when changed. You should replace any references to 142to re-execute when changed. You should replace any references to
143``module_autoload_*`` with ``KERNEL_MODULE_AUTOLOAD``, and add any 143``module_autoload_*`` with :term:`KERNEL_MODULE_AUTOLOAD`, and add any
144modules for which ``module_conf_*`` is specified to 144modules for which ``module_conf_*`` is specified to
145``KERNEL_MODULE_PROBECONF``. 145:term:`KERNEL_MODULE_PROBECONF`.
146 146
147.. _migration-1.7-qa-check-changes: 147.. _migration-1.7-qa-check-changes:
148 148
diff --git a/documentation/migration-guides/migration-1.8.rst b/documentation/migration-guides/migration-1.8.rst
index 971bd33f40..51a13873e2 100644
--- a/documentation/migration-guides/migration-1.8.rst
+++ b/documentation/migration-guides/migration-1.8.rst
@@ -153,8 +153,8 @@ The following QA Check and Validation Changes have occurred:
153 instead of ``${D}``. 153 instead of ``${D}``.
154 154
155- :term:`S` now needs to be set to a valid value within a 155- :term:`S` now needs to be set to a valid value within a
156 recipe. If ``S`` is not set in the recipe, the directory is not 156 recipe. If :term:`S` is not set in the recipe, the directory is not
157 automatically created. If ``S`` does not point to a directory that 157 automatically created. If :term:`S` does not point to a directory that
158 exists at the time the :ref:`ref-tasks-unpack` task 158 exists at the time the :ref:`ref-tasks-unpack` task
159 finishes, a warning will be shown. 159 finishes, a warning will be shown.
160 160
diff --git a/documentation/migration-guides/migration-2.0.rst b/documentation/migration-guides/migration-2.0.rst
index 22d0752226..7217853779 100644
--- a/documentation/migration-guides/migration-2.0.rst
+++ b/documentation/migration-guides/migration-2.0.rst
@@ -25,7 +25,7 @@ and the porting guide at
25https://gcc.gnu.org/gcc-5/porting_to.html. 25https://gcc.gnu.org/gcc-5/porting_to.html.
26 26
27Alternatively, you can switch back to GCC 4.9 or 4.8 by setting 27Alternatively, you can switch back to GCC 4.9 or 4.8 by setting
28``GCCVERSION`` in your configuration, as follows:: 28:term:`GCCVERSION` in your configuration, as follows::
29 29
30 GCCVERSION = "4.9%" 30 GCCVERSION = "4.9%"
31 31
@@ -244,7 +244,7 @@ The following QA checks have been added:
244 244
245- Added an "invalid-packageconfig" check for any options specified in 245- Added an "invalid-packageconfig" check for any options specified in
246 :term:`PACKAGECONFIG` that do not match any 246 :term:`PACKAGECONFIG` that do not match any
247 ``PACKAGECONFIG`` option defined for the recipe. 247 :term:`PACKAGECONFIG` option defined for the recipe.
248 248
249.. _migration-2.0-miscellaneous: 249.. _migration-2.0-miscellaneous:
250 250
diff --git a/documentation/migration-guides/migration-2.1.rst b/documentation/migration-guides/migration-2.1.rst
index d4db8218cf..6c5ed965dc 100644
--- a/documentation/migration-guides/migration-2.1.rst
+++ b/documentation/migration-guides/migration-2.1.rst
@@ -28,8 +28,8 @@ characters. This practice is now a requirement as BitBake's datastore
28now assumes lower-case characters in order to give a slight performance 28now assumes lower-case characters in order to give a slight performance
29boost during parsing. In practical terms, this requirement means that 29boost during parsing. In practical terms, this requirement means that
30anything that ends up in :term:`OVERRIDES` must now 30anything that ends up in :term:`OVERRIDES` must now
31appear in lower-case characters (e.g. values for ``MACHINE``, 31appear in lower-case characters (e.g. values for :term:`MACHINE`,
32``TARGET_ARCH``, ``DISTRO``, and also recipe names if 32:term:`TARGET_ARCH`, :term:`DISTRO`, and also recipe names if
33``_pn-``\ recipename overrides are to be effective). 33``_pn-``\ recipename overrides are to be effective).
34 34
35.. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory: 35.. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory:
@@ -68,7 +68,7 @@ was a historical accident that has required many classes (e.g.
68to work with sensible build systems. When upgrading to the release, you 68to work with sensible build systems. When upgrading to the release, you
69must edit any recipe that relies upon this old default by either setting 69must edit any recipe that relies upon this old default by either setting
70``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any 70``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any
71required variable value overrides using ``EXTRA_OEMAKE``, which is 71required variable value overrides using :term:`EXTRA_OEMAKE`, which is
72typically only needed when a Makefile sets a default value for a 72typically only needed when a Makefile sets a default value for a
73variable that is inappropriate for cross-compilation using the "=" 73variable that is inappropriate for cross-compilation using the "="
74operator rather than the "?=" operator. 74operator rather than the "?=" operator.
@@ -376,7 +376,7 @@ These additional changes exist:
376 run-postinsts 376 run-postinsts
377 377
378 With the Yocto Project 2.1 release, these packages are 378 With the Yocto Project 2.1 release, these packages are
379 only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since 379 only removed if "read-only-rootfs" is in :term:`IMAGE_FEATURES`, since
380 they might still be needed for a read-write image even in the absence 380 they might still be needed for a read-write image even in the absence
381 of a package manager (e.g. if users need to be added, modified, or 381 of a package manager (e.g. if users need to be added, modified, or
382 removed at runtime). 382 removed at runtime).
diff --git a/documentation/migration-guides/migration-2.2.rst b/documentation/migration-guides/migration-2.2.rst
index e30761dc99..c93081e1da 100644
--- a/documentation/migration-guides/migration-2.2.rst
+++ b/documentation/migration-guides/migration-2.2.rst
@@ -239,7 +239,7 @@ to catch recipes that are building software without using the
239OpenEmbedded :term:`LDFLAGS`. This change could result in 239OpenEmbedded :term:`LDFLAGS`. This change could result in
240seeing some "No GNU_HASH in the elf binary" QA issues when building such 240seeing some "No GNU_HASH in the elf binary" QA issues when building such
241recipes. You need to fix these recipes so that they use the expected 241recipes. You need to fix these recipes so that they use the expected
242``LDFLAGS``. Depending on how the software is built, the build system 242:term:`LDFLAGS`. Depending on how the software is built, the build system
243used by the software (e.g. a Makefile) might need to be patched. 243used by the software (e.g. a Makefile) might need to be patched.
244However, sometimes making this fix is as simple as adding the following 244However, sometimes making this fix is as simple as adding the following
245to the recipe:: 245to the recipe::
@@ -291,7 +291,7 @@ The following changes took place for BitBake:
291 :term:`SRC_URI` parameters to specify these. This 291 :term:`SRC_URI` parameters to specify these. This
292 change is more in-line with how the other fetchers work for source 292 change is more in-line with how the other fetchers work for source
293 control systems. Recipes that fetch from Perforce will need to be 293 control systems. Recipes that fetch from Perforce will need to be
294 updated to use ``SRCREV`` in place of specifying the source revision 294 updated to use :term:`SRCREV` in place of specifying the source revision
295 within ``SRC_URI``. 295 within ``SRC_URI``.
296 296
297- Some of BitBake's internal code structures for accessing the recipe 297- Some of BitBake's internal code structures for accessing the recipe
@@ -308,7 +308,7 @@ The following changes took place for BitBake:
308 to cause any problems for most users. However, the setscene 308 to cause any problems for most users. However, the setscene
309 verification function as pointed to by 309 verification function as pointed to by
310 ``BB_SETSCENE_VERIFY_FUNCTION`` needed to change signature. 310 ``BB_SETSCENE_VERIFY_FUNCTION`` needed to change signature.
311 Consequently, a new variable named ``BB_SETSCENE_VERIFY_FUNCTION2`` 311 Consequently, a new variable named :term:`BB_SETSCENE_VERIFY_FUNCTION2`
312 has been added allowing multiple versions of BitBake to work with 312 has been added allowing multiple versions of BitBake to work with
313 suitably written metadata, which includes OpenEmbedded-Core and Poky. 313 suitably written metadata, which includes OpenEmbedded-Core and Poky.
314 Anyone with custom BitBake task scheduler code might also need to 314 Anyone with custom BitBake task scheduler code might also need to
diff --git a/documentation/migration-guides/migration-2.3.rst b/documentation/migration-guides/migration-2.3.rst
index 6cdc209e35..f9bdf0d27b 100644
--- a/documentation/migration-guides/migration-2.3.rst
+++ b/documentation/migration-guides/migration-2.3.rst
@@ -35,7 +35,7 @@ Consider the following:
35 As an example, see the ``dbus`` recipe. You will see that this recipe 35 As an example, see the ``dbus`` recipe. You will see that this recipe
36 has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in 36 has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in
37 :term:`DISTRO_FEATURES`. In the example, 37 :term:`DISTRO_FEATURES`. In the example,
38 ``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``, 38 ``systemd-systemctl-native`` is added to :term:`PACKAGE_WRITE_DEPS`,
39 which is also conditional on "systemd" being in ``DISTRO_FEATURES``. 39 which is also conditional on "systemd" being in ``DISTRO_FEATURES``.
40 40
41- Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to 41- Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to
@@ -136,7 +136,7 @@ The following changes to scripts took place:
136 removed because the script was found to be deleting files it should 136 removed because the script was found to be deleting files it should
137 not have, which lead to broken build trees. Rather than trying to 137 not have, which lead to broken build trees. Rather than trying to
138 delete portions of :term:`TMPDIR` and getting it wrong, 138 delete portions of :term:`TMPDIR` and getting it wrong,
139 it is recommended that you delete ``TMPDIR`` and have it restored 139 it is recommended that you delete :term:`TMPDIR` and have it restored
140 from shared state (sstate) on subsequent builds. 140 from shared state (sstate) on subsequent builds.
141 141
142- ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as 142- ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as
@@ -200,10 +200,10 @@ The following changes took place for BitBake:
200 section in the BitBake 200 section in the BitBake
201 User Manual for additional information. 201 User Manual for additional information.
202 202
203- ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2`` 203- ``BB_SETSCENE_VERIFY_FUNCTION`` and :term:`BB_SETSCENE_VERIFY_FUNCTION2`
204 Removed: Because the mechanism they were part of is no longer 204 Removed: Because the mechanism they were part of is no longer
205 necessary with recipe-specific sysroots, the 205 necessary with recipe-specific sysroots, the
206 ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2`` 206 ``BB_SETSCENE_VERIFY_FUNCTION`` and :term:`BB_SETSCENE_VERIFY_FUNCTION2`
207 variables have been removed. 207 variables have been removed.
208 208
209.. _migration-2.3-absolute-symlinks: 209.. _migration-2.3-absolute-symlinks:
@@ -426,10 +426,10 @@ The following miscellaneous changes have occurred:
426 426
427- If the :term:`DISTRO_VERSION` value contains 427- If the :term:`DISTRO_VERSION` value contains
428 the value of the :term:`DATE` variable, which is the 428 the value of the :term:`DATE` variable, which is the
429 default between Poky releases, the ``DATE`` value is explicitly 429 default between Poky releases, the :term:`DATE` value is explicitly
430 excluded from ``/etc/issue`` and ``/etc/issue.net``, which is 430 excluded from ``/etc/issue`` and ``/etc/issue.net``, which is
431 displayed at the login prompt, in order to avoid conflicts with 431 displayed at the login prompt, in order to avoid conflicts with
432 Multilib enabled. Regardless, the ``DATE`` value is inaccurate if the 432 Multilib enabled. Regardless, the :term:`DATE` value is inaccurate if the
433 ``base-files`` recipe is restored from shared state (sstate) rather 433 ``base-files`` recipe is restored from shared state (sstate) rather
434 than rebuilt. 434 than rebuilt.
435 435
@@ -451,7 +451,7 @@ The following miscellaneous changes have occurred:
451 tools. 451 tools.
452 452
453- The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig" 453- The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig"
454 ``DISTRO_FEATURES`` feature. Distributions that previously set:: 454 :term:`DISTRO_FEATURES` feature. Distributions that previously set::
455 455
456 USE_LDCONFIG = "0" 456 USE_LDCONFIG = "0"
457 457
@@ -494,12 +494,12 @@ The following miscellaneous changes have occurred:
494 information. 494 information.
495 495
496- All native and nativesdk recipes now use a separate 496- All native and nativesdk recipes now use a separate
497 ``DISTRO_FEATURES`` value instead of sharing the value used by 497 :term:`DISTRO_FEATURES` value instead of sharing the value used by
498 recipes for the target, in order to avoid unnecessary rebuilds. 498 recipes for the target, in order to avoid unnecessary rebuilds.
499 499
500 The ``DISTRO_FEATURES`` for ``native`` recipes is 500 The :term:`DISTRO_FEATURES` for ``native`` recipes is
501 :term:`DISTRO_FEATURES_NATIVE` added to 501 :term:`DISTRO_FEATURES_NATIVE` added to
502 an intersection of ``DISTRO_FEATURES`` and 502 an intersection of :term:`DISTRO_FEATURES` and
503 :term:`DISTRO_FEATURES_FILTER_NATIVE`. 503 :term:`DISTRO_FEATURES_FILTER_NATIVE`.
504 504
505 For nativesdk recipes, the corresponding variables are 505 For nativesdk recipes, the corresponding variables are
diff --git a/documentation/migration-guides/migration-2.4.rst b/documentation/migration-guides/migration-2.4.rst
index 44f31dc8a9..07f2bef623 100644
--- a/documentation/migration-guides/migration-2.4.rst
+++ b/documentation/migration-guides/migration-2.4.rst
@@ -63,7 +63,7 @@ occurred:
63 63
64 - The ``ionice`` program is now packaged in a separate 64 - The ``ionice`` program is now packaged in a separate
65 "util-linux-ionice" package. The main ``util-linux`` package has a 65 "util-linux-ionice" package. The main ``util-linux`` package has a
66 recommended runtime dependency (i.e. ``RRECOMMENDS``) on the 66 recommended runtime dependency (i.e. :term:`RRECOMMENDS`) on the
67 ``util-linux-ionice`` package. 67 ``util-linux-ionice`` package.
68 68
69- ``initscripts``: The ``sushell`` program is now packaged in a 69- ``initscripts``: The ``sushell`` program is now packaged in a
@@ -71,7 +71,7 @@ occurred:
71 systems to pull ``sushell`` in when ``selinux`` is enabled. The 71 systems to pull ``sushell`` in when ``selinux`` is enabled. The
72 change also eliminates needing to pull in the entire ``initscripts`` 72 change also eliminates needing to pull in the entire ``initscripts``
73 package. The main ``initscripts`` package has a runtime dependency 73 package. The main ``initscripts`` package has a runtime dependency
74 (i.e. ``RDEPENDS``) on the ``sushell`` package when "selinux" is in 74 (i.e. :term:`RDEPENDS`) on the ``sushell`` package when "selinux" is in
75 ``DISTRO_FEATURES``. 75 ``DISTRO_FEATURES``.
76 76
77- ``glib-2.0``: The ``glib-2.0`` package now has a recommended 77- ``glib-2.0``: The ``glib-2.0`` package now has a recommended
diff --git a/documentation/migration-guides/migration-2.5.rst b/documentation/migration-guides/migration-2.5.rst
index c7e0760463..d14580df21 100644
--- a/documentation/migration-guides/migration-2.5.rst
+++ b/documentation/migration-guides/migration-2.5.rst
@@ -281,7 +281,7 @@ The following are additional changes:
281 ``IMAGE_FSTYPES``. 281 ``IMAGE_FSTYPES``.
282 282
283- Recipes with an unconditional dependency on ``libpam`` are only 283- Recipes with an unconditional dependency on ``libpam`` are only
284 buildable with ``pam`` in ``DISTRO_FEATURES``. If the dependency is 284 buildable with ``pam`` in :term:`DISTRO_FEATURES`. If the dependency is
285 truly optional then it is recommended that the dependency be 285 truly optional then it is recommended that the dependency be
286 conditional upon ``pam`` being in ``DISTRO_FEATURES``. 286 conditional upon ``pam`` being in ``DISTRO_FEATURES``.
287 287
diff --git a/documentation/migration-guides/migration-2.6.rst b/documentation/migration-guides/migration-2.6.rst
index e27fad82c6..3216ed5ae3 100644
--- a/documentation/migration-guides/migration-2.6.rst
+++ b/documentation/migration-guides/migration-2.6.rst
@@ -156,11 +156,11 @@ Image/Kernel Artifact Naming Changes
156The following changes have been made: 156The following changes have been made:
157 157
158- Name variables (e.g. :term:`IMAGE_NAME`) use a new 158- Name variables (e.g. :term:`IMAGE_NAME`) use a new
159 ``IMAGE_VERSION_SUFFIX`` variable instead of 159 :term:`IMAGE_VERSION_SUFFIX` variable instead of
160 :term:`DATETIME`. Using ``IMAGE_VERSION_SUFFIX`` 160 :term:`DATETIME`. Using :term:`IMAGE_VERSION_SUFFIX`
161 allows easier and more direct changes. 161 allows easier and more direct changes.
162 162
163 The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf`` 163 The :term:`IMAGE_VERSION_SUFFIX` variable is set in the ``bitbake.conf``
164 configuration file as follows:: 164 configuration file as follows::
165 165
166 IMAGE_VERSION_SUFFIX = "-${DATETIME}" 166 IMAGE_VERSION_SUFFIX = "-${DATETIME}"
@@ -212,19 +212,19 @@ The following changes have been made:
212The :term:`SERIAL_CONSOLE` variable has been 212The :term:`SERIAL_CONSOLE` variable has been
213functionally replaced by the 213functionally replaced by the
214:term:`SERIAL_CONSOLES` variable for some time. 214:term:`SERIAL_CONSOLES` variable for some time.
215With the Yocto Project 2.6 release, ``SERIAL_CONSOLE`` has been 215With the Yocto Project 2.6 release, :term:`SERIAL_CONSOLE` has been
216officially deprecated. 216officially deprecated.
217 217
218``SERIAL_CONSOLE`` will continue to work as before for the 2.6 release. 218:term:`SERIAL_CONSOLE` will continue to work as before for the 2.6 release.
219However, for the sake of future compatibility, it is recommended that 219However, for the sake of future compatibility, it is recommended that
220you replace all instances of ``SERIAL_CONSOLE`` with 220you replace all instances of :term:`SERIAL_CONSOLE` with
221``SERIAL_CONSOLES``. 221:term:`SERIAL_CONSOLES`.
222 222
223.. note:: 223.. note::
224 224
225 The only difference in usage is that ``SERIAL_CONSOLES`` 225 The only difference in usage is that :term:`SERIAL_CONSOLES`
226 expects entries to be separated using semicolons as compared to 226 expects entries to be separated using semicolons as compared to
227 ``SERIAL_CONSOLE``, which expects spaces. 227 :term:`SERIAL_CONSOLE`, which expects spaces.
228 228
229.. _migration-2.6-poky-sets-unknown-configure-option-to-qa-error: 229.. _migration-2.6-poky-sets-unknown-configure-option-to-qa-error:
230 230
@@ -387,14 +387,14 @@ QEMU (i.e. "qemu-usermode" is in
387default). 387default).
388 388
389If you wish to disable Python profile-guided optimization regardless of 389If you wish to disable Python profile-guided optimization regardless of
390the value of ``MACHINE_FEATURES``, then ensure that 390the value of :term:`MACHINE_FEATURES`, then ensure that
391:term:`PACKAGECONFIG` for the ``python3`` recipe 391:term:`PACKAGECONFIG` for the ``python3`` recipe
392does not contain "pgo". You could accomplish the latter using the 392does not contain "pgo". You could accomplish the latter using the
393following at the configuration level:: 393following at the configuration level::
394 394
395 PACKAGECONFIG_remove_pn-python3 = "pgo" 395 PACKAGECONFIG_remove_pn-python3 = "pgo"
396 396
397Alternatively, you can set ``PACKAGECONFIG`` using an append file 397Alternatively, you can set :term:`PACKAGECONFIG` using an append file
398for the ``python3`` recipe. 398for the ``python3`` recipe.
399 399
400.. _migration-2.6-miscellaneous-changes: 400.. _migration-2.6-miscellaneous-changes:
diff --git a/documentation/migration-guides/migration-2.7.rst b/documentation/migration-guides/migration-2.7.rst
index 66cb84584f..25d92296cc 100644
--- a/documentation/migration-guides/migration-2.7.rst
+++ b/documentation/migration-guides/migration-2.7.rst
@@ -91,7 +91,7 @@ This section provides information about packaging changes.
91 package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in 91 package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in
92 :term:`IMAGE_FEATURES` to bring in debug 92 :term:`IMAGE_FEATURES` to bring in debug
93 symbols and you still need the sources, you must now also add 93 symbols and you still need the sources, you must now also add
94 ``src-pkgs`` to ``IMAGE_FEATURES``. Source packages remain in the 94 ``src-pkgs`` to :term:`IMAGE_FEATURES`. Source packages remain in the
95 target portion of the SDK by default, unless you have set your own 95 target portion of the SDK by default, unless you have set your own
96 value for :term:`SDKIMAGE_FEATURES` that 96 value for :term:`SDKIMAGE_FEATURES` that
97 does not include ``src-pkgs``. 97 does not include ``src-pkgs``.
diff --git a/documentation/migration-guides/migration-3.1.rst b/documentation/migration-guides/migration-3.1.rst
index d6a30dc274..80b8f6baa5 100644
--- a/documentation/migration-guides/migration-3.1.rst
+++ b/documentation/migration-guides/migration-3.1.rst
@@ -260,7 +260,7 @@ Miscellaneous changes
260--------------------- 260---------------------
261 261
262- The undocumented ``SRC_DISTRIBUTE_LICENSES`` variable has now been 262- The undocumented ``SRC_DISTRIBUTE_LICENSES`` variable has now been
263 removed in favour of a new ``AVAILABLE_LICENSES`` variable which is 263 removed in favour of a new :term:`AVAILABLE_LICENSES` variable which is
264 dynamically set based upon license files found in 264 dynamically set based upon license files found in
265 ``${COMMON_LICENSE_DIR}`` and ``${LICENSE_PATH}``. 265 ``${COMMON_LICENSE_DIR}`` and ``${LICENSE_PATH}``.
266 266
diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst
index dd316a70ff..a940f23238 100644
--- a/documentation/migration-guides/migration-3.2.rst
+++ b/documentation/migration-guides/migration-3.2.rst
@@ -62,10 +62,10 @@ There is a possible complication where some existing recipe may break, for
62example, a recipe was found to be writing to ``${B}/install`` for 62example, a recipe was found to be writing to ``${B}/install`` for
63``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked, 63``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
64there were errors trying to ``chown root`` for files in this location. Another 64there were errors trying to ``chown root`` for files in this location. Another
65example was the ``tcl`` recipe where the source directory ``S`` is set to a 65example was the ``tcl`` recipe where the source directory :term:`S` is set to a
66subdirectory of the source tree but files were written out to the directory 66subdirectory of the source tree but files were written out to the directory
67structure above that subdirectory. For these types of cases in your own recipes, 67structure above that subdirectory. For these types of cases in your own recipes,
68extend ``PSEUDO_IGNORE_PATHS`` to cover additional paths that pseudo should not 68extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not
69be monitoring. 69be monitoring.
70 70
71In addition, pseudo's behaviour on mismatches has now been changed - rather 71In addition, pseudo's behaviour on mismatches has now been changed - rather
@@ -207,7 +207,7 @@ files into a subdirectory and reference that instead.
207deploy class now cleans ``DEPLOYDIR`` before ``do_deploy`` 207deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
208---------------------------------------------------------- 208----------------------------------------------------------
209 209
210``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of ``DEPLOYDIR`` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds. 210``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
211 211
212Most recipes and classes that inherit the ``deploy`` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead. 212Most recipes and classes that inherit the ``deploy`` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead.
213 213
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index e5bdcdad2a..ab882ff778 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -332,7 +332,7 @@ created by an autobuilder:
332 One useful scenario for using the ``conf/site.conf`` file is to 332 One useful scenario for using the ``conf/site.conf`` file is to
333 extend your :term:`BBPATH` variable 333 extend your :term:`BBPATH` variable
334 to include the path to a ``conf/site.conf``. Then, when BitBake looks 334 to include the path to a ``conf/site.conf``. Then, when BitBake looks
335 for Metadata using ``BBPATH``, it finds the ``conf/site.conf`` file 335 for Metadata using :term:`BBPATH`, it finds the ``conf/site.conf`` file
336 and applies your common configurations found in the file. To override 336 and applies your common configurations found in the file. To override
337 configurations in a particular build directory, alter the similar 337 configurations in a particular build directory, alter the similar
338 configurations within that build directory's ``conf/local.conf`` 338 configurations within that build directory's ``conf/local.conf``
@@ -532,7 +532,7 @@ to build software. A combination of the two is also possible.
532 532
533BitBake uses the :term:`SRC_URI` 533BitBake uses the :term:`SRC_URI`
534variable to point to source files regardless of their location. Each 534variable to point to source files regardless of their location. Each
535recipe must have a ``SRC_URI`` variable that points to the source. 535recipe must have a :term:`SRC_URI` variable that points to the source.
536 536
537Another area that plays a significant role in where source files come 537Another area that plays a significant role in where source files come
538from is pointed to by the 538from is pointed to by the
@@ -540,13 +540,13 @@ from is pointed to by the
540a cache that can hold previously downloaded source. You can also 540a cache that can hold previously downloaded source. You can also
541instruct the OpenEmbedded build system to create tarballs from Git 541instruct the OpenEmbedded build system to create tarballs from Git
542repositories, which is not the default behavior, and store them in the 542repositories, which is not the default behavior, and store them in the
543``DL_DIR`` by using the 543:term:`DL_DIR` by using the
544:term:`BB_GENERATE_MIRROR_TARBALLS` 544:term:`BB_GENERATE_MIRROR_TARBALLS`
545variable. 545variable.
546 546
547Judicious use of a ``DL_DIR`` directory can save the build system a trip 547Judicious use of a :term:`DL_DIR` directory can save the build system a trip
548across the Internet when looking for files. A good method for using a 548across the Internet when looking for files. A good method for using a
549download directory is to have ``DL_DIR`` point to an area outside of 549download directory is to have :term:`DL_DIR` point to an area outside of
550your Build Directory. Doing so allows you to safely delete the Build 550your Build Directory. Doing so allows you to safely delete the Build
551Directory if needed without fear of removing any downloaded source file. 551Directory if needed without fear of removing any downloaded source file.
552 552
@@ -747,7 +747,7 @@ Build Directory's hierarchy:
747 architecture of the built package or packages. Depending on the 747 architecture of the built package or packages. Depending on the
748 eventual destination of the package or packages (i.e. machine 748 eventual destination of the package or packages (i.e. machine
749 architecture, :term:`Build Host`, SDK, or 749 architecture, :term:`Build Host`, SDK, or
750 specific machine), ``PACKAGE_ARCH`` varies. See the variable's 750 specific machine), :term:`PACKAGE_ARCH` varies. See the variable's
751 description for details. 751 description for details.
752 752
753- :term:`TARGET_OS`: The operating 753- :term:`TARGET_OS`: The operating
@@ -756,7 +756,7 @@ Build Directory's hierarchy:
756 756
757- :term:`PN`: The name of the recipe used 757- :term:`PN`: The name of the recipe used
758 to build the package. This variable can have multiple meanings. 758 to build the package. This variable can have multiple meanings.
759 However, when used in the context of input files, ``PN`` represents 759 However, when used in the context of input files, :term:`PN` represents
760 the name of the recipe. 760 the name of the recipe.
761 761
762- :term:`WORKDIR`: The location 762- :term:`WORKDIR`: The location
@@ -773,7 +773,7 @@ Build Directory's hierarchy:
773 files for a given recipe. 773 files for a given recipe.
774 774
775 - :term:`BPN`: The name of the recipe 775 - :term:`BPN`: The name of the recipe
776 used to build the package. The ``BPN`` variable is a version of 776 used to build the package. The :term:`BPN` variable is a version of
777 the ``PN`` variable but with common prefixes and suffixes removed. 777 the ``PN`` variable but with common prefixes and suffixes removed.
778 778
779 - :term:`PV`: The version of the 779 - :term:`PV`: The version of the
@@ -803,13 +803,13 @@ and the :term:`FILESPATH` variable
803to locate applicable patch files. 803to locate applicable patch files.
804 804
805Default processing for patch files assumes the files have either 805Default processing for patch files assumes the files have either
806``*.patch`` or ``*.diff`` file types. You can use ``SRC_URI`` parameters 806``*.patch`` or ``*.diff`` file types. You can use :term:`SRC_URI` parameters
807to change the way the build system recognizes patch files. See the 807to change the way the build system recognizes patch files. See the
808:ref:`ref-tasks-patch` task for more 808:ref:`ref-tasks-patch` task for more
809information. 809information.
810 810
811BitBake finds and applies multiple patches for a single recipe in the 811BitBake finds and applies multiple patches for a single recipe in the
812order in which it locates the patches. The ``FILESPATH`` variable 812order in which it locates the patches. The :term:`FILESPATH` variable
813defines the default set of directories that the build system uses to 813defines the default set of directories that the build system uses to
814search for patch files. Once found, patches are applied to the recipe's 814search for patch files. Once found, patches are applied to the recipe's
815source files, which are located in the 815source files, which are located in the
@@ -877,12 +877,12 @@ This step in the build process consists of the following tasks:
877 :ref:`ref-tasks-compile` task. 877 :ref:`ref-tasks-compile` task.
878 Compilation occurs in the directory pointed to by the 878 Compilation occurs in the directory pointed to by the
879 :term:`B` variable. Realize that the 879 :term:`B` variable. Realize that the
880 ``B`` directory is, by default, the same as the 880 :term:`B` directory is, by default, the same as the
881 :term:`S` directory. 881 :term:`S` directory.
882 882
883- *do_install*: After compilation completes, BitBake executes the 883- *do_install*: After compilation completes, BitBake executes the
884 :ref:`ref-tasks-install` task. 884 :ref:`ref-tasks-install` task.
885 This task copies files from the ``B`` directory and places them in a 885 This task copies files from the :term:`B` directory and places them in a
886 holding area pointed to by the :term:`D` 886 holding area pointed to by the :term:`D`
887 variable. Packaging occurs later using files from this holding 887 variable. Packaging occurs later using files from this holding
888 directory. 888 directory.
@@ -928,7 +928,7 @@ the analysis and package splitting process use several areas:
928- :term:`PKGDATA_DIR`: A shared, 928- :term:`PKGDATA_DIR`: A shared,
929 global-state directory that holds packaging metadata generated during 929 global-state directory that holds packaging metadata generated during
930 the packaging process. The packaging process copies metadata from 930 the packaging process. The packaging process copies metadata from
931 ``PKGDESTWORK`` to the ``PKGDATA_DIR`` area where it becomes globally 931 :term:`PKGDESTWORK` to the :term:`PKGDATA_DIR` area where it becomes globally
932 available. 932 available.
933 933
934- :term:`STAGING_DIR_HOST`: 934- :term:`STAGING_DIR_HOST`:
@@ -1008,7 +1008,7 @@ actually install:
1008 1008
1009With :term:`IMAGE_ROOTFS` 1009With :term:`IMAGE_ROOTFS`
1010pointing to the location of the filesystem under construction and the 1010pointing to the location of the filesystem under construction and the
1011``PACKAGE_INSTALL`` variable providing the final list of packages to 1011:term:`PACKAGE_INSTALL` variable providing the final list of packages to
1012install, the root file system is created. 1012install, the root file system is created.
1013 1013
1014Package installation is under control of the package manager (e.g. 1014Package installation is under control of the package manager (e.g.
@@ -1057,7 +1057,7 @@ based on the image types specified in the
1057The process turns everything into an image file or a set of image files 1057The process turns everything into an image file or a set of image files
1058and can compress the root filesystem image to reduce the overall size of 1058and can compress the root filesystem image to reduce the overall size of
1059the image. The formats used for the root filesystem depend on the 1059the image. The formats used for the root filesystem depend on the
1060``IMAGE_FSTYPES`` variable. Compression depends on whether the formats 1060:term:`IMAGE_FSTYPES` variable. Compression depends on whether the formats
1061support compression. 1061support compression.
1062 1062
1063As an example, a dynamically created task when creating a particular 1063As an example, a dynamically created task when creating a particular
@@ -1066,7 +1066,7 @@ image type would take the following form::
1066 do_image_type 1066 do_image_type
1067 1067
1068So, if the type 1068So, if the type
1069as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically 1069as specified by the :term:`IMAGE_FSTYPES` were ``ext4``, the dynamically
1070generated task would be as follows:: 1070generated task would be as follows::
1071 1071
1072 do_image_ext4 1072 do_image_ext4
@@ -1171,9 +1171,9 @@ the task is rerun.
1171 the sstate cache mechanism adds is a way to cache task output that 1171 the sstate cache mechanism adds is a way to cache task output that
1172 can then be shared between build machines. 1172 can then be shared between build machines.
1173 1173
1174Since ``STAMPS_DIR`` is usually a subdirectory of ``TMPDIR``, removing 1174Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing
1175``TMPDIR`` will also remove ``STAMPS_DIR``, which means tasks will 1175:term:`TMPDIR` will also remove :term:`STAMPS_DIR`, which means tasks will
1176properly be rerun to repopulate ``TMPDIR``. 1176properly be rerun to repopulate :term:`TMPDIR`.
1177 1177
1178If you want some task to always be considered "out of date", you can 1178If you want some task to always be considered "out of date", you can
1179mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>` 1179mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`
@@ -1408,7 +1408,7 @@ This next list, shows the variables associated with a standard SDK:
1408 1408
1409- :term:`TOOLCHAIN_HOST_TASK`: 1409- :term:`TOOLCHAIN_HOST_TASK`:
1410 Lists packages that make up the host part of the SDK (i.e. the part 1410 Lists packages that make up the host part of the SDK (i.e. the part
1411 that runs on the ``SDKMACHINE``). When you use 1411 that runs on the :term:`SDKMACHINE`). When you use
1412 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of 1412 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
1413 default packages apply. This variable allows you to add more 1413 default packages apply. This variable allows you to add more
1414 packages. 1414 packages.
@@ -1614,7 +1614,7 @@ them if they are deemed to be valid.
1614 :term:`PR` information as part of 1614 :term:`PR` information as part of
1615 the shared state packages. Consequently, there are considerations that 1615 the shared state packages. Consequently, there are considerations that
1616 affect maintaining shared state feeds. For information on how the 1616 affect maintaining shared state feeds. For information on how the
1617 build system works with packages and can track incrementing ``PR`` 1617 build system works with packages and can track incrementing :term:`PR`
1618 information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`" 1618 information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
1619 section in the Yocto Project Development Tasks Manual. 1619 section in the Yocto Project Development Tasks Manual.
1620 1620
@@ -1671,8 +1671,8 @@ objective of making native or cross packages relocatable.
1671 build host. However, cross packages generate output for the target 1671 build host. However, cross packages generate output for the target
1672 architecture. 1672 architecture.
1673 1673
1674The checksum therefore needs to exclude ``WORKDIR``. The simplistic 1674The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic
1675approach for excluding the work directory is to set ``WORKDIR`` to some 1675approach for excluding the work directory is to set :term:`WORKDIR` to some
1676fixed value and create the checksum for the "run" script. 1676fixed value and create the checksum for the "run" script.
1677 1677
1678Another problem results from the "run" scripts containing functions that 1678Another problem results from the "run" scripts containing functions that
@@ -1690,7 +1690,7 @@ contains code that first figures out the variable and function
1690dependencies, and then creates a checksum for the data used as the input 1690dependencies, and then creates a checksum for the data used as the input
1691to the task. 1691to the task.
1692 1692
1693Like the ``WORKDIR`` case, there can be situations where dependencies should be 1693Like the :term:`WORKDIR` case, there can be situations where dependencies should be
1694ignored. For these situations, you can instruct the build process to 1694ignored. For these situations, you can instruct the build process to
1695ignore a dependency by using a line like the following:: 1695ignore a dependency by using a line like the following::
1696 1696
@@ -1707,7 +1707,7 @@ following::
1707 PACKAGE_ARCHS[vardeps] = "MACHINE" 1707 PACKAGE_ARCHS[vardeps] = "MACHINE"
1708 1708
1709This example explicitly 1709This example explicitly
1710adds the ``MACHINE`` variable as a dependency for ``PACKAGE_ARCHS``. 1710adds the :term:`MACHINE` variable as a dependency for :term:`PACKAGE_ARCHS`.
1711 1711
1712As an example, consider a case with in-line Python where BitBake is not 1712As an example, consider a case with in-line Python where BitBake is not
1713able to figure out dependencies. When running in debug mode (i.e. using 1713able to figure out dependencies. When running in debug mode (i.e. using
@@ -1761,7 +1761,7 @@ through this setting in the ``bitbake.conf`` file::
1761 1761
1762 BB_SIGNATURE_HANDLER ?= "OEBasicHash" 1762 BB_SIGNATURE_HANDLER ?= "OEBasicHash"
1763 1763
1764The "OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same 1764The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same
1765as the "OEBasic" version but adds the task hash to the :ref:`stamp 1765as the "OEBasic" version but adds the task hash to the :ref:`stamp
1766files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This 1766files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
1767results in any metadata change that changes the task hash, automatically causing 1767results in any metadata change that changes the task hash, automatically causing
@@ -1782,7 +1782,7 @@ the build. This information includes:
1782- ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for 1782- ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for
1783 each task. 1783 each task.
1784 1784
1785- ``BB_TASKHASH``: The hash of the currently running task. 1785- :term:`BB_TASKHASH`: The hash of the currently running task.
1786 1786
1787Shared State 1787Shared State
1788------------ 1788------------
@@ -1851,7 +1851,7 @@ The following list explains the previous example:
1851 ``do_deploy`` is in the shared state cache and its signature indicates 1851 ``do_deploy`` is in the shared state cache and its signature indicates
1852 that the cached output is still valid (i.e. if no relevant task inputs 1852 that the cached output is still valid (i.e. if no relevant task inputs
1853 have changed), then the contents of the shared state cache copies 1853 have changed), then the contents of the shared state cache copies
1854 directly to ${``DEPLOY_DIR_IMAGE``} by the ``do_deploy_setscene`` task 1854 directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
1855 instead, skipping the ``do_deploy`` task. 1855 instead, skipping the ``do_deploy`` task.
1856 1856
1857- The following task definition is glue logic needed to make the 1857- The following task definition is glue logic needed to make the
@@ -1897,8 +1897,8 @@ The following list explains the previous example:
1897 1897
1898- ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with 1898- ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with
1899 multiple directories. For example, the following declares 1899 multiple directories. For example, the following declares
1900 ``PKGDESTWORK`` and ``SHLIBWORK`` as shared state input directories, 1900 :term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories,
1901 which populates the shared state cache, and ``PKGDATA_DIR`` and 1901 which populates the shared state cache, and :term:`PKGDATA_DIR` and
1902 ``SHLIBSDIR`` as the corresponding shared state output directories:: 1902 ``SHLIBSDIR`` as the corresponding shared state output directories::
1903 1903
1904 do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}" 1904 do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
@@ -1925,7 +1925,7 @@ shared state files. Here is an example::
1925 subdirectories, where the subdirectory names are based on the first two 1925 subdirectories, where the subdirectory names are based on the first two
1926 characters of the hash. 1926 characters of the hash.
1927 If the shared state directory structure for a mirror has the same structure 1927 If the shared state directory structure for a mirror has the same structure
1928 as ``SSTATE_DIR``, you must specify "PATH" as part of the URI to enable the build 1928 as :term:`SSTATE_DIR`, you must specify "PATH" as part of the URI to enable the build
1929 system to map to the appropriate subdirectory. 1929 system to map to the appropriate subdirectory.
1930 1930
1931The shared state package validity can be detected just by looking at the 1931The shared state package validity can be detected just by looking at the
@@ -1976,7 +1976,7 @@ dependencies, you must manually declare the dependencies.
1976 1976
1977 Simultaneously, all executables and shared libraries installed by the 1977 Simultaneously, all executables and shared libraries installed by the
1978 recipe are inspected to see what shared libraries they link against. 1978 recipe are inspected to see what shared libraries they link against.
1979 For each shared library dependency that is found, ``PKGDATA_DIR`` is 1979 For each shared library dependency that is found, :term:`PKGDATA_DIR` is
1980 queried to see if some package (likely from a different recipe) 1980 queried to see if some package (likely from a different recipe)
1981 contains the shared library. If such a package is found, a runtime 1981 contains the shared library. If such a package is found, a runtime
1982 dependency is added from the package that depends on the shared 1982 dependency is added from the package that depends on the shared
@@ -1985,7 +1985,7 @@ dependencies, you must manually declare the dependencies.
1985 The automatically added runtime dependency also includes a version 1985 The automatically added runtime dependency also includes a version
1986 restriction. This version restriction specifies that at least the 1986 restriction. This version restriction specifies that at least the
1987 current version of the package that provides the shared library must 1987 current version of the package that provides the shared library must
1988 be used, as if "package (>= version)" had been added to ``RDEPENDS``. 1988 be used, as if "package (>= version)" had been added to :term:`RDEPENDS`.
1989 This forces an upgrade of the package containing the shared library 1989 This forces an upgrade of the package containing the shared library
1990 when installing the package that depends on the library, if needed. 1990 when installing the package that depends on the library, if needed.
1991 1991
@@ -1999,14 +1999,14 @@ dependencies, you must manually declare the dependencies.
1999 pkg-config modules (``*.pc`` files) installed by the recipe are 1999 pkg-config modules (``*.pc`` files) installed by the recipe are
2000 located. For each module, the package that contains the module is 2000 located. For each module, the package that contains the module is
2001 registered as providing the module. The resulting module-to-package 2001 registered as providing the module. The resulting module-to-package
2002 mapping is saved globally in ``PKGDATA_DIR`` by the 2002 mapping is saved globally in :term:`PKGDATA_DIR` by the
2003 ``do_packagedata`` task. 2003 ``do_packagedata`` task.
2004 2004
2005 Simultaneously, all pkg-config modules installed by the recipe are 2005 Simultaneously, all pkg-config modules installed by the recipe are
2006 inspected to see what other pkg-config modules they depend on. A 2006 inspected to see what other pkg-config modules they depend on. A
2007 module is seen as depending on another module if it contains a 2007 module is seen as depending on another module if it contains a
2008 "Requires:" line that specifies the other module. For each module 2008 "Requires:" line that specifies the other module. For each module
2009 dependency, ``PKGDATA_DIR`` is queried to see if some package 2009 dependency, :term:`PKGDATA_DIR` is queried to see if some package
2010 contains the module. If such a package is found, a runtime dependency 2010 contains the module. If such a package is found, a runtime dependency
2011 is added from the package that depends on the module to the package 2011 is added from the package that depends on the module to the package
2012 that contains the module. 2012 that contains the module.
@@ -2046,7 +2046,7 @@ recipe in :term:`DEPENDS` through use
2046of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]`` 2046of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
2047declaration, which guarantees that the required 2047declaration, which guarantees that the required
2048shared-library/module-to-package mapping information will be available 2048shared-library/module-to-package mapping information will be available
2049when needed as long as ``DEPENDS`` has been correctly set. 2049when needed as long as :term:`DEPENDS` has been correctly set.
2050 2050
2051Fakeroot and Pseudo 2051Fakeroot and Pseudo
2052=================== 2052===================
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 2314added7..09878c480f 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -50,7 +50,7 @@ splitting out of debug symbols during packaging).
50 ``do_package_write_*`` tasks to 50 ``do_package_write_*`` tasks to
51 have different signatures for the machines with different tunings. 51 have different signatures for the machines with different tunings.
52 Additionally, unnecessary rebuilds occur every time an image for a 52 Additionally, unnecessary rebuilds occur every time an image for a
53 different ``MACHINE`` is built even when the recipe never changes. 53 different :term:`MACHINE` is built even when the recipe never changes.
54 54
55By default, all recipes inherit the :ref:`base <ref-classes-base>` and 55By default, all recipes inherit the :ref:`base <ref-classes-base>` and
56:ref:`package <ref-classes-package>` classes, which enable 56:ref:`package <ref-classes-package>` classes, which enable
@@ -110,7 +110,7 @@ It's useful to have some idea of how the tasks defined by the
110- :ref:`ref-tasks-configure` - Regenerates the 110- :ref:`ref-tasks-configure` - Regenerates the
111 configure script (using ``autoreconf``) and then launches it with a 111 configure script (using ``autoreconf``) and then launches it with a
112 standard set of arguments used during cross-compilation. You can pass 112 standard set of arguments used during cross-compilation. You can pass
113 additional parameters to ``configure`` through the ``EXTRA_OECONF`` 113 additional parameters to ``configure`` through the :term:`EXTRA_OECONF`
114 or :term:`PACKAGECONFIG_CONFARGS` 114 or :term:`PACKAGECONFIG_CONFARGS`
115 variables. 115 variables.
116 116
@@ -168,7 +168,7 @@ example use for this class.
168 the "subpath" parameter limits the checkout to a specific subpath 168 the "subpath" parameter limits the checkout to a specific subpath
169 of the tree. Here is an example where ``${BP}`` is used so that the files 169 of the tree. Here is an example where ``${BP}`` is used so that the files
170 are extracted into the subdirectory expected by the default value of 170 are extracted into the subdirectory expected by the default value of
171 ``S``:: 171 :term:`S`::
172 172
173 SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}" 173 SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}"
174 174
@@ -256,7 +256,7 @@ Collecting build statistics is enabled by default through the
256:term:`USER_CLASSES` variable from your 256:term:`USER_CLASSES` variable from your
257``local.conf`` file. Consequently, you do not have to do anything to 257``local.conf`` file. Consequently, you do not have to do anything to
258enable the class. However, if you want to disable the class, simply 258enable the class. However, if you want to disable the class, simply
259remove "buildstats" from the ``USER_CLASSES`` list. 259remove "buildstats" from the :term:`USER_CLASSES` list.
260 260
261.. _ref-classes-buildstats-summary: 261.. _ref-classes-buildstats-summary:
262 262
@@ -433,7 +433,7 @@ deployed to :term:`DEPLOYDIR`, and use ``addtask`` to
433add the task at the appropriate place, which is usually after 433add the task at the appropriate place, which is usually after
434:ref:`ref-tasks-compile` or 434:ref:`ref-tasks-compile` or
435:ref:`ref-tasks-install`. The class then takes care of 435:ref:`ref-tasks-install`. The class then takes care of
436staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``. 436staging the files from :term:`DEPLOYDIR` to :term:`DEPLOY_DIR_IMAGE`.
437 437
438.. _ref-classes-devshell: 438.. _ref-classes-devshell:
439 439
@@ -474,7 +474,7 @@ The class
474currently only supports creating a development variant of the target 474currently only supports creating a development variant of the target
475recipe, not ``native`` or ``nativesdk`` variants. 475recipe, not ``native`` or ``nativesdk`` variants.
476 476
477The ``BBCLASSEXTEND`` syntax (i.e. ``devupstream:target``) provides 477The :term:`BBCLASSEXTEND` syntax (i.e. ``devupstream:target``) provides
478support for ``native`` and ``nativesdk`` variants. Consequently, this 478support for ``native`` and ``nativesdk`` variants. Consequently, this
479functionality can be added in a future release. 479functionality can be added in a future release.
480 480
@@ -519,13 +519,13 @@ and to build it, respectively. When your recipe inherits the
519``externalsrc`` class, you use the 519``externalsrc`` class, you use the
520:term:`EXTERNALSRC` and 520:term:`EXTERNALSRC` and
521:term:`EXTERNALSRC_BUILD` variables to 521:term:`EXTERNALSRC_BUILD` variables to
522ultimately define ``S`` and ``B``. 522ultimately define :term:`S` and :term:`B`.
523 523
524By default, this class expects the source code to support recipe builds 524By default, this class expects the source code to support recipe builds
525that use the :term:`B` variable to point to the directory in 525that use the :term:`B` variable to point to the directory in
526which the OpenEmbedded build system places the generated objects built 526which the OpenEmbedded build system places the generated objects built
527from the recipes. By default, the ``B`` directory is set to the 527from the recipes. By default, the :term:`B` directory is set to the
528following, which is separate from the source directory (``S``):: 528following, which is separate from the source directory (:term:`S`)::
529 529
530 ${WORKDIR}/${BPN}/{PV}/ 530 ${WORKDIR}/${BPN}/{PV}/
531 531
@@ -689,8 +689,8 @@ introspection. This functionality is only enabled if the
689.. note:: 689.. note::
690 690
691 This functionality is backfilled by default and, if not applicable, 691 This functionality is backfilled by default and, if not applicable,
692 should be disabled through ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` or 692 should be disabled through :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` or
693 ``MACHINE_FEATURES_BACKFILL_CONSIDERED``, respectively. 693 :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`, respectively.
694 694
695.. _ref-classes-grub-efi: 695.. _ref-classes-grub-efi:
696 696
@@ -838,7 +838,7 @@ using an empty :term:`PARALLEL_MAKE` variable.
838Inheriting the ``icecc`` class changes all sstate signatures. 838Inheriting the ``icecc`` class changes all sstate signatures.
839Consequently, if a development team has a dedicated build system that 839Consequently, if a development team has a dedicated build system that
840populates :term:`SSTATE_MIRRORS` and they want to 840populates :term:`SSTATE_MIRRORS` and they want to
841reuse sstate from ``SSTATE_MIRRORS``, then all developers and the build 841reuse sstate from :term:`SSTATE_MIRRORS`, then all developers and the build
842system need to either inherit the ``icecc`` class or nobody should. 842system need to either inherit the ``icecc`` class or nobody should.
843 843
844At the distribution level, you can inherit the ``icecc`` class to be 844At the distribution level, you can inherit the ``icecc`` class to be
@@ -866,10 +866,10 @@ First, the root filesystem is created from packages using one of the
866``rootfs*.bbclass`` files (depending on the package format used) and 866``rootfs*.bbclass`` files (depending on the package format used) and
867then one or more image files are created. 867then one or more image files are created.
868 868
869- The ``IMAGE_FSTYPES`` variable controls the types of images to 869- The :term:`IMAGE_FSTYPES` variable controls the types of images to
870 generate. 870 generate.
871 871
872- The ``IMAGE_INSTALL`` variable controls the list of packages to 872- The :term:`IMAGE_INSTALL` variable controls the list of packages to
873 install into the image. 873 install into the image.
874 874
875For information on customizing images, see the 875For information on customizing images, see the
@@ -916,7 +916,7 @@ The ``image_types`` class also handles conversion and compression of images.
916.. note:: 916.. note::
917 917
918 To build a VMware VMDK image, you need to add "wic.vmdk" to 918 To build a VMware VMDK image, you need to add "wic.vmdk" to
919 ``IMAGE_FSTYPES``. This would also be similar for Virtual Box Virtual Disk 919 :term:`IMAGE_FSTYPES`. This would also be similar for Virtual Box Virtual Disk
920 Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images. 920 Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
921 921
922.. _ref-classes-image-live: 922.. _ref-classes-image-live:
@@ -994,7 +994,7 @@ Please keep in mind that the QA checks
994are meant to detect real or potential problems in the packaged 994are meant to detect real or potential problems in the packaged
995output. So exercise caution when disabling these checks. 995output. So exercise caution when disabling these checks.
996 996
997Here are the tests you can list with the ``WARN_QA`` and 997Here are the tests you can list with the :term:`WARN_QA` and
998``ERROR_QA`` variables: 998``ERROR_QA`` variables:
999 999
1000- ``already-stripped:`` Checks that produced binaries have not 1000- ``already-stripped:`` Checks that produced binaries have not
@@ -1127,13 +1127,13 @@ Here are the tests you can list with the ``WARN_QA`` and
1127 1127
1128 PACKAGECONFIG[foo] = "..." 1128 PACKAGECONFIG[foo] = "..."
1129 1129
1130- ``la:`` Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la`` 1130- ``la:`` Checks ``.la`` files for any :term:`TMPDIR` paths. Any ``.la``
1131 file containing these paths is incorrect since ``libtool`` adds the 1131 file containing these paths is incorrect since ``libtool`` adds the
1132 correct sysroot prefix when using the files automatically itself. 1132 correct sysroot prefix when using the files automatically itself.
1133 1133
1134- ``ldflags:`` Ensures that the binaries were linked with the 1134- ``ldflags:`` Ensures that the binaries were linked with the
1135 :term:`LDFLAGS` options provided by the build system. 1135 :term:`LDFLAGS` options provided by the build system.
1136 If this test fails, check that the ``LDFLAGS`` variable is being 1136 If this test fails, check that the :term:`LDFLAGS` variable is being
1137 passed to the linker command. 1137 passed to the linker command.
1138 1138
1139- ``libdir:`` Checks for libraries being installed into incorrect 1139- ``libdir:`` Checks for libraries being installed into incorrect
@@ -1173,7 +1173,7 @@ Here are the tests you can list with the ``WARN_QA`` and
1173 invalid characters (i.e. characters other than 0-9, a-z, ., +, and 1173 invalid characters (i.e. characters other than 0-9, a-z, ., +, and
1174 -). 1174 -).
1175 1175
1176- ``pkgv-undefined:`` Checks to see if the ``PKGV`` variable is 1176- ``pkgv-undefined:`` Checks to see if the :term:`PKGV` variable is
1177 undefined during :ref:`ref-tasks-package`. 1177 undefined during :ref:`ref-tasks-package`.
1178 1178
1179- ``pkgvarcheck:`` Checks through the variables 1179- ``pkgvarcheck:`` Checks through the variables
@@ -1193,8 +1193,8 @@ Here are the tests you can list with the ``WARN_QA`` and
1193- ``pn-overrides:`` Checks that a recipe does not have a name 1193- ``pn-overrides:`` Checks that a recipe does not have a name
1194 (:term:`PN`) value that appears in 1194 (:term:`PN`) value that appears in
1195 :term:`OVERRIDES`. If a recipe is named such that 1195 :term:`OVERRIDES`. If a recipe is named such that
1196 its ``PN`` value matches something already in ``OVERRIDES`` (e.g. 1196 its :term:`PN` value matches something already in :term:`OVERRIDES` (e.g.
1197 ``PN`` happens to be the same as :term:`MACHINE` or 1197 :term:`PN` happens to be the same as :term:`MACHINE` or
1198 :term:`DISTRO`), it can have unexpected consequences. 1198 :term:`DISTRO`), it can have unexpected consequences.
1199 For example, assignments such as ``FILES_${PN} = "xyz"`` effectively 1199 For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
1200 turn into ``FILES = "xyz"``. 1200 turn into ``FILES = "xyz"``.
@@ -1725,7 +1725,7 @@ To use this class, inherit it globally and specify
1725 SOURCE_MIRROR_URL = "http://example.com/my-source-mirror" 1725 SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
1726 1726
1727You can specify only a single URL 1727You can specify only a single URL
1728in ``SOURCE_MIRROR_URL``. 1728in :term:`SOURCE_MIRROR_URL`.
1729 1729
1730.. _ref-classes-package: 1730.. _ref-classes-package:
1731 1731
@@ -1749,7 +1749,7 @@ package-specific classes:
1749 use this class. 1749 use this class.
1750 1750
1751You can control the list of resulting package formats by using the 1751You can control the list of resulting package formats by using the
1752``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf`` 1752:term:`PACKAGE_CLASSES` variable defined in your ``conf/local.conf``
1753configuration file, which is located in the :term:`Build Directory`. 1753configuration file, which is located in the :term:`Build Directory`.
1754When defining the variable, you can 1754When defining the variable, you can
1755specify one or more package types. Since images are generated from 1755specify one or more package types. Since images are generated from
@@ -1770,7 +1770,7 @@ the same or similar package. This comparison takes into account a
1770complete build of the package with all dependencies previously built. 1770complete build of the package with all dependencies previously built.
1771The reason for this discrepancy is because the RPM package manager 1771The reason for this discrepancy is because the RPM package manager
1772creates and processes more :term:`Metadata` than the IPK package 1772creates and processes more :term:`Metadata` than the IPK package
1773manager. Consequently, you might consider setting ``PACKAGE_CLASSES`` to 1773manager. Consequently, you might consider setting :term:`PACKAGE_CLASSES` to
1774"package_ipk" if you are building smaller systems. 1774"package_ipk" if you are building smaller systems.
1775 1775
1776Before making your package manager decision, however, you should 1776Before making your package manager decision, however, you should
@@ -1852,7 +1852,7 @@ variable in the ``local.conf`` file.
1852.. note:: 1852.. note::
1853 1853
1854 You cannot specify the ``package_tar`` class first using the 1854 You cannot specify the ``package_tar`` class first using the
1855 ``PACKAGE_CLASSES`` variable. You must use ``.deb``, ``.ipk``, or ``.rpm`` 1855 :term:`PACKAGE_CLASSES` variable. You must use ``.deb``, ``.ipk``, or ``.rpm``
1856 file formats for your image or SDK. 1856 file formats for your image or SDK.
1857 1857
1858.. _ref-classes-packagedata: 1858.. _ref-classes-packagedata:
@@ -1874,7 +1874,7 @@ This class is enabled by default because it is inherited by the
1874======================== 1874========================
1875 1875
1876The ``packagegroup`` class sets default values appropriate for package 1876The ``packagegroup`` class sets default values appropriate for package
1877group recipes (e.g. ``PACKAGES``, ``PACKAGE_ARCH``, ``ALLOW_EMPTY``, and 1877group recipes (e.g. :term:`PACKAGES`, :term:`PACKAGE_ARCH`, :term:`ALLOW_EMPTY`, and
1878so forth). It is highly recommended that all package group recipes 1878so forth). It is highly recommended that all package group recipes
1879inherit this class. 1879inherit this class.
1880 1880
@@ -2193,7 +2193,7 @@ modifying and building source code out of the work directory for a
2193recipe, enabling ``rm_work`` will potentially result in your changes to 2193recipe, enabling ``rm_work`` will potentially result in your changes to
2194the source being lost. To exclude some recipes from having their work 2194the source being lost. To exclude some recipes from having their work
2195directories deleted by ``rm_work``, you can add the names of the recipe 2195directories deleted by ``rm_work``, you can add the names of the recipe
2196or recipes you are working on to the ``RM_WORK_EXCLUDE`` variable, which 2196or recipes you are working on to the :term:`RM_WORK_EXCLUDE` variable, which
2197can also be set in your ``local.conf`` file. Here is an example:: 2197can also be set in your ``local.conf`` file. Here is an example::
2198 2198
2199 RM_WORK_EXCLUDE += "busybox glibc" 2199 RM_WORK_EXCLUDE += "busybox glibc"
@@ -2308,11 +2308,11 @@ results so these tests can be skipped over but still make the correct
2308values available. The ``meta/site directory`` contains test results 2308values available. The ``meta/site directory`` contains test results
2309sorted into different categories such as architecture, endianness, and 2309sorted into different categories such as architecture, endianness, and
2310the ``libc`` used. Site information provides a list of files containing 2310the ``libc`` used. Site information provides a list of files containing
2311data relevant to the current build in the ``CONFIG_SITE`` variable that 2311data relevant to the current build in the :term:`CONFIG_SITE` variable that
2312Autotools automatically picks up. 2312Autotools automatically picks up.
2313 2313
2314The class also provides variables like ``SITEINFO_ENDIANNESS`` and 2314The class also provides variables like :term:`SITEINFO_ENDIANNESS` and
2315``SITEINFO_BITS`` that can be used elsewhere in the metadata. 2315:term:`SITEINFO_BITS` that can be used elsewhere in the metadata.
2316 2316
2317.. _ref-classes-sstate: 2317.. _ref-classes-sstate:
2318 2318
@@ -2363,7 +2363,7 @@ stages:
2363 .. note:: 2363 .. note::
2364 2364
2365 Additionally, a recipe can customize the files further by 2365 Additionally, a recipe can customize the files further by
2366 declaring a processing function in the ``SYSROOT_PREPROCESS_FUNCS`` 2366 declaring a processing function in the :term:`SYSROOT_PREPROCESS_FUNCS`
2367 variable. 2367 variable.
2368 2368
2369 A shared state (sstate) object is built from these files and the 2369 A shared state (sstate) object is built from these files and the
@@ -2405,11 +2405,11 @@ stages:
2405 recommended for general use, the files do allow some issues such 2405 recommended for general use, the files do allow some issues such
2406 as user creation and module indexes to be addressed. 2406 as user creation and module indexes to be addressed.
2407 2407
2408 Because recipes can have other dependencies outside of ``DEPENDS`` 2408 Because recipes can have other dependencies outside of :term:`DEPENDS`
2409 (e.g. ``do_unpack[depends] += "tar-native:do_populate_sysroot"``), 2409 (e.g. ``do_unpack[depends] += "tar-native:do_populate_sysroot"``),
2410 the sysroot creation function ``extend_recipe_sysroot`` is also added 2410 the sysroot creation function ``extend_recipe_sysroot`` is also added
2411 as a pre-function for those tasks whose dependencies are not through 2411 as a pre-function for those tasks whose dependencies are not through
2412 ``DEPENDS`` but operate similarly. 2412 :term:`DEPENDS` but operate similarly.
2413 2413
2414 When installing dependencies into the sysroot, the code traverses the 2414 When installing dependencies into the sysroot, the code traverses the
2415 dependency graph and processes dependencies in exactly the same way 2415 dependency graph and processes dependencies in exactly the same way
@@ -2735,8 +2735,8 @@ initialization script on behalf of the package. The OpenEmbedded build
2735system takes care of details such as making sure the script is stopped 2735system takes care of details such as making sure the script is stopped
2736before a package is removed and started when the package is installed. 2736before a package is removed and started when the package is installed.
2737 2737
2738Three variables control this class: ``INITSCRIPT_PACKAGES``, 2738Three variables control this class: :term:`INITSCRIPT_PACKAGES`,
2739``INITSCRIPT_NAME`` and ``INITSCRIPT_PARAMS``. See the variable links 2739:term:`INITSCRIPT_NAME` and :term:`INITSCRIPT_PARAMS`. See the variable links
2740for details. 2740for details.
2741 2741
2742.. _ref-classes-useradd: 2742.. _ref-classes-useradd:
@@ -2790,9 +2790,9 @@ additional information.
2790.. note:: 2790.. note::
2791 2791
2792 You do not use the ``useradd-staticids`` class directly. You either enable 2792 You do not use the ``useradd-staticids`` class directly. You either enable
2793 or disable the class by setting the ``USERADDEXTENSION`` variable. If you 2793 or disable the class by setting the :term:`USERADDEXTENSION` variable. If you
2794 enable or disable the class in a configured system, :term:`TMPDIR` might 2794 enable or disable the class in a configured system, :term:`TMPDIR` might
2795 contain incorrect ``uid`` and ``gid`` values. Deleting the ``TMPDIR`` 2795 contain incorrect ``uid`` and ``gid`` values. Deleting the :term:`TMPDIR`
2796 directory will correct this condition. 2796 directory will correct this condition.
2797 2797
2798.. _ref-classes-utility-tasks: 2798.. _ref-classes-utility-tasks:
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index f1b564a60e..640ef77d03 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -108,10 +108,10 @@ the team can place sources there so builds continue to work.
108but the package is being marked as machine-specific in all cases, how do 108but the package is being marked as machine-specific in all cases, how do
109I prevent this? 109I prevent this?
110 110
111**A:** Set ``SRC_URI_OVERRIDES_PACKAGE_ARCH`` = "0" in the ``.bb`` file 111**A:** Set :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` = "0" in the ``.bb`` file
112but make sure the package is manually marked as machine-specific for the 112but make sure the package is manually marked as machine-specific for the
113case that needs it. The code that handles 113case that needs it. The code that handles
114``SRC_URI_OVERRIDES_PACKAGE_ARCH`` is in the 114:term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` is in the
115``meta/classes/base.bbclass`` file. 115``meta/classes/base.bbclass`` file.
116 116
117**Q:** I'm behind a firewall and need to use a proxy server. How do I do 117**Q:** I'm behind a firewall and need to use a proxy server. How do I do
@@ -250,7 +250,7 @@ size, you need to set various configurations:
250 :term:`IMAGE_ROOTFS_EXTRA_SPACE` 250 :term:`IMAGE_ROOTFS_EXTRA_SPACE`
251 variable to add additional free space to the image. The build system 251 variable to add additional free space to the image. The build system
252 adds this space to the image after it determines its 252 adds this space to the image after it determines its
253 ``IMAGE_ROOTFS_SIZE``. 253 :term:`IMAGE_ROOTFS_SIZE`.
254 254
255**Q:** Why don't you support directories with spaces in the pathnames? 255**Q:** Why don't you support directories with spaces in the pathnames?
256 256
@@ -262,11 +262,11 @@ situation changes, the team will not support spaces in pathnames.
262**Q:** How do I use an external toolchain? 262**Q:** How do I use an external toolchain?
263 263
264**A:** The toolchain configuration is very flexible and customizable. It 264**A:** The toolchain configuration is very flexible and customizable. It
265is primarily controlled with the ``TCMODE`` variable. This variable 265is primarily controlled with the :term:`TCMODE` variable. This variable
266controls which ``tcmode-*.inc`` file to include from the 266controls which ``tcmode-*.inc`` file to include from the
267``meta/conf/distro/include`` directory within the :term:`Source Directory`. 267``meta/conf/distro/include`` directory within the :term:`Source Directory`.
268 268
269The default value of ``TCMODE`` is "default", which tells the 269The default value of :term:`TCMODE` is "default", which tells the
270OpenEmbedded build system to use its internally built toolchain (i.e. 270OpenEmbedded build system to use its internally built toolchain (i.e.
271``tcmode-default.inc``). However, other patterns are accepted. In 271``tcmode-default.inc``). However, other patterns are accepted. In
272particular, "external-\*" refers to external toolchains. One example is 272particular, "external-\*" refers to external toolchains. One example is
@@ -325,7 +325,7 @@ Here is another technique::
325 BB_FETCH_PREMIRRORONLY = "1" 325 BB_FETCH_PREMIRRORONLY = "1"
326 326
327This statement 327This statement
328limits the build system to pulling source from the ``PREMIRRORS`` only. 328limits the build system to pulling source from the :term:`PREMIRRORS` only.
329Again, this technique is useful for reproducing builds. 329Again, this technique is useful for reproducing builds.
330 330
331Here is another technique:: 331Here is another technique::
@@ -339,7 +339,7 @@ however, the technique can simply waste time during the build.
339 339
340Finally, consider an example where you are behind an HTTP-only firewall. 340Finally, consider an example where you are behind an HTTP-only firewall.
341You could make the following changes to the ``local.conf`` configuration 341You could make the following changes to the ``local.conf`` configuration
342file as long as the ``PREMIRRORS`` server is current:: 342file as long as the :term:`PREMIRRORS` server is current::
343 343
344 PREMIRRORS_prepend = "\ 344 PREMIRRORS_prepend = "\
345 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ 345 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -349,7 +349,7 @@ file as long as the ``PREMIRRORS`` server is current::
349 349
350These changes would cause the build system to successfully fetch source 350These changes would cause the build system to successfully fetch source
351over HTTP and any network accesses to anything other than the 351over HTTP and any network accesses to anything other than the
352``PREMIRRORS`` would fail. 352:term:`PREMIRRORS` would fail.
353 353
354The build system also honors the standard shell environment variables 354The build system also honors the standard shell environment variables
355``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to 355``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to
diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst
index 31d24b8c28..ded653221c 100644
--- a/documentation/ref-manual/features.rst
+++ b/documentation/ref-manual/features.rst
@@ -10,10 +10,10 @@ can select, and a reference on feature backfilling.
10 10
11Features provide a mechanism for working out which packages should be 11Features provide a mechanism for working out which packages should be
12included in the generated images. Distributions can select which 12included in the generated images. Distributions can select which
13features they want to support through the ``DISTRO_FEATURES`` variable, 13features they want to support through the :term:`DISTRO_FEATURES` variable,
14which is set or appended to in a distribution's configuration file such 14which is set or appended to in a distribution's configuration file such
15as ``poky.conf``, ``poky-tiny.conf``, ``poky-lsb.conf`` and so forth. 15as ``poky.conf``, ``poky-tiny.conf``, ``poky-lsb.conf`` and so forth.
16Machine features are set in the ``MACHINE_FEATURES`` variable, which is 16Machine features are set in the :term:`MACHINE_FEATURES` variable, which is
17set in the machine configuration file and specifies the hardware 17set in the machine configuration file and specifies the hardware
18features for a given machine. 18features for a given machine.
19 19
@@ -267,7 +267,7 @@ these valid features is as follows:
267- *ssh-server-openssh:* Installs the OpenSSH SSH server, which is more 267- *ssh-server-openssh:* Installs the OpenSSH SSH server, which is more
268 full-featured than Dropbear. Note that if both the OpenSSH SSH server 268 full-featured than Dropbear. Note that if both the OpenSSH SSH server
269 and the Dropbear minimal SSH server are present in 269 and the Dropbear minimal SSH server are present in
270 ``IMAGE_FEATURES``, then OpenSSH will take precedence and Dropbear 270 :term:`IMAGE_FEATURES`, then OpenSSH will take precedence and Dropbear
271 will not be installed. 271 will not be installed.
272 272
273- *tools-debug:* Installs debugging tools such as ``strace`` and 273- *tools-debug:* Installs debugging tools such as ``strace`` and
@@ -323,27 +323,27 @@ Here are two examples to help illustrate feature backfilling:
323- *The "pulseaudio" distro feature option*: Previously, PulseAudio 323- *The "pulseaudio" distro feature option*: Previously, PulseAudio
324 support was enabled within the Qt and GStreamer frameworks. Because 324 support was enabled within the Qt and GStreamer frameworks. Because
325 of this, the feature is backfilled and thus enabled for all distros 325 of this, the feature is backfilled and thus enabled for all distros
326 through the ``DISTRO_FEATURES_BACKFILL`` variable in the 326 through the :term:`DISTRO_FEATURES_BACKFILL` variable in the
327 ``meta/conf/bitbake.conf`` file. However, your distro needs to 327 ``meta/conf/bitbake.conf`` file. However, your distro needs to
328 disable the feature. You can disable the feature without affecting 328 disable the feature. You can disable the feature without affecting
329 other existing distro configurations that need PulseAudio support by 329 other existing distro configurations that need PulseAudio support by
330 adding "pulseaudio" to ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` in 330 adding "pulseaudio" to :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` in
331 your distro's ``.conf`` file. Adding the feature to this variable 331 your distro's ``.conf`` file. Adding the feature to this variable
332 when it also exists in the ``DISTRO_FEATURES_BACKFILL`` variable 332 when it also exists in the :term:`DISTRO_FEATURES_BACKFILL` variable
333 prevents the build system from adding the feature to your 333 prevents the build system from adding the feature to your
334 configuration's ``DISTRO_FEATURES``, effectively disabling the 334 configuration's :term:`DISTRO_FEATURES`, effectively disabling the
335 feature for that particular distro. 335 feature for that particular distro.
336 336
337- *The "rtc" machine feature option*: Previously, real time clock (RTC) 337- *The "rtc" machine feature option*: Previously, real time clock (RTC)
338 support was enabled for all target devices. Because of this, the 338 support was enabled for all target devices. Because of this, the
339 feature is backfilled and thus enabled for all machines through the 339 feature is backfilled and thus enabled for all machines through the
340 ``MACHINE_FEATURES_BACKFILL`` variable in the 340 :term:`MACHINE_FEATURES_BACKFILL` variable in the
341 ``meta/conf/bitbake.conf`` file. However, your target device does not 341 ``meta/conf/bitbake.conf`` file. However, your target device does not
342 have this capability. You can disable RTC support for your device 342 have this capability. You can disable RTC support for your device
343 without affecting other machines that need RTC support by adding the 343 without affecting other machines that need RTC support by adding the
344 feature to your machine's ``MACHINE_FEATURES_BACKFILL_CONSIDERED`` 344 feature to your machine's :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
345 list in the machine's ``.conf`` file. Adding the feature to this 345 list in the machine's ``.conf`` file. Adding the feature to this
346 variable when it also exists in the ``MACHINE_FEATURES_BACKFILL`` 346 variable when it also exists in the :term:`MACHINE_FEATURES_BACKFILL`
347 variable prevents the build system from adding the feature to your 347 variable prevents the build system from adding the feature to your
348 configuration's ``MACHINE_FEATURES``, effectively disabling RTC 348 configuration's :term:`MACHINE_FEATURES`, effectively disabling RTC
349 support for that particular machine. 349 support for that particular machine.
diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst
index 2e98713a27..a105acc2c8 100644
--- a/documentation/ref-manual/qa-checks.rst
+++ b/documentation/ref-manual/qa-checks.rst
@@ -88,7 +88,7 @@ Errors and Warnings
88 A file-level dependency has been identified from the specified 88 A file-level dependency has been identified from the specified
89 package on the specified files, but there is no explicit 89 package on the specified files, but there is no explicit
90 corresponding entry in :term:`RDEPENDS`. If 90 corresponding entry in :term:`RDEPENDS`. If
91 particular files are required at runtime then ``RDEPENDS`` should be 91 particular files are required at runtime then :term:`RDEPENDS` should be
92 declared in the recipe to ensure the packages providing them are 92 declared in the recipe to ensure the packages providing them are
93 built. 93 built.
94 94
@@ -104,7 +104,7 @@ Errors and Warnings
104 :term:`RDEPENDS` value being added at the packaging 104 :term:`RDEPENDS` value being added at the packaging
105 stage rather than up front, which is usually automatic based on the 105 stage rather than up front, which is usually automatic based on the
106 contents of the package. In most cases, you should change the recipe 106 contents of the package. In most cases, you should change the recipe
107 to add an explicit ``RDEPENDS`` for the dependency. 107 to add an explicit :term:`RDEPENDS` for the dependency.
108 108
109   109  
110.. _qa-check-dev-so: 110.. _qa-check-dev-so:
@@ -152,7 +152,7 @@ Errors and Warnings
152 not explicitly add the ``.debug`` directory to the ``-dbg`` package. 152 not explicitly add the ``.debug`` directory to the ``-dbg`` package.
153 If this is the case, add the ``.debug`` directory explicitly to 153 If this is the case, add the ``.debug`` directory explicitly to
154 ``FILES_${PN}-dbg``. See :term:`FILES` for additional 154 ``FILES_${PN}-dbg``. See :term:`FILES` for additional
155 information on ``FILES``. 155 information on :term:`FILES`.
156 156
157   157  
158.. _qa-check-arch: 158.. _qa-check-arch:
@@ -235,9 +235,9 @@ Errors and Warnings
235 235
236 This indicates that binaries produced when building the recipe have 236 This indicates that binaries produced when building the recipe have
237 not been linked with the :term:`LDFLAGS` options 237 not been linked with the :term:`LDFLAGS` options
238 provided by the build system. Check to be sure that the ``LDFLAGS`` 238 provided by the build system. Check to be sure that the :term:`LDFLAGS`
239 variable is being passed to the linker command. A common workaround 239 variable is being passed to the linker command. A common workaround
240 for this situation is to pass in ``LDFLAGS`` using 240 for this situation is to pass in :term:`LDFLAGS` using
241 :term:`TARGET_CC_ARCH` within the recipe as 241 :term:`TARGET_CC_ARCH` within the recipe as
242 follows:: 242 follows::
243 243
@@ -403,7 +403,7 @@ Errors and Warnings
403 If your recipe name does not match this, or you add packages to 403 If your recipe name does not match this, or you add packages to
404 :term:`PACKAGES` that do not conform to the 404 :term:`PACKAGES` that do not conform to the
405 convention, then you will receive this error. Rename your recipe. Or, 405 convention, then you will receive this error. Rename your recipe. Or,
406 if you have added a non-conforming package name to ``PACKAGES``, 406 if you have added a non-conforming package name to :term:`PACKAGES`,
407 change the package name appropriately. 407 change the package name appropriately.
408 408
409   409  
@@ -431,13 +431,13 @@ Errors and Warnings
431 431
432 The specified recipe has a name (:term:`PN`) value that 432 The specified recipe has a name (:term:`PN`) value that
433 appears in :term:`OVERRIDES`. If a recipe is named 433 appears in :term:`OVERRIDES`. If a recipe is named
434 such that its ``PN`` value matches something already in ``OVERRIDES`` 434 such that its :term:`PN` value matches something already in :term:`OVERRIDES`
435 (e.g. ``PN`` happens to be the same as :term:`MACHINE` 435 (e.g. :term:`PN` happens to be the same as :term:`MACHINE`
436 or :term:`DISTRO`), it can have unexpected 436 or :term:`DISTRO`), it can have unexpected
437 consequences. For example, assignments such as 437 consequences. For example, assignments such as
438 ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. 438 ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``.
439 Rename your recipe (or if ``PN`` is being set explicitly, change the 439 Rename your recipe (or if :term:`PN` is being set explicitly, change the
440 ``PN`` value) so that the conflict does not occur. See 440 :term:`PN` value) so that the conflict does not occur. See
441 :term:`FILES` for additional information. 441 :term:`FILES` for additional information.
442 442
443   443  
@@ -464,7 +464,7 @@ Errors and Warnings
464 This check looks for instances of setting ``DEPENDS_${PN}`` 464 This check looks for instances of setting ``DEPENDS_${PN}``
465 which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus 465 which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus
466 it is not correct to specify it for a particular package, nor will such 466 it is not correct to specify it for a particular package, nor will such
467 an assignment actually work.) Set ``DEPENDS`` instead. 467 an assignment actually work.) Set :term:`DEPENDS` instead.
468 468
469 469
470.. _qa-check-already-stripped: 470.. _qa-check-already-stripped:
@@ -499,7 +499,7 @@ Errors and Warnings
499 499
500 Package names must appear only once in the 500 Package names must appear only once in the
501 :term:`PACKAGES` variable. You might receive this 501 :term:`PACKAGES` variable. You might receive this
502 error if you are attempting to add a package to ``PACKAGES`` that is 502 error if you are attempting to add a package to :term:`PACKAGES` that is
503 already in the variable's value. 503 already in the variable's value.
504 504
505   505  
@@ -523,7 +523,7 @@ Errors and Warnings
523 in an image later on in the build process. You need to do one of the 523 in an image later on in the build process. You need to do one of the
524 following: 524 following:
525 525
526 - Add the files to ``FILES`` for the package you want them to appear 526 - Add the files to :term:`FILES` for the package you want them to appear
527 in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main 527 in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main
528 package). 528 package).
529 529
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
index 36c9efc1e2..5f00edb06c 100644
--- a/documentation/ref-manual/structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -251,9 +251,9 @@ variables are hard-coded for various reasons but such variables are
251relatively rare. 251relatively rare.
252 252
253At a minimum, you would normally edit this file to select the target 253At a minimum, you would normally edit this file to select the target
254``MACHINE``, which package types you wish to use 254:term:`MACHINE`, which package types you wish to use
255(:term:`PACKAGE_CLASSES`), and the location from 255(:term:`PACKAGE_CLASSES`), and the location from
256which you want to access downloaded files (``DL_DIR``). 256which you want to access downloaded files (:term:`DL_DIR`).
257 257
258If ``local.conf`` is not present when you start the build, the 258If ``local.conf`` is not present when you start the build, the
259OpenEmbedded build system creates it from ``local.conf.sample`` when you 259OpenEmbedded build system creates it from ``local.conf.sample`` when you
@@ -336,7 +336,7 @@ the build.
336This directory contains downloaded upstream source tarballs. You can 336This directory contains downloaded upstream source tarballs. You can
337reuse the directory for multiple builds or move the directory to another 337reuse the directory for multiple builds or move the directory to another
338location. You can control the location of this directory through the 338location. You can control the location of this directory through the
339``DL_DIR`` variable. 339:term:`DL_DIR` variable.
340 340
341.. _structure-build-sstate-cache: 341.. _structure-build-sstate-cache:
342 342
@@ -346,7 +346,7 @@ location. You can control the location of this directory through the
346This directory contains the shared state cache. You can reuse the 346This directory contains the shared state cache. You can reuse the
347directory for multiple builds or move the directory to another location. 347directory for multiple builds or move the directory to another location.
348You can control the location of this directory through the 348You can control the location of this directory through the
349``SSTATE_DIR`` variable. 349:term:`SSTATE_DIR` variable.
350 350
351.. _structure-build-tmp: 351.. _structure-build-tmp:
352 352
@@ -548,7 +548,7 @@ section in the Yocto Project Overview and Concepts Manual.
548------------------ 548------------------
549 549
550This directory contains general logs that are not otherwise placed using 550This directory contains general logs that are not otherwise placed using
551the package's ``WORKDIR``. Examples of logs are the output from the 551the package's :term:`WORKDIR`. Examples of logs are the output from the
552``do_check_pkg`` or ``do_distro_check`` tasks. Running a build does not 552``do_check_pkg`` or ``do_distro_check`` tasks. Running a build does not
553necessarily mean this directory is created. 553necessarily mean this directory is created.
554 554
@@ -569,7 +569,7 @@ It is worth considering the structure of a typical work directory. As an
569example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86`` 569example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
570built within the Yocto Project. For this package, a work directory of 570built within the Yocto Project. For this package, a work directory of
571``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred 571``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
572to as the ``WORKDIR``, is created. Within this directory, the source is 572to as the :term:`WORKDIR`, is created. Within this directory, the source is
573unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt. 573unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
574(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in 574(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
575the Yocto Project Development Tasks Manual for more information.) Within 575the Yocto Project Development Tasks Manual for more information.) Within
@@ -577,7 +577,7 @@ the ``linux-qemux86-standard-build`` directory, standard Quilt
577directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and 577directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
578standard Quilt commands can be used. 578standard Quilt commands can be used.
579 579
580There are other directories generated within ``WORKDIR``. The most 580There are other directories generated within :term:`WORKDIR`. The most
581important directory is ``WORKDIR/temp/``, which has log files for each 581important directory is ``WORKDIR/temp/``, which has log files for each
582task (``log.do_*.pid``) and contains the scripts BitBake runs for each 582task (``log.do_*.pid``) and contains the scripts BitBake runs for each
583task (``run.do_*.pid``). The ``WORKDIR/image/`` directory is where "make 583task (``run.do_*.pid``). The ``WORKDIR/image/`` directory is where "make
@@ -709,7 +709,7 @@ support for a new machine to the Yocto Project, look in this directory.
709 709
710The contents of this directory controls any distribution-specific 710The contents of this directory controls any distribution-specific
711configurations. For the Yocto Project, the ``defaultsetup.conf`` is the 711configurations. For the Yocto Project, the ``defaultsetup.conf`` is the
712main file here. This directory includes the versions and the ``SRCDATE`` 712main file here. This directory includes the versions and the :term:`SRCDATE`
713definitions for applications that are configured here. An example of an 713definitions for applications that are configured here. An example of an
714alternative configuration might be ``poky-bleeding.conf``. Although this 714alternative configuration might be ``poky-bleeding.conf``. Although this
715file mainly inherits its configuration from Poky. 715file mainly inherits its configuration from Poky.
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 5bceb79b8d..970b083942 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -57,7 +57,7 @@ the current working directory set to ``${``\ :term:`B`\ ``}``.
57The default behavior of this task is to run ``oe_runmake clean`` if a 57The default behavior of this task is to run ``oe_runmake clean`` if a
58makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and 58makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and
59:term:`CLEANBROKEN` is not set to "1". If no such 59:term:`CLEANBROKEN` is not set to "1". If no such
60file is found or the ``CLEANBROKEN`` variable is set to "1", the 60file is found or the :term:`CLEANBROKEN` variable is set to "1", the
61``do_configure`` task does nothing. 61``do_configure`` task does nothing.
62 62
63.. _ref-tasks-configure_ptest_base: 63.. _ref-tasks-configure_ptest_base:
@@ -308,17 +308,17 @@ This recipe has two patch files located here::
308 308
309 poky/meta/recipes-connectivity/bluez5/bluez5 309 poky/meta/recipes-connectivity/bluez5/bluez5
310 310
311In the ``bluez5`` recipe, the ``SRC_URI`` statements point to the source 311In the ``bluez5`` recipe, the :term:`SRC_URI` statements point to the source
312and patch files needed to build the package. 312and patch files needed to build the package.
313 313
314.. note:: 314.. note::
315 315
316 In the case for the ``bluez5_5.48.bb`` recipe, the ``SRC_URI`` statements 316 In the case for the ``bluez5_5.48.bb`` recipe, the :term:`SRC_URI` statements
317 are from an include file ``bluez5.inc``. 317 are from an include file ``bluez5.inc``.
318 318
319As mentioned earlier, the build system treats files whose file types are 319As mentioned earlier, the build system treats files whose file types are
320``.patch`` and ``.diff`` as patch files. However, you can use the 320``.patch`` and ``.diff`` as patch files. However, you can use the
321"apply=yes" parameter with the ``SRC_URI`` statement to indicate any 321"apply=yes" parameter with the :term:`SRC_URI` statement to indicate any
322file as a patch file:: 322file as a patch file::
323 323
324 SRC_URI = " \ 324 SRC_URI = " \
@@ -329,7 +329,7 @@ file as a patch file::
329Conversely, if you have a directory full of patch files and you want to 329Conversely, if you have a directory full of patch files and you want to
330exclude some so that the ``do_patch`` task does not apply them during 330exclude some so that the ``do_patch`` task does not apply them during
331the patch phase, you can use the "apply=no" parameter with the 331the patch phase, you can use the "apply=no" parameter with the
332``SRC_URI`` statement:: 332:term:`SRC_URI` statement::
333 333
334 SRC_URI = " \ 334 SRC_URI = " \
335 git://path_to_repo/some_package \ 335 git://path_to_repo/some_package \
@@ -430,7 +430,7 @@ variable also plays a role in where unpacked source files ultimately
430reside. For more information on how source files are unpacked, see the 430reside. For more information on how source files are unpacked, see the
431":ref:`overview-manual/concepts:source fetching`" 431":ref:`overview-manual/concepts:source fetching`"
432section in the Yocto Project Overview and Concepts Manual and also see 432section in the Yocto Project Overview and Concepts Manual and also see
433the ``WORKDIR`` and ``S`` variable descriptions. 433the :term:`WORKDIR` and :term:`S` variable descriptions.
434 434
435Manually Called Tasks 435Manually Called Tasks
436===================== 436=====================
diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst
index 0af9af6485..54469e507d 100644
--- a/documentation/ref-manual/terms.rst
+++ b/documentation/ref-manual/terms.rst
@@ -97,11 +97,11 @@ universal, the list includes them just in case:
97 .. note:: 97 .. note::
98 98
99 By default, the Build Directory contains :term:`TMPDIR`, which is a 99 By default, the Build Directory contains :term:`TMPDIR`, which is a
100 temporary directory the build system uses for its work. ``TMPDIR`` cannot 100 temporary directory the build system uses for its work. :term:`TMPDIR` cannot
101 be under NFS. Thus, by default, the Build Directory cannot be under 101 be under NFS. Thus, by default, the Build Directory cannot be under
102 NFS. However, if you need the Build Directory to be under NFS, you can 102 NFS. However, if you need the Build Directory to be under NFS, you can
103 set this up by setting ``TMPDIR`` in your ``local.conf`` file to use a local 103 set this up by setting :term:`TMPDIR` in your ``local.conf`` file to use a local
104 drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the 104 drive. Doing so effectively separates :term:`TMPDIR` from :term:`TOPDIR`, which is the
105 Build Directory. 105 Build Directory.
106 106
107 :term:`Build Host` 107 :term:`Build Host`
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index ff37c9f18d..71c2e11d9b 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -63,7 +63,7 @@ system and gives an overview of their function and contents.
63 Used by the alternatives system to map duplicated commands to actual 63 Used by the alternatives system to map duplicated commands to actual
64 locations. For example, if the ``bracket`` command provided by the 64 locations. For example, if the ``bracket`` command provided by the
65 ``busybox`` package is duplicated through another package, you must 65 ``busybox`` package is duplicated through another package, you must
66 use the ``ALTERNATIVE_LINK_NAME`` variable to specify the actual 66 use the :term:`ALTERNATIVE_LINK_NAME` variable to specify the actual
67 location:: 67 location::
68 68
69 ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/[" 69 ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
@@ -73,7 +73,7 @@ system and gives an overview of their function and contents.
73 73
74 .. note:: 74 .. note::
75 75
76 If ``ALTERNATIVE_LINK_NAME`` is not defined, it defaults to ``${bindir}/name``. 76 If :term:`ALTERNATIVE_LINK_NAME` is not defined, it defaults to ``${bindir}/name``.
77 77
78 For more information on the alternatives system, see the 78 For more information on the alternatives system, see the
79 ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`" 79 ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
@@ -109,11 +109,11 @@ system and gives an overview of their function and contents.
109 109
110 .. note:: 110 .. note::
111 111
112 If ``ALTERNATIVE_TARGET`` is not defined, it inherits the value 112 If :term:`ALTERNATIVE_TARGET` is not defined, it inherits the value
113 from the :term:`ALTERNATIVE_LINK_NAME` variable. 113 from the :term:`ALTERNATIVE_LINK_NAME` variable.
114 114
115 If ``ALTERNATIVE_LINK_NAME`` and ``ALTERNATIVE_TARGET`` are the 115 If :term:`ALTERNATIVE_LINK_NAME` and :term:`ALTERNATIVE_TARGET` are the
116 same, the target for ``ALTERNATIVE_TARGET`` has "``.{BPN}``" 116 same, the target for :term:`ALTERNATIVE_TARGET` has "``.{BPN}``"
117 appended to it. 117 appended to it.
118 118
119 Finally, if the file referenced has not been renamed, the 119 Finally, if the file referenced has not been renamed, the
@@ -131,8 +131,8 @@ system and gives an overview of their function and contents.
131 class, this variable identifies a list of distribution features where 131 class, this variable identifies a list of distribution features where
132 at least one must be enabled in the current configuration in order 132 at least one must be enabled in the current configuration in order
133 for the OpenEmbedded build system to build the recipe. In other words, 133 for the OpenEmbedded build system to build the recipe. In other words,
134 if none of the features listed in ``ANY_OF_DISTRO_FEATURES`` 134 if none of the features listed in :term:`ANY_OF_DISTRO_FEATURES`
135 appear in ``DISTRO_FEATURES`` within the current configuration, then 135 appear in :term:`DISTRO_FEATURES` within the current configuration, then
136 the recipe will be skipped, and if the build system attempts to build 136 the recipe will be skipped, and if the build system attempts to build
137 the recipe then an error will be triggered. 137 the recipe then an error will be triggered.
138 138
@@ -174,7 +174,7 @@ system and gives an overview of their function and contents.
174 attempt to build. Instead, BitBake assumes these recipes have already 174 attempt to build. Instead, BitBake assumes these recipes have already
175 been built. 175 been built.
176 176
177 In OpenEmbedded-Core, ``ASSUME_PROVIDED`` mostly specifies native 177 In OpenEmbedded-Core, :term:`ASSUME_PROVIDED` mostly specifies native
178 tools that should not be built. An example is ``git-native``, which 178 tools that should not be built. An example is ``git-native``, which
179 when specified, allows for the Git binary from the host to be used 179 when specified, allows for the Git binary from the host to be used
180 rather than building ``git-native``. 180 rather than building ``git-native``.
@@ -200,7 +200,7 @@ system and gives an overview of their function and contents.
200 200
201 :term:`AUTO_LIBNAME_PKGS` 201 :term:`AUTO_LIBNAME_PKGS`
202 When the :ref:`debian <ref-classes-debian>` class is inherited, 202 When the :ref:`debian <ref-classes-debian>` class is inherited,
203 which is the default behavior, ``AUTO_LIBNAME_PKGS`` specifies which 203 which is the default behavior, :term:`AUTO_LIBNAME_PKGS` specifies which
204 packages should be checked for libraries and renamed according to 204 packages should be checked for libraries and renamed according to
205 Debian library package naming. 205 Debian library package naming.
206 206
@@ -213,7 +213,7 @@ system and gives an overview of their function and contents.
213 :ref:`syslinux <ref-classes-syslinux>` class checks this variable. 213 :ref:`syslinux <ref-classes-syslinux>` class checks this variable.
214 214
215 :term:`AUTOREV` 215 :term:`AUTOREV`
216 When ``SRCREV`` is set to the value of this variable, it specifies to 216 When :term:`SRCREV` is set to the value of this variable, it specifies to
217 use the latest source revision in the repository. Here is an example:: 217 use the latest source revision in the repository. Here is an example::
218 218
219 SRCREV = "${AUTOREV}" 219 SRCREV = "${AUTOREV}"
@@ -224,7 +224,7 @@ system and gives an overview of their function and contents.
224 have a kernel recipe that inherits the 224 have a kernel recipe that inherits the
225 :ref:`kernel <ref-classes-kernel>` class and you use the previous 225 :ref:`kernel <ref-classes-kernel>` class and you use the previous
226 statement. In this example, ``${SRCPV}`` does not automatically get 226 statement. In this example, ``${SRCPV}`` does not automatically get
227 into ``PV``. Consequently, you need to change ``PV`` in your recipe 227 into :term:`PV`. Consequently, you need to change :term:`PV` in your recipe
228 so that it does contain ``${SRCPV}``. 228 so that it does contain ``${SRCPV}``.
229 229
230 For more information see the 230 For more information see the
@@ -238,8 +238,8 @@ system and gives an overview of their function and contents.
238 238
239 .. note:: 239 .. note::
240 240
241 It is assumed that all changes to ``COMMON_LICENSE_DIR`` and 241 It is assumed that all changes to :term:`COMMON_LICENSE_DIR` and
242 ``LICENSE_PATH`` have been done before ``AVAILABLE_LICENSES`` 242 :term:`LICENSE_PATH` have been done before :term:`AVAILABLE_LICENSES`
243 is defined (in :ref:`ref-classes-license`). 243 is defined (in :ref:`ref-classes-license`).
244 244
245 :term:`AVAILTUNES` 245 :term:`AVAILTUNES`
@@ -279,7 +279,7 @@ system and gives an overview of their function and contents.
279 279
280 S = "${WORKDIR}/${BP}" 280 S = "${WORKDIR}/${BP}"
281 281
282 You can separate the (``S``) directory and the directory pointed to 282 You can separate the (:term:`S`) directory and the directory pointed to
283 by the ``B`` variable. Most Autotools-based recipes support 283 by the ``B`` variable. Most Autotools-based recipes support
284 separating these directories. The build system defaults to using 284 separating these directories. The build system defaults to using
285 separate directories for ``gcc`` and some kernel recipes. 285 separate directories for ``gcc`` and some kernel recipes.
@@ -289,7 +289,7 @@ system and gives an overview of their function and contents.
289 packages are packages installed only through the 289 packages are packages installed only through the
290 :term:`RRECOMMENDS` variable. You can prevent any 290 :term:`RRECOMMENDS` variable. You can prevent any
291 of these "recommended" packages from being installed by listing them 291 of these "recommended" packages from being installed by listing them
292 with the ``BAD_RECOMMENDATIONS`` variable:: 292 with the :term:`BAD_RECOMMENDATIONS` variable::
293 293
294 BAD_RECOMMENDATIONS = "package_name package_name package_name ..." 294 BAD_RECOMMENDATIONS = "package_name package_name package_name ..."
295 295
@@ -314,12 +314,12 @@ system and gives an overview of their function and contents.
314 314
315 :term:`BASE_LIB` 315 :term:`BASE_LIB`
316 The library directory name for the CPU or Application Binary 316 The library directory name for the CPU or Application Binary
317 Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib 317 Interface (ABI) tune. The :term:`BASE_LIB` applies only in the Multilib
318 context. See the ":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`" 318 context. See the ":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
319 section in the Yocto Project Development Tasks Manual for information 319 section in the Yocto Project Development Tasks Manual for information
320 on Multilib. 320 on Multilib.
321 321
322 The ``BASE_LIB`` variable is defined in the machine include files in 322 The :term:`BASE_LIB` variable is defined in the machine include files in
323 the :term:`Source Directory`. If Multilib is not 323 the :term:`Source Directory`. If Multilib is not
324 being used, the value defaults to "lib". 324 being used, the value defaults to "lib".
325 325
@@ -332,7 +332,7 @@ system and gives an overview of their function and contents.
332 to use to obtain the required source code. Following are 332 to use to obtain the required source code. Following are
333 considerations surrounding this variable: 333 considerations surrounding this variable:
334 334
335 - This host list is only used if ``BB_NO_NETWORK`` is either not set 335 - This host list is only used if :term:`BB_NO_NETWORK` is either not set
336 or set to "0". 336 or set to "0".
337 337
338 - There is limited support for wildcard matching against the beginning of 338 - There is limited support for wildcard matching against the beginning of
@@ -357,14 +357,14 @@ system and gives an overview of their function and contents.
357 357
358 - Attempts to access networks not in the host list cause a failure. 358 - Attempts to access networks not in the host list cause a failure.
359 359
360 Using ``BB_ALLOWED_NETWORKS`` in conjunction with 360 Using :term:`BB_ALLOWED_NETWORKS` in conjunction with
361 :term:`PREMIRRORS` is very useful. Adding the host 361 :term:`PREMIRRORS` is very useful. Adding the host
362 you want to use to ``PREMIRRORS`` results in the source code being 362 you want to use to :term:`PREMIRRORS` results in the source code being
363 fetched from an allowed location and avoids raising an error when a 363 fetched from an allowed location and avoids raising an error when a
364 host that is not allowed is in a :term:`SRC_URI` 364 host that is not allowed is in a :term:`SRC_URI`
365 statement. This is because the fetcher does not attempt to use the 365 statement. This is because the fetcher does not attempt to use the
366 host listed in ``SRC_URI`` after a successful fetch from the 366 host listed in :term:`SRC_URI` after a successful fetch from the
367 ``PREMIRRORS`` occurs. 367 :term:`PREMIRRORS` occurs.
368 368
369 :term:`BB_DANGLINGAPPENDS_WARNONLY` 369 :term:`BB_DANGLINGAPPENDS_WARNONLY`
370 Defines how BitBake handles situations where an append file 370 Defines how BitBake handles situations where an append file
@@ -389,7 +389,7 @@ system and gives an overview of their function and contents.
389 you to control the build based on these parameters. 389 you to control the build based on these parameters.
390 390
391 Disk space monitoring is disabled by default. To enable monitoring, 391 Disk space monitoring is disabled by default. To enable monitoring,
392 add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file 392 add the :term:`BB_DISKMON_DIRS` variable to your ``conf/local.conf`` file
393 found in the :term:`Build Directory`. Use the 393 found in the :term:`Build Directory`. Use the
394 following form: 394 following form:
395 395
@@ -444,7 +444,7 @@ system and gives an overview of their function and contents.
444 variable, the build system also issue a warning when the disk space 444 variable, the build system also issue a warning when the disk space
445 in the ``${SSTATE_DIR}`` directory drops below 1 Gbyte or the number 445 in the ``${SSTATE_DIR}`` directory drops below 1 Gbyte or the number
446 of free inodes drops below 100 Kbytes. Subsequent warnings are issued 446 of free inodes drops below 100 Kbytes. Subsequent warnings are issued
447 during intervals as defined by the ``BB_DISKMON_WARNINTERVAL`` 447 during intervals as defined by the :term:`BB_DISKMON_WARNINTERVAL`
448 variable. 448 variable.
449 449
450 The second example stops the build after all currently executing 450 The second example stops the build after all currently executing
@@ -461,14 +461,14 @@ system and gives an overview of their function and contents.
461 intervals, define the variable in your ``conf/local.conf`` file in 461 intervals, define the variable in your ``conf/local.conf`` file in
462 the :term:`Build Directory`. 462 the :term:`Build Directory`.
463 463
464 If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you 464 If you are going to use the :term:`BB_DISKMON_WARNINTERVAL` variable, you
465 must also use the :term:`BB_DISKMON_DIRS` 465 must also use the :term:`BB_DISKMON_DIRS`
466 variable and define its action as "WARN". During the build, 466 variable and define its action as "WARN". During the build,
467 subsequent warnings are issued each time disk space or number of free 467 subsequent warnings are issued each time disk space or number of free
468 inodes further reduces by the respective interval. 468 inodes further reduces by the respective interval.
469 469
470 If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you 470 If you do not provide a :term:`BB_DISKMON_WARNINTERVAL` variable and you
471 do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk 471 do use :term:`BB_DISKMON_DIRS` with the "WARN" action, the disk
472 monitoring interval defaults to the following:: 472 monitoring interval defaults to the following::
473 473
474 BB_DISKMON_WARNINTERVAL = "50M,5K" 474 BB_DISKMON_WARNINTERVAL = "50M,5K"
@@ -521,7 +521,7 @@ system and gives an overview of their function and contents.
521 ``local.conf`` file in the :term:`Build Directory`. 521 ``local.conf`` file in the :term:`Build Directory`.
522 522
523 Once you have the tarballs containing your source files, you can 523 Once you have the tarballs containing your source files, you can
524 clean up your ``DL_DIR`` directory by deleting any Git or other 524 clean up your :term:`DL_DIR` directory by deleting any Git or other
525 source control work directories. 525 source control work directories.
526 526
527 :term:`BB_NUMBER_THREADS` 527 :term:`BB_NUMBER_THREADS`
@@ -529,13 +529,13 @@ system and gives an overview of their function and contents.
529 time. The OpenEmbedded build system automatically configures this 529 time. The OpenEmbedded build system automatically configures this
530 variable to be equal to the number of cores on the build system. For 530 variable to be equal to the number of cores on the build system. For
531 example, a system with a dual core processor that also uses 531 example, a system with a dual core processor that also uses
532 hyper-threading causes the ``BB_NUMBER_THREADS`` variable to default 532 hyper-threading causes the :term:`BB_NUMBER_THREADS` variable to default
533 to "4". 533 to "4".
534 534
535 For single socket systems (i.e. one CPU), you should not have to 535 For single socket systems (i.e. one CPU), you should not have to
536 override this variable to gain optimal parallelism during builds. 536 override this variable to gain optimal parallelism during builds.
537 However, if you have very large systems that employ multiple physical 537 However, if you have very large systems that employ multiple physical
538 CPUs, you might want to make sure the ``BB_NUMBER_THREADS`` variable 538 CPUs, you might want to make sure the :term:`BB_NUMBER_THREADS` variable
539 is not set higher than "20". 539 is not set higher than "20".
540 540
541 For more information on speeding up builds, see the 541 For more information on speeding up builds, see the
@@ -544,7 +544,7 @@ system and gives an overview of their function and contents.
544 544
545 :term:`BB_SERVER_TIMEOUT` 545 :term:`BB_SERVER_TIMEOUT`
546 Specifies the time (in seconds) after which to unload the BitBake 546 Specifies the time (in seconds) after which to unload the BitBake
547 server due to inactivity. Set ``BB_SERVER_TIMEOUT`` to determine how 547 server due to inactivity. Set :term:`BB_SERVER_TIMEOUT` to determine how
548 long the BitBake server stays resident between invocations. 548 long the BitBake server stays resident between invocations.
549 549
550 For example, the following statement in your ``local.conf`` file 550 For example, the following statement in your ``local.conf`` file
@@ -562,7 +562,7 @@ system and gives an overview of their function and contents.
562 system; "crosses" such as ``gcc-cross``, which is a compiler built to 562 system; "crosses" such as ``gcc-cross``, which is a compiler built to
563 run on the build machine but produces binaries that run on the target 563 run on the build machine but produces binaries that run on the target
564 :term:`MACHINE`; "nativesdk", which targets the SDK 564 :term:`MACHINE`; "nativesdk", which targets the SDK
565 machine instead of ``MACHINE``; and "mulitlibs" in the form 565 machine instead of :term:`MACHINE`; and "mulitlibs" in the form
566 "``multilib:``\ multilib_name". 566 "``multilib:``\ multilib_name".
567 567
568 To build a different variant of the recipe with a minimal amount of 568 To build a different variant of the recipe with a minimal amount of
@@ -573,13 +573,13 @@ system and gives an overview of their function and contents.
573 573
574 .. note:: 574 .. note::
575 575
576 Internally, the ``BBCLASSEXTEND`` mechanism generates recipe 576 Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe
577 variants by rewriting variable values and applying overrides such 577 variants by rewriting variable values and applying overrides such
578 as ``_class-native``. For example, to generate a native version of 578 as ``_class-native``. For example, to generate a native version of
579 a recipe, a :term:`DEPENDS` on "foo" is rewritten 579 a recipe, a :term:`DEPENDS` on "foo" is rewritten
580 to a ``DEPENDS`` on "foo-native". 580 to a ``DEPENDS`` on "foo-native".
581 581
582 Even when using ``BBCLASSEXTEND``, the recipe is only parsed once. 582 Even when using :term:`BBCLASSEXTEND`, the recipe is only parsed once.
583 Parsing once adds some limitations. For example, it is not 583 Parsing once adds some limitations. For example, it is not
584 possible to include a different file depending on the variant, 584 possible to include a different file depending on the variant,
585 since ``include`` statements are processed when the recipe is 585 since ``include`` statements are processed when the recipe is
@@ -605,14 +605,14 @@ system and gives an overview of their function and contents.
605 - effectively letting you control the precedence for the multiple 605 - effectively letting you control the precedence for the multiple
606 layers. The precedence established through this variable stands 606 layers. The precedence established through this variable stands
607 regardless of a recipe's version (:term:`PV` variable). For 607 regardless of a recipe's version (:term:`PV` variable). For
608 example, a layer that has a recipe with a higher ``PV`` value but for 608 example, a layer that has a recipe with a higher :term:`PV` value but for
609 which the ``BBFILE_PRIORITY`` is set to have a lower precedence still 609 which the :term:`BBFILE_PRIORITY` is set to have a lower precedence still
610 has a lower precedence. 610 has a lower precedence.
611 611
612 A larger value for the ``BBFILE_PRIORITY`` variable results in a 612 A larger value for the :term:`BBFILE_PRIORITY` variable results in a
613 higher precedence. For example, the value 6 has a higher precedence 613 higher precedence. For example, the value 6 has a higher precedence
614 than the value 5. If not specified, the ``BBFILE_PRIORITY`` variable 614 than the value 5. If not specified, the :term:`BBFILE_PRIORITY` variable
615 is set based on layer dependencies (see the ``LAYERDEPENDS`` variable 615 is set based on layer dependencies (see the :term:`LAYERDEPENDS` variable
616 for more information. The default priority, if unspecified for a 616 for more information. The default priority, if unspecified for a
617 layer with no dependencies, is the lowest defined priority + 1 (or 1 617 layer with no dependencies, is the lowest defined priority + 1 (or 1
618 if no priorities are defined). 618 if no priorities are defined).
@@ -635,12 +635,12 @@ system and gives an overview of their function and contents.
635 Activates content when identified layers are present. You identify 635 Activates content when identified layers are present. You identify
636 the layers by the collections that the layers define. 636 the layers by the collections that the layers define.
637 637
638 Use the ``BBFILES_DYNAMIC`` variable to avoid ``.bbappend`` files 638 Use the :term:`BBFILES_DYNAMIC` variable to avoid ``.bbappend`` files
639 whose corresponding ``.bb`` file is in a layer that attempts to 639 whose corresponding ``.bb`` file is in a layer that attempts to
640 modify other layers through ``.bbappend`` but does not want to 640 modify other layers through ``.bbappend`` but does not want to
641 introduce a hard dependency on those other layers. 641 introduce a hard dependency on those other layers.
642 642
643 Use the following form for ``BBFILES_DYNAMIC``: 643 Use the following form for :term:`BBFILES_DYNAMIC`:
644 collection_name:filename_pattern The following example identifies two 644 collection_name:filename_pattern The following example identifies two
645 collection names and two filename patterns:: 645 collection names and two filename patterns::
646 646
@@ -664,7 +664,7 @@ system and gives an overview of their function and contents.
664 :term:`BBINCLUDELOGS_LINES` 664 :term:`BBINCLUDELOGS_LINES`
665 If :term:`BBINCLUDELOGS` is set, specifies the 665 If :term:`BBINCLUDELOGS` is set, specifies the
666 maximum number of lines from the task log file to print when 666 maximum number of lines from the task log file to print when
667 reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``, 667 reporting a failed task. If you do not set :term:`BBINCLUDELOGS_LINES`,
668 the entire log is printed. 668 the entire log is printed.
669 669
670 :term:`BBLAYERS` 670 :term:`BBLAYERS`
@@ -685,7 +685,7 @@ system and gives an overview of their function and contents.
685 :term:`BBMASK` 685 :term:`BBMASK`
686 Prevents BitBake from processing recipes and recipe append files. 686 Prevents BitBake from processing recipes and recipe append files.
687 687
688 You can use the ``BBMASK`` variable to "hide" these ``.bb`` and 688 You can use the :term:`BBMASK` variable to "hide" these ``.bb`` and
689 ``.bbappend`` files. BitBake ignores any recipe or recipe append 689 ``.bbappend`` files. BitBake ignores any recipe or recipe append
690 files that match any of the expressions. It is as if BitBake does not 690 files that match any of the expressions. It is as if BitBake does not
691 see them at all. Consequently, matching files are not parsed or 691 see them at all. Consequently, matching files are not parsed or
@@ -732,7 +732,7 @@ system and gives an overview of their function and contents.
732 ``conf/multiconfig`` directory (e.g. 732 ``conf/multiconfig`` directory (e.g.
733 build_directory\ ``/conf/multiconfig/configA.conf``). 733 build_directory\ ``/conf/multiconfig/configA.conf``).
734 734
735 For information on how to use ``BBMULTICONFIG`` in an environment 735 For information on how to use :term:`BBMULTICONFIG` in an environment
736 that supports building targets with multiple configurations, see the 736 that supports building targets with multiple configurations, see the
737 ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configurations`" 737 ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configurations`"
738 section in the Yocto Project Development Tasks Manual. 738 section in the Yocto Project Development Tasks Manual.
@@ -744,7 +744,7 @@ system and gives an overview of their function and contents.
744 .. note:: 744 .. note::
745 745
746 If you run BitBake from a directory outside of the 746 If you run BitBake from a directory outside of the
747 :term:`Build Directory`, you must be sure to set ``BBPATH`` 747 :term:`Build Directory`, you must be sure to set :term:`BBPATH`
748 to point to the Build Directory. Set the variable as you would any 748 to point to the Build Directory. Set the variable as you would any
749 environment variable and then run BitBake:: 749 environment variable and then run BitBake::
750 750
@@ -754,7 +754,7 @@ system and gives an overview of their function and contents.
754 754
755 755
756 :term:`BBSERVER` 756 :term:`BBSERVER`
757 If defined in the BitBake environment, ``BBSERVER`` points to the 757 If defined in the BitBake environment, :term:`BBSERVER` points to the
758 BitBake remote server. 758 BitBake remote server.
759 759
760 Use the following format to export the variable to the BitBake 760 Use the following format to export the variable to the BitBake
@@ -762,9 +762,9 @@ system and gives an overview of their function and contents.
762 762
763 export BBSERVER=localhost:$port 763 export BBSERVER=localhost:$port
764 764
765 By default, ``BBSERVER`` also appears in 765 By default, :term:`BBSERVER` also appears in
766 :term:`bitbake:BB_HASHBASE_WHITELIST`. 766 :term:`bitbake:BB_HASHBASE_WHITELIST`.
767 Consequently, ``BBSERVER`` is excluded from checksum and dependency 767 Consequently, :term:`BBSERVER` is excluded from checksum and dependency
768 data. 768 data.
769 769
770 :term:`BINCONFIG` 770 :term:`BINCONFIG`
@@ -791,7 +791,7 @@ system and gives an overview of their function and contents.
791 791
792 .. note:: 792 .. note::
793 793
794 The ``BINCONFIG_GLOB`` variable uses 794 The :term:`BINCONFIG_GLOB` variable uses
795 `shell globbing <https://tldp.org/LDP/abs/html/globbingref.html>`__, 795 `shell globbing <https://tldp.org/LDP/abs/html/globbingref.html>`__,
796 which is recognition and expansion of wildcards during pattern 796 which is recognition and expansion of wildcards during pattern
797 matching. Shell globbing is very similar to 797 matching. Shell globbing is very similar to
@@ -806,7 +806,7 @@ system and gives an overview of their function and contents.
806 806
807 :term:`BP` 807 :term:`BP`
808 The base recipe name and version but without any special recipe name 808 The base recipe name and version but without any special recipe name
809 suffix (i.e. ``-native``, ``lib64-``, and so forth). ``BP`` is 809 suffix (i.e. ``-native``, ``lib64-``, and so forth). :term:`BP` is
810 comprised of the following:: 810 comprised of the following::
811 811
812 ${BPN}-${PV} 812 ${BPN}-${PV}
@@ -828,23 +828,23 @@ system and gives an overview of their function and contents.
828 828
829 :term:`BUILD_ARCH` 829 :term:`BUILD_ARCH`
830 Specifies the architecture of the build host (e.g. ``i686``). The 830 Specifies the architecture of the build host (e.g. ``i686``). The
831 OpenEmbedded build system sets the value of ``BUILD_ARCH`` from the 831 OpenEmbedded build system sets the value of :term:`BUILD_ARCH` from the
832 machine name reported by the ``uname`` command. 832 machine name reported by the ``uname`` command.
833 833
834 :term:`BUILD_AS_ARCH` 834 :term:`BUILD_AS_ARCH`
835 Specifies the architecture-specific assembler flags for the build 835 Specifies the architecture-specific assembler flags for the build
836 host. By default, the value of ``BUILD_AS_ARCH`` is empty. 836 host. By default, the value of :term:`BUILD_AS_ARCH` is empty.
837 837
838 :term:`BUILD_CC_ARCH` 838 :term:`BUILD_CC_ARCH`
839 Specifies the architecture-specific C compiler flags for the build 839 Specifies the architecture-specific C compiler flags for the build
840 host. By default, the value of ``BUILD_CC_ARCH`` is empty. 840 host. By default, the value of :term:`BUILD_CC_ARCH` is empty.
841 841
842 :term:`BUILD_CCLD` 842 :term:`BUILD_CCLD`
843 Specifies the linker command to be used for the build host when the C 843 Specifies the linker command to be used for the build host when the C
844 compiler is being used as the linker. By default, ``BUILD_CCLD`` 844 compiler is being used as the linker. By default, :term:`BUILD_CCLD`
845 points to GCC and passes as arguments the value of 845 points to GCC and passes as arguments the value of
846 :term:`BUILD_CC_ARCH`, assuming 846 :term:`BUILD_CC_ARCH`, assuming
847 ``BUILD_CC_ARCH`` is set. 847 :term:`BUILD_CC_ARCH` is set.
848 848
849 :term:`BUILD_CFLAGS` 849 :term:`BUILD_CFLAGS`
850 Specifies the flags to pass to the C compiler when building for the 850 Specifies the flags to pass to the C compiler when building for the
@@ -866,19 +866,19 @@ system and gives an overview of their function and contents.
866 866
867 :term:`BUILD_FC` 867 :term:`BUILD_FC`
868 Specifies the Fortran compiler command for the build host. By 868 Specifies the Fortran compiler command for the build host. By
869 default, ``BUILD_FC`` points to Gfortran and passes as arguments the 869 default, :term:`BUILD_FC` points to Gfortran and passes as arguments the
870 value of :term:`BUILD_CC_ARCH`, assuming 870 value of :term:`BUILD_CC_ARCH`, assuming
871 ``BUILD_CC_ARCH`` is set. 871 :term:`BUILD_CC_ARCH` is set.
872 872
873 :term:`BUILD_LD` 873 :term:`BUILD_LD`
874 Specifies the linker command for the build host. By default, 874 Specifies the linker command for the build host. By default,
875 ``BUILD_LD`` points to the GNU linker (ld) and passes as arguments 875 :term:`BUILD_LD` points to the GNU linker (ld) and passes as arguments
876 the value of :term:`BUILD_LD_ARCH`, assuming 876 the value of :term:`BUILD_LD_ARCH`, assuming
877 ``BUILD_LD_ARCH`` is set. 877 :term:`BUILD_LD_ARCH` is set.
878 878
879 :term:`BUILD_LD_ARCH` 879 :term:`BUILD_LD_ARCH`
880 Specifies architecture-specific linker flags for the build host. By 880 Specifies architecture-specific linker flags for the build host. By
881 default, the value of ``BUILD_LD_ARCH`` is empty. 881 default, the value of :term:`BUILD_LD_ARCH` is empty.
882 882
883 :term:`BUILD_LDFLAGS` 883 :term:`BUILD_LDFLAGS`
884 Specifies the flags to pass to the linker when building for the build 884 Specifies the flags to pass to the linker when building for the build
@@ -903,13 +903,13 @@ system and gives an overview of their function and contents.
903 903
904 :term:`BUILD_PREFIX` 904 :term:`BUILD_PREFIX`
905 The toolchain binary prefix used for native recipes. The OpenEmbedded 905 The toolchain binary prefix used for native recipes. The OpenEmbedded
906 build system uses the ``BUILD_PREFIX`` value to set the 906 build system uses the :term:`BUILD_PREFIX` value to set the
907 :term:`TARGET_PREFIX` when building for 907 :term:`TARGET_PREFIX` when building for
908 ``native`` recipes. 908 ``native`` recipes.
909 909
910 :term:`BUILD_STRIP` 910 :term:`BUILD_STRIP`
911 Specifies the command to be used to strip debugging symbols from 911 Specifies the command to be used to strip debugging symbols from
912 binaries produced for the build host. By default, ``BUILD_STRIP`` 912 binaries produced for the build host. By default, :term:`BUILD_STRIP`
913 points to 913 points to
914 ``${``\ :term:`BUILD_PREFIX`\ ``}strip``. 914 ``${``\ :term:`BUILD_PREFIX`\ ``}strip``.
915 915
@@ -922,7 +922,7 @@ system and gives an overview of their function and contents.
922 on :term:`BUILD_ARCH`, 922 on :term:`BUILD_ARCH`,
923 :term:`BUILD_VENDOR`, and 923 :term:`BUILD_VENDOR`, and
924 :term:`BUILD_OS`. You do not need to set the 924 :term:`BUILD_OS`. You do not need to set the
925 ``BUILD_SYS`` variable yourself. 925 :term:`BUILD_SYS` variable yourself.
926 926
927 :term:`BUILD_VENDOR` 927 :term:`BUILD_VENDOR`
928 Specifies the vendor name to use when building for the build host. 928 Specifies the vendor name to use when building for the build host.
@@ -933,7 +933,7 @@ system and gives an overview of their function and contents.
933 You can define this directory indirectly through the 933 You can define this directory indirectly through the
934 :ref:`structure-core-script` script by passing in a Build 934 :ref:`structure-core-script` script by passing in a Build
935 Directory path when you run the script. If you run the script and do 935 Directory path when you run the script. If you run the script and do
936 not provide a Build Directory path, the ``BUILDDIR`` defaults to 936 not provide a Build Directory path, the :term:`BUILDDIR` defaults to
937 ``build`` in the current directory. 937 ``build`` in the current directory.
938 938
939 :term:`BUILDHISTORY_COMMIT` 939 :term:`BUILDHISTORY_COMMIT`
@@ -954,12 +954,12 @@ system and gives an overview of their function and contents.
954 :term:`BUILDHISTORY_COMMIT_AUTHOR` 954 :term:`BUILDHISTORY_COMMIT_AUTHOR`
955 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>` 955 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
956 class, this variable specifies the author to use for each Git commit. 956 class, this variable specifies the author to use for each Git commit.
957 In order for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable to work, the 957 In order for the :term:`BUILDHISTORY_COMMIT_AUTHOR` variable to work, the
958 :term:`BUILDHISTORY_COMMIT` variable must 958 :term:`BUILDHISTORY_COMMIT` variable must
959 be set to "1". 959 be set to "1".
960 960
961 Git requires that the value you provide for the 961 Git requires that the value you provide for the
962 ``BUILDHISTORY_COMMIT_AUTHOR`` variable takes the form of "name 962 :term:`BUILDHISTORY_COMMIT_AUTHOR` variable takes the form of "name
963 email@host". Providing an email address or host that is not valid 963 email@host". Providing an email address or host that is not valid
964 does not produce an error. 964 does not produce an error.
965 965
@@ -1025,7 +1025,7 @@ system and gives an overview of their function and contents.
1025 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>` 1025 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
1026 class, this variable optionally specifies a remote repository to 1026 class, this variable optionally specifies a remote repository to
1027 which build history pushes Git changes. In order for 1027 which build history pushes Git changes. In order for
1028 ``BUILDHISTORY_PUSH_REPO`` to work, 1028 :term:`BUILDHISTORY_PUSH_REPO` to work,
1029 :term:`BUILDHISTORY_COMMIT` must be set to 1029 :term:`BUILDHISTORY_COMMIT` must be set to
1030 "1". 1030 "1".
1031 1031
@@ -1066,7 +1066,7 @@ system and gives an overview of their function and contents.
1066 Points to the location of the directory that holds build statistics 1066 Points to the location of the directory that holds build statistics
1067 when you use and enable the 1067 when you use and enable the
1068 :ref:`buildstats <ref-classes-buildstats>` class. The 1068 :ref:`buildstats <ref-classes-buildstats>` class. The
1069 ``BUILDSTATS_BASE`` directory defaults to 1069 :term:`BUILDSTATS_BASE` directory defaults to
1070 ``${``\ :term:`TMPDIR`\ ``}/buildstats/``. 1070 ``${``\ :term:`TMPDIR`\ ``}/buildstats/``.
1071 1071
1072 :term:`BUSYBOX_SPLIT_SUID` 1072 :term:`BUSYBOX_SPLIT_SUID`
@@ -1075,7 +1075,7 @@ system and gives an overview of their function and contents.
1075 ``setuid root``, and one for the remaining features (i.e. those that 1075 ``setuid root``, and one for the remaining features (i.e. those that
1076 do not require ``setuid root``). 1076 do not require ``setuid root``).
1077 1077
1078 The ``BUSYBOX_SPLIT_SUID`` variable defaults to "1", which results in 1078 The :term:`BUSYBOX_SPLIT_SUID` variable defaults to "1", which results in
1079 splitting the output executable file. Set the variable to "0" to get 1079 splitting the output executable file. Set the variable to "0" to get
1080 a single output executable file. 1080 a single output executable file.
1081 1081
@@ -1092,7 +1092,7 @@ system and gives an overview of their function and contents.
1092 exported to an environment variable and thus made visible to the 1092 exported to an environment variable and thus made visible to the
1093 software being built during the compilation step. 1093 software being built during the compilation step.
1094 1094
1095 Default initialization for ``CFLAGS`` varies depending on what is 1095 Default initialization for :term:`CFLAGS` varies depending on what is
1096 being built: 1096 being built:
1097 1097
1098 - :term:`TARGET_CFLAGS` when building for the 1098 - :term:`TARGET_CFLAGS` when building for the
@@ -1131,12 +1131,12 @@ system and gives an overview of their function and contents.
1131 FOO_class-native = "native" 1131 FOO_class-native = "native"
1132 FOO = "other" 1132 FOO = "other"
1133 1133
1134 The underlying mechanism behind ``CLASSOVERRIDE`` is simply 1134 The underlying mechanism behind :term:`CLASSOVERRIDE` is simply
1135 that it is included in the default value of 1135 that it is included in the default value of
1136 :term:`OVERRIDES`. 1136 :term:`OVERRIDES`.
1137 1137
1138 :term:`CLEANBROKEN` 1138 :term:`CLEANBROKEN`
1139 If set to "1" within a recipe, ``CLEANBROKEN`` specifies that the 1139 If set to "1" within a recipe, :term:`CLEANBROKEN` specifies that the
1140 ``make clean`` command does not work for the software being built. 1140 ``make clean`` command does not work for the software being built.
1141 Consequently, the OpenEmbedded build system will not try to run 1141 Consequently, the OpenEmbedded build system will not try to run
1142 ``make clean`` during the :ref:`ref-tasks-configure` 1142 ``make clean`` during the :ref:`ref-tasks-configure`
@@ -1185,7 +1185,7 @@ system and gives an overview of their function and contents.
1185 1185
1186 .. note:: 1186 .. note::
1187 1187
1188 The ``COMPLEMENTARY_GLOB`` variable uses Unix filename pattern matching 1188 The :term:`COMPLEMENTARY_GLOB` variable uses Unix filename pattern matching
1189 (`fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`__), 1189 (`fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`__),
1190 which is similar to the Unix style pathname pattern expansion 1190 which is similar to the Unix style pathname pattern expansion
1191 (`glob <https://docs.python.org/3/library/glob.html>`__). 1191 (`glob <https://docs.python.org/3/library/glob.html>`__).
@@ -1193,7 +1193,7 @@ system and gives an overview of their function and contents.
1193 The resulting list of complementary packages is associated with an 1193 The resulting list of complementary packages is associated with an
1194 item that can be added to 1194 item that can be added to
1195 :term:`IMAGE_FEATURES`. An example usage of 1195 :term:`IMAGE_FEATURES`. An example usage of
1196 this is the "dev-pkgs" item that when added to ``IMAGE_FEATURES`` 1196 this is the "dev-pkgs" item that when added to :term:`IMAGE_FEATURES`
1197 will install -dev packages (containing headers and other development 1197 will install -dev packages (containing headers and other development
1198 files) for every package in the image. 1198 files) for every package in the image.
1199 1199
@@ -1215,7 +1215,7 @@ system and gives an overview of their function and contents.
1215 1215
1216 :term:`CONF_VERSION` 1216 :term:`CONF_VERSION`
1217 Tracks the version of the local configuration file (i.e. 1217 Tracks the version of the local configuration file (i.e.
1218 ``local.conf``). The value for ``CONF_VERSION`` increments each time 1218 ``local.conf``). The value for :term:`CONF_VERSION` increments each time
1219 ``build/conf/`` compatibility changes. 1219 ``build/conf/`` compatibility changes.
1220 1220
1221 :term:`CONFFILES` 1221 :term:`CONFFILES`
@@ -1225,28 +1225,28 @@ system and gives an overview of their function and contents.
1225 files you have changed after the original installation and that you 1225 files you have changed after the original installation and that you
1226 now want to remain unchanged are overwritten. In other words, 1226 now want to remain unchanged are overwritten. In other words,
1227 editable files might exist in the package that you do not want reset 1227 editable files might exist in the package that you do not want reset
1228 as part of the package update process. You can use the ``CONFFILES`` 1228 as part of the package update process. You can use the :term:`CONFFILES`
1229 variable to list the files in the package that you wish to prevent 1229 variable to list the files in the package that you wish to prevent
1230 the PMS from overwriting during this update process. 1230 the PMS from overwriting during this update process.
1231 1231
1232 To use the ``CONFFILES`` variable, provide a package name override 1232 To use the :term:`CONFFILES` variable, provide a package name override
1233 that identifies the resulting package. Then, provide a 1233 that identifies the resulting package. Then, provide a
1234 space-separated list of files. Here is an example:: 1234 space-separated list of files. Here is an example::
1235 1235
1236 CONFFILES_${PN} += "${sysconfdir}/file1 \ 1236 CONFFILES_${PN} += "${sysconfdir}/file1 \
1237 ${sysconfdir}/file2 ${sysconfdir}/file3" 1237 ${sysconfdir}/file2 ${sysconfdir}/file3"
1238 1238
1239 There is a relationship between the ``CONFFILES`` and ``FILES`` 1239 There is a relationship between the :term:`CONFFILES` and :term:`FILES`
1240 variables. The files listed within ``CONFFILES`` must be a subset of 1240 variables. The files listed within :term:`CONFFILES` must be a subset of
1241 the files listed within ``FILES``. Because the configuration files 1241 the files listed within :term:`FILES`. Because the configuration files
1242 you provide with ``CONFFILES`` are simply being identified so that 1242 you provide with :term:`CONFFILES` are simply being identified so that
1243 the PMS will not overwrite them, it makes sense that the files must 1243 the PMS will not overwrite them, it makes sense that the files must
1244 already be included as part of the package through the ``FILES`` 1244 already be included as part of the package through the :term:`FILES`
1245 variable. 1245 variable.
1246 1246
1247 .. note:: 1247 .. note::
1248 1248
1249 When specifying paths as part of the ``CONFFILES`` variable, it is 1249 When specifying paths as part of the :term:`CONFFILES` variable, it is
1250 good practice to use appropriate path variables. 1250 good practice to use appropriate path variables.
1251 For example, ``${sysconfdir}`` rather than ``/etc`` or ``${bindir}`` 1251 For example, ``${sysconfdir}`` rather than ``/etc`` or ``${bindir}``
1252 rather than ``/usr/bin``. You can find a list of these variables at 1252 rather than ``/usr/bin``. You can find a list of these variables at
@@ -1259,7 +1259,7 @@ system and gives an overview of their function and contents.
1259 variable as an environment variable. By default, the variable is set 1259 variable as an environment variable. By default, the variable is set
1260 to null (""). 1260 to null ("").
1261 1261
1262 The ``CONFIG_INITRAMFS_SOURCE`` can be either a single cpio archive 1262 The :term:`CONFIG_INITRAMFS_SOURCE` can be either a single cpio archive
1263 with a ``.cpio`` suffix or a space-separated list of directories and 1263 with a ``.cpio`` suffix or a space-separated list of directories and
1264 files for building the initramfs image. A cpio archive should contain 1264 files for building the initramfs image. A cpio archive should contain
1265 a filesystem archive to be used as an initramfs image. Directories 1265 a filesystem archive to be used as an initramfs image. Directories
@@ -1287,8 +1287,8 @@ system and gives an overview of their function and contents.
1287 :ref:`features_check <ref-classes-features_check>` 1287 :ref:`features_check <ref-classes-features_check>`
1288 class, this variable identifies distribution features that would be 1288 class, this variable identifies distribution features that would be
1289 in conflict should the recipe be built. In other words, if the 1289 in conflict should the recipe be built. In other words, if the
1290 ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also 1290 :term:`CONFLICT_DISTRO_FEATURES` variable lists a feature that also
1291 appears in ``DISTRO_FEATURES`` within the current configuration, then 1291 appears in :term:`DISTRO_FEATURES` within the current configuration, then
1292 the recipe will be skipped, and if the build system attempts to build 1292 the recipe will be skipped, and if the build system attempts to build
1293 the recipe then an error will be triggered. 1293 the recipe then an error will be triggered.
1294 1294
@@ -1297,16 +1297,16 @@ system and gives an overview of their function and contents.
1297 archived by the :ref:`archiver <ref-classes-archiver>` class. In 1297 archived by the :ref:`archiver <ref-classes-archiver>` class. In
1298 other words, if a license in a recipe's 1298 other words, if a license in a recipe's
1299 :term:`LICENSE` value is in the value of 1299 :term:`LICENSE` value is in the value of
1300 ``COPYLEFT_LICENSE_EXCLUDE``, then its source is not archived by the 1300 :term:`COPYLEFT_LICENSE_EXCLUDE`, then its source is not archived by the
1301 class. 1301 class.
1302 1302
1303 .. note:: 1303 .. note::
1304 1304
1305 The ``COPYLEFT_LICENSE_EXCLUDE`` variable takes precedence over the 1305 The :term:`COPYLEFT_LICENSE_EXCLUDE` variable takes precedence over the
1306 :term:`COPYLEFT_LICENSE_INCLUDE` variable. 1306 :term:`COPYLEFT_LICENSE_INCLUDE` variable.
1307 1307
1308 The default value, which is "CLOSED Proprietary", for 1308 The default value, which is "CLOSED Proprietary", for
1309 ``COPYLEFT_LICENSE_EXCLUDE`` is set by the 1309 :term:`COPYLEFT_LICENSE_EXCLUDE` is set by the
1310 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which 1310 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1311 is inherited by the ``archiver`` class. 1311 is inherited by the ``archiver`` class.
1312 1312
@@ -1314,7 +1314,7 @@ system and gives an overview of their function and contents.
1314 A space-separated list of licenses to include in the source archived 1314 A space-separated list of licenses to include in the source archived
1315 by the :ref:`archiver <ref-classes-archiver>` class. In other 1315 by the :ref:`archiver <ref-classes-archiver>` class. In other
1316 words, if a license in a recipe's :term:`LICENSE` 1316 words, if a license in a recipe's :term:`LICENSE`
1317 value is in the value of ``COPYLEFT_LICENSE_INCLUDE``, then its 1317 value is in the value of :term:`COPYLEFT_LICENSE_INCLUDE`, then its
1318 source is archived by the class. 1318 source is archived by the class.
1319 1319
1320 The default value is set by the 1320 The default value is set by the
@@ -1325,28 +1325,28 @@ system and gives an overview of their function and contents.
1325 :term:`COPYLEFT_PN_EXCLUDE` 1325 :term:`COPYLEFT_PN_EXCLUDE`
1326 A list of recipes to exclude in the source archived by the 1326 A list of recipes to exclude in the source archived by the
1327 :ref:`archiver <ref-classes-archiver>` class. The 1327 :ref:`archiver <ref-classes-archiver>` class. The
1328 ``COPYLEFT_PN_EXCLUDE`` variable overrides the license inclusion and 1328 :term:`COPYLEFT_PN_EXCLUDE` variable overrides the license inclusion and
1329 exclusion caused through the 1329 exclusion caused through the
1330 :term:`COPYLEFT_LICENSE_INCLUDE` and 1330 :term:`COPYLEFT_LICENSE_INCLUDE` and
1331 :term:`COPYLEFT_LICENSE_EXCLUDE` 1331 :term:`COPYLEFT_LICENSE_EXCLUDE`
1332 variables, respectively. 1332 variables, respectively.
1333 1333
1334 The default value, which is "" indicating to not explicitly exclude 1334 The default value, which is "" indicating to not explicitly exclude
1335 any recipes by name, for ``COPYLEFT_PN_EXCLUDE`` is set by the 1335 any recipes by name, for :term:`COPYLEFT_PN_EXCLUDE` is set by the
1336 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which 1336 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1337 is inherited by the ``archiver`` class. 1337 is inherited by the ``archiver`` class.
1338 1338
1339 :term:`COPYLEFT_PN_INCLUDE` 1339 :term:`COPYLEFT_PN_INCLUDE`
1340 A list of recipes to include in the source archived by the 1340 A list of recipes to include in the source archived by the
1341 :ref:`archiver <ref-classes-archiver>` class. The 1341 :ref:`archiver <ref-classes-archiver>` class. The
1342 ``COPYLEFT_PN_INCLUDE`` variable overrides the license inclusion and 1342 :term:`COPYLEFT_PN_INCLUDE` variable overrides the license inclusion and
1343 exclusion caused through the 1343 exclusion caused through the
1344 :term:`COPYLEFT_LICENSE_INCLUDE` and 1344 :term:`COPYLEFT_LICENSE_INCLUDE` and
1345 :term:`COPYLEFT_LICENSE_EXCLUDE` 1345 :term:`COPYLEFT_LICENSE_EXCLUDE`
1346 variables, respectively. 1346 variables, respectively.
1347 1347
1348 The default value, which is "" indicating to not explicitly include 1348 The default value, which is "" indicating to not explicitly include
1349 any recipes by name, for ``COPYLEFT_PN_INCLUDE`` is set by the 1349 any recipes by name, for :term:`COPYLEFT_PN_INCLUDE` is set by the
1350 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which 1350 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1351 is inherited by the ``archiver`` class. 1351 is inherited by the ``archiver`` class.
1352 1352
@@ -1356,7 +1356,7 @@ system and gives an overview of their function and contents.
1356 Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``, 1356 Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``,
1357 ``crosssdk``, and ``cross-canadian``. 1357 ``crosssdk``, and ``cross-canadian``.
1358 1358
1359 The default value, which is "target*", for ``COPYLEFT_RECIPE_TYPES`` 1359 The default value, which is "target*", for :term:`COPYLEFT_RECIPE_TYPES`
1360 is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>` 1360 is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
1361 class, which is inherited by the ``archiver`` class. 1361 class, which is inherited by the ``archiver`` class.
1362 1362
@@ -1370,7 +1370,7 @@ system and gives an overview of their function and contents.
1370 1370
1371 .. note:: 1371 .. note::
1372 1372
1373 The ``COPY_LIC_DIRS`` does not offer a path for adding licenses for 1373 The :term:`COPY_LIC_DIRS` does not offer a path for adding licenses for
1374 newly installed packages to an image, which might be most suitable for 1374 newly installed packages to an image, which might be most suitable for
1375 read-only filesystems that cannot be upgraded. See the 1375 read-only filesystems that cannot be upgraded. See the
1376 :term:`LICENSE_CREATE_PACKAGE` variable for additional information. 1376 :term:`LICENSE_CREATE_PACKAGE` variable for additional information.
@@ -1386,7 +1386,7 @@ system and gives an overview of their function and contents.
1386 1386
1387 .. note:: 1387 .. note::
1388 1388
1389 The ``COPY_LIC_MANIFEST`` does not offer a path for adding licenses for 1389 The :term:`COPY_LIC_MANIFEST` does not offer a path for adding licenses for
1390 newly installed packages to an image, which might be most suitable for 1390 newly installed packages to an image, which might be most suitable for
1391 read-only filesystems that cannot be upgraded. See the 1391 read-only filesystems that cannot be upgraded. See the
1392 :term:`LICENSE_CREATE_PACKAGE` variable for additional information. 1392 :term:`LICENSE_CREATE_PACKAGE` variable for additional information.
@@ -1406,24 +1406,24 @@ system and gives an overview of their function and contents.
1406 Specifies the parent directory of the OpenEmbedded-Core Metadata 1406 Specifies the parent directory of the OpenEmbedded-Core Metadata
1407 layer (i.e. ``meta``). 1407 layer (i.e. ``meta``).
1408 1408
1409 It is an important distinction that ``COREBASE`` points to the parent 1409 It is an important distinction that :term:`COREBASE` points to the parent
1410 of this layer and not the layer itself. Consider an example where you 1410 of this layer and not the layer itself. Consider an example where you
1411 have cloned the Poky Git repository and retained the ``poky`` name 1411 have cloned the Poky Git repository and retained the ``poky`` name
1412 for your local copy of the repository. In this case, ``COREBASE`` 1412 for your local copy of the repository. In this case, :term:`COREBASE`
1413 points to the ``poky`` folder because it is the parent directory of 1413 points to the ``poky`` folder because it is the parent directory of
1414 the ``poky/meta`` layer. 1414 the ``poky/meta`` layer.
1415 1415
1416 :term:`COREBASE_FILES` 1416 :term:`COREBASE_FILES`
1417 Lists files from the :term:`COREBASE` directory that 1417 Lists files from the :term:`COREBASE` directory that
1418 should be copied other than the layers listed in the 1418 should be copied other than the layers listed in the
1419 ``bblayers.conf`` file. The ``COREBASE_FILES`` variable allows 1419 ``bblayers.conf`` file. The :term:`COREBASE_FILES` variable allows
1420 to copy metadata from the OpenEmbedded build system 1420 to copy metadata from the OpenEmbedded build system
1421 into the extensible SDK. 1421 into the extensible SDK.
1422 1422
1423 Explicitly listing files in ``COREBASE`` is needed because it 1423 Explicitly listing files in :term:`COREBASE` is needed because it
1424 typically contains build directories and other files that should not 1424 typically contains build directories and other files that should not
1425 normally be copied into the extensible SDK. Consequently, the value 1425 normally be copied into the extensible SDK. Consequently, the value
1426 of ``COREBASE_FILES`` is used in order to only copy the files that 1426 of :term:`COREBASE_FILES` is used in order to only copy the files that
1427 are actually needed. 1427 are actually needed.
1428 1428
1429 :term:`CPP` 1429 :term:`CPP`
@@ -1435,7 +1435,7 @@ system and gives an overview of their function and contents.
1435 variable and thus made visible to the software being built during the 1435 variable and thus made visible to the software being built during the
1436 compilation step. 1436 compilation step.
1437 1437
1438 Default initialization for ``CPPFLAGS`` varies depending on what is 1438 Default initialization for :term:`CPPFLAGS` varies depending on what is
1439 being built: 1439 being built:
1440 1440
1441 - :term:`TARGET_CPPFLAGS` when building for 1441 - :term:`TARGET_CPPFLAGS` when building for
@@ -1449,12 +1449,12 @@ system and gives an overview of their function and contents.
1449 1449
1450 :term:`CROSS_COMPILE` 1450 :term:`CROSS_COMPILE`
1451 The toolchain binary prefix for the target tools. The 1451 The toolchain binary prefix for the target tools. The
1452 ``CROSS_COMPILE`` variable is the same as the 1452 :term:`CROSS_COMPILE` variable is the same as the
1453 :term:`TARGET_PREFIX` variable. 1453 :term:`TARGET_PREFIX` variable.
1454 1454
1455 .. note:: 1455 .. note::
1456 1456
1457 The OpenEmbedded build system sets the ``CROSS_COMPILE`` 1457 The OpenEmbedded build system sets the :term:`CROSS_COMPILE`
1458 variable only in certain contexts (e.g. when building for kernel 1458 variable only in certain contexts (e.g. when building for kernel
1459 and kernel module recipes). 1459 and kernel module recipes).
1460 1460
@@ -1470,7 +1470,7 @@ system and gives an overview of their function and contents.
1470 exported to an environment variable and thus made visible to the 1470 exported to an environment variable and thus made visible to the
1471 software being built during the compilation step. 1471 software being built during the compilation step.
1472 1472
1473 Default initialization for ``CXXFLAGS`` varies depending on what is 1473 Default initialization for :term:`CXXFLAGS` varies depending on what is
1474 being built: 1474 being built:
1475 1475
1476 - :term:`TARGET_CXXFLAGS` when building for 1476 - :term:`TARGET_CXXFLAGS` when building for
@@ -1505,7 +1505,7 @@ system and gives an overview of their function and contents.
1505 1505
1506 :term:`DEBIAN_NOAUTONAME` 1506 :term:`DEBIAN_NOAUTONAME`
1507 When the :ref:`debian <ref-classes-debian>` class is inherited, 1507 When the :ref:`debian <ref-classes-debian>` class is inherited,
1508 which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a 1508 which is the default behavior, :term:`DEBIAN_NOAUTONAME` specifies a
1509 particular package should not be renamed according to Debian library 1509 particular package should not be renamed according to Debian library
1510 package naming. You must use the package name as an override when you 1510 package naming. You must use the package name as an override when you
1511 set this variable. Here is an example from the ``fontconfig`` recipe:: 1511 set this variable. Here is an example from the ``fontconfig`` recipe::
@@ -1514,7 +1514,7 @@ system and gives an overview of their function and contents.
1514 1514
1515 :term:`DEBIANNAME` 1515 :term:`DEBIANNAME`
1516 When the :ref:`debian <ref-classes-debian>` class is inherited, 1516 When the :ref:`debian <ref-classes-debian>` class is inherited,
1517 which is the default behavior, ``DEBIANNAME`` allows you to override 1517 which is the default behavior, :term:`DEBIANNAME` allows you to override
1518 the library name for an individual package. Overriding the library 1518 the library name for an individual package. Overriding the library
1519 name in these cases is rare. You must use the package name as an 1519 name in these cases is rare. You must use the package name as an
1520 override when you set this variable. Here is an example from the 1520 override when you set this variable. Here is an example from the
@@ -1542,14 +1542,14 @@ system and gives an overview of their function and contents.
1542 1542
1543 .. note:: 1543 .. note::
1544 1544
1545 The bias provided by ``DEFAULT_PREFERENCE`` is weak and is overridden 1545 The bias provided by :term:`DEFAULT_PREFERENCE` is weak and is overridden
1546 by :term:`BBFILE_PRIORITY` if that variable is different between two 1546 by :term:`BBFILE_PRIORITY` if that variable is different between two
1547 layers that contain different versions of the same recipe. 1547 layers that contain different versions of the same recipe.
1548 1548
1549 :term:`DEFAULTTUNE` 1549 :term:`DEFAULTTUNE`
1550 The default CPU and Application Binary Interface (ABI) tunings (i.e. 1550 The default CPU and Application Binary Interface (ABI) tunings (i.e.
1551 the "tune") used by the OpenEmbedded build system. The 1551 the "tune") used by the OpenEmbedded build system. The
1552 ``DEFAULTTUNE`` helps define 1552 :term:`DEFAULTTUNE` helps define
1553 :term:`TUNE_FEATURES`. 1553 :term:`TUNE_FEATURES`.
1554 1554
1555 The default tune is either implicitly or explicitly set by the 1555 The default tune is either implicitly or explicitly set by the
@@ -1574,17 +1574,17 @@ system and gives an overview of their function and contents.
1574 :ref:`ref-tasks-configure` task for ``foo`` runs. 1574 :ref:`ref-tasks-configure` task for ``foo`` runs.
1575 This mechanism is implemented by having ``do_configure`` depend on 1575 This mechanism is implemented by having ``do_configure`` depend on
1576 the :ref:`ref-tasks-populate_sysroot` task of 1576 the :ref:`ref-tasks-populate_sysroot` task of
1577 each recipe listed in ``DEPENDS``, through a 1577 each recipe listed in :term:`DEPENDS`, through a
1578 ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]`` 1578 ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
1579 declaration in the :ref:`base <ref-classes-base>` class. 1579 declaration in the :ref:`base <ref-classes-base>` class.
1580 1580
1581 .. note:: 1581 .. note::
1582 1582
1583 It seldom is necessary to reference, for example, ``STAGING_DIR_HOST`` 1583 It seldom is necessary to reference, for example, :term:`STAGING_DIR_HOST`
1584 explicitly. The standard classes and build-related variables are 1584 explicitly. The standard classes and build-related variables are
1585 configured to automatically use the appropriate staging sysroots. 1585 configured to automatically use the appropriate staging sysroots.
1586 1586
1587 As another example, ``DEPENDS`` can also be used to add utilities 1587 As another example, :term:`DEPENDS` can also be used to add utilities
1588 that run on the build machine during the build. For example, a recipe 1588 that run on the build machine during the build. For example, a recipe
1589 that makes use of a code generator built by the recipe ``codegen`` 1589 that makes use of a code generator built by the recipe ``codegen``
1590 might have the following:: 1590 might have the following::
@@ -1597,15 +1597,15 @@ system and gives an overview of their function and contents.
1597 1597
1598 .. note:: 1598 .. note::
1599 1599
1600 - ``DEPENDS`` is a list of recipe names. Or, to be more precise, 1600 - :term:`DEPENDS` is a list of recipe names. Or, to be more precise,
1601 it is a list of :term:`PROVIDES` names, which 1601 it is a list of :term:`PROVIDES` names, which
1602 usually match recipe names. Putting a package name such as 1602 usually match recipe names. Putting a package name such as
1603 "foo-dev" in ``DEPENDS`` does not make sense. Use "foo" 1603 "foo-dev" in :term:`DEPENDS` does not make sense. Use "foo"
1604 instead, as this will put files from all the packages that make 1604 instead, as this will put files from all the packages that make
1605 up ``foo``, which includes those from ``foo-dev``, into the 1605 up ``foo``, which includes those from ``foo-dev``, into the
1606 sysroot. 1606 sysroot.
1607 1607
1608 - One recipe having another recipe in ``DEPENDS`` does not by 1608 - One recipe having another recipe in :term:`DEPENDS` does not by
1609 itself add any runtime dependencies between the packages 1609 itself add any runtime dependencies between the packages
1610 produced by the two recipes. However, as explained in the 1610 produced by the two recipes. However, as explained in the
1611 ":ref:`overview-manual/concepts:automatically added runtime dependencies`" 1611 ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
@@ -1613,12 +1613,12 @@ system and gives an overview of their function and contents.
1613 runtime dependencies will often be added automatically, meaning 1613 runtime dependencies will often be added automatically, meaning
1614 ``DEPENDS`` alone is sufficient for most recipes. 1614 ``DEPENDS`` alone is sufficient for most recipes.
1615 1615
1616 - Counterintuitively, ``DEPENDS`` is often necessary even for 1616 - Counterintuitively, :term:`DEPENDS` is often necessary even for
1617 recipes that install precompiled components. For example, if 1617 recipes that install precompiled components. For example, if
1618 ``libfoo`` is a precompiled library that links against 1618 ``libfoo`` is a precompiled library that links against
1619 ``libbar``, then linking against ``libfoo`` requires both 1619 ``libbar``, then linking against ``libfoo`` requires both
1620 ``libfoo`` and ``libbar`` to be available in the sysroot. 1620 ``libfoo`` and ``libbar`` to be available in the sysroot.
1621 Without a ``DEPENDS`` from the recipe that installs ``libfoo`` 1621 Without a :term:`DEPENDS` from the recipe that installs ``libfoo``
1622 to the recipe that installs ``libbar``, other recipes might 1622 to the recipe that installs ``libbar``, other recipes might
1623 fail to link against ``libfoo``. 1623 fail to link against ``libfoo``.
1624 1624
@@ -1658,7 +1658,7 @@ system and gives an overview of their function and contents.
1658 DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb" 1658 DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
1659 1659
1660 The :ref:`package_deb <ref-classes-package_deb>` class uses the 1660 The :ref:`package_deb <ref-classes-package_deb>` class uses the
1661 ``DEPLOY_DIR_DEB`` variable to make sure the 1661 :term:`DEPLOY_DIR_DEB` variable to make sure the
1662 :ref:`ref-tasks-package_write_deb` task 1662 :ref:`ref-tasks-package_write_deb` task
1663 writes Debian packages into the appropriate folder. For more 1663 writes Debian packages into the appropriate folder. For more
1664 information on how packaging works, see the 1664 information on how packaging works, see the
@@ -1700,7 +1700,7 @@ system and gives an overview of their function and contents.
1700 DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk" 1700 DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
1701 1701
1702 The :ref:`package_ipk <ref-classes-package_ipk>` class uses the 1702 The :ref:`package_ipk <ref-classes-package_ipk>` class uses the
1703 ``DEPLOY_DIR_IPK`` variable to make sure the 1703 :term:`DEPLOY_DIR_IPK` variable to make sure the
1704 :ref:`ref-tasks-package_write_ipk` task 1704 :ref:`ref-tasks-package_write_ipk` task
1705 writes IPK packages into the appropriate folder. For more information 1705 writes IPK packages into the appropriate folder. For more information
1706 on how packaging works, see the 1706 on how packaging works, see the
@@ -1720,7 +1720,7 @@ system and gives an overview of their function and contents.
1720 DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm" 1720 DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
1721 1721
1722 The :ref:`package_rpm <ref-classes-package_rpm>` class uses the 1722 The :ref:`package_rpm <ref-classes-package_rpm>` class uses the
1723 ``DEPLOY_DIR_RPM`` variable to make sure the 1723 :term:`DEPLOY_DIR_RPM` variable to make sure the
1724 :ref:`ref-tasks-package_write_rpm` task 1724 :ref:`ref-tasks-package_write_rpm` task
1725 writes RPM packages into the appropriate folder. For more information 1725 writes RPM packages into the appropriate folder. For more information
1726 on how packaging works, see the 1726 on how packaging works, see the
@@ -1740,7 +1740,7 @@ system and gives an overview of their function and contents.
1740 DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar" 1740 DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
1741 1741
1742 The :ref:`package_tar <ref-classes-package_tar>` class uses the 1742 The :ref:`package_tar <ref-classes-package_tar>` class uses the
1743 ``DEPLOY_DIR_TAR`` variable to make sure the 1743 :term:`DEPLOY_DIR_TAR` variable to make sure the
1744 :ref:`ref-tasks-package_write_tar` task 1744 :ref:`ref-tasks-package_write_tar` task
1745 writes TAR packages into the appropriate folder. For more information 1745 writes TAR packages into the appropriate folder. For more information
1746 on how packaging works, see the 1746 on how packaging works, see the
@@ -1749,19 +1749,19 @@ system and gives an overview of their function and contents.
1749 1749
1750 :term:`DEPLOYDIR` 1750 :term:`DEPLOYDIR`
1751 When inheriting the :ref:`deploy <ref-classes-deploy>` class, the 1751 When inheriting the :ref:`deploy <ref-classes-deploy>` class, the
1752 ``DEPLOYDIR`` points to a temporary work area for deployed files that 1752 :term:`DEPLOYDIR` points to a temporary work area for deployed files that
1753 is set in the ``deploy`` class as follows:: 1753 is set in the ``deploy`` class as follows::
1754 1754
1755 DEPLOYDIR = "${WORKDIR}/deploy-${PN}" 1755 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
1756 1756
1757 Recipes inheriting the ``deploy`` class should copy files to be 1757 Recipes inheriting the ``deploy`` class should copy files to be
1758 deployed into ``DEPLOYDIR``, and the class will take care of copying 1758 deployed into :term:`DEPLOYDIR`, and the class will take care of copying
1759 them into :term:`DEPLOY_DIR_IMAGE` 1759 them into :term:`DEPLOY_DIR_IMAGE`
1760 afterwards. 1760 afterwards.
1761 1761
1762 :term:`DESCRIPTION` 1762 :term:`DESCRIPTION`
1763 The package description used by package managers. If not set, 1763 The package description used by package managers. If not set,
1764 ``DESCRIPTION`` takes the value of the :term:`SUMMARY` 1764 :term:`DESCRIPTION` takes the value of the :term:`SUMMARY`
1765 variable. 1765 variable.
1766 1766
1767 :term:`DISTRO` 1767 :term:`DISTRO`
@@ -1769,26 +1769,26 @@ system and gives an overview of their function and contents.
1769 of the distribution, see the :term:`DISTRO_NAME` 1769 of the distribution, see the :term:`DISTRO_NAME`
1770 variable. 1770 variable.
1771 1771
1772 The ``DISTRO`` variable corresponds to a distribution configuration 1772 The :term:`DISTRO` variable corresponds to a distribution configuration
1773 file whose root name is the same as the variable's argument and whose 1773 file whose root name is the same as the variable's argument and whose
1774 filename extension is ``.conf``. For example, the distribution 1774 filename extension is ``.conf``. For example, the distribution
1775 configuration file for the Poky distribution is named ``poky.conf`` 1775 configuration file for the Poky distribution is named ``poky.conf``
1776 and resides in the ``meta-poky/conf/distro`` directory of the 1776 and resides in the ``meta-poky/conf/distro`` directory of the
1777 :term:`Source Directory`. 1777 :term:`Source Directory`.
1778 1778
1779 Within that ``poky.conf`` file, the ``DISTRO`` variable is set as 1779 Within that ``poky.conf`` file, the :term:`DISTRO` variable is set as
1780 follows:: 1780 follows::
1781 1781
1782 DISTRO = "poky" 1782 DISTRO = "poky"
1783 1783
1784 Distribution configuration files are located in a ``conf/distro`` 1784 Distribution configuration files are located in a ``conf/distro``
1785 directory within the :term:`Metadata` that contains the 1785 directory within the :term:`Metadata` that contains the
1786 distribution configuration. The value for ``DISTRO`` must not contain 1786 distribution configuration. The value for :term:`DISTRO` must not contain
1787 spaces, and is typically all lower-case. 1787 spaces, and is typically all lower-case.
1788 1788
1789 .. note:: 1789 .. note::
1790 1790
1791 If the ``DISTRO`` variable is blank, a set of default configurations 1791 If the :term:`DISTRO` variable is blank, a set of default configurations
1792 are used, which are specified within 1792 are used, which are specified within
1793 ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory. 1793 ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
1794 1794
@@ -1815,11 +1815,11 @@ system and gives an overview of their function and contents.
1815 configuration file. 1815 configuration file.
1816 1816
1817 In most cases, the presence or absence of a feature in 1817 In most cases, the presence or absence of a feature in
1818 ``DISTRO_FEATURES`` is translated to the appropriate option supplied 1818 :term:`DISTRO_FEATURES` is translated to the appropriate option supplied
1819 to the configure script during the 1819 to the configure script during the
1820 :ref:`ref-tasks-configure` task for recipes that 1820 :ref:`ref-tasks-configure` task for recipes that
1821 optionally support the feature. For example, specifying "x11" in 1821 optionally support the feature. For example, specifying "x11" in
1822 ``DISTRO_FEATURES``, causes every piece of software built for the 1822 :term:`DISTRO_FEATURES`, causes every piece of software built for the
1823 target that can optionally support X11 to have its X11 support 1823 target that can optionally support X11 to have its X11 support
1824 enabled. 1824 enabled.
1825 1825
@@ -1828,8 +1828,8 @@ system and gives an overview of their function and contents.
1828 provide with this variable, see the ":ref:`ref-features-distro`" section. 1828 provide with this variable, see the ":ref:`ref-features-distro`" section.
1829 1829
1830 :term:`DISTRO_FEATURES_BACKFILL` 1830 :term:`DISTRO_FEATURES_BACKFILL`
1831 Features to be added to ``DISTRO_FEATURES`` if not also present in 1831 Features to be added to :term:`DISTRO_FEATURES` if not also present in
1832 ``DISTRO_FEATURES_BACKFILL_CONSIDERED``. 1832 :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
1833 1833
1834 This variable is set in the ``meta/conf/bitbake.conf`` file. It is 1834 This variable is set in the ``meta/conf/bitbake.conf`` file. It is
1835 not intended to be user-configurable. It is best to just reference 1835 not intended to be user-configurable. It is best to just reference
@@ -1838,8 +1838,8 @@ system and gives an overview of their function and contents.
1838 for more information. 1838 for more information.
1839 1839
1840 :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` 1840 :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
1841 Features from ``DISTRO_FEATURES_BACKFILL`` that should not be 1841 Features from :term:`DISTRO_FEATURES_BACKFILL` that should not be
1842 backfilled (i.e. added to ``DISTRO_FEATURES``) during the build. See 1842 backfilled (i.e. added to :term:`DISTRO_FEATURES`) during the build. See
1843 the ":ref:`ref-features-backfill`" section for more information. 1843 the ":ref:`ref-features-backfill`" section for more information.
1844 1844
1845 :term:`DISTRO_FEATURES_DEFAULT` 1845 :term:`DISTRO_FEATURES_DEFAULT`
@@ -1851,14 +1851,14 @@ system and gives an overview of their function and contents.
1851 able to reuse the default 1851 able to reuse the default
1852 :term:`DISTRO_FEATURES` options without the 1852 :term:`DISTRO_FEATURES` options without the
1853 need to write out the full set. Here is an example that uses 1853 need to write out the full set. Here is an example that uses
1854 ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file:: 1854 :term:`DISTRO_FEATURES_DEFAULT` from a custom distro configuration file::
1855 1855
1856 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" 1856 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
1857 1857
1858 :term:`DISTRO_FEATURES_FILTER_NATIVE` 1858 :term:`DISTRO_FEATURES_FILTER_NATIVE`
1859 Specifies a list of features that if present in the target 1859 Specifies a list of features that if present in the target
1860 :term:`DISTRO_FEATURES` value should be 1860 :term:`DISTRO_FEATURES` value should be
1861 included in ``DISTRO_FEATURES`` when building native recipes. This 1861 included in :term:`DISTRO_FEATURES` when building native recipes. This
1862 variable is used in addition to the features filtered using the 1862 variable is used in addition to the features filtered using the
1863 :term:`DISTRO_FEATURES_NATIVE` 1863 :term:`DISTRO_FEATURES_NATIVE`
1864 variable. 1864 variable.
@@ -1866,7 +1866,7 @@ system and gives an overview of their function and contents.
1866 :term:`DISTRO_FEATURES_FILTER_NATIVESDK` 1866 :term:`DISTRO_FEATURES_FILTER_NATIVESDK`
1867 Specifies a list of features that if present in the target 1867 Specifies a list of features that if present in the target
1868 :term:`DISTRO_FEATURES` value should be 1868 :term:`DISTRO_FEATURES` value should be
1869 included in ``DISTRO_FEATURES`` when building nativesdk recipes. This 1869 included in :term:`DISTRO_FEATURES` when building nativesdk recipes. This
1870 variable is used in addition to the features filtered using the 1870 variable is used in addition to the features filtered using the
1871 :term:`DISTRO_FEATURES_NATIVESDK` 1871 :term:`DISTRO_FEATURES_NATIVESDK`
1872 variable. 1872 variable.
@@ -1891,14 +1891,14 @@ system and gives an overview of their function and contents.
1891 The long name of the distribution. For information on the short name 1891 The long name of the distribution. For information on the short name
1892 of the distribution, see the :term:`DISTRO` variable. 1892 of the distribution, see the :term:`DISTRO` variable.
1893 1893
1894 The ``DISTRO_NAME`` variable corresponds to a distribution 1894 The :term:`DISTRO_NAME` variable corresponds to a distribution
1895 configuration file whose root name is the same as the variable's 1895 configuration file whose root name is the same as the variable's
1896 argument and whose filename extension is ``.conf``. For example, the 1896 argument and whose filename extension is ``.conf``. For example, the
1897 distribution configuration file for the Poky distribution is named 1897 distribution configuration file for the Poky distribution is named
1898 ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory 1898 ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory
1899 of the :term:`Source Directory`. 1899 of the :term:`Source Directory`.
1900 1900
1901 Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set 1901 Within that ``poky.conf`` file, the :term:`DISTRO_NAME` variable is set
1902 as follows:: 1902 as follows::
1903 1903
1904 DISTRO_NAME = "Poky (Yocto Project Reference Distro)" 1904 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
@@ -1909,7 +1909,7 @@ system and gives an overview of their function and contents.
1909 1909
1910 .. note:: 1910 .. note::
1911 1911
1912 If the ``DISTRO_NAME`` variable is blank, a set of default 1912 If the :term:`DISTRO_NAME` variable is blank, a set of default
1913 configurations are used, which are specified within 1913 configurations are used, which are specified within
1914 ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory. 1914 ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
1915 1915
@@ -1921,10 +1921,10 @@ system and gives an overview of their function and contents.
1921 distribution. By default, this list includes the value of 1921 distribution. By default, this list includes the value of
1922 :term:`DISTRO`. 1922 :term:`DISTRO`.
1923 1923
1924 You can extend ``DISTROOVERRIDES`` to add extra overrides that should 1924 You can extend :term:`DISTROOVERRIDES` to add extra overrides that should
1925 apply to the distribution. 1925 apply to the distribution.
1926 1926
1927 The underlying mechanism behind ``DISTROOVERRIDES`` is simply that it 1927 The underlying mechanism behind :term:`DISTROOVERRIDES` is simply that it
1928 is included in the default value of 1928 is included in the default value of
1929 :term:`OVERRIDES`. 1929 :term:`OVERRIDES`.
1930 1930
@@ -1943,13 +1943,13 @@ system and gives an overview of their function and contents.
1943 1943
1944 :term:`DL_DIR` 1944 :term:`DL_DIR`
1945 The central download directory used by the build process to store 1945 The central download directory used by the build process to store
1946 downloads. By default, ``DL_DIR`` gets files suitable for mirroring 1946 downloads. By default, :term:`DL_DIR` gets files suitable for mirroring
1947 for everything except Git repositories. If you want tarballs of Git 1947 for everything except Git repositories. If you want tarballs of Git
1948 repositories, use the 1948 repositories, use the
1949 :term:`BB_GENERATE_MIRROR_TARBALLS` 1949 :term:`BB_GENERATE_MIRROR_TARBALLS`
1950 variable. 1950 variable.
1951 1951
1952 You can set this directory by defining the ``DL_DIR`` variable in the 1952 You can set this directory by defining the :term:`DL_DIR` variable in the
1953 ``conf/local.conf`` file. This directory is self-maintaining and you 1953 ``conf/local.conf`` file. This directory is self-maintaining and you
1954 should not have to touch it. By default, the directory is 1954 should not have to touch it. By default, the directory is
1955 ``downloads`` in the :term:`Build Directory`. 1955 ``downloads`` in the :term:`Build Directory`.
@@ -1963,7 +1963,7 @@ system and gives an overview of their function and contents.
1963 During a first build, the system downloads many different source code 1963 During a first build, the system downloads many different source code
1964 tarballs from various upstream projects. Downloading can take a 1964 tarballs from various upstream projects. Downloading can take a
1965 while, particularly if your network connection is slow. Tarballs are 1965 while, particularly if your network connection is slow. Tarballs are
1966 all stored in the directory defined by ``DL_DIR`` and the build 1966 all stored in the directory defined by :term:`DL_DIR` and the build
1967 system looks there first to find source tarballs. 1967 system looks there first to find source tarballs.
1968 1968
1969 .. note:: 1969 .. note::
@@ -1992,7 +1992,7 @@ system and gives an overview of their function and contents.
1992 :term:`EFI_PROVIDER` 1992 :term:`EFI_PROVIDER`
1993 When building bootable images (i.e. where ``hddimg``, ``iso``, or 1993 When building bootable images (i.e. where ``hddimg``, ``iso``, or
1994 ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the 1994 ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the
1995 ``EFI_PROVIDER`` variable specifies the EFI bootloader to use. The 1995 :term:`EFI_PROVIDER` variable specifies the EFI bootloader to use. The
1996 default is "grub-efi", but "systemd-boot" can be used instead. 1996 default is "grub-efi", but "systemd-boot" can be used instead.
1997 1997
1998 See the :ref:`systemd-boot <ref-classes-systemd-boot>` and 1998 See the :ref:`systemd-boot <ref-classes-systemd-boot>` and
@@ -2013,7 +2013,7 @@ system and gives an overview of their function and contents.
2013 database. By default, the value of this variable is 2013 database. By default, the value of this variable is
2014 ``${``\ :term:`LOG_DIR`\ ``}/error-report``. 2014 ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
2015 2015
2016 You can set ``ERR_REPORT_DIR`` to the path you want the error 2016 You can set :term:`ERR_REPORT_DIR` to the path you want the error
2017 reporting tool to store the debug files as follows in your 2017 reporting tool to store the debug files as follows in your
2018 ``local.conf`` file:: 2018 ``local.conf`` file::
2019 2019
@@ -2038,11 +2038,11 @@ system and gives an overview of their function and contents.
2038 libraries resolver might implicitly define some dependencies between 2038 libraries resolver might implicitly define some dependencies between
2039 packages. 2039 packages.
2040 2040
2041 The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the 2041 The :term:`EXCLUDE_FROM_SHLIBS` variable is similar to the
2042 :term:`PRIVATE_LIBS` variable, which excludes a 2042 :term:`PRIVATE_LIBS` variable, which excludes a
2043 package's particular libraries only and not the whole package. 2043 package's particular libraries only and not the whole package.
2044 2044
2045 Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a 2045 Use the :term:`EXCLUDE_FROM_SHLIBS` variable by setting it to "1" for a
2046 particular package:: 2046 particular package::
2047 2047
2048 EXCLUDE_FROM_SHLIBS = "1" 2048 EXCLUDE_FROM_SHLIBS = "1"
@@ -2058,18 +2058,18 @@ system and gives an overview of their function and contents.
2058 2058
2059 .. note:: 2059 .. note::
2060 2060
2061 Recipes added to ``EXCLUDE_FROM_WORLD`` may still be built during a 2061 Recipes added to :term:`EXCLUDE_FROM_WORLD` may still be built during a
2062 world build in order to satisfy dependencies of other recipes. Adding 2062 world build in order to satisfy dependencies of other recipes. Adding
2063 a recipe to ``EXCLUDE_FROM_WORLD`` only ensures that the recipe is not 2063 a recipe to :term:`EXCLUDE_FROM_WORLD` only ensures that the recipe is not
2064 explicitly added to the list of build targets in a world build. 2064 explicitly added to the list of build targets in a world build.
2065 2065
2066 :term:`EXTENDPE` 2066 :term:`EXTENDPE`
2067 Used with file and pathnames to create a prefix for a recipe's 2067 Used with file and pathnames to create a prefix for a recipe's
2068 version based on the recipe's :term:`PE` value. If ``PE`` 2068 version based on the recipe's :term:`PE` value. If :term:`PE`
2069 is set and greater than zero for a recipe, ``EXTENDPE`` becomes that 2069 is set and greater than zero for a recipe, :term:`EXTENDPE` becomes that
2070 value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1"). 2070 value (e.g if :term:`PE` is equal to "1" then :term:`EXTENDPE` becomes "1").
2071 If a recipe's ``PE`` is not set (the default) or is equal to zero, 2071 If a recipe's :term:`PE` is not set (the default) or is equal to zero,
2072 ``EXTENDPE`` becomes "". 2072 :term:`EXTENDPE` becomes "".
2073 2073
2074 See the :term:`STAMP` variable for an example. 2074 See the :term:`STAMP` variable for an example.
2075 2075
@@ -2085,11 +2085,11 @@ system and gives an overview of their function and contents.
2085 manager to upgrade these types of packages in lock-step. 2085 manager to upgrade these types of packages in lock-step.
2086 2086
2087 :term:`EXTERNAL_KERNEL_TOOLS` 2087 :term:`EXTERNAL_KERNEL_TOOLS`
2088 When set, the ``EXTERNAL_KERNEL_TOOLS`` variable indicates that these 2088 When set, the :term:`EXTERNAL_KERNEL_TOOLS` variable indicates that these
2089 tools are not in the source tree. 2089 tools are not in the source tree.
2090 2090
2091 When kernel tools are available in the tree, they are preferred over 2091 When kernel tools are available in the tree, they are preferred over
2092 any externally installed tools. Setting the ``EXTERNAL_KERNEL_TOOLS`` 2092 any externally installed tools. Setting the :term:`EXTERNAL_KERNEL_TOOLS`
2093 variable tells the OpenEmbedded build system to prefer the installed 2093 variable tells the OpenEmbedded build system to prefer the installed
2094 external tools. See the 2094 external tools. See the
2095 :ref:`kernel-yocto <ref-classes-kernel-yocto>` class in 2095 :ref:`kernel-yocto <ref-classes-kernel-yocto>` class in
@@ -2124,7 +2124,7 @@ system and gives an overview of their function and contents.
2124 2124
2125 :term:`EXTRA_AUTORECONF` 2125 :term:`EXTRA_AUTORECONF`
2126 For recipes inheriting the :ref:`autotools <ref-classes-autotools>` 2126 For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
2127 class, you can use ``EXTRA_AUTORECONF`` to specify extra options to 2127 class, you can use :term:`EXTRA_AUTORECONF` to specify extra options to
2128 pass to the ``autoreconf`` command that is executed during the 2128 pass to the ``autoreconf`` command that is executed during the
2129 :ref:`ref-tasks-configure` task. 2129 :ref:`ref-tasks-configure` task.
2130 2130
@@ -2186,7 +2186,7 @@ system and gives an overview of their function and contents.
2186 installing into the root filesystem. 2186 installing into the root filesystem.
2187 2187
2188 Sometimes a recipe is required to build the final image but is not 2188 Sometimes a recipe is required to build the final image but is not
2189 needed in the root filesystem. You can use the ``EXTRA_IMAGEDEPENDS`` 2189 needed in the root filesystem. You can use the :term:`EXTRA_IMAGEDEPENDS`
2190 variable to list these recipes and thus specify the dependencies. A 2190 variable to list these recipes and thus specify the dependencies. A
2191 typical example is a required bootloader in a machine configuration. 2191 typical example is a required bootloader in a machine configuration.
2192 2192
@@ -2217,12 +2217,12 @@ system and gives an overview of their function and contents.
2217 :term:`EXTRA_OEMAKE` 2217 :term:`EXTRA_OEMAKE`
2218 Additional GNU ``make`` options. 2218 Additional GNU ``make`` options.
2219 2219
2220 Because the ``EXTRA_OEMAKE`` defaults to "", you need to set the 2220 Because the :term:`EXTRA_OEMAKE` defaults to "", you need to set the
2221 variable to specify any required GNU options. 2221 variable to specify any required GNU options.
2222 2222
2223 :term:`PARALLEL_MAKE` and 2223 :term:`PARALLEL_MAKE` and
2224 :term:`PARALLEL_MAKEINST` also make use of 2224 :term:`PARALLEL_MAKEINST` also make use of
2225 ``EXTRA_OEMAKE`` to pass the required flags. 2225 :term:`EXTRA_OEMAKE` to pass the required flags.
2226 2226
2227 :term:`EXTRA_OESCONS` 2227 :term:`EXTRA_OESCONS`
2228 When inheriting the :ref:`scons <ref-classes-scons>` class, this 2228 When inheriting the :ref:`scons <ref-classes-scons>` class, this
@@ -2238,7 +2238,7 @@ system and gives an overview of their function and contents.
2238 group configurations to a specific recipe. 2238 group configurations to a specific recipe.
2239 2239
2240 The set list of commands you can configure using the 2240 The set list of commands you can configure using the
2241 ``EXTRA_USERS_PARAMS`` is shown in the ``extrausers`` class. These 2241 :term:`EXTRA_USERS_PARAMS` is shown in the ``extrausers`` class. These
2242 commands map to the normal Unix commands of the same names:: 2242 commands map to the normal Unix commands of the same names::
2243 2243
2244 # EXTRA_USERS_PARAMS = "\ 2244 # EXTRA_USERS_PARAMS = "\
@@ -2264,19 +2264,19 @@ system and gives an overview of their function and contents.
2264 :term:`FEATURE_PACKAGES` 2264 :term:`FEATURE_PACKAGES`
2265 Defines one or more packages to include in an image when a specific 2265 Defines one or more packages to include in an image when a specific
2266 item is included in :term:`IMAGE_FEATURES`. 2266 item is included in :term:`IMAGE_FEATURES`.
2267 When setting the value, ``FEATURE_PACKAGES`` should have the name of 2267 When setting the value, :term:`FEATURE_PACKAGES` should have the name of
2268 the feature item as an override. Here is an example:: 2268 the feature item as an override. Here is an example::
2269 2269
2270 FEATURE_PACKAGES_widget = "package1 package2" 2270 FEATURE_PACKAGES_widget = "package1 package2"
2271 2271
2272 In this example, if "widget" were added to ``IMAGE_FEATURES``, 2272 In this example, if "widget" were added to :term:`IMAGE_FEATURES`,
2273 package1 and package2 would be included in the image. 2273 package1 and package2 would be included in the image.
2274 2274
2275 .. note:: 2275 .. note::
2276 2276
2277 Packages installed by features defined through ``FEATURE_PACKAGES`` 2277 Packages installed by features defined through :term:`FEATURE_PACKAGES`
2278 are often package groups. While similarly named, you should not 2278 are often package groups. While similarly named, you should not
2279 confuse the ``FEATURE_PACKAGES`` variable with package groups, which 2279 confuse the :term:`FEATURE_PACKAGES` variable with package groups, which
2280 are discussed elsewhere in the documentation. 2280 are discussed elsewhere in the documentation.
2281 2281
2282 :term:`FEED_DEPLOYDIR_BASE_URI` 2282 :term:`FEED_DEPLOYDIR_BASE_URI`
@@ -2301,7 +2301,7 @@ system and gives an overview of their function and contents.
2301 :term:`PACKAGES` variable lists the packages 2301 :term:`PACKAGES` variable lists the packages
2302 generated by a recipe. 2302 generated by a recipe.
2303 2303
2304 To use the ``FILES`` variable, provide a package name override that 2304 To use the :term:`FILES` variable, provide a package name override that
2305 identifies the resulting package. Then, provide a space-separated 2305 identifies the resulting package. Then, provide a space-separated
2306 list of files or paths that identify the files you want included as 2306 list of files or paths that identify the files you want included as
2307 part of the resulting package. Here is an example:: 2307 part of the resulting package. Here is an example::
@@ -2316,7 +2316,7 @@ system and gives an overview of their function and contents.
2316 syntax. For details on the syntax, see the documentation by 2316 syntax. For details on the syntax, see the documentation by
2317 following the previous link. 2317 following the previous link.
2318 2318
2319 - When specifying paths as part of the ``FILES`` variable, it is 2319 - When specifying paths as part of the :term:`FILES` variable, it is
2320 good practice to use appropriate path variables. For example, 2320 good practice to use appropriate path variables. For example,
2321 use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}`` 2321 use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}``
2322 rather than ``/usr/bin``. You can find a list of these 2322 rather than ``/usr/bin``. You can find a list of these
@@ -2325,7 +2325,7 @@ system and gives an overview of their function and contents.
2325 find the default values of the various ``FILES_*`` variables in 2325 find the default values of the various ``FILES_*`` variables in
2326 this file. 2326 this file.
2327 2327
2328 If some of the files you provide with the ``FILES`` variable are 2328 If some of the files you provide with the :term:`FILES` variable are
2329 editable and you know they should not be overwritten during the 2329 editable and you know they should not be overwritten during the
2330 package update process by the Package Management System (PMS), you 2330 package update process by the Package Management System (PMS), you
2331 can identify these files so that the PMS will not overwrite them. See 2331 can identify these files so that the PMS will not overwrite them. See
@@ -2335,7 +2335,7 @@ system and gives an overview of their function and contents.
2335 :term:`FILES_SOLIBSDEV` 2335 :term:`FILES_SOLIBSDEV`
2336 Defines the file specification to match 2336 Defines the file specification to match
2337 :term:`SOLIBSDEV`. In other words, 2337 :term:`SOLIBSDEV`. In other words,
2338 ``FILES_SOLIBSDEV`` defines the full path name of the development 2338 :term:`FILES_SOLIBSDEV` defines the full path name of the development
2339 symbolic link (symlink) for shared libraries on the target platform. 2339 symbolic link (symlink) for shared libraries on the target platform.
2340 2340
2341 The following statement from the ``bitbake.conf`` shows how it is 2341 The following statement from the ``bitbake.conf`` shows how it is
@@ -2348,11 +2348,11 @@ system and gives an overview of their function and contents.
2348 looking for files and patches as it processes recipes and append 2348 looking for files and patches as it processes recipes and append
2349 files. The default directories BitBake uses when it processes recipes 2349 files. The default directories BitBake uses when it processes recipes
2350 are initially defined by the :term:`FILESPATH` 2350 are initially defined by the :term:`FILESPATH`
2351 variable. You can extend ``FILESPATH`` variable by using 2351 variable. You can extend :term:`FILESPATH` variable by using
2352 ``FILESEXTRAPATHS``. 2352 :term:`FILESEXTRAPATHS`.
2353 2353
2354 Best practices dictate that you accomplish this by using 2354 Best practices dictate that you accomplish this by using
2355 ``FILESEXTRAPATHS`` from within a ``.bbappend`` file and that you 2355 :term:`FILESEXTRAPATHS` from within a ``.bbappend`` file and that you
2356 prepend paths as follows:: 2356 prepend paths as follows::
2357 2357
2358 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 2358 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -2363,7 +2363,7 @@ system and gives an overview of their function and contents.
2363 2363
2364 .. note:: 2364 .. note::
2365 2365
2366 When extending ``FILESEXTRAPATHS``, be sure to use the immediate 2366 When extending :term:`FILESEXTRAPATHS`, be sure to use the immediate
2367 expansion (``:=``) operator. Immediate expansion makes sure that 2367 expansion (``:=``) operator. Immediate expansion makes sure that
2368 BitBake evaluates :term:`THISDIR` at the time the 2368 BitBake evaluates :term:`THISDIR` at the time the
2369 directive is encountered rather than at some later time when 2369 directive is encountered rather than at some later time when
@@ -2380,7 +2380,7 @@ system and gives an overview of their function and contents.
2380 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" 2380 FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
2381 2381
2382 In this example, the build system extends the 2382 In this example, the build system extends the
2383 ``FILESPATH`` variable to include a directory named ``files`` that is 2383 :term:`FILESPATH` variable to include a directory named ``files`` that is
2384 in the same directory as the corresponding append file. 2384 in the same directory as the corresponding append file.
2385 2385
2386 This next example specifically adds three paths:: 2386 This next example specifically adds three paths::
@@ -2403,7 +2403,7 @@ system and gives an overview of their function and contents.
2403 .. note:: 2403 .. note::
2404 2404
2405 For a layer that supports a single BSP, the override could just be 2405 For a layer that supports a single BSP, the override could just be
2406 the value of ``MACHINE``. 2406 the value of :term:`MACHINE`.
2407 2407
2408 By prepending paths in ``.bbappend`` files, you allow multiple append 2408 By prepending paths in ``.bbappend`` files, you allow multiple append
2409 files that reside in different layers but are used for the same 2409 files that reside in different layers but are used for the same
@@ -2412,7 +2412,7 @@ system and gives an overview of their function and contents.
2412 :term:`FILESOVERRIDES` 2412 :term:`FILESOVERRIDES`
2413 A subset of :term:`OVERRIDES` used by the 2413 A subset of :term:`OVERRIDES` used by the
2414 OpenEmbedded build system for creating 2414 OpenEmbedded build system for creating
2415 :term:`FILESPATH`. The ``FILESOVERRIDES`` variable 2415 :term:`FILESPATH`. The :term:`FILESOVERRIDES` variable
2416 uses overrides to automatically extend the 2416 uses overrides to automatically extend the
2417 :term:`FILESPATH` variable. For an example of how 2417 :term:`FILESPATH` variable. For an example of how
2418 that works, see the :term:`FILESPATH` variable 2418 that works, see the :term:`FILESPATH` variable
@@ -2421,13 +2421,13 @@ system and gives an overview of their function and contents.
2421 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`" 2421 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
2422 section of the BitBake User Manual. 2422 section of the BitBake User Manual.
2423 2423
2424 By default, the ``FILESOVERRIDES`` variable is defined as:: 2424 By default, the :term:`FILESOVERRIDES` variable is defined as::
2425 2425
2426 FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" 2426 FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
2427 2427
2428 .. note:: 2428 .. note::
2429 2429
2430 Do not hand-edit the ``FILESOVERRIDES`` variable. The values match up 2430 Do not hand-edit the :term:`FILESOVERRIDES` variable. The values match up
2431 with expected overrides and are used in an expected manner by the 2431 with expected overrides and are used in an expected manner by the
2432 build system. 2432 build system.
2433 2433
@@ -2436,11 +2436,11 @@ system and gives an overview of their function and contents.
2436 when searching for patches and files. 2436 when searching for patches and files.
2437 2437
2438 During the build process, BitBake searches each directory in 2438 During the build process, BitBake searches each directory in
2439 ``FILESPATH`` in the specified order when looking for files and 2439 :term:`FILESPATH` in the specified order when looking for files and
2440 patches specified by each ``file://`` URI in a recipe's 2440 patches specified by each ``file://`` URI in a recipe's
2441 :term:`SRC_URI` statements. 2441 :term:`SRC_URI` statements.
2442 2442
2443 The default value for the ``FILESPATH`` variable is defined in the 2443 The default value for the :term:`FILESPATH` variable is defined in the
2444 ``base.bbclass`` class found in ``meta/classes`` in the 2444 ``base.bbclass`` class found in ``meta/classes`` in the
2445 :term:`Source Directory`:: 2445 :term:`Source Directory`::
2446 2446
@@ -2448,22 +2448,22 @@ system and gives an overview of their function and contents.
2448 "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" 2448 "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
2449 2449
2450 The 2450 The
2451 ``FILESPATH`` variable is automatically extended using the overrides 2451 :term:`FILESPATH` variable is automatically extended using the overrides
2452 from the :term:`FILESOVERRIDES` variable. 2452 from the :term:`FILESOVERRIDES` variable.
2453 2453
2454 .. note:: 2454 .. note::
2455 2455
2456 - Do not hand-edit the ``FILESPATH`` variable. If you want the 2456 - Do not hand-edit the :term:`FILESPATH` variable. If you want the
2457 build system to look in directories other than the defaults, 2457 build system to look in directories other than the defaults,
2458 extend the ``FILESPATH`` variable by using the 2458 extend the :term:`FILESPATH` variable by using the
2459 :term:`FILESEXTRAPATHS` variable. 2459 :term:`FILESEXTRAPATHS` variable.
2460 2460
2461 - Be aware that the default ``FILESPATH`` directories do not map 2461 - Be aware that the default :term:`FILESPATH` directories do not map
2462 to directories in custom layers where append files 2462 to directories in custom layers where append files
2463 (``.bbappend``) are used. If you want the build system to find 2463 (``.bbappend``) are used. If you want the build system to find
2464 patches or files that reside with your append files, you need 2464 patches or files that reside with your append files, you need
2465 to extend the ``FILESPATH`` variable by using the 2465 to extend the :term:`FILESPATH` variable by using the
2466 ``FILESEXTRAPATHS`` variable. 2466 :term:`FILESEXTRAPATHS` variable.
2467 2467
2468 You can take advantage of this searching behavior in useful ways. For 2468 You can take advantage of this searching behavior in useful ways. For
2469 example, consider a case where there is the following directory structure 2469 example, consider a case where there is the following directory structure
@@ -2473,10 +2473,10 @@ system and gives an overview of their function and contents.
2473 files/MACHINEA/defconfig 2473 files/MACHINEA/defconfig
2474 files/MACHINEB/defconfig 2474 files/MACHINEB/defconfig
2475 2475
2476 Also in the example, the ``SRC_URI`` statement contains 2476 Also in the example, the :term:`SRC_URI` statement contains
2477 "file://defconfig". Given this scenario, you can set 2477 "file://defconfig". Given this scenario, you can set
2478 :term:`MACHINE` to "MACHINEA" and cause the build 2478 :term:`MACHINE` to "MACHINEA" and cause the build
2479 system to use files from ``files/MACHINEA``. Set ``MACHINE`` to 2479 system to use files from ``files/MACHINEA``. Set :term:`MACHINE` to
2480 "MACHINEB" and the build system uses files from ``files/MACHINEB``. 2480 "MACHINEB" and the build system uses files from ``files/MACHINEB``.
2481 Finally, for any machine other than "MACHINEA" and "MACHINEB", the 2481 Finally, for any machine other than "MACHINEA" and "MACHINEB", the
2482 build system uses files from ``files/defconfig``. 2482 build system uses files from ``files/defconfig``.
@@ -2501,7 +2501,7 @@ system and gives an overview of their function and contents.
2501 permissions setting table, you should place it in your layer or the 2501 permissions setting table, you should place it in your layer or the
2502 distro's layer. 2502 distro's layer.
2503 2503
2504 You define the ``FILESYSTEM_PERMS_TABLES`` variable in the 2504 You define the :term:`FILESYSTEM_PERMS_TABLES` variable in the
2505 ``conf/local.conf`` file, which is found in the :term:`Build Directory`, 2505 ``conf/local.conf`` file, which is found in the :term:`Build Directory`,
2506 to point to your custom 2506 to point to your custom
2507 ``fs-perms.txt``. You can specify more than a single file permissions 2507 ``fs-perms.txt``. You can specify more than a single file permissions
@@ -2520,7 +2520,7 @@ system and gives an overview of their function and contents.
2520 2520
2521 :term:`FIT_GENERATE_KEYS` 2521 :term:`FIT_GENERATE_KEYS`
2522 Decides whether to generate the keys for signing fitImage if they 2522 Decides whether to generate the keys for signing fitImage if they
2523 don't already exist. The keys are created in ``UBOOT_SIGN_KEYDIR``. 2523 don't already exist. The keys are created in :term:`UBOOT_SIGN_KEYDIR`.
2524 The default value is 0. 2524 The default value is 0.
2525 2525
2526 :term:`FIT_HASH_ALG` 2526 :term:`FIT_HASH_ALG`
@@ -2601,7 +2601,7 @@ system and gives an overview of their function and contents.
2601 2601
2602 :term:`GCCVERSION` 2602 :term:`GCCVERSION`
2603 Specifies the default version of the GNU C Compiler (GCC) used for 2603 Specifies the default version of the GNU C Compiler (GCC) used for
2604 compilation. By default, ``GCCVERSION`` is set to "8.x" in the 2604 compilation. By default, :term:`GCCVERSION` is set to "8.x" in the
2605 ``meta/conf/distro/include/tcmode-default.inc`` include file:: 2605 ``meta/conf/distro/include/tcmode-default.inc`` include file::
2606 2606
2607 GCCVERSION ?= "8.%" 2607 GCCVERSION ?= "8.%"
@@ -2625,7 +2625,7 @@ system and gives an overview of their function and contents.
2625 If you specifically remove the locale ``en_US.UTF-8``, you must set 2625 If you specifically remove the locale ``en_US.UTF-8``, you must set
2626 :term:`IMAGE_LINGUAS` appropriately. 2626 :term:`IMAGE_LINGUAS` appropriately.
2627 2627
2628 You can set ``GLIBC_GENERATE_LOCALES`` in your ``local.conf`` file. 2628 You can set :term:`GLIBC_GENERATE_LOCALES` in your ``local.conf`` file.
2629 By default, all locales are generated. 2629 By default, all locales are generated.
2630 :: 2630 ::
2631 2631
@@ -2667,7 +2667,7 @@ system and gives an overview of their function and contents.
2667 configuration. Use a semi-colon character (``;``) to separate 2667 configuration. Use a semi-colon character (``;``) to separate
2668 multiple options. 2668 multiple options.
2669 2669
2670 The ``GRUB_OPTS`` variable is optional. See the 2670 The :term:`GRUB_OPTS` variable is optional. See the
2671 :ref:`grub-efi <ref-classes-grub-efi>` class for more information 2671 :ref:`grub-efi <ref-classes-grub-efi>` class for more information
2672 on how this variable is used. 2672 on how this variable is used.
2673 2673
@@ -2675,7 +2675,7 @@ system and gives an overview of their function and contents.
2675 Specifies the timeout before executing the default ``LABEL`` in the 2675 Specifies the timeout before executing the default ``LABEL`` in the
2676 GNU GRand Unified Bootloader (GRUB). 2676 GNU GRand Unified Bootloader (GRUB).
2677 2677
2678 The ``GRUB_TIMEOUT`` variable is optional. See the 2678 The :term:`GRUB_TIMEOUT` variable is optional. See the
2679 :ref:`grub-efi <ref-classes-grub-efi>` class for more information 2679 :ref:`grub-efi <ref-classes-grub-efi>` class for more information
2680 on how this variable is used. 2680 on how this variable is used.
2681 2681
@@ -2709,7 +2709,7 @@ system and gives an overview of their function and contents.
2709 Specifies architecture-specific compiler flags that are passed to the 2709 Specifies architecture-specific compiler flags that are passed to the
2710 C compiler. 2710 C compiler.
2711 2711
2712 Default initialization for ``HOST_CC_ARCH`` varies depending on what 2712 Default initialization for :term:`HOST_CC_ARCH` varies depending on what
2713 is being built: 2713 is being built:
2714 2714
2715 - :term:`TARGET_CC_ARCH` when building for the 2715 - :term:`TARGET_CC_ARCH` when building for the
@@ -2729,7 +2729,7 @@ system and gives an overview of their function and contents.
2729 "linux-musleabi" values possible. 2729 "linux-musleabi" values possible.
2730 2730
2731 :term:`HOST_PREFIX` 2731 :term:`HOST_PREFIX`
2732 Specifies the prefix for the cross-compile toolchain. ``HOST_PREFIX`` 2732 Specifies the prefix for the cross-compile toolchain. :term:`HOST_PREFIX`
2733 is normally the same as :term:`TARGET_PREFIX`. 2733 is normally the same as :term:`TARGET_PREFIX`.
2734 2734
2735 :term:`HOST_SYS` 2735 :term:`HOST_SYS`
@@ -2758,7 +2758,7 @@ system and gives an overview of their function and contents.
2758 A space-separated list (filter) of tools on the build host that 2758 A space-separated list (filter) of tools on the build host that
2759 should be allowed to be called from within build tasks. Using this 2759 should be allowed to be called from within build tasks. Using this
2760 filter helps reduce the possibility of host contamination. If a tool 2760 filter helps reduce the possibility of host contamination. If a tool
2761 specified in the value of ``HOSTTOOLS`` is not found on the build 2761 specified in the value of :term:`HOSTTOOLS` is not found on the build
2762 host, the OpenEmbedded build system produces an error and the build 2762 host, the OpenEmbedded build system produces an error and the build
2763 is not started. 2763 is not started.
2764 2764
@@ -2771,11 +2771,11 @@ system and gives an overview of their function and contents.
2771 filter helps reduce the possibility of host contamination. Unlike 2771 filter helps reduce the possibility of host contamination. Unlike
2772 :term:`HOSTTOOLS`, the OpenEmbedded build system 2772 :term:`HOSTTOOLS`, the OpenEmbedded build system
2773 does not produce an error if a tool specified in the value of 2773 does not produce an error if a tool specified in the value of
2774 ``HOSTTOOLS_NONFATAL`` is not found on the build host. Thus, you can 2774 :term:`HOSTTOOLS_NONFATAL` is not found on the build host. Thus, you can
2775 use ``HOSTTOOLS_NONFATAL`` to filter optional host tools. 2775 use :term:`HOSTTOOLS_NONFATAL` to filter optional host tools.
2776 2776
2777 :term:`HOST_VENDOR` 2777 :term:`HOST_VENDOR`
2778 Specifies the name of the vendor. ``HOST_VENDOR`` is normally the 2778 Specifies the name of the vendor. :term:`HOST_VENDOR` is normally the
2779 same as :term:`TARGET_VENDOR`. 2779 same as :term:`TARGET_VENDOR`.
2780 2780
2781 :term:`ICECC_DISABLED` 2781 :term:`ICECC_DISABLED`
@@ -2820,12 +2820,12 @@ system and gives an overview of their function and contents.
2820 network lag, available memory, and existing machine loads can all 2820 network lag, available memory, and existing machine loads can all
2821 affect build time. Consequently, unlike the 2821 affect build time. Consequently, unlike the
2822 :term:`PARALLEL_MAKE` variable, there is no 2822 :term:`PARALLEL_MAKE` variable, there is no
2823 rule-of-thumb for setting ``ICECC_PARALLEL_MAKE`` to achieve optimal 2823 rule-of-thumb for setting :term:`ICECC_PARALLEL_MAKE` to achieve optimal
2824 performance. 2824 performance.
2825 2825
2826 If you do not set ``ICECC_PARALLEL_MAKE``, the build system does not 2826 If you do not set :term:`ICECC_PARALLEL_MAKE`, the build system does not
2827 use it (i.e. the system does not detect and assign the number of 2827 use it (i.e. the system does not detect and assign the number of
2828 cores as is done with ``PARALLEL_MAKE``). 2828 cores as is done with :term:`PARALLEL_MAKE`).
2829 2829
2830 :term:`ICECC_PATH` 2830 :term:`ICECC_PATH`
2831 The location of the ``icecc`` binary. You can set this variable in 2831 The location of the ``icecc`` binary. You can set this variable in
@@ -2938,7 +2938,7 @@ system and gives an overview of their function and contents.
2938 this variable to specify the list of classes that register the 2938 this variable to specify the list of classes that register the
2939 different types of images the OpenEmbedded build system creates. 2939 different types of images the OpenEmbedded build system creates.
2940 2940
2941 The default value for ``IMAGE_CLASSES`` is ``image_types``. You can 2941 The default value for :term:`IMAGE_CLASSES` is ``image_types``. You can
2942 set this variable in your ``local.conf`` or in a distribution 2942 set this variable in your ``local.conf`` or in a distribution
2943 configuration file. 2943 configuration file.
2944 2944
@@ -2965,7 +2965,7 @@ system and gives an overview of their function and contents.
2965 Specifies one or more files that contain custom device tables that 2965 Specifies one or more files that contain custom device tables that
2966 are passed to the ``makedevs`` command as part of creating an image. 2966 are passed to the ``makedevs`` command as part of creating an image.
2967 These files list basic device nodes that should be created under 2967 These files list basic device nodes that should be created under
2968 ``/dev`` within the image. If ``IMAGE_DEVICE_TABLES`` is not set, 2968 ``/dev`` within the image. If :term:`IMAGE_DEVICE_TABLES` is not set,
2969 ``files/device_table-minimal.txt`` is used, which is located by 2969 ``files/device_table-minimal.txt`` is used, which is located by
2970 :term:`BBPATH`. For details on how you should write 2970 :term:`BBPATH`. For details on how you should write
2971 device table files, see ``meta/files/device_table-minimal.txt`` as an 2971 device table files, see ``meta/files/device_table-minimal.txt`` as an
@@ -2993,7 +2993,7 @@ system and gives an overview of their function and contents.
2993 :term:`IMAGE_FSTYPES` 2993 :term:`IMAGE_FSTYPES`
2994 Specifies the formats the OpenEmbedded build system uses during the 2994 Specifies the formats the OpenEmbedded build system uses during the
2995 build when creating the root filesystem. For example, setting 2995 build when creating the root filesystem. For example, setting
2996 ``IMAGE_FSTYPES`` as follows causes the build system to create root 2996 :term:`IMAGE_FSTYPES` as follows causes the build system to create root
2997 filesystems using two formats: ``.ext3`` and ``.tar.bz2``:: 2997 filesystems using two formats: ``.ext3`` and ``.tar.bz2``::
2998 2998
2999 IMAGE_FSTYPES = "ext3 tar.bz2" 2999 IMAGE_FSTYPES = "ext3 tar.bz2"
@@ -3004,25 +3004,25 @@ system and gives an overview of their function and contents.
3004 .. note:: 3004 .. note::
3005 3005
3006 - If an image recipe uses the "inherit image" line and you are 3006 - If an image recipe uses the "inherit image" line and you are
3007 setting ``IMAGE_FSTYPES`` inside the recipe, you must set 3007 setting :term:`IMAGE_FSTYPES` inside the recipe, you must set
3008 ``IMAGE_FSTYPES`` prior to using the "inherit image" line. 3008 ``IMAGE_FSTYPES`` prior to using the "inherit image" line.
3009 3009
3010 - Due to the way the OpenEmbedded build system processes this 3010 - Due to the way the OpenEmbedded build system processes this
3011 variable, you cannot update its contents by using ``_append`` 3011 variable, you cannot update its contents by using ``_append``
3012 or ``_prepend``. You must use the ``+=`` operator to add one or 3012 or ``_prepend``. You must use the ``+=`` operator to add one or
3013 more options to the ``IMAGE_FSTYPES`` variable. 3013 more options to the :term:`IMAGE_FSTYPES` variable.
3014 3014
3015 :term:`IMAGE_INSTALL` 3015 :term:`IMAGE_INSTALL`
3016 Used by recipes to specify the packages to install into an image 3016 Used by recipes to specify the packages to install into an image
3017 through the :ref:`image <ref-classes-image>` class. Use the 3017 through the :ref:`image <ref-classes-image>` class. Use the
3018 ``IMAGE_INSTALL`` variable with care to avoid ordering issues. 3018 :term:`IMAGE_INSTALL` variable with care to avoid ordering issues.
3019 3019
3020 Image recipes set ``IMAGE_INSTALL`` to specify the packages to 3020 Image recipes set :term:`IMAGE_INSTALL` to specify the packages to
3021 install into an image through ``image.bbclass``. Additionally, 3021 install into an image through ``image.bbclass``. Additionally,
3022 there are "helper" classes such as the 3022 there are "helper" classes such as the
3023 :ref:`core-image <ref-classes-core-image>` class which can 3023 :ref:`core-image <ref-classes-core-image>` class which can
3024 take lists used with ``IMAGE_FEATURES`` and turn them into 3024 take lists used with :term:`IMAGE_FEATURES` and turn them into
3025 auto-generated entries in ``IMAGE_INSTALL`` in addition to its 3025 auto-generated entries in :term:`IMAGE_INSTALL` in addition to its
3026 default contents. 3026 default contents.
3027 3027
3028 When you use this variable, it is best to use it as follows:: 3028 When you use this variable, it is best to use it as follows::
@@ -3037,24 +3037,24 @@ system and gives an overview of their function and contents.
3037 3037
3038 - When working with a 3038 - When working with a
3039 :ref:`core-image-minimal-initramfs <ref-manual/images:images>` 3039 :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
3040 image, do not use the ``IMAGE_INSTALL`` variable to specify 3040 image, do not use the :term:`IMAGE_INSTALL` variable to specify
3041 packages for installation. Instead, use the 3041 packages for installation. Instead, use the
3042 :term:`PACKAGE_INSTALL` variable, which 3042 :term:`PACKAGE_INSTALL` variable, which
3043 allows the initial RAM filesystem (initramfs) recipe to use a 3043 allows the initial RAM filesystem (initramfs) recipe to use a
3044 fixed set of packages and not be affected by ``IMAGE_INSTALL``. 3044 fixed set of packages and not be affected by :term:`IMAGE_INSTALL`.
3045 For information on creating an initramfs, see the 3045 For information on creating an initramfs, see the
3046 ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" 3046 ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
3047 section in the Yocto Project Development Tasks Manual. 3047 section in the Yocto Project Development Tasks Manual.
3048 3048
3049 - Using ``IMAGE_INSTALL`` with the 3049 - Using :term:`IMAGE_INSTALL` with the
3050 :ref:`+= <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending (+=) and prepending (=+) with spaces>` 3050 :ref:`+= <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending (+=) and prepending (=+) with spaces>`
3051 BitBake operator within the ``/conf/local.conf`` file or from 3051 BitBake operator within the ``/conf/local.conf`` file or from
3052 within an image recipe is not recommended. Use of this operator 3052 within an image recipe is not recommended. Use of this operator
3053 in these ways can cause ordering issues. Since 3053 in these ways can cause ordering issues. Since
3054 ``core-image.bbclass`` sets ``IMAGE_INSTALL`` to a default 3054 ``core-image.bbclass`` sets :term:`IMAGE_INSTALL` to a default
3055 value using the 3055 value using the
3056 :ref:`?= <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:setting a default value (?=)>` 3056 :ref:`?= <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:setting a default value (?=)>`
3057 operator, using a ``+=`` operation against ``IMAGE_INSTALL`` 3057 operator, using a ``+=`` operation against :term:`IMAGE_INSTALL`
3058 results in unexpected behavior when used within 3058 results in unexpected behavior when used within
3059 ``conf/local.conf``. Furthermore, the same operation from 3059 ``conf/local.conf``. Furthermore, the same operation from
3060 within an image recipe may or may not succeed depending on the 3060 within an image recipe may or may not succeed depending on the
@@ -3065,7 +3065,7 @@ system and gives an overview of their function and contents.
3065 Specifies the list of locales to install into the image during the 3065 Specifies the list of locales to install into the image during the
3066 root filesystem construction process. The OpenEmbedded build system 3066 root filesystem construction process. The OpenEmbedded build system
3067 automatically splits locale files, which are used for localization, 3067 automatically splits locale files, which are used for localization,
3068 into separate packages. Setting the ``IMAGE_LINGUAS`` variable 3068 into separate packages. Setting the :term:`IMAGE_LINGUAS` variable
3069 ensures that any locale packages that correspond to packages already 3069 ensures that any locale packages that correspond to packages already
3070 selected for installation into the image are also installed. Here is 3070 selected for installation into the image are also installed. Here is
3071 an example:: 3071 an example::
@@ -3129,7 +3129,7 @@ system and gives an overview of their function and contents.
3129 Defines a multiplier that the build system applies to the initial 3129 Defines a multiplier that the build system applies to the initial
3130 image size for cases when the multiplier times the returned disk 3130 image size for cases when the multiplier times the returned disk
3131 usage value for the image is greater than the sum of 3131 usage value for the image is greater than the sum of
3132 ``IMAGE_ROOTFS_SIZE`` and ``IMAGE_ROOTFS_EXTRA_SPACE``. The result of 3132 :term:`IMAGE_ROOTFS_SIZE` and :term:`IMAGE_ROOTFS_EXTRA_SPACE`. The result of
3133 the multiplier applied to the initial image size creates free disk 3133 the multiplier applied to the initial image size creates free disk
3134 space in the image as overhead. By default, the build process uses a 3134 space in the image as overhead. By default, the build process uses a
3135 multiplier of 1.3 for this variable. This default value results in 3135 multiplier of 1.3 for this variable. This default value results in
@@ -3138,7 +3138,7 @@ system and gives an overview of their function and contents.
3138 post install scripts and the package management system uses disk 3138 post install scripts and the package management system uses disk
3139 space inside this overhead area. Consequently, the multiplier does 3139 space inside this overhead area. Consequently, the multiplier does
3140 not produce an image with all the theoretical free disk space. See 3140 not produce an image with all the theoretical free disk space. See
3141 ``IMAGE_ROOTFS_SIZE`` for information on how the build system 3141 :term:`IMAGE_ROOTFS_SIZE` for information on how the build system
3142 determines the overall image size. 3142 determines the overall image size.
3143 3143
3144 The default 30% free disk space typically gives the image enough room 3144 The default 30% free disk space typically gives the image enough room
@@ -3150,7 +3150,7 @@ system and gives an overview of their function and contents.
3150 IMAGE_OVERHEAD_FACTOR = "1.5" 3150 IMAGE_OVERHEAD_FACTOR = "1.5"
3151 3151
3152 Alternatively, you can ensure a specific amount of free disk space is 3152 Alternatively, you can ensure a specific amount of free disk space is
3153 added to the image by using the ``IMAGE_ROOTFS_EXTRA_SPACE`` 3153 added to the image by using the :term:`IMAGE_ROOTFS_EXTRA_SPACE`
3154 variable. 3154 variable.
3155 3155
3156 :term:`IMAGE_PKGTYPE` 3156 :term:`IMAGE_PKGTYPE`
@@ -3167,10 +3167,10 @@ system and gives an overview of their function and contents.
3167 recommended that you do not use it. 3167 recommended that you do not use it.
3168 3168
3169 The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and 3169 The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
3170 :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE`` 3170 :ref:`image <ref-classes-image>` classes use the :term:`IMAGE_PKGTYPE`
3171 for packaging up images and SDKs. 3171 for packaging up images and SDKs.
3172 3172
3173 You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the 3173 You should not set the :term:`IMAGE_PKGTYPE` manually. Rather, the
3174 variable is set indirectly through the appropriate 3174 variable is set indirectly through the appropriate
3175 :ref:`package_* <ref-classes-package>` class using the 3175 :ref:`package_* <ref-classes-package>` class using the
3176 :term:`PACKAGE_CLASSES` variable. The 3176 :term:`PACKAGE_CLASSES` variable. The
@@ -3225,7 +3225,7 @@ system and gives an overview of their function and contents.
3225 Defines additional free disk space created in the image in Kbytes. By 3225 Defines additional free disk space created in the image in Kbytes. By
3226 default, this variable is set to "0". This free disk space is added 3226 default, this variable is set to "0". This free disk space is added
3227 to the image after the build system determines the image size as 3227 to the image after the build system determines the image size as
3228 described in ``IMAGE_ROOTFS_SIZE``. 3228 described in :term:`IMAGE_ROOTFS_SIZE`.
3229 3229
3230 This variable is particularly useful when you want to ensure that a 3230 This variable is particularly useful when you want to ensure that a
3231 specific amount of free disk space is available on a device after an 3231 specific amount of free disk space is available on a device after an
@@ -3358,16 +3358,16 @@ system and gives an overview of their function and contents.
3358 common functionality are upgraded to a new revision. 3358 common functionality are upgraded to a new revision.
3359 3359
3360 A more efficient way of dealing with this situation is to set the 3360 A more efficient way of dealing with this situation is to set the
3361 ``INC_PR`` variable inside the ``include`` files that the recipes 3361 :term:`INC_PR` variable inside the ``include`` files that the recipes
3362 share and then expand the ``INC_PR`` variable within the recipes to 3362 share and then expand the :term:`INC_PR` variable within the recipes to
3363 help define the recipe revision. 3363 help define the recipe revision.
3364 3364
3365 The following provides an example that shows how to use the 3365 The following provides an example that shows how to use the
3366 ``INC_PR`` variable given a common ``include`` file that defines the 3366 :term:`INC_PR` variable given a common ``include`` file that defines the
3367 variable. Once the variable is defined in the ``include`` file, you 3367 variable. Once the variable is defined in the ``include`` file, you
3368 can use the variable to set the ``PR`` values in each recipe. You 3368 can use the variable to set the :term:`PR` values in each recipe. You
3369 will notice that when you set a recipe's ``PR`` you can provide more 3369 will notice that when you set a recipe's :term:`PR` you can provide more
3370 granular revisioning by appending values to the ``INC_PR`` variable:: 3370 granular revisioning by appending values to the :term:`INC_PR` variable::
3371 3371
3372 recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" 3372 recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
3373 recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1" 3373 recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
@@ -3378,7 +3378,7 @@ system and gives an overview of their function and contents.
3378 first line of the example establishes the baseline revision to be 3378 first line of the example establishes the baseline revision to be
3379 used for all recipes that use the ``include`` file. The remaining 3379 used for all recipes that use the ``include`` file. The remaining
3380 lines in the example are from individual recipes and show how the 3380 lines in the example are from individual recipes and show how the
3381 ``PR`` value is set. 3381 :term:`PR` value is set.
3382 3382
3383 :term:`INCOMPATIBLE_LICENSE` 3383 :term:`INCOMPATIBLE_LICENSE`
3384 Specifies a space-separated list of license names (as they would 3384 Specifies a space-separated list of license names (as they would
@@ -3404,12 +3404,12 @@ system and gives an overview of their function and contents.
3404 It is possible to define a list of licenses that are allowed to be 3404 It is possible to define a list of licenses that are allowed to be
3405 used instead of the licenses that are excluded. To do this, define 3405 used instead of the licenses that are excluded. To do this, define
3406 a variable ``COMPATIBLE_LICENSES`` with the names of the licenses 3406 a variable ``COMPATIBLE_LICENSES`` with the names of the licenses
3407 that are allowed. Then define ``INCOMPATIBLE_LICENSE`` as:: 3407 that are allowed. Then define :term:`INCOMPATIBLE_LICENSE` as::
3408 3408
3409 INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}" 3409 INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}"
3410 3410
3411 3411
3412 This will result in ``INCOMPATIBLE_LICENSE`` containing the names of 3412 This will result in :term:`INCOMPATIBLE_LICENSE` containing the names of
3413 all licenses from :term:`AVAILABLE_LICENSES` except the ones specified 3413 all licenses from :term:`AVAILABLE_LICENSES` except the ones specified
3414 in ``COMPATIBLE_LICENSES``, thus only allowing the latter licenses to 3414 in ``COMPATIBLE_LICENSES``, thus only allowing the latter licenses to
3415 be used. 3415 be used.
@@ -3418,9 +3418,9 @@ system and gives an overview of their function and contents.
3418 Causes the named class or classes to be inherited globally. Anonymous 3418 Causes the named class or classes to be inherited globally. Anonymous
3419 functions in the class or classes are not executed for the base 3419 functions in the class or classes are not executed for the base
3420 configuration and in each individual recipe. The OpenEmbedded build 3420 configuration and in each individual recipe. The OpenEmbedded build
3421 system ignores changes to ``INHERIT`` in individual recipes. 3421 system ignores changes to :term:`INHERIT` in individual recipes.
3422 3422
3423 For more information on ``INHERIT``, see the 3423 For more information on :term:`INHERIT`, see the
3424 :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`" 3424 :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
3425 section in the Bitbake User Manual. 3425 section in the Bitbake User Manual.
3426 3426
@@ -3452,7 +3452,7 @@ system and gives an overview of their function and contents.
3452 variable. 3452 variable.
3453 3453
3454 To prevent the build system from splitting out debug information 3454 To prevent the build system from splitting out debug information
3455 during packaging, set the ``INHIBIT_PACKAGE_DEBUG_SPLIT`` variable as 3455 during packaging, set the :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` variable as
3456 follows:: 3456 follows::
3457 3457
3458 INHIBIT_PACKAGE_DEBUG_SPLIT = "1" 3458 INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
@@ -3464,7 +3464,7 @@ system and gives an overview of their function and contents.
3464 3464
3465 By default, the OpenEmbedded build system strips binaries and puts 3465 By default, the OpenEmbedded build system strips binaries and puts
3466 the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``. 3466 the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``.
3467 Consequently, you should not set ``INHIBIT_PACKAGE_STRIP`` when you 3467 Consequently, you should not set :term:`INHIBIT_PACKAGE_STRIP` when you
3468 plan to debug in general. 3468 plan to debug in general.
3469 3469
3470 :term:`INHIBIT_SYSROOT_STRIP` 3470 :term:`INHIBIT_SYSROOT_STRIP`
@@ -3473,7 +3473,7 @@ system and gives an overview of their function and contents.
3473 3473
3474 By default, the OpenEmbedded build system strips binaries in the 3474 By default, the OpenEmbedded build system strips binaries in the
3475 resulting sysroot. When you specifically set the 3475 resulting sysroot. When you specifically set the
3476 ``INHIBIT_SYSROOT_STRIP`` variable to "1" in your recipe, you inhibit 3476 :term:`INHIBIT_SYSROOT_STRIP` variable to "1" in your recipe, you inhibit
3477 this stripping. 3477 this stripping.
3478 3478
3479 If you want to use this variable, include the 3479 If you want to use this variable, include the
@@ -3483,7 +3483,7 @@ system and gives an overview of their function and contents.
3483 3483
3484 .. note:: 3484 .. note::
3485 3485
3486 Use of the ``INHIBIT_SYSROOT_STRIP`` variable occurs in rare and 3486 Use of the :term:`INHIBIT_SYSROOT_STRIP` variable occurs in rare and
3487 special circumstances. For example, suppose you are building 3487 special circumstances. For example, suppose you are building
3488 bare-metal firmware by using an external GCC toolchain. Furthermore, 3488 bare-metal firmware by using an external GCC toolchain. Furthermore,
3489 even if the toolchain's binaries are strippable, there are other files 3489 even if the toolchain's binaries are strippable, there are other files
@@ -3505,7 +3505,7 @@ system and gives an overview of their function and contents.
3505 :term:`INITRAMFS_IMAGE` 3505 :term:`INITRAMFS_IMAGE`
3506 Specifies the :term:`PROVIDES` name of an image 3506 Specifies the :term:`PROVIDES` name of an image
3507 recipe that is used to build an initial RAM filesystem (initramfs) 3507 recipe that is used to build an initial RAM filesystem (initramfs)
3508 image. In other words, the ``INITRAMFS_IMAGE`` variable causes an 3508 image. In other words, the :term:`INITRAMFS_IMAGE` variable causes an
3509 additional recipe to be built as a dependency to whatever root 3509 additional recipe to be built as a dependency to whatever root
3510 filesystem recipe you might be using (e.g. ``core-image-sato``). The 3510 filesystem recipe you might be using (e.g. ``core-image-sato``). The
3511 initramfs image recipe you provide should set 3511 initramfs image recipe you provide should set
@@ -3521,16 +3521,16 @@ system and gives an overview of their function and contents.
3521 See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb`` 3521 See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
3522 recipe in the :term:`Source Directory` 3522 recipe in the :term:`Source Directory`
3523 for an example initramfs recipe. To select this sample recipe as 3523 for an example initramfs recipe. To select this sample recipe as
3524 the one built to provide the initramfs image, set ``INITRAMFS_IMAGE`` 3524 the one built to provide the initramfs image, set :term:`INITRAMFS_IMAGE`
3525 to "core-image-minimal-initramfs". 3525 to "core-image-minimal-initramfs".
3526 3526
3527 You can also find more information by referencing the 3527 You can also find more information by referencing the
3528 ``meta-poky/conf/local.conf.sample.extended`` configuration file in 3528 ``meta-poky/conf/local.conf.sample.extended`` configuration file in
3529 the Source Directory, the :ref:`image <ref-classes-image>` class, 3529 the Source Directory, the :ref:`image <ref-classes-image>` class,
3530 and the :ref:`kernel <ref-classes-kernel>` class to see how to use 3530 and the :ref:`kernel <ref-classes-kernel>` class to see how to use
3531 the ``INITRAMFS_IMAGE`` variable. 3531 the :term:`INITRAMFS_IMAGE` variable.
3532 3532
3533 If ``INITRAMFS_IMAGE`` is empty, which is the default, then no 3533 If :term:`INITRAMFS_IMAGE` is empty, which is the default, then no
3534 initramfs image is built. 3534 initramfs image is built.
3535 3535
3536 For more information, you can also see the 3536 For more information, you can also see the
@@ -3565,7 +3565,7 @@ system and gives an overview of their function and contents.
3565 3565
3566 Setting the variable to "1" in a configuration file causes the 3566 Setting the variable to "1" in a configuration file causes the
3567 OpenEmbedded build system to generate a kernel image with the 3567 OpenEmbedded build system to generate a kernel image with the
3568 initramfs specified in ``INITRAMFS_IMAGE`` bundled within:: 3568 initramfs specified in :term:`INITRAMFS_IMAGE` bundled within::
3569 3569
3570 INITRAMFS_IMAGE_BUNDLE = "1" 3570 INITRAMFS_IMAGE_BUNDLE = "1"
3571 3571
@@ -3577,7 +3577,7 @@ system and gives an overview of their function and contents.
3577 3577
3578 .. note:: 3578 .. note::
3579 3579
3580 You must set the ``INITRAMFS_IMAGE_BUNDLE`` variable in a 3580 You must set the :term:`INITRAMFS_IMAGE_BUNDLE` variable in a
3581 configuration file. You cannot set the variable in a recipe file. 3581 configuration file. You cannot set the variable in a recipe file.
3582 3582
3583 See the 3583 See the
@@ -3618,13 +3618,13 @@ system and gives an overview of their function and contents.
3618 Indicates list of filesystem images to concatenate and use as an 3618 Indicates list of filesystem images to concatenate and use as an
3619 initial RAM disk (``initrd``). 3619 initial RAM disk (``initrd``).
3620 3620
3621 The ``INITRD`` variable is an optional variable used with the 3621 The :term:`INITRD` variable is an optional variable used with the
3622 :ref:`image-live <ref-classes-image-live>` class. 3622 :ref:`image-live <ref-classes-image-live>` class.
3623 3623
3624 :term:`INITRD_IMAGE` 3624 :term:`INITRD_IMAGE`
3625 When building a "live" bootable image (i.e. when 3625 When building a "live" bootable image (i.e. when
3626 :term:`IMAGE_FSTYPES` contains "live"), 3626 :term:`IMAGE_FSTYPES` contains "live"),
3627 ``INITRD_IMAGE`` specifies the image recipe that should be built to 3627 :term:`INITRD_IMAGE` specifies the image recipe that should be built to
3628 provide the initial RAM disk image. The default value is 3628 provide the initial RAM disk image. The default value is
3629 "core-image-minimal-initramfs". 3629 "core-image-minimal-initramfs".
3630 3630
@@ -3658,7 +3658,7 @@ system and gives an overview of their function and contents.
3658 The variable's default value is "defaults", which is set in the 3658 The variable's default value is "defaults", which is set in the
3659 :ref:`update-rc.d <ref-classes-update-rc.d>` class. 3659 :ref:`update-rc.d <ref-classes-update-rc.d>` class.
3660 3660
3661 The value in ``INITSCRIPT_PARAMS`` is passed through to the 3661 The value in :term:`INITSCRIPT_PARAMS` is passed through to the
3662 ``update-rc.d`` command. For more information on valid parameters, 3662 ``update-rc.d`` command. For more information on valid parameters,
3663 please see the ``update-rc.d`` manual page at 3663 please see the ``update-rc.d`` manual page at
3664 https://manpages.debian.org/buster/init-system-helpers/update-rc.d.8.en.html 3664 https://manpages.debian.org/buster/init-system-helpers/update-rc.d.8.en.html
@@ -3677,7 +3677,7 @@ system and gives an overview of their function and contents.
3677 3677
3678 :term:`INSTALL_TIMEZONE_FILE` 3678 :term:`INSTALL_TIMEZONE_FILE`
3679 By default, the ``tzdata`` recipe packages an ``/etc/timezone`` file. 3679 By default, the ``tzdata`` recipe packages an ``/etc/timezone`` file.
3680 Set the ``INSTALL_TIMEZONE_FILE`` variable to "0" at the 3680 Set the :term:`INSTALL_TIMEZONE_FILE` variable to "0" at the
3681 configuration level to disable this behavior. 3681 configuration level to disable this behavior.
3682 3682
3683 :term:`IPK_FEED_URIS` 3683 :term:`IPK_FEED_URIS`
@@ -3709,7 +3709,7 @@ system and gives an overview of their function and contents.
3709 Values for this variable are set in the kernel's recipe file and the 3709 Values for this variable are set in the kernel's recipe file and the
3710 kernel's append file. For example, if you are using the 3710 kernel's append file. For example, if you are using the
3711 ``linux-yocto_4.12`` kernel, the kernel recipe file is the 3711 ``linux-yocto_4.12`` kernel, the kernel recipe file is the
3712 ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` file. ``KBRANCH`` 3712 ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` file. :term:`KBRANCH`
3713 is set as follows in that kernel recipe file:: 3713 is set as follows in that kernel recipe file::
3714 3714
3715 KBRANCH ?= "standard/base" 3715 KBRANCH ?= "standard/base"
@@ -3729,7 +3729,7 @@ system and gives an overview of their function and contents.
3729 KBRANCH_edgerouter = "standard/edgerouter" 3729 KBRANCH_edgerouter = "standard/edgerouter"
3730 KBRANCH_beaglebone = "standard/beaglebone" 3730 KBRANCH_beaglebone = "standard/beaglebone"
3731 3731
3732 The ``KBRANCH`` statements 3732 The :term:`KBRANCH` statements
3733 identify the kernel branch to use when building for each supported 3733 identify the kernel branch to use when building for each supported
3734 BSP. 3734 BSP.
3735 3735
@@ -3743,7 +3743,7 @@ system and gives an overview of their function and contents.
3743 would place patch files and configuration fragment files (i.e. 3743 would place patch files and configuration fragment files (i.e.
3744 "out-of-tree"). However, if you want to use a ``defconfig`` file that 3744 "out-of-tree"). However, if you want to use a ``defconfig`` file that
3745 is part of the kernel tree (i.e. "in-tree"), you can use the 3745 is part of the kernel tree (i.e. "in-tree"), you can use the
3746 ``KBUILD_DEFCONFIG`` variable and append the 3746 :term:`KBUILD_DEFCONFIG` variable and append the
3747 :term:`KMACHINE` variable to point to the 3747 :term:`KMACHINE` variable to point to the
3748 ``defconfig`` file. 3748 ``defconfig`` file.
3749 3749
@@ -3752,7 +3752,7 @@ system and gives an overview of their function and contents.
3752 3752
3753 KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file 3753 KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
3754 3754
3755 Here is an example from a "raspberrypi2" ``KMACHINE`` build that uses 3755 Here is an example from a "raspberrypi2" :term:`KMACHINE` build that uses
3756 a ``defconfig`` file named "bcm2709_defconfig":: 3756 a ``defconfig`` file named "bcm2709_defconfig"::
3757 3757
3758 KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig" 3758 KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
@@ -3762,7 +3762,7 @@ system and gives an overview of their function and contents.
3762 KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file 3762 KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file
3763 3763
3764 For more 3764 For more
3765 information on how to use the ``KBUILD_DEFCONFIG`` variable, see the 3765 information on how to use the :term:`KBUILD_DEFCONFIG` variable, see the
3766 ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`" 3766 ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`"
3767 section in the Yocto Project Linux Kernel Development Manual. 3767 section in the Yocto Project Linux Kernel Development Manual.
3768 3768
@@ -3779,27 +3779,27 @@ system and gives an overview of their function and contents.
3779 options not explicitly specified will be disabled in the kernel 3779 options not explicitly specified will be disabled in the kernel
3780 config. 3780 config.
3781 3781
3782 In case ``KCONFIG_MODE`` is not set the behaviour will depend on where 3782 In case :term:`KCONFIG_MODE` is not set the behaviour will depend on where
3783 the ``defconfig`` file is coming from. An "in-tree" ``defconfig`` file 3783 the ``defconfig`` file is coming from. An "in-tree" ``defconfig`` file
3784 will be handled in ``alldefconfig`` mode, a ``defconfig`` file placed 3784 will be handled in ``alldefconfig`` mode, a ``defconfig`` file placed
3785 in ``${WORKDIR}`` through a meta-layer will be handled in 3785 in ``${WORKDIR}`` through a meta-layer will be handled in
3786 ``allnoconfig`` mode. 3786 ``allnoconfig`` mode.
3787 3787
3788 An "in-tree" ``defconfig`` file can be selected via the 3788 An "in-tree" ``defconfig`` file can be selected via the
3789 :term:`KBUILD_DEFCONFIG` variable. ``KCONFIG_MODE`` does not need to 3789 :term:`KBUILD_DEFCONFIG` variable. :term:`KCONFIG_MODE` does not need to
3790 be explicitly set. 3790 be explicitly set.
3791 3791
3792 A ``defconfig`` file compatible with ``allnoconfig`` mode can be 3792 A ``defconfig`` file compatible with ``allnoconfig`` mode can be
3793 generated by copying the ``.config`` file from a working Linux kernel 3793 generated by copying the ``.config`` file from a working Linux kernel
3794 build, renaming it to ``defconfig`` and placing it into the Linux 3794 build, renaming it to ``defconfig`` and placing it into the Linux
3795 kernel ``${WORKDIR}`` through your meta-layer. ``KCONFIG_MODE`` does 3795 kernel ``${WORKDIR}`` through your meta-layer. :term:`KCONFIG_MODE` does
3796 not need to be explicitly set. 3796 not need to be explicitly set.
3797 3797
3798 A ``defconfig`` file compatible with ``alldefconfig`` mode can be 3798 A ``defconfig`` file compatible with ``alldefconfig`` mode can be
3799 generated using the 3799 generated using the
3800 :ref:`ref-tasks-savedefconfig` 3800 :ref:`ref-tasks-savedefconfig`
3801 task and placed into the Linux kernel ``${WORKDIR}`` through your 3801 task and placed into the Linux kernel ``${WORKDIR}`` through your
3802 meta-layer. Explicitely set ``KCONFIG_MODE``:: 3802 meta-layer. Explicitely set :term:`KCONFIG_MODE`::
3803 3803
3804 KCONFIG_MODE = "alldefconfig" 3804 KCONFIG_MODE = "alldefconfig"
3805 3805
@@ -3811,10 +3811,10 @@ system and gives an overview of their function and contents.
3811 3811
3812 :term:`KERNEL_ARTIFACT_NAME` 3812 :term:`KERNEL_ARTIFACT_NAME`
3813 Specifies the name of all of the build artifacts. You can change the 3813 Specifies the name of all of the build artifacts. You can change the
3814 name of the artifacts by changing the ``KERNEL_ARTIFACT_NAME`` 3814 name of the artifacts by changing the :term:`KERNEL_ARTIFACT_NAME`
3815 variable. 3815 variable.
3816 3816
3817 The value of ``KERNEL_ARTIFACT_NAME``, which is set in the 3817 The value of :term:`KERNEL_ARTIFACT_NAME`, which is set in the
3818 ``meta/classes/kernel-artifact-names.bbclass`` file, has the 3818 ``meta/classes/kernel-artifact-names.bbclass`` file, has the
3819 following default value:: 3819 following default value::
3820 3820
@@ -3891,13 +3891,13 @@ system and gives an overview of their function and contents.
3891 system, the default Board Support Packages (BSPs) 3891 system, the default Board Support Packages (BSPs)
3892 :term:`Metadata` is provided through the 3892 :term:`Metadata` is provided through the
3893 :term:`KMACHINE` and :term:`KBRANCH` 3893 :term:`KMACHINE` and :term:`KBRANCH`
3894 variables. You can use the ``KERNEL_FEATURES`` variable from within 3894 variables. You can use the :term:`KERNEL_FEATURES` variable from within
3895 the kernel recipe or kernel append file to further add metadata for 3895 the kernel recipe or kernel append file to further add metadata for
3896 all BSPs or specific BSPs. 3896 all BSPs or specific BSPs.
3897 3897
3898 The metadata you add through this variable includes config fragments 3898 The metadata you add through this variable includes config fragments
3899 and features descriptions, which usually includes patches as well as 3899 and features descriptions, which usually includes patches as well as
3900 config fragments. You typically override the ``KERNEL_FEATURES`` 3900 config fragments. You typically override the :term:`KERNEL_FEATURES`
3901 variable for a specific machine. In this way, you can provide 3901 variable for a specific machine. In this way, you can provide
3902 validated, but optional, sets of kernel configurations and features. 3902 validated, but optional, sets of kernel configurations and features.
3903 3903
@@ -3957,12 +3957,12 @@ system and gives an overview of their function and contents.
3957 3957
3958 :term:`KERNEL_IMAGE_MAXSIZE` 3958 :term:`KERNEL_IMAGE_MAXSIZE`
3959 Specifies the maximum size of the kernel image file in kilobytes. If 3959 Specifies the maximum size of the kernel image file in kilobytes. If
3960 ``KERNEL_IMAGE_MAXSIZE`` is set, the size of the kernel image file is 3960 :term:`KERNEL_IMAGE_MAXSIZE` is set, the size of the kernel image file is
3961 checked against the set value during the 3961 checked against the set value during the
3962 :ref:`ref-tasks-sizecheck` task. The task fails if 3962 :ref:`ref-tasks-sizecheck` task. The task fails if
3963 the kernel image file is larger than the setting. 3963 the kernel image file is larger than the setting.
3964 3964
3965 ``KERNEL_IMAGE_MAXSIZE`` is useful for target devices that have a 3965 :term:`KERNEL_IMAGE_MAXSIZE` is useful for target devices that have a
3966 limited amount of space in which the kernel image must be stored. 3966 limited amount of space in which the kernel image must be stored.
3967 3967
3968 By default, this variable is not set, which means the size of the 3968 By default, this variable is not set, which means the size of the
@@ -3987,7 +3987,7 @@ system and gives an overview of their function and contents.
3987 build. 3987 build.
3988 3988
3989 If you want to build an alternate kernel image type in addition to that 3989 If you want to build an alternate kernel image type in addition to that
3990 specified by ``KERNEL_IMAGETYPE``, use the :term:`KERNEL_ALT_IMAGETYPE` 3990 specified by :term:`KERNEL_IMAGETYPE`, use the :term:`KERNEL_ALT_IMAGETYPE`
3991 variable. 3991 variable.
3992 3992
3993 :term:`KERNEL_MODULE_AUTOLOAD` 3993 :term:`KERNEL_MODULE_AUTOLOAD`
@@ -3998,7 +3998,7 @@ system and gives an overview of their function and contents.
3998 This variable replaces the deprecated :term:`module_autoload` 3998 This variable replaces the deprecated :term:`module_autoload`
3999 variable. 3999 variable.
4000 4000
4001 You can use the ``KERNEL_MODULE_AUTOLOAD`` variable anywhere that it 4001 You can use the :term:`KERNEL_MODULE_AUTOLOAD` variable anywhere that it
4002 can be recognized by the kernel recipe or by an out-of-tree kernel 4002 can be recognized by the kernel recipe or by an out-of-tree kernel
4003 module recipe (e.g. a machine configuration file, a distribution 4003 module recipe (e.g. a machine configuration file, a distribution
4004 configuration file, an append file for the recipe, or the recipe 4004 configuration file, an append file for the recipe, or the recipe
@@ -4008,7 +4008,7 @@ system and gives an overview of their function and contents.
4008 4008
4009 KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3" 4009 KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"
4010 4010
4011 Including ``KERNEL_MODULE_AUTOLOAD`` causes the OpenEmbedded build 4011 Including :term:`KERNEL_MODULE_AUTOLOAD` causes the OpenEmbedded build
4012 system to populate the ``/etc/modules-load.d/modname.conf`` file with 4012 system to populate the ``/etc/modules-load.d/modname.conf`` file with
4013 the list of modules to be auto-loaded on boot. The modules appear 4013 the list of modules to be auto-loaded on boot. The modules appear
4014 one-per-line in the file. Here is an example of the most common use 4014 one-per-line in the file. Here is an example of the most common use
@@ -4037,7 +4037,7 @@ system and gives an overview of their function and contents.
4037 To help maximize compatibility with out-of-tree drivers used to build 4037 To help maximize compatibility with out-of-tree drivers used to build
4038 modules, the OpenEmbedded build system also recognizes and uses the 4038 modules, the OpenEmbedded build system also recognizes and uses the
4039 :term:`KERNEL_SRC` variable, which is identical to 4039 :term:`KERNEL_SRC` variable, which is identical to
4040 the ``KERNEL_PATH`` variable. Both variables are common variables 4040 the :term:`KERNEL_PATH` variable. Both variables are common variables
4041 used by external Makefiles to point to the kernel source directory. 4041 used by external Makefiles to point to the kernel source directory.
4042 4042
4043 :term:`KERNEL_SRC` 4043 :term:`KERNEL_SRC`
@@ -4051,7 +4051,7 @@ system and gives an overview of their function and contents.
4051 To help maximize compatibility with out-of-tree drivers used to build 4051 To help maximize compatibility with out-of-tree drivers used to build
4052 modules, the OpenEmbedded build system also recognizes and uses the 4052 modules, the OpenEmbedded build system also recognizes and uses the
4053 :term:`KERNEL_PATH` variable, which is identical 4053 :term:`KERNEL_PATH` variable, which is identical
4054 to the ``KERNEL_SRC`` variable. Both variables are common variables 4054 to the :term:`KERNEL_SRC` variable. Both variables are common variables
4055 used by external Makefiles to point to the kernel source directory. 4055 used by external Makefiles to point to the kernel source directory.
4056 4056
4057 :term:`KERNEL_VERSION` 4057 :term:`KERNEL_VERSION`
@@ -4064,9 +4064,9 @@ system and gives an overview of their function and contents.
4064 :term:`KERNELDEPMODDEPEND` 4064 :term:`KERNELDEPMODDEPEND`
4065 Specifies whether the data referenced through 4065 Specifies whether the data referenced through
4066 :term:`PKGDATA_DIR` is needed or not. 4066 :term:`PKGDATA_DIR` is needed or not.
4067 ``KERNELDEPMODDEPEND`` does not control whether or not that data 4067 :term:`KERNELDEPMODDEPEND` does not control whether or not that data
4068 exists, but simply whether or not it is used. If you do not need to 4068 exists, but simply whether or not it is used. If you do not need to
4069 use the data, set the ``KERNELDEPMODDEPEND`` variable in your 4069 use the data, set the :term:`KERNELDEPMODDEPEND` variable in your
4070 ``initramfs`` recipe. Setting the variable there when the data is not 4070 ``initramfs`` recipe. Setting the variable there when the data is not
4071 needed avoids a potential dependency loop. 4071 needed avoids a potential dependency loop.
4072 4072
@@ -4085,7 +4085,7 @@ system and gives an overview of their function and contents.
4085 OpenEmbedded build system understands as ``core2-32-intel-common`` 4085 OpenEmbedded build system understands as ``core2-32-intel-common``
4086 goes by a different name in the Linux Yocto kernel. The kernel 4086 goes by a different name in the Linux Yocto kernel. The kernel
4087 understands that machine as ``intel-core2-32``. For cases like these, 4087 understands that machine as ``intel-core2-32``. For cases like these,
4088 the ``KMACHINE`` variable maps the kernel machine name to the 4088 the :term:`KMACHINE` variable maps the kernel machine name to the
4089 OpenEmbedded build system machine name. 4089 OpenEmbedded build system machine name.
4090 4090
4091 These mappings between different names occur in the Yocto Linux 4091 These mappings between different names occur in the Yocto Linux
@@ -4100,7 +4100,7 @@ system and gives an overview of their function and contents.
4100 KBRANCH_core2-32-intel-common = "standard/base" 4100 KBRANCH_core2-32-intel-common = "standard/base"
4101 KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}" 4101 KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
4102 4102
4103 The ``KMACHINE`` statement says 4103 The :term:`KMACHINE` statement says
4104 that the kernel understands the machine name as "intel-core2-32". 4104 that the kernel understands the machine name as "intel-core2-32".
4105 However, the OpenEmbedded build system understands the machine as 4105 However, the OpenEmbedded build system understands the machine as
4106 "core2-32-intel-common". 4106 "core2-32-intel-common".
@@ -4113,7 +4113,7 @@ system and gives an overview of their function and contents.
4113 Yocto Project Linux Kernel Development Manual for more information on 4113 Yocto Project Linux Kernel Development Manual for more information on
4114 kernel types. 4114 kernel types.
4115 4115
4116 You define the ``KTYPE`` variable in the 4116 You define the :term:`KTYPE` variable in the
4117 :ref:`kernel-dev/advanced:bsp descriptions`. The 4117 :ref:`kernel-dev/advanced:bsp descriptions`. The
4118 value you use must match the value used for the 4118 value you use must match the value used for the
4119 :term:`LINUX_KERNEL_TYPE` value used by the 4119 :term:`LINUX_KERNEL_TYPE` value used by the
@@ -4166,7 +4166,7 @@ system and gives an overview of their function and contents.
4166 4166
4167 :term:`LAYERSERIES_COMPAT` 4167 :term:`LAYERSERIES_COMPAT`
4168 Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which 4168 Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which
4169 a layer is compatible. Using the ``LAYERSERIES_COMPAT`` variable 4169 a layer is compatible. Using the :term:`LAYERSERIES_COMPAT` variable
4170 allows the layer maintainer to indicate which combinations of the 4170 allows the layer maintainer to indicate which combinations of the
4171 layer and OE-Core can be expected to work. The variable gives the 4171 layer and OE-Core can be expected to work. The variable gives the
4172 system a way to detect when a layer has not been tested with new 4172 system a way to detect when a layer has not been tested with new
@@ -4183,7 +4183,7 @@ system and gives an overview of their function and contents.
4183 4183
4184 .. note:: 4184 .. note::
4185 4185
4186 Setting ``LAYERSERIES_COMPAT`` is required by the Yocto Project 4186 Setting :term:`LAYERSERIES_COMPAT` is required by the Yocto Project
4187 Compatible version 2 standard. 4187 Compatible version 2 standard.
4188 The OpenEmbedded build system produces a warning if the variable 4188 The OpenEmbedded build system produces a warning if the variable
4189 is not set for any given layer. 4189 is not set for any given layer.
@@ -4207,7 +4207,7 @@ system and gives an overview of their function and contents.
4207 to an environment variable and thus made visible to the software 4207 to an environment variable and thus made visible to the software
4208 being built during the compilation step. 4208 being built during the compilation step.
4209 4209
4210 Default initialization for ``LDFLAGS`` varies depending on what is 4210 Default initialization for :term:`LDFLAGS` varies depending on what is
4211 being built: 4211 being built:
4212 4212
4213 - :term:`TARGET_LDFLAGS` when building for the 4213 - :term:`TARGET_LDFLAGS` when building for the
@@ -4282,7 +4282,7 @@ system and gives an overview of their function and contents.
4282 LICENSE_${PN}-doc = "GFDL-1.2" 4282 LICENSE_${PN}-doc = "GFDL-1.2"
4283 4283
4284 :term:`LICENSE_CREATE_PACKAGE` 4284 :term:`LICENSE_CREATE_PACKAGE`
4285 Setting ``LICENSE_CREATE_PACKAGE`` to "1" causes the OpenEmbedded 4285 Setting :term:`LICENSE_CREATE_PACKAGE` to "1" causes the OpenEmbedded
4286 build system to create an extra package (i.e. 4286 build system to create an extra package (i.e.
4287 ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add 4287 ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add
4288 those packages to the 4288 those packages to the
@@ -4327,9 +4327,9 @@ system and gives an overview of their function and contents.
4327 4327
4328 :term:`LICENSE_PATH` 4328 :term:`LICENSE_PATH`
4329 Path to additional licenses used during the build. By default, the 4329 Path to additional licenses used during the build. By default, the
4330 OpenEmbedded build system uses ``COMMON_LICENSE_DIR`` to define the 4330 OpenEmbedded build system uses :term:`COMMON_LICENSE_DIR` to define the
4331 directory that holds common license text used during the build. The 4331 directory that holds common license text used during the build. The
4332 ``LICENSE_PATH`` variable allows you to extend that location to other 4332 :term:`LICENSE_PATH` variable allows you to extend that location to other
4333 areas that have additional licenses:: 4333 areas that have additional licenses::
4334 4334
4335 LICENSE_PATH += "path-to-additional-common-licenses" 4335 LICENSE_PATH += "path-to-additional-common-licenses"
@@ -4342,9 +4342,9 @@ system and gives an overview of their function and contents.
4342 Yocto Project Linux Kernel Development Manual for more information on 4342 Yocto Project Linux Kernel Development Manual for more information on
4343 kernel types. 4343 kernel types.
4344 4344
4345 If you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to 4345 If you do not specify a :term:`LINUX_KERNEL_TYPE`, it defaults to
4346 "standard". Together with :term:`KMACHINE`, the 4346 "standard". Together with :term:`KMACHINE`, the
4347 ``LINUX_KERNEL_TYPE`` variable defines the search arguments used by 4347 :term:`LINUX_KERNEL_TYPE` variable defines the search arguments used by
4348 the kernel tools to find the appropriate description within the 4348 the kernel tools to find the appropriate description within the
4349 kernel :term:`Metadata` with which to build out the sources 4349 kernel :term:`Metadata` with which to build out the sources
4350 and configuration. 4350 and configuration.
@@ -4358,7 +4358,7 @@ system and gives an overview of their function and contents.
4358 4358
4359 LINUX_VERSION ?= "3.4.24" 4359 LINUX_VERSION ?= "3.4.24"
4360 4360
4361 The ``LINUX_VERSION`` variable is used to define :term:`PV` 4361 The :term:`LINUX_VERSION` variable is used to define :term:`PV`
4362 for the recipe:: 4362 for the recipe::
4363 4363
4364 PV = "${LINUX_VERSION}+git${SRCPV}" 4364 PV = "${LINUX_VERSION}+git${SRCPV}"
@@ -4388,8 +4388,8 @@ system and gives an overview of their function and contents.
4388 4388
4389 :term:`MACHINE` 4389 :term:`MACHINE`
4390 Specifies the target device for which the image is built. You define 4390 Specifies the target device for which the image is built. You define
4391 ``MACHINE`` in the ``local.conf`` file found in the 4391 :term:`MACHINE` in the ``local.conf`` file found in the
4392 :term:`Build Directory`. By default, ``MACHINE`` is set to 4392 :term:`Build Directory`. By default, :term:`MACHINE` is set to
4393 "qemux86", which is an x86-based architecture machine to be emulated 4393 "qemux86", which is an x86-based architecture machine to be emulated
4394 using QEMU:: 4394 using QEMU::
4395 4395
@@ -4397,7 +4397,7 @@ system and gives an overview of their function and contents.
4397 4397
4398 The variable corresponds to a machine configuration file of the same 4398 The variable corresponds to a machine configuration file of the same
4399 name, through which machine-specific configurations are set. Thus, 4399 name, through which machine-specific configurations are set. Thus,
4400 when ``MACHINE`` is set to "qemux86", the corresponding 4400 when :term:`MACHINE` is set to "qemux86", the corresponding
4401 ``qemux86.conf`` machine configuration file can be found in 4401 ``qemux86.conf`` machine configuration file can be found in
4402 the :term:`Source Directory` in 4402 the :term:`Source Directory` in
4403 ``meta/conf/machine``. 4403 ``meta/conf/machine``.
@@ -4423,13 +4423,13 @@ system and gives an overview of their function and contents.
4423 .. note:: 4423 .. note::
4424 4424
4425 Adding additional Board Support Package (BSP) layers to your 4425 Adding additional Board Support Package (BSP) layers to your
4426 configuration adds new possible settings for ``MACHINE``. 4426 configuration adds new possible settings for :term:`MACHINE`.
4427 4427
4428 :term:`MACHINE_ARCH` 4428 :term:`MACHINE_ARCH`
4429 Specifies the name of the machine-specific architecture. This 4429 Specifies the name of the machine-specific architecture. This
4430 variable is set automatically from :term:`MACHINE` or 4430 variable is set automatically from :term:`MACHINE` or
4431 :term:`TUNE_PKGARCH`. You should not hand-edit 4431 :term:`TUNE_PKGARCH`. You should not hand-edit
4432 the ``MACHINE_ARCH`` variable. 4432 the :term:`MACHINE_ARCH` variable.
4433 4433
4434 :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS` 4434 :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
4435 A list of required machine-specific packages to install as part of 4435 A list of required machine-specific packages to install as part of
@@ -4441,7 +4441,7 @@ system and gives an overview of their function and contents.
4441 image. 4441 image.
4442 4442
4443 This variable is similar to the 4443 This variable is similar to the
4444 ``MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` variable with the exception 4444 :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS` variable with the exception
4445 that the image being built has a build dependency on the variable's 4445 that the image being built has a build dependency on the variable's
4446 list of packages. In other words, the image will not build if a file 4446 list of packages. In other words, the image will not build if a file
4447 in this list is not found. 4447 in this list is not found.
@@ -4462,7 +4462,7 @@ system and gives an overview of their function and contents.
4462 on ``packagegroup-core-boot``, including the ``core-image-minimal`` 4462 on ``packagegroup-core-boot``, including the ``core-image-minimal``
4463 image. 4463 image.
4464 4464
4465 This variable is similar to the ``MACHINE_ESSENTIAL_EXTRA_RDEPENDS`` 4465 This variable is similar to the :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
4466 variable with the exception that the image being built does not have 4466 variable with the exception that the image being built does not have
4467 a build dependency on the variable's list of packages. In other 4467 a build dependency on the variable's list of packages. In other
4468 words, the image will still build if a package in this list is not 4468 words, the image will still build if a package in this list is not
@@ -4504,7 +4504,7 @@ system and gives an overview of their function and contents.
4504 which does not include the ``core-image-minimal`` or 4504 which does not include the ``core-image-minimal`` or
4505 ``core-image-full-cmdline`` images. 4505 ``core-image-full-cmdline`` images.
4506 4506
4507 The variable is similar to the ``MACHINE_EXTRA_RRECOMMENDS`` variable 4507 The variable is similar to the :term:`MACHINE_EXTRA_RRECOMMENDS` variable
4508 with the exception that the image being built has a build dependency 4508 with the exception that the image being built has a build dependency
4509 on the variable's list of packages. In other words, the image will 4509 on the variable's list of packages. In other words, the image will
4510 not build if a file in this list is not found. 4510 not build if a file in this list is not found.
@@ -4529,7 +4529,7 @@ system and gives an overview of their function and contents.
4529 which does not include the ``core-image-minimal`` or 4529 which does not include the ``core-image-minimal`` or
4530 ``core-image-full-cmdline`` images. 4530 ``core-image-full-cmdline`` images.
4531 4531
4532 This variable is similar to the ``MACHINE_EXTRA_RDEPENDS`` variable 4532 This variable is similar to the :term:`MACHINE_EXTRA_RDEPENDS` variable
4533 with the exception that the image being built does not have a build 4533 with the exception that the image being built does not have a build
4534 dependency on the variable's list of packages. In other words, the 4534 dependency on the variable's list of packages. In other words, the
4535 image will build if a file in this list is not found. 4535 image will build if a file in this list is not found.
@@ -4558,8 +4558,8 @@ system and gives an overview of their function and contents.
4558 shipped, see the ":ref:`ref-features-machine`" section. 4558 shipped, see the ":ref:`ref-features-machine`" section.
4559 4559
4560 :term:`MACHINE_FEATURES_BACKFILL` 4560 :term:`MACHINE_FEATURES_BACKFILL`
4561 Features to be added to ``MACHINE_FEATURES`` if not also present in 4561 Features to be added to :term:`MACHINE_FEATURES` if not also present in
4562 ``MACHINE_FEATURES_BACKFILL_CONSIDERED``. 4562 :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`.
4563 4563
4564 This variable is set in the ``meta/conf/bitbake.conf`` file. It is 4564 This variable is set in the ``meta/conf/bitbake.conf`` file. It is
4565 not intended to be user-configurable. It is best to just reference 4565 not intended to be user-configurable. It is best to just reference
@@ -4568,8 +4568,8 @@ system and gives an overview of their function and contents.
4568 section for more information. 4568 section for more information.
4569 4569
4570 :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED` 4570 :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
4571 Features from ``MACHINE_FEATURES_BACKFILL`` that should not be 4571 Features from :term:`MACHINE_FEATURES_BACKFILL` that should not be
4572 backfilled (i.e. added to ``MACHINE_FEATURES``) during the build. See 4572 backfilled (i.e. added to :term:`MACHINE_FEATURES`) during the build. See
4573 the ":ref:`ref-features-backfill`" section for more information. 4573 the ":ref:`ref-features-backfill`" section for more information.
4574 4574
4575 :term:`MACHINEOVERRIDES` 4575 :term:`MACHINEOVERRIDES`
@@ -4577,11 +4577,11 @@ system and gives an overview of their function and contents.
4577 machine. By default, this list includes the value of 4577 machine. By default, this list includes the value of
4578 :term:`MACHINE`. 4578 :term:`MACHINE`.
4579 4579
4580 You can extend ``MACHINEOVERRIDES`` to add extra overrides that 4580 You can extend :term:`MACHINEOVERRIDES` to add extra overrides that
4581 should apply to a machine. For example, all machines emulated in QEMU 4581 should apply to a machine. For example, all machines emulated in QEMU
4582 (e.g. ``qemuarm``, ``qemux86``, and so forth) include a file named 4582 (e.g. ``qemuarm``, ``qemux86``, and so forth) include a file named
4583 ``meta/conf/machine/include/qemu.inc`` that prepends the following 4583 ``meta/conf/machine/include/qemu.inc`` that prepends the following
4584 override to ``MACHINEOVERRIDES``:: 4584 override to :term:`MACHINEOVERRIDES`::
4585 4585
4586 MACHINEOVERRIDES =. "qemuall:" 4586 MACHINEOVERRIDES =. "qemuall:"
4587 4587
@@ -4595,7 +4595,7 @@ system and gives an overview of their function and contents.
4595 " 4595 "
4596 4596
4597 The underlying mechanism behind 4597 The underlying mechanism behind
4598 ``MACHINEOVERRIDES`` is simply that it is included in the default 4598 :term:`MACHINEOVERRIDES` is simply that it is included in the default
4599 value of :term:`OVERRIDES`. 4599 value of :term:`OVERRIDES`.
4600 4600
4601 :term:`MAINTAINER` 4601 :term:`MAINTAINER`
@@ -4615,10 +4615,10 @@ system and gives an overview of their function and contents.
4615 first tries the local download directory. If that location fails, the 4615 first tries the local download directory. If that location fails, the
4616 build system tries locations defined by 4616 build system tries locations defined by
4617 :term:`PREMIRRORS`, the upstream source, and then 4617 :term:`PREMIRRORS`, the upstream source, and then
4618 locations specified by ``MIRRORS`` in that order. 4618 locations specified by :term:`MIRRORS` in that order.
4619 4619
4620 Assuming your distribution (:term:`DISTRO`) is "poky", 4620 Assuming your distribution (:term:`DISTRO`) is "poky",
4621 the default value for ``MIRRORS`` is defined in the 4621 the default value for :term:`MIRRORS` is defined in the
4622 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository. 4622 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
4623 4623
4624 :term:`MLPREFIX` 4624 :term:`MLPREFIX`
@@ -4626,16 +4626,16 @@ system and gives an overview of their function and contents.
4626 special version of a recipe or package (i.e. a Multilib version). The 4626 special version of a recipe or package (i.e. a Multilib version). The
4627 variable is used in places where the prefix needs to be added to or 4627 variable is used in places where the prefix needs to be added to or
4628 removed from a the name (e.g. the :term:`BPN` variable). 4628 removed from a the name (e.g. the :term:`BPN` variable).
4629 ``MLPREFIX`` gets set when a prefix has been added to ``PN``. 4629 :term:`MLPREFIX` gets set when a prefix has been added to :term:`PN`.
4630 4630
4631 .. note:: 4631 .. note::
4632 4632
4633 The "ML" in ``MLPREFIX`` stands for "MultiLib". This representation is 4633 The "ML" in :term:`MLPREFIX` stands for "MultiLib". This representation is
4634 historical and comes from a time when ``nativesdk`` was a suffix 4634 historical and comes from a time when ``nativesdk`` was a suffix
4635 rather than a prefix on the recipe name. When ``nativesdk`` was turned 4635 rather than a prefix on the recipe name. When ``nativesdk`` was turned
4636 into a prefix, it made sense to set ``MLPREFIX`` for it as well. 4636 into a prefix, it made sense to set :term:`MLPREFIX` for it as well.
4637 4637
4638 To help understand when ``MLPREFIX`` might be needed, consider when 4638 To help understand when :term:`MLPREFIX` might be needed, consider when
4639 :term:`BBCLASSEXTEND` is used to provide a 4639 :term:`BBCLASSEXTEND` is used to provide a
4640 ``nativesdk`` version of a recipe in addition to the target version. 4640 ``nativesdk`` version of a recipe in addition to the target version.
4641 If that recipe declares build-time dependencies on tasks in other 4641 If that recipe declares build-time dependencies on tasks in other
@@ -4652,9 +4652,9 @@ system and gives an overview of their function and contents.
4652 do_foo[depends] += "${MLPREFIX}recipe:do_foo" 4652 do_foo[depends] += "${MLPREFIX}recipe:do_foo"
4653 4653
4654 :term:`module_autoload` 4654 :term:`module_autoload`
4655 This variable has been replaced by the ``KERNEL_MODULE_AUTOLOAD`` 4655 This variable has been replaced by the :term:`KERNEL_MODULE_AUTOLOAD`
4656 variable. You should replace all occurrences of ``module_autoload`` 4656 variable. You should replace all occurrences of ``module_autoload``
4657 with additions to ``KERNEL_MODULE_AUTOLOAD``, for example:: 4657 with additions to :term:`KERNEL_MODULE_AUTOLOAD`, for example::
4658 4658
4659 module_autoload_rfcomm = "rfcomm" 4659 module_autoload_rfcomm = "rfcomm"
4660 4660
@@ -4738,7 +4738,7 @@ system and gives an overview of their function and contents.
4738 4738
4739 Some classes (e.g. 4739 Some classes (e.g.
4740 :ref:`cross-canadian <ref-classes-cross-canadian>`) modify the 4740 :ref:`cross-canadian <ref-classes-cross-canadian>`) modify the
4741 ``MULTIMACH_TARGET_SYS`` value. 4741 :term:`MULTIMACH_TARGET_SYS` value.
4742 4742
4743 See the :term:`STAMP` variable for an example. See the 4743 See the :term:`STAMP` variable for an example. See the
4744 :term:`STAGING_DIR_TARGET` variable for more information. 4744 :term:`STAGING_DIR_TARGET` variable for more information.
@@ -4767,10 +4767,10 @@ system and gives an overview of their function and contents.
4767 licenses that are not in any way common. Also, new licenses are added 4767 licenses that are not in any way common. Also, new licenses are added
4768 occasionally to avoid introducing a lot of common license files, 4768 occasionally to avoid introducing a lot of common license files,
4769 which are only applicable to a specific package. 4769 which are only applicable to a specific package.
4770 ``NO_GENERIC_LICENSE`` is used to allow copying a license that does 4770 :term:`NO_GENERIC_LICENSE` is used to allow copying a license that does
4771 not exist in common licenses. 4771 not exist in common licenses.
4772 4772
4773 The following example shows how to add ``NO_GENERIC_LICENSE`` to a 4773 The following example shows how to add :term:`NO_GENERIC_LICENSE` to a
4774 recipe:: 4774 recipe::
4775 4775
4776 NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source" 4776 NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source"
@@ -4785,7 +4785,7 @@ system and gives an overview of their function and contents.
4785 Prevents installation of all "recommended-only" packages. 4785 Prevents installation of all "recommended-only" packages.
4786 Recommended-only packages are packages installed only through the 4786 Recommended-only packages are packages installed only through the
4787 :term:`RRECOMMENDS` variable). Setting the 4787 :term:`RRECOMMENDS` variable). Setting the
4788 ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on:: 4788 :term:`NO_RECOMMENDATIONS` variable to "1" turns this feature on::
4789 4789
4790 NO_RECOMMENDATIONS = "1" 4790 NO_RECOMMENDATIONS = "1"
4791 4791
@@ -4817,7 +4817,7 @@ system and gives an overview of their function and contents.
4817 :term:`NOAUTOPACKAGEDEBUG` 4817 :term:`NOAUTOPACKAGEDEBUG`
4818 Disables auto package from splitting ``.debug`` files. If a recipe 4818 Disables auto package from splitting ``.debug`` files. If a recipe
4819 requires ``FILES_${PN}-dbg`` to be set manually, the 4819 requires ``FILES_${PN}-dbg`` to be set manually, the
4820 ``NOAUTOPACKAGEDEBUG`` can be defined allowing you to define the 4820 :term:`NOAUTOPACKAGEDEBUG` can be defined allowing you to define the
4821 content of the debug package. For example:: 4821 content of the debug package. For example::
4822 4822
4823 NOAUTOPACKAGEDEBUG = "1" 4823 NOAUTOPACKAGEDEBUG = "1"
@@ -4867,7 +4867,7 @@ system and gives an overview of their function and contents.
4867 value is "oe-init-build-env". 4867 value is "oe-init-build-env".
4868 4868
4869 If you use a custom script to set up your build environment, set the 4869 If you use a custom script to set up your build environment, set the
4870 ``OE_INIT_ENV_SCRIPT`` variable to its name. 4870 :term:`OE_INIT_ENV_SCRIPT` variable to its name.
4871 4871
4872 :term:`OE_TERMINAL` 4872 :term:`OE_TERMINAL`
4873 Controls how the OpenEmbedded build system spawns interactive 4873 Controls how the OpenEmbedded build system spawns interactive
@@ -4890,7 +4890,7 @@ system and gives an overview of their function and contents.
4890 The directory from which the top-level build environment setup script 4890 The directory from which the top-level build environment setup script
4891 is sourced. The Yocto Project provides a top-level build environment 4891 is sourced. The Yocto Project provides a top-level build environment
4892 setup script: :ref:`structure-core-script`. When you run this 4892 setup script: :ref:`structure-core-script`. When you run this
4893 script, the ``OEROOT`` variable resolves to the directory that 4893 script, the :term:`OEROOT` variable resolves to the directory that
4894 contains the script. 4894 contains the script.
4895 4895
4896 For additional information on how this variable is used, see the 4896 For additional information on how this variable is used, see the
@@ -4910,12 +4910,12 @@ system and gives an overview of their function and contents.
4910 A colon-separated list of overrides that currently apply. Overrides 4910 A colon-separated list of overrides that currently apply. Overrides
4911 are a BitBake mechanism that allows variables to be selectively 4911 are a BitBake mechanism that allows variables to be selectively
4912 overridden at the end of parsing. The set of overrides in 4912 overridden at the end of parsing. The set of overrides in
4913 ``OVERRIDES`` represents the "state" during building, which includes 4913 :term:`OVERRIDES` represents the "state" during building, which includes
4914 the current recipe being built, the machine for which it is being 4914 the current recipe being built, the machine for which it is being
4915 built, and so forth. 4915 built, and so forth.
4916 4916
4917 As an example, if the string "an-override" appears as an element in 4917 As an example, if the string "an-override" appears as an element in
4918 the colon-separated list in ``OVERRIDES``, then the following 4918 the colon-separated list in :term:`OVERRIDES`, then the following
4919 assignment will override ``FOO`` with the value "overridden" at the 4919 assignment will override ``FOO`` with the value "overridden" at the
4920 end of parsing:: 4920 end of parsing::
4921 4921
@@ -4926,7 +4926,7 @@ system and gives an overview of their function and contents.
4926 section in the BitBake User Manual for more information on the 4926 section in the BitBake User Manual for more information on the
4927 overrides mechanism. 4927 overrides mechanism.
4928 4928
4929 The default value of ``OVERRIDES`` includes the values of the 4929 The default value of :term:`OVERRIDES` includes the values of the
4930 :term:`CLASSOVERRIDE`, 4930 :term:`CLASSOVERRIDE`,
4931 :term:`MACHINEOVERRIDES`, and 4931 :term:`MACHINEOVERRIDES`, and
4932 :term:`DISTROOVERRIDES` variables. Another 4932 :term:`DISTROOVERRIDES` variables. Another
@@ -4938,13 +4938,13 @@ system and gives an overview of their function and contents.
4938 4938
4939 .. note:: 4939 .. note::
4940 4940
4941 An easy way to see what overrides apply is to search for ``OVERRIDES`` 4941 An easy way to see what overrides apply is to search for :term:`OVERRIDES`
4942 in the output of the ``bitbake -e`` command. See the 4942 in the output of the ``bitbake -e`` command. See the
4943 ":ref:`dev-manual/common-tasks:viewing variable values`" section in the Yocto 4943 ":ref:`dev-manual/common-tasks:viewing variable values`" section in the Yocto
4944 Project Development Tasks Manual for more information. 4944 Project Development Tasks Manual for more information.
4945 4945
4946 :term:`P` 4946 :term:`P`
4947 The recipe name and version. ``P`` is comprised of the following:: 4947 The recipe name and version. :term:`P` is comprised of the following::
4948 4948
4949 ${PN}-${PV} 4949 ${PN}-${PV}
4950 4950
@@ -4979,7 +4979,7 @@ system and gives an overview of their function and contents.
4979 4979
4980 However, if your recipe's output packages are built specific to the 4980 However, if your recipe's output packages are built specific to the
4981 target machine rather than generally for the architecture of the 4981 target machine rather than generally for the architecture of the
4982 machine, you should set ``PACKAGE_ARCH`` to the value of 4982 machine, you should set :term:`PACKAGE_ARCH` to the value of
4983 :term:`MACHINE_ARCH` in the recipe as follows:: 4983 :term:`MACHINE_ARCH` in the recipe as follows::
4984 4984
4985 PACKAGE_ARCH = "${MACHINE_ARCH}" 4985 PACKAGE_ARCH = "${MACHINE_ARCH}"
@@ -4988,11 +4988,11 @@ system and gives an overview of their function and contents.
4988 Specifies a list of architectures compatible with the target machine. 4988 Specifies a list of architectures compatible with the target machine.
4989 This variable is set automatically and should not normally be 4989 This variable is set automatically and should not normally be
4990 hand-edited. Entries are separated using spaces and listed in order 4990 hand-edited. Entries are separated using spaces and listed in order
4991 of priority. The default value for ``PACKAGE_ARCHS`` is "all any 4991 of priority. The default value for :term:`PACKAGE_ARCHS` is "all any
4992 noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}". 4992 noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}".
4993 4993
4994 :term:`PACKAGE_BEFORE_PN` 4994 :term:`PACKAGE_BEFORE_PN`
4995 Enables easily adding packages to ``PACKAGES`` before ``${PN}`` so 4995 Enables easily adding packages to :term:`PACKAGES` before ``${PN}`` so
4996 that those added packages can pick up files that would normally be 4996 that those added packages can pick up files that would normally be
4997 included in the default package. 4997 included in the default package.
4998 4998
@@ -5032,7 +5032,7 @@ system and gives an overview of their function and contents.
5032 creating ``*-dbg`` packages to be used with the GNU Project Debugger 5032 creating ``*-dbg`` packages to be used with the GNU Project Debugger
5033 (GDB). 5033 (GDB).
5034 5034
5035 With the ``PACKAGE_DEBUG_SPLIT_STYLE`` variable, you can control 5035 With the :term:`PACKAGE_DEBUG_SPLIT_STYLE` variable, you can control
5036 where debug information, which can include or exclude source files, 5036 where debug information, which can include or exclude source files,
5037 is stored: 5037 is stored:
5038 5038
@@ -5069,7 +5069,7 @@ system and gives an overview of their function and contents.
5069 are using :term:`IMAGE_FEATURES` to install 5069 are using :term:`IMAGE_FEATURES` to install
5070 ``dev-pkgs``, you might not want to install all packages from a 5070 ``dev-pkgs``, you might not want to install all packages from a
5071 particular multilib. If you find yourself in this situation, you can 5071 particular multilib. If you find yourself in this situation, you can
5072 use the ``PACKAGE_EXCLUDE_COMPLEMENTARY`` variable to specify regular 5072 use the :term:`PACKAGE_EXCLUDE_COMPLEMENTARY` variable to specify regular
5073 expressions to match the packages you want to exclude. 5073 expressions to match the packages you want to exclude.
5074 5074
5075 :term:`PACKAGE_EXCLUDE` 5075 :term:`PACKAGE_EXCLUDE`
@@ -5107,7 +5107,7 @@ system and gives an overview of their function and contents.
5107 :term:`PACKAGE_FEED_ARCHS` 5107 :term:`PACKAGE_FEED_ARCHS`
5108 Optionally specifies the package architectures used as part of the 5108 Optionally specifies the package architectures used as part of the
5109 package feed URIs during the build. When used, the 5109 package feed URIs during the build. When used, the
5110 ``PACKAGE_FEED_ARCHS`` variable is appended to the final package feed 5110 :term:`PACKAGE_FEED_ARCHS` variable is appended to the final package feed
5111 URI, which is constructed using the 5111 URI, which is constructed using the
5112 :term:`PACKAGE_FEED_URIS` and 5112 :term:`PACKAGE_FEED_URIS` and
5113 :term:`PACKAGE_FEED_BASE_PATHS` 5113 :term:`PACKAGE_FEED_BASE_PATHS`
@@ -5115,15 +5115,15 @@ system and gives an overview of their function and contents.
5115 5115
5116 .. note:: 5116 .. note::
5117 5117
5118 You can use the ``PACKAGE_FEED_ARCHS`` 5118 You can use the :term:`PACKAGE_FEED_ARCHS`
5119 variable to whitelist specific package architectures. If you do 5119 variable to whitelist specific package architectures. If you do
5120 not need to whitelist specific architectures, which is a common 5120 not need to whitelist specific architectures, which is a common
5121 case, you can omit this variable. Omitting the variable results in 5121 case, you can omit this variable. Omitting the variable results in
5122 all available architectures for the current machine being included 5122 all available architectures for the current machine being included
5123 into remote package feeds. 5123 into remote package feeds.
5124 5124
5125 Consider the following example where the ``PACKAGE_FEED_URIS``, 5125 Consider the following example where the :term:`PACKAGE_FEED_URIS`,
5126 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are 5126 :term:`PACKAGE_FEED_BASE_PATHS`, and :term:`PACKAGE_FEED_ARCHS` variables are
5127 defined in your ``local.conf`` file:: 5127 defined in your ``local.conf`` file::
5128 5128
5129 PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ 5129 PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
@@ -5146,13 +5146,13 @@ system and gives an overview of their function and contents.
5146 5146
5147 :term:`PACKAGE_FEED_BASE_PATHS` 5147 :term:`PACKAGE_FEED_BASE_PATHS`
5148 Specifies the base path used when constructing package feed URIs. The 5148 Specifies the base path used when constructing package feed URIs. The
5149 ``PACKAGE_FEED_BASE_PATHS`` variable makes up the middle portion of a 5149 :term:`PACKAGE_FEED_BASE_PATHS` variable makes up the middle portion of a
5150 package feed URI used by the OpenEmbedded build system. The base path 5150 package feed URI used by the OpenEmbedded build system. The base path
5151 lies between the :term:`PACKAGE_FEED_URIS` 5151 lies between the :term:`PACKAGE_FEED_URIS`
5152 and :term:`PACKAGE_FEED_ARCHS` variables. 5152 and :term:`PACKAGE_FEED_ARCHS` variables.
5153 5153
5154 Consider the following example where the ``PACKAGE_FEED_URIS``, 5154 Consider the following example where the :term:`PACKAGE_FEED_URIS`,
5155 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are 5155 :term:`PACKAGE_FEED_BASE_PATHS`, and :term:`PACKAGE_FEED_ARCHS` variables are
5156 defined in your ``local.conf`` file:: 5156 defined in your ``local.conf`` file::
5157 5157
5158 PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ 5158 PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
@@ -5176,12 +5176,12 @@ system and gives an overview of their function and contents.
5176 :term:`PACKAGE_FEED_URIS` 5176 :term:`PACKAGE_FEED_URIS`
5177 Specifies the front portion of the package feed URI used by the 5177 Specifies the front portion of the package feed URI used by the
5178 OpenEmbedded build system. Each final package feed URI is comprised 5178 OpenEmbedded build system. Each final package feed URI is comprised
5179 of ``PACKAGE_FEED_URIS``, 5179 of :term:`PACKAGE_FEED_URIS`,
5180 :term:`PACKAGE_FEED_BASE_PATHS`, and 5180 :term:`PACKAGE_FEED_BASE_PATHS`, and
5181 :term:`PACKAGE_FEED_ARCHS` variables. 5181 :term:`PACKAGE_FEED_ARCHS` variables.
5182 5182
5183 Consider the following example where the ``PACKAGE_FEED_URIS``, 5183 Consider the following example where the :term:`PACKAGE_FEED_URIS`,
5184 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are 5184 :term:`PACKAGE_FEED_BASE_PATHS`, and :term:`PACKAGE_FEED_ARCHS` variables are
5185 defined in your ``local.conf`` file:: 5185 defined in your ``local.conf`` file::
5186 5186
5187 PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ 5187 PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
@@ -5207,7 +5207,7 @@ system and gives an overview of their function and contents.
5207 installation into the image. 5207 installation into the image.
5208 5208
5209 Because the package manager controls actual installation of all 5209 Because the package manager controls actual installation of all
5210 packages, the list of packages passed using ``PACKAGE_INSTALL`` is 5210 packages, the list of packages passed using :term:`PACKAGE_INSTALL` is
5211 not the final list of packages that are actually installed. This 5211 not the final list of packages that are actually installed. This
5212 variable is internal to the image construction code. Consequently, in 5212 variable is internal to the image construction code. Consequently, in
5213 general, you should use the 5213 general, you should use the
@@ -5215,7 +5215,7 @@ system and gives an overview of their function and contents.
5215 packages for installation. The exception to this is when working with 5215 packages for installation. The exception to this is when working with
5216 the :ref:`core-image-minimal-initramfs <ref-manual/images:images>` 5216 the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
5217 image. When working with an initial RAM filesystem (initramfs) image, 5217 image. When working with an initial RAM filesystem (initramfs) image,
5218 use the ``PACKAGE_INSTALL`` variable. For information on creating an 5218 use the :term:`PACKAGE_INSTALL` variable. For information on creating an
5219 initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section 5219 initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
5220 in the Yocto Project Development Tasks Manual. 5220 in the Yocto Project Development Tasks Manual.
5221 5221
@@ -5236,7 +5236,7 @@ system and gives an overview of their function and contents.
5236 post-installation or pre-installation script can execute at rootfs 5236 post-installation or pre-installation script can execute at rootfs
5237 creation time rather than on the target but depends on a native tool 5237 creation time rather than on the target but depends on a native tool
5238 in order to execute, you need to list the tools in 5238 in order to execute, you need to list the tools in
5239 ``PACKAGE_WRITE_DEPS``. 5239 :term:`PACKAGE_WRITE_DEPS`.
5240 5240
5241 For information on running post-installation scripts, see the 5241 For information on running post-installation scripts, see the
5242 ":ref:`dev-manual/common-tasks:post-installation scripts`" 5242 ":ref:`dev-manual/common-tasks:post-installation scripts`"
@@ -5244,7 +5244,7 @@ system and gives an overview of their function and contents.
5244 5244
5245 :term:`PACKAGECONFIG` 5245 :term:`PACKAGECONFIG`
5246 This variable provides a means of enabling or disabling features of a 5246 This variable provides a means of enabling or disabling features of a
5247 recipe on a per-recipe basis. ``PACKAGECONFIG`` blocks are defined in 5247 recipe on a per-recipe basis. :term:`PACKAGECONFIG` blocks are defined in
5248 recipes when you specify features and then arguments that define 5248 recipes when you specify features and then arguments that define
5249 feature behaviors. Here is the basic block structure (broken over 5249 feature behaviors. Here is the basic block structure (broken over
5250 multiple lines for readability):: 5250 multiple lines for readability)::
@@ -5272,8 +5272,8 @@ system and gives an overview of their function and contents.
5272 :term:`PACKAGECONFIG_CONFARGS`) if 5272 :term:`PACKAGECONFIG_CONFARGS`) if
5273 the feature is enabled. 5273 the feature is enabled.
5274 5274
5275 2. Extra arguments that should be added to ``EXTRA_OECONF`` or 5275 2. Extra arguments that should be added to :term:`EXTRA_OECONF` or
5276 ``PACKAGECONFIG_CONFARGS`` if the feature is disabled. 5276 :term:`PACKAGECONFIG_CONFARGS` if the feature is disabled.
5277 5277
5278 3. Additional build dependencies (:term:`DEPENDS`) 5278 3. Additional build dependencies (:term:`DEPENDS`)
5279 that should be added if the feature is enabled. 5279 that should be added if the feature is enabled.
@@ -5285,10 +5285,10 @@ system and gives an overview of their function and contents.
5285 (:term:`RRECOMMENDS`) that should be added if 5285 (:term:`RRECOMMENDS`) that should be added if
5286 the feature is enabled. 5286 the feature is enabled.
5287 5287
5288 6. Any conflicting (that is, mutually exclusive) ``PACKAGECONFIG`` 5288 6. Any conflicting (that is, mutually exclusive) :term:`PACKAGECONFIG`
5289 settings for this feature. 5289 settings for this feature.
5290 5290
5291 Consider the following ``PACKAGECONFIG`` block taken from the 5291 Consider the following :term:`PACKAGECONFIG` block taken from the
5292 ``librsvg`` recipe. In this example the feature is ``gtk``, which has 5292 ``librsvg`` recipe. In this example the feature is ``gtk``, which has
5293 three arguments that determine the feature's behavior. 5293 three arguments that determine the feature's behavior.
5294 :: 5294 ::
@@ -5298,21 +5298,21 @@ system and gives an overview of their function and contents.
5298 The 5298 The
5299 ``--with-gtk3`` and ``gtk+3`` arguments apply only if the feature is 5299 ``--with-gtk3`` and ``gtk+3`` arguments apply only if the feature is
5300 enabled. In this case, ``--with-gtk3`` is added to the configure 5300 enabled. In this case, ``--with-gtk3`` is added to the configure
5301 script argument list and ``gtk+3`` is added to ``DEPENDS``. On the 5301 script argument list and ``gtk+3`` is added to :term:`DEPENDS`. On the
5302 other hand, if the feature is disabled say through a ``.bbappend`` 5302 other hand, if the feature is disabled say through a ``.bbappend``
5303 file in another layer, then the second argument ``--without-gtk3`` is 5303 file in another layer, then the second argument ``--without-gtk3`` is
5304 added to the configure script instead. 5304 added to the configure script instead.
5305 5305
5306 The basic ``PACKAGECONFIG`` structure previously described holds true 5306 The basic :term:`PACKAGECONFIG` structure previously described holds true
5307 regardless of whether you are creating a block or changing a block. 5307 regardless of whether you are creating a block or changing a block.
5308 When creating a block, use the structure inside your recipe. 5308 When creating a block, use the structure inside your recipe.
5309 5309
5310 If you want to change an existing ``PACKAGECONFIG`` block, you can do 5310 If you want to change an existing :term:`PACKAGECONFIG` block, you can do
5311 so one of two ways: 5311 so one of two ways:
5312 5312
5313 - *Append file:* Create an append file named 5313 - *Append file:* Create an append file named
5314 recipename\ ``.bbappend`` in your layer and override the value of 5314 recipename\ ``.bbappend`` in your layer and override the value of
5315 ``PACKAGECONFIG``. You can either completely override the 5315 :term:`PACKAGECONFIG`. You can either completely override the
5316 variable:: 5316 variable::
5317 5317
5318 PACKAGECONFIG = "f4 f5" 5318 PACKAGECONFIG = "f4 f5"
@@ -5337,16 +5337,16 @@ system and gives an overview of their function and contents.
5337 :term:`PACKAGECONFIG` setting. 5337 :term:`PACKAGECONFIG` setting.
5338 5338
5339 Classes such as :ref:`autotools <ref-classes-autotools>` and 5339 Classes such as :ref:`autotools <ref-classes-autotools>` and
5340 :ref:`cmake <ref-classes-cmake>` use ``PACKAGECONFIG_CONFARGS`` to 5340 :ref:`cmake <ref-classes-cmake>` use :term:`PACKAGECONFIG_CONFARGS` to
5341 pass ``PACKAGECONFIG`` options to ``configure`` and ``cmake``, 5341 pass :term:`PACKAGECONFIG` options to ``configure`` and ``cmake``,
5342 respectively. If you are using ``PACKAGECONFIG`` but not a class that 5342 respectively. If you are using :term:`PACKAGECONFIG` but not a class that
5343 handles the ``do_configure`` task, then you need to use 5343 handles the ``do_configure`` task, then you need to use
5344 ``PACKAGECONFIG_CONFARGS`` appropriately. 5344 :term:`PACKAGECONFIG_CONFARGS` appropriately.
5345 5345
5346 :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY` 5346 :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY`
5347 For recipes inheriting the 5347 For recipes inheriting the
5348 :ref:`packagegroup <ref-classes-packagegroup>` class, setting 5348 :ref:`packagegroup <ref-classes-packagegroup>` class, setting
5349 ``PACKAGEGROUP_DISABLE_COMPLEMENTARY`` to "1" specifies that the 5349 :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY` to "1" specifies that the
5350 normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth) 5350 normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth)
5351 should not be automatically created by the ``packagegroup`` recipe, 5351 should not be automatically created by the ``packagegroup`` recipe,
5352 which is the default behavior. 5352 which is the default behavior.
@@ -5358,10 +5358,10 @@ system and gives an overview of their function and contents.
5358 ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} 5358 ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
5359 5359
5360 During packaging, the :ref:`ref-tasks-package` task 5360 During packaging, the :ref:`ref-tasks-package` task
5361 goes through ``PACKAGES`` and uses the :term:`FILES` 5361 goes through :term:`PACKAGES` and uses the :term:`FILES`
5362 variable corresponding to each package to assign files to the 5362 variable corresponding to each package to assign files to the
5363 package. If a file matches the ``FILES`` variable for more than one 5363 package. If a file matches the :term:`FILES` variable for more than one
5364 package in ``PACKAGES``, it will be assigned to the earliest 5364 package in :term:`PACKAGES`, it will be assigned to the earliest
5365 (leftmost) package. 5365 (leftmost) package.
5366 5366
5367 Packages in the variable's list that are empty (i.e. where none of 5367 Packages in the variable's list that are empty (i.e. where none of
@@ -5373,10 +5373,10 @@ system and gives an overview of their function and contents.
5373 :term:`PACKAGES_DYNAMIC` 5373 :term:`PACKAGES_DYNAMIC`
5374 A promise that your recipe satisfies runtime dependencies for 5374 A promise that your recipe satisfies runtime dependencies for
5375 optional modules that are found in other recipes. 5375 optional modules that are found in other recipes.
5376 ``PACKAGES_DYNAMIC`` does not actually satisfy the dependencies, it 5376 :term:`PACKAGES_DYNAMIC` does not actually satisfy the dependencies, it
5377 only states that they should be satisfied. For example, if a hard, 5377 only states that they should be satisfied. For example, if a hard,
5378 runtime dependency (:term:`RDEPENDS`) of another 5378 runtime dependency (:term:`RDEPENDS`) of another
5379 package is satisfied at build time through the ``PACKAGES_DYNAMIC`` 5379 package is satisfied at build time through the :term:`PACKAGES_DYNAMIC`
5380 variable, but a package with the module name is never actually 5380 variable, but a package with the module name is never actually
5381 produced, then the other package will be broken. Thus, if you attempt 5381 produced, then the other package will be broken. Thus, if you attempt
5382 to include that package in an image, you will get a dependency 5382 to include that package in an image, you will get a dependency
@@ -5386,9 +5386,9 @@ system and gives an overview of their function and contents.
5386 Typically, if there is a chance that such a situation can occur and 5386 Typically, if there is a chance that such a situation can occur and
5387 the package that is not created is valid without the dependency being 5387 the package that is not created is valid without the dependency being
5388 satisfied, then you should use :term:`RRECOMMENDS` 5388 satisfied, then you should use :term:`RRECOMMENDS`
5389 (a soft runtime dependency) instead of ``RDEPENDS``. 5389 (a soft runtime dependency) instead of :term:`RDEPENDS`.
5390 5390
5391 For an example of how to use the ``PACKAGES_DYNAMIC`` variable when 5391 For an example of how to use the :term:`PACKAGES_DYNAMIC` variable when
5392 you are splitting packages, see the 5392 you are splitting packages, see the
5393 ":ref:`dev-manual/common-tasks:handling optional module packaging`" 5393 ":ref:`dev-manual/common-tasks:handling optional module packaging`"
5394 section in the Yocto Project Development Tasks Manual. 5394 section in the Yocto Project Development Tasks Manual.
@@ -5412,7 +5412,7 @@ system and gives an overview of their function and contents.
5412 5412
5413 .. note:: 5413 .. note::
5414 5414
5415 In order for ``PARALLEL_MAKE`` to be effective, ``make`` must be 5415 In order for :term:`PARALLEL_MAKE` to be effective, ``make`` must be
5416 called with ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy way to ensure 5416 called with ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy way to ensure
5417 this is to use the ``oe_runmake`` function. 5417 this is to use the ``oe_runmake`` function.
5418 5418
@@ -5423,7 +5423,7 @@ system and gives an overview of their function and contents.
5423 5423
5424 If the software being built experiences dependency issues during 5424 If the software being built experiences dependency issues during
5425 the ``do_compile`` task that result in race conditions, you can clear 5425 the ``do_compile`` task that result in race conditions, you can clear
5426 the ``PARALLEL_MAKE`` variable within the recipe as a workaround. For 5426 the :term:`PARALLEL_MAKE` variable within the recipe as a workaround. For
5427 information on addressing race conditions, see the 5427 information on addressing race conditions, see the
5428 ":ref:`dev-manual/common-tasks:debugging parallel make races`" 5428 ":ref:`dev-manual/common-tasks:debugging parallel make races`"
5429 section in the Yocto Project Development Tasks Manual. 5429 section in the Yocto Project Development Tasks Manual.
@@ -5431,7 +5431,7 @@ system and gives an overview of their function and contents.
5431 For single socket systems (i.e. one CPU), you should not have to 5431 For single socket systems (i.e. one CPU), you should not have to
5432 override this variable to gain optimal parallelism during builds. 5432 override this variable to gain optimal parallelism during builds.
5433 However, if you have very large systems that employ multiple physical 5433 However, if you have very large systems that employ multiple physical
5434 CPUs, you might want to make sure the ``PARALLEL_MAKE`` variable is 5434 CPUs, you might want to make sure the :term:`PARALLEL_MAKE` variable is
5435 not set higher than "-j 20". 5435 not set higher than "-j 20".
5436 5436
5437 For more information on speeding up builds, see the 5437 For more information on speeding up builds, see the
@@ -5446,14 +5446,14 @@ system and gives an overview of their function and contents.
5446 5446
5447 .. note:: 5447 .. note::
5448 5448
5449 In order for ``PARALLEL_MAKEINST`` to be effective, ``make`` must 5449 In order for :term:`PARALLEL_MAKEINST` to be effective, ``make`` must
5450 be called with 5450 be called with
5451 ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy 5451 ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy
5452 way to ensure this is to use the ``oe_runmake`` function. 5452 way to ensure this is to use the ``oe_runmake`` function.
5453 5453
5454 If the software being built experiences dependency issues during 5454 If the software being built experiences dependency issues during
5455 the ``do_install`` task that result in race conditions, you can 5455 the ``do_install`` task that result in race conditions, you can
5456 clear the ``PARALLEL_MAKEINST`` variable within the recipe as a 5456 clear the :term:`PARALLEL_MAKEINST` variable within the recipe as a
5457 workaround. For information on addressing race conditions, see the 5457 workaround. For information on addressing race conditions, see the
5458 ":ref:`dev-manual/common-tasks:debugging parallel make races`" 5458 ":ref:`dev-manual/common-tasks:debugging parallel make races`"
5459 section in the Yocto Project Development Tasks Manual. 5459 section in the Yocto Project Development Tasks Manual.
@@ -5490,7 +5490,7 @@ system and gives an overview of their function and contents.
5490 variable is used to make upgrades possible when the versioning scheme 5490 variable is used to make upgrades possible when the versioning scheme
5491 changes in some backwards incompatible way. 5491 changes in some backwards incompatible way.
5492 5492
5493 ``PE`` is the default value of the :term:`PKGE` variable. 5493 :term:`PE` is the default value of the :term:`PKGE` variable.
5494 5494
5495 :term:`PF` 5495 :term:`PF`
5496 Specifies the recipe or package name and includes all version and 5496 Specifies the recipe or package name and includes all version and
@@ -5512,7 +5512,7 @@ system and gives an overview of their function and contents.
5512 5512
5513 .. note:: 5513 .. note::
5514 5514
5515 When using the ``PKG`` variable, you must use a package name override. 5515 When using the :term:`PKG` variable, you must use a package name override.
5516 5516
5517 For example, when the :ref:`debian <ref-classes-debian>` class 5517 For example, when the :ref:`debian <ref-classes-debian>` class
5518 renames the output package, it does so by setting 5518 renames the output package, it does so by setting
@@ -5563,45 +5563,45 @@ system and gives an overview of their function and contents.
5563 :term:`PKGDESTWORK` 5563 :term:`PKGDESTWORK`
5564 Points to a temporary work area where the 5564 Points to a temporary work area where the
5565 :ref:`ref-tasks-package` task saves package metadata. 5565 :ref:`ref-tasks-package` task saves package metadata.
5566 The ``PKGDESTWORK`` location defaults to the following:: 5566 The :term:`PKGDESTWORK` location defaults to the following::
5567 5567
5568 ${WORKDIR}/pkgdata 5568 ${WORKDIR}/pkgdata
5569 5569
5570 Do not change this default. 5570 Do not change this default.
5571 5571
5572 The :ref:`ref-tasks-packagedata` task copies the 5572 The :ref:`ref-tasks-packagedata` task copies the
5573 package metadata from ``PKGDESTWORK`` to 5573 package metadata from :term:`PKGDESTWORK` to
5574 :term:`PKGDATA_DIR` to make it available globally. 5574 :term:`PKGDATA_DIR` to make it available globally.
5575 5575
5576 :term:`PKGE` 5576 :term:`PKGE`
5577 The epoch of the package(s) built by the recipe. By default, ``PKGE`` 5577 The epoch of the package(s) built by the recipe. By default, :term:`PKGE`
5578 is set to :term:`PE`. 5578 is set to :term:`PE`.
5579 5579
5580 :term:`PKGR` 5580 :term:`PKGR`
5581 The revision of the package(s) built by the recipe. By default, 5581 The revision of the package(s) built by the recipe. By default,
5582 ``PKGR`` is set to :term:`PR`. 5582 :term:`PKGR` is set to :term:`PR`.
5583 5583
5584 :term:`PKGV` 5584 :term:`PKGV`
5585 The version of the package(s) built by the recipe. By default, 5585 The version of the package(s) built by the recipe. By default,
5586 ``PKGV`` is set to :term:`PV`. 5586 :term:`PKGV` is set to :term:`PV`.
5587 5587
5588 :term:`PN` 5588 :term:`PN`
5589 This variable can have two separate functions depending on the 5589 This variable can have two separate functions depending on the
5590 context: a recipe name or a resulting package name. 5590 context: a recipe name or a resulting package name.
5591 5591
5592 ``PN`` refers to a recipe name in the context of a file used by the 5592 :term:`PN` refers to a recipe name in the context of a file used by the
5593 OpenEmbedded build system as input to create a package. The name is 5593 OpenEmbedded build system as input to create a package. The name is
5594 normally extracted from the recipe file name. For example, if the 5594 normally extracted from the recipe file name. For example, if the
5595 recipe is named ``expat_2.0.1.bb``, then the default value of ``PN`` 5595 recipe is named ``expat_2.0.1.bb``, then the default value of :term:`PN`
5596 will be "expat". 5596 will be "expat".
5597 5597
5598 The variable refers to a package name in the context of a file 5598 The variable refers to a package name in the context of a file
5599 created or produced by the OpenEmbedded build system. 5599 created or produced by the OpenEmbedded build system.
5600 5600
5601 If applicable, the ``PN`` variable also contains any special suffix 5601 If applicable, the :term:`PN` variable also contains any special suffix
5602 or prefix. For example, using ``bash`` to build packages for the 5602 or prefix. For example, using ``bash`` to build packages for the
5603 native machine, ``PN`` is ``bash-native``. Using ``bash`` to build 5603 native machine, ``PN`` is ``bash-native``. Using ``bash`` to build
5604 packages for the target and for Multilib, ``PN`` would be ``bash`` 5604 packages for the target and for Multilib, :term:`PN` would be ``bash``
5605 and ``lib64-bash``, respectively. 5605 and ``lib64-bash``, respectively.
5606 5606
5607 :term:`PNBLACKLIST` 5607 :term:`PNBLACKLIST`
@@ -5610,7 +5610,7 @@ system and gives an overview of their function and contents.
5610 :ref:`blacklist <ref-classes-blacklist>` class, which is inherited 5610 :ref:`blacklist <ref-classes-blacklist>` class, which is inherited
5611 globally. 5611 globally.
5612 5612
5613 To prevent a recipe from being built, use the ``PNBLACKLIST`` 5613 To prevent a recipe from being built, use the :term:`PNBLACKLIST`
5614 variable in your ``local.conf`` file. Here is an example that 5614 variable in your ``local.conf`` file. Here is an example that
5615 prevents ``myrecipe`` from being built:: 5615 prevents ``myrecipe`` from being built::
5616 5616
@@ -5644,30 +5644,30 @@ system and gives an overview of their function and contents.
5644 The revision of the recipe. The default value for this variable is 5644 The revision of the recipe. The default value for this variable is
5645 "r0". Subsequent revisions of the recipe conventionally have the 5645 "r0". Subsequent revisions of the recipe conventionally have the
5646 values "r1", "r2", and so forth. When :term:`PV` increases, 5646 values "r1", "r2", and so forth. When :term:`PV` increases,
5647 ``PR`` is conventionally reset to "r0". 5647 :term:`PR` is conventionally reset to "r0".
5648 5648
5649 .. note:: 5649 .. note::
5650 5650
5651 The OpenEmbedded build system does not need the aid of ``PR`` 5651 The OpenEmbedded build system does not need the aid of :term:`PR`
5652 to know when to rebuild a recipe. The build system uses the task 5652 to know when to rebuild a recipe. The build system uses the task
5653 :ref:`input checksums <overview-manual/concepts:checksums (signatures)>` along with the 5653 :ref:`input checksums <overview-manual/concepts:checksums (signatures)>` along with the
5654 :ref:`stamp <structure-build-tmp-stamps>` and 5654 :ref:`stamp <structure-build-tmp-stamps>` and
5655 :ref:`overview-manual/concepts:shared state cache` 5655 :ref:`overview-manual/concepts:shared state cache`
5656 mechanisms. 5656 mechanisms.
5657 5657
5658 The ``PR`` variable primarily becomes significant when a package 5658 The :term:`PR` variable primarily becomes significant when a package
5659 manager dynamically installs packages on an already built image. In 5659 manager dynamically installs packages on an already built image. In
5660 this case, ``PR``, which is the default value of 5660 this case, :term:`PR`, which is the default value of
5661 :term:`PKGR`, helps the package manager distinguish which 5661 :term:`PKGR`, helps the package manager distinguish which
5662 package is the most recent one in cases where many packages have the 5662 package is the most recent one in cases where many packages have the
5663 same ``PV`` (i.e. ``PKGV``). A component having many packages with 5663 same :term:`PV` (i.e. :term:`PKGV`). A component having many packages with
5664 the same ``PV`` usually means that the packages all install the same 5664 the same :term:`PV` usually means that the packages all install the same
5665 upstream version, but with later (``PR``) version packages including 5665 upstream version, but with later (:term:`PR`) version packages including
5666 packaging fixes. 5666 packaging fixes.
5667 5667
5668 .. note:: 5668 .. note::
5669 5669
5670 ``PR`` does not need to be increased for changes that do not change the 5670 :term:`PR` does not need to be increased for changes that do not change the
5671 package contents or metadata. 5671 package contents or metadata.
5672 5672
5673 Because manually managing ``PR`` can be cumbersome and error-prone, 5673 Because manually managing ``PR`` can be cumbersome and error-prone,
@@ -5686,7 +5686,7 @@ system and gives an overview of their function and contents.
5686 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" 5686 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
5687 5687
5688 In the previous example, multiple recipes are providing "virtual/kernel". 5688 In the previous example, multiple recipes are providing "virtual/kernel".
5689 The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of 5689 The :term:`PREFERRED_PROVIDER` variable is set with the name (:term:`PN`) of
5690 the recipe you prefer to provide "virtual/kernel". 5690 the recipe you prefer to provide "virtual/kernel".
5691 5691
5692 Following are more examples:: 5692 Following are more examples::
@@ -5700,9 +5700,9 @@ system and gives an overview of their function and contents.
5700 5700
5701 .. note:: 5701 .. note::
5702 5702
5703 If you use a ``virtual/\*`` item with ``PREFERRED_PROVIDER``, then any 5703 If you use a ``virtual/\*`` item with :term:`PREFERRED_PROVIDER`, then any
5704 recipe that :term:`PROVIDES` that item but is not selected (defined) 5704 recipe that :term:`PROVIDES` that item but is not selected (defined)
5705 by ``PREFERRED_PROVIDER`` is prevented from building, which is usually 5705 by :term:`PREFERRED_PROVIDER` is prevented from building, which is usually
5706 desirable since this mechanism is designed to select between mutually 5706 desirable since this mechanism is designed to select between mutually
5707 exclusive alternative providers. 5707 exclusive alternative providers.
5708 5708
@@ -5713,7 +5713,7 @@ system and gives an overview of their function and contents.
5713 the first example below), and you should specify the :term:`PV` 5713 the first example below), and you should specify the :term:`PV`
5714 accordingly (`3.4.0` in the example). 5714 accordingly (`3.4.0` in the example).
5715 5715
5716 The ``PREFERRED_VERSION`` variable supports limited wildcard use 5716 The :term:`PREFERRED_VERSION` variable supports limited wildcard use
5717 through the "``%``" character. You can use the character to match any 5717 through the "``%``" character. You can use the character to match any
5718 number of characters, which can be useful when specifying versions 5718 number of characters, which can be useful when specifying versions
5719 that contain long revision numbers that potentially change. Here are 5719 that contain long revision numbers that potentially change. Here are
@@ -5745,7 +5745,7 @@ system and gives an overview of their function and contents.
5745 5745
5746 PREFERRED_VERSION_foo = "git" 5746 PREFERRED_VERSION_foo = "git"
5747 5747
5748 Sometimes the ``PREFERRED_VERSION`` variable can be set by 5748 Sometimes the :term:`PREFERRED_VERSION` variable can be set by
5749 configuration files in a way that is hard to change. You can use 5749 configuration files in a way that is hard to change. You can use
5750 :term:`OVERRIDES` to set a machine-specific 5750 :term:`OVERRIDES` to set a machine-specific
5751 override. Here is an example:: 5751 override. Here is an example::
@@ -5761,7 +5761,7 @@ system and gives an overview of their function and contents.
5761 .. note:: 5761 .. note::
5762 5762
5763 The ``\_forcevariable`` override is not handled specially. This override 5763 The ``\_forcevariable`` override is not handled specially. This override
5764 only works because the default value of ``OVERRIDES`` includes "forcevariable". 5764 only works because the default value of :term:`OVERRIDES` includes "forcevariable".
5765 5765
5766 If a recipe with the specified version is not available, a warning 5766 If a recipe with the specified version is not available, a warning
5767 message will be shown. See :term:`REQUIRED_VERSION` if you want this 5767 message will be shown. See :term:`REQUIRED_VERSION` if you want this
@@ -5771,12 +5771,12 @@ system and gives an overview of their function and contents.
5771 Specifies additional paths from which the OpenEmbedded build system 5771 Specifies additional paths from which the OpenEmbedded build system
5772 gets source code. When the build system searches for source code, it 5772 gets source code. When the build system searches for source code, it
5773 first tries the local download directory. If that location fails, the 5773 first tries the local download directory. If that location fails, the
5774 build system tries locations defined by ``PREMIRRORS``, the upstream 5774 build system tries locations defined by :term:`PREMIRRORS`, the upstream
5775 source, and then locations specified by 5775 source, and then locations specified by
5776 :term:`MIRRORS` in that order. 5776 :term:`MIRRORS` in that order.
5777 5777
5778 Assuming your distribution (:term:`DISTRO`) is "poky", 5778 Assuming your distribution (:term:`DISTRO`) is "poky",
5779 the default value for ``PREMIRRORS`` is defined in the 5779 the default value for :term:`PREMIRRORS` is defined in the
5780 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository. 5780 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
5781 5781
5782 Typically, you could add a specific server for the build system to 5782 Typically, you could add a specific server for the build system to
@@ -5799,12 +5799,12 @@ system and gives an overview of their function and contents.
5799 :term:`PRIORITY` 5799 :term:`PRIORITY`
5800 Indicates the importance of a package. 5800 Indicates the importance of a package.
5801 5801
5802 ``PRIORITY`` is considered to be part of the distribution policy 5802 :term:`PRIORITY` is considered to be part of the distribution policy
5803 because the importance of any given recipe depends on the purpose for 5803 because the importance of any given recipe depends on the purpose for
5804 which the distribution is being produced. Thus, ``PRIORITY`` is not 5804 which the distribution is being produced. Thus, :term:`PRIORITY` is not
5805 normally set within recipes. 5805 normally set within recipes.
5806 5806
5807 You can set ``PRIORITY`` to "required", "standard", "extra", and 5807 You can set :term:`PRIORITY` to "required", "standard", "extra", and
5808 "optional", which is the default. 5808 "optional", which is the default.
5809 5809
5810 :term:`PRIVATE_LIBS` 5810 :term:`PRIVATE_LIBS`
@@ -5834,19 +5834,19 @@ system and gives an overview of their function and contents.
5834 5834
5835 :term:`PROVIDES` 5835 :term:`PROVIDES`
5836 A list of aliases by which a particular recipe can be known. By 5836 A list of aliases by which a particular recipe can be known. By
5837 default, a recipe's own ``PN`` is implicitly already in its 5837 default, a recipe's own :term:`PN` is implicitly already in its
5838 ``PROVIDES`` list and therefore does not need to mention that it 5838 :term:`PROVIDES` list and therefore does not need to mention that it
5839 provides itself. If a recipe uses ``PROVIDES``, the additional 5839 provides itself. If a recipe uses :term:`PROVIDES`, the additional
5840 aliases are synonyms for the recipe and can be useful for satisfying 5840 aliases are synonyms for the recipe and can be useful for satisfying
5841 dependencies of other recipes during the build as specified by 5841 dependencies of other recipes during the build as specified by
5842 ``DEPENDS``. 5842 :term:`DEPENDS`.
5843 5843
5844 Consider the following example ``PROVIDES`` statement from the recipe 5844 Consider the following example :term:`PROVIDES` statement from the recipe
5845 file ``eudev_3.2.9.bb``:: 5845 file ``eudev_3.2.9.bb``::
5846 5846
5847 PROVIDES += "udev" 5847 PROVIDES += "udev"
5848 5848
5849 The ``PROVIDES`` statement 5849 The :term:`PROVIDES` statement
5850 results in the "eudev" recipe also being available as simply "udev". 5850 results in the "eudev" recipe also being available as simply "udev".
5851 5851
5852 .. note:: 5852 .. note::
@@ -5856,12 +5856,12 @@ system and gives an overview of their function and contents.
5856 strictly necessary it is recommended to avoid confusion. 5856 strictly necessary it is recommended to avoid confusion.
5857 5857
5858 In addition to providing recipes under alternate names, the 5858 In addition to providing recipes under alternate names, the
5859 ``PROVIDES`` mechanism is also used to implement virtual targets. A 5859 :term:`PROVIDES` mechanism is also used to implement virtual targets. A
5860 virtual target is a name that corresponds to some particular 5860 virtual target is a name that corresponds to some particular
5861 functionality (e.g. a Linux kernel). Recipes that provide the 5861 functionality (e.g. a Linux kernel). Recipes that provide the
5862 functionality in question list the virtual target in ``PROVIDES``. 5862 functionality in question list the virtual target in :term:`PROVIDES`.
5863 Recipes that depend on the functionality in question can include the 5863 Recipes that depend on the functionality in question can include the
5864 virtual target in ``DEPENDS`` to leave the choice of provider open. 5864 virtual target in :term:`DEPENDS` to leave the choice of provider open.
5865 5865
5866 Conventionally, virtual targets have names on the form 5866 Conventionally, virtual targets have names on the form
5867 "virtual/function" (e.g. "virtual/kernel"). The slash is simply part 5867 "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
@@ -5889,14 +5889,14 @@ system and gives an overview of their function and contents.
5889 5889
5890 The ``conf/local.conf.sample.extended`` configuration file in the 5890 The ``conf/local.conf.sample.extended`` configuration file in the
5891 :term:`Source Directory` shows how the 5891 :term:`Source Directory` shows how the
5892 ``PRSERV_HOST`` variable is set:: 5892 :term:`PRSERV_HOST` variable is set::
5893 5893
5894 PRSERV_HOST = "localhost:0" 5894 PRSERV_HOST = "localhost:0"
5895 5895
5896 You must 5896 You must
5897 set the variable if you want to automatically start a local :ref:`PR 5897 set the variable if you want to automatically start a local :ref:`PR
5898 service <dev-manual/common-tasks:working with a pr service>`. You can 5898 service <dev-manual/common-tasks:working with a pr service>`. You can
5899 set ``PRSERV_HOST`` to other values to use a remote PR service. 5899 set :term:`PRSERV_HOST` to other values to use a remote PR service.
5900 5900
5901 5901
5902 :term:`PSEUDO_IGNORE_PATHS` 5902 :term:`PSEUDO_IGNORE_PATHS`
@@ -5918,12 +5918,12 @@ system and gives an overview of their function and contents.
5918 :term:`PV` 5918 :term:`PV`
5919 The version of the recipe. The version is normally extracted from the 5919 The version of the recipe. The version is normally extracted from the
5920 recipe filename. For example, if the recipe is named 5920 recipe filename. For example, if the recipe is named
5921 ``expat_2.0.1.bb``, then the default value of ``PV`` will be "2.0.1". 5921 ``expat_2.0.1.bb``, then the default value of :term:`PV` will be "2.0.1".
5922 ``PV`` is generally not overridden within a recipe unless it is 5922 :term:`PV` is generally not overridden within a recipe unless it is
5923 building an unstable (i.e. development) version from a source code 5923 building an unstable (i.e. development) version from a source code
5924 repository (e.g. Git or Subversion). 5924 repository (e.g. Git or Subversion).
5925 5925
5926 ``PV`` is the default value of the :term:`PKGV` variable. 5926 :term:`PV` is the default value of the :term:`PKGV` variable.
5927 5927
5928 :term:`PYTHON_ABI` 5928 :term:`PYTHON_ABI`
5929 When used by recipes that inherit the 5929 When used by recipes that inherit the
@@ -5945,7 +5945,7 @@ system and gives an overview of their function and contents.
5945 When used by recipes that inherit the 5945 When used by recipes that inherit the
5946 `distutils3 <ref-classes-distutils3>`, 5946 `distutils3 <ref-classes-distutils3>`,
5947 :ref:`setuptools3 <ref-classes-setuptools3>` classes, specifies the 5947 :ref:`setuptools3 <ref-classes-setuptools3>` classes, specifies the
5948 major Python version being built. For Python 3.x, ``PYTHON_PN`` would 5948 major Python version being built. For Python 3.x, :term:`PYTHON_PN` would
5949 be "python3". You do not have to set this variable as the 5949 be "python3". You do not have to set this variable as the
5950 OpenEmbedded build system automatically sets it for you. 5950 OpenEmbedded build system automatically sets it for you.
5951 5951
@@ -5955,7 +5955,7 @@ system and gives an overview of their function and contents.
5955 DEPENDS += "${PYTHON_PN}-native" 5955 DEPENDS += "${PYTHON_PN}-native"
5956 5956
5957 In the previous example, 5957 In the previous example,
5958 the version of the dependency is ``PYTHON_PN``. 5958 the version of the dependency is :term:`PYTHON_PN`.
5959 5959
5960 :term:`RANLIB` 5960 :term:`RANLIB`
5961 The minimal command and arguments to run ``ranlib``. 5961 The minimal command and arguments to run ``ranlib``.
@@ -5973,7 +5973,7 @@ system and gives an overview of their function and contents.
5973 specifying versioned dependencies. Although the syntax varies 5973 specifying versioned dependencies. Although the syntax varies
5974 depending on the packaging format, BitBake hides these differences 5974 depending on the packaging format, BitBake hides these differences
5975 from you. Here is the general syntax to specify versions with the 5975 from you. Here is the general syntax to specify versions with the
5976 ``RCONFLICTS`` variable:: 5976 :term:`RCONFLICTS` variable::
5977 5977
5978 RCONFLICTS_${PN} = "package (operator version)" 5978 RCONFLICTS_${PN} = "package (operator version)"
5979 5979
@@ -6001,12 +6001,12 @@ system and gives an overview of their function and contents.
6001 6001
6002 The most common types of package 6002 The most common types of package
6003 runtime dependencies are automatically detected and added. Therefore, 6003 runtime dependencies are automatically detected and added. Therefore,
6004 most recipes do not need to set ``RDEPENDS``. For more information, 6004 most recipes do not need to set :term:`RDEPENDS`. For more information,
6005 see the 6005 see the
6006 ":ref:`overview-manual/concepts:automatically added runtime dependencies`" 6006 ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
6007 section in the Yocto Project Overview and Concepts Manual. 6007 section in the Yocto Project Overview and Concepts Manual.
6008 6008
6009 The practical effect of the above ``RDEPENDS`` assignment is that 6009 The practical effect of the above :term:`RDEPENDS` assignment is that
6010 ``bar`` and ``baz`` will be declared as dependencies inside the 6010 ``bar`` and ``baz`` will be declared as dependencies inside the
6011 package ``foo`` when it is written out by one of the 6011 package ``foo`` when it is written out by one of the
6012 :ref:`do_package_write_\* <ref-tasks-package_write_deb>` tasks. 6012 :ref:`do_package_write_\* <ref-tasks-package_write_deb>` tasks.
@@ -6017,26 +6017,26 @@ system and gives an overview of their function and contents.
6017 also install the packages on which it depends. 6017 also install the packages on which it depends.
6018 6018
6019 To ensure that the packages ``bar`` and ``baz`` get built, the 6019 To ensure that the packages ``bar`` and ``baz`` get built, the
6020 previous ``RDEPENDS`` assignment also causes a task dependency to be 6020 previous :term:`RDEPENDS` assignment also causes a task dependency to be
6021 added. This dependency is from the recipe's 6021 added. This dependency is from the recipe's
6022 :ref:`ref-tasks-build` (not to be confused with 6022 :ref:`ref-tasks-build` (not to be confused with
6023 :ref:`ref-tasks-compile`) task to the 6023 :ref:`ref-tasks-compile`) task to the
6024 ``do_package_write_*`` task of the recipes that build ``bar`` and 6024 ``do_package_write_*`` task of the recipes that build ``bar`` and
6025 ``baz``. 6025 ``baz``.
6026 6026
6027 The names of the packages you list within ``RDEPENDS`` must be the 6027 The names of the packages you list within :term:`RDEPENDS` must be the
6028 names of other packages - they cannot be recipe names. Although 6028 names of other packages - they cannot be recipe names. Although
6029 package names and recipe names usually match, the important point 6029 package names and recipe names usually match, the important point
6030 here is that you are providing package names within the ``RDEPENDS`` 6030 here is that you are providing package names within the :term:`RDEPENDS`
6031 variable. For an example of the default list of packages created from 6031 variable. For an example of the default list of packages created from
6032 a recipe, see the :term:`PACKAGES` variable. 6032 a recipe, see the :term:`PACKAGES` variable.
6033 6033
6034 Because the ``RDEPENDS`` variable applies to packages being built, 6034 Because the :term:`RDEPENDS` variable applies to packages being built,
6035 you should always use the variable in a form with an attached package 6035 you should always use the variable in a form with an attached package
6036 name (remember that a single recipe can build multiple packages). For 6036 name (remember that a single recipe can build multiple packages). For
6037 example, suppose you are building a development package that depends 6037 example, suppose you are building a development package that depends
6038 on the ``perl`` package. In this case, you would use the following 6038 on the ``perl`` package. In this case, you would use the following
6039 ``RDEPENDS`` statement:: 6039 :term:`RDEPENDS` statement::
6040 6040
6041 RDEPENDS_${PN}-dev += "perl" 6041 RDEPENDS_${PN}-dev += "perl"
6042 6042
@@ -6053,19 +6053,19 @@ system and gives an overview of their function and contents.
6053 ``${PN}`` when modifying ``RDEPENDS_${PN}-dev``. Use the "+=" operator 6053 ``${PN}`` when modifying ``RDEPENDS_${PN}-dev``. Use the "+=" operator
6054 rather than the "=" operator. 6054 rather than the "=" operator.
6055 6055
6056 The package names you use with ``RDEPENDS`` must appear as they would 6056 The package names you use with :term:`RDEPENDS` must appear as they would
6057 in the ``PACKAGES`` variable. The :term:`PKG` variable 6057 in the :term:`PACKAGES` variable. The :term:`PKG` variable
6058 allows a different name to be used for the final package (e.g. the 6058 allows a different name to be used for the final package (e.g. the
6059 :ref:`debian <ref-classes-debian>` class uses this to rename 6059 :ref:`debian <ref-classes-debian>` class uses this to rename
6060 packages), but this final package name cannot be used with 6060 packages), but this final package name cannot be used with
6061 ``RDEPENDS``, which makes sense as ``RDEPENDS`` is meant to be 6061 :term:`RDEPENDS`, which makes sense as :term:`RDEPENDS` is meant to be
6062 independent of the package format used. 6062 independent of the package format used.
6063 6063
6064 BitBake, which the OpenEmbedded build system uses, supports 6064 BitBake, which the OpenEmbedded build system uses, supports
6065 specifying versioned dependencies. Although the syntax varies 6065 specifying versioned dependencies. Although the syntax varies
6066 depending on the packaging format, BitBake hides these differences 6066 depending on the packaging format, BitBake hides these differences
6067 from you. Here is the general syntax to specify versions with the 6067 from you. Here is the general syntax to specify versions with the
6068 ``RDEPENDS`` variable:: 6068 :term:`RDEPENDS` variable::
6069 6069
6070 RDEPENDS_${PN} = "package (operator version)" 6070 RDEPENDS_${PN} = "package (operator version)"
6071 6071
@@ -6081,7 +6081,7 @@ system and gives an overview of their function and contents.
6081 6081
6082 .. note:: 6082 .. note::
6083 6083
6084 You can use ``EXTENDPKGV`` to provide a full package version 6084 You can use :term:`EXTENDPKGV` to provide a full package version
6085 specification. 6085 specification.
6086 6086
6087 For example, the following sets up a dependency on version 1.2 or 6087 For example, the following sets up a dependency on version 1.2 or
@@ -6102,8 +6102,8 @@ system and gives an overview of their function and contents.
6102 class, this variable identifies distribution features that must exist 6102 class, this variable identifies distribution features that must exist
6103 in the current configuration in order for the OpenEmbedded build 6103 in the current configuration in order for the OpenEmbedded build
6104 system to build the recipe. In other words, if the 6104 system to build the recipe. In other words, if the
6105 ``REQUIRED_DISTRO_FEATURES`` variable lists a feature that does not 6105 :term:`REQUIRED_DISTRO_FEATURES` variable lists a feature that does not
6106 appear in ``DISTRO_FEATURES`` within the current configuration, then 6106 appear in :term:`DISTRO_FEATURES` within the current configuration, then
6107 the recipe will be skipped, and if the build system attempts to build 6107 the recipe will be skipped, and if the build system attempts to build
6108 the recipe then an error will be triggered. 6108 the recipe then an error will be triggered.
6109 6109
@@ -6151,7 +6151,7 @@ system and gives an overview of their function and contents.
6151 :term:`ROOTFS` 6151 :term:`ROOTFS`
6152 Indicates a filesystem image to include as the root filesystem. 6152 Indicates a filesystem image to include as the root filesystem.
6153 6153
6154 The ``ROOTFS`` variable is an optional variable used with the 6154 The :term:`ROOTFS` variable is an optional variable used with the
6155 :ref:`image-live <ref-classes-image-live>` class. 6155 :ref:`image-live <ref-classes-image-live>` class.
6156 6156
6157 :term:`ROOTFS_POSTINSTALL_COMMAND` 6157 :term:`ROOTFS_POSTINSTALL_COMMAND`
@@ -6212,11 +6212,11 @@ system and gives an overview of their function and contents.
6212 A list of package name aliases that a package also provides. These 6212 A list of package name aliases that a package also provides. These
6213 aliases are useful for satisfying runtime dependencies of other 6213 aliases are useful for satisfying runtime dependencies of other
6214 packages both during the build and on the target (as specified by 6214 packages both during the build and on the target (as specified by
6215 ``RDEPENDS``). 6215 :term:`RDEPENDS`).
6216 6216
6217 .. note:: 6217 .. note::
6218 6218
6219 A package's own name is implicitly already in its ``RPROVIDES`` list. 6219 A package's own name is implicitly already in its :term:`RPROVIDES` list.
6220 6220
6221 As with all package-controlling variables, you must always use the 6221 As with all package-controlling variables, you must always use the
6222 variable in conjunction with a package name override. Here is an 6222 variable in conjunction with a package name override. Here is an
@@ -6229,16 +6229,16 @@ system and gives an overview of their function and contents.
6229 built. The package being built does not depend on this list of 6229 built. The package being built does not depend on this list of
6230 packages in order to successfully build, but rather uses them for 6230 packages in order to successfully build, but rather uses them for
6231 extended usability. To specify runtime dependencies for packages, see 6231 extended usability. To specify runtime dependencies for packages, see
6232 the ``RDEPENDS`` variable. 6232 the :term:`RDEPENDS` variable.
6233 6233
6234 The package manager will automatically install the ``RRECOMMENDS`` 6234 The package manager will automatically install the :term:`RRECOMMENDS`
6235 list of packages when installing the built package. However, you can 6235 list of packages when installing the built package. However, you can
6236 prevent listed packages from being installed by using the 6236 prevent listed packages from being installed by using the
6237 :term:`BAD_RECOMMENDATIONS`, 6237 :term:`BAD_RECOMMENDATIONS`,
6238 :term:`NO_RECOMMENDATIONS`, and 6238 :term:`NO_RECOMMENDATIONS`, and
6239 :term:`PACKAGE_EXCLUDE` variables. 6239 :term:`PACKAGE_EXCLUDE` variables.
6240 6240
6241 Packages specified in ``RRECOMMENDS`` need not actually be produced. 6241 Packages specified in :term:`RRECOMMENDS` need not actually be produced.
6242 However, there must be a recipe providing each package, either 6242 However, there must be a recipe providing each package, either
6243 through the :term:`PACKAGES` or 6243 through the :term:`PACKAGES` or
6244 :term:`PACKAGES_DYNAMIC` variables or the 6244 :term:`PACKAGES_DYNAMIC` variables or the
@@ -6246,7 +6246,7 @@ system and gives an overview of their function and contents.
6246 during the build. If such a recipe does exist and the package is not 6246 during the build. If such a recipe does exist and the package is not
6247 produced, the build continues without error. 6247 produced, the build continues without error.
6248 6248
6249 Because the ``RRECOMMENDS`` variable applies to packages being built, 6249 Because the :term:`RRECOMMENDS` variable applies to packages being built,
6250 you should always attach an override to the variable to specify the 6250 you should always attach an override to the variable to specify the
6251 particular package whose usability is being extended. For example, 6251 particular package whose usability is being extended. For example,
6252 suppose you are building a development package that is extended to 6252 suppose you are building a development package that is extended to
@@ -6257,14 +6257,14 @@ system and gives an overview of their function and contents.
6257 6257
6258 In the 6258 In the
6259 example, the package name (``${PN}-dev``) must appear as it would in 6259 example, the package name (``${PN}-dev``) must appear as it would in
6260 the ``PACKAGES`` namespace before any renaming of the output package 6260 the :term:`PACKAGES` namespace before any renaming of the output package
6261 by classes such as ``debian.bbclass``. 6261 by classes such as ``debian.bbclass``.
6262 6262
6263 BitBake, which the OpenEmbedded build system uses, supports 6263 BitBake, which the OpenEmbedded build system uses, supports
6264 specifying versioned recommends. Although the syntax varies depending 6264 specifying versioned recommends. Although the syntax varies depending
6265 on the packaging format, BitBake hides these differences from you. 6265 on the packaging format, BitBake hides these differences from you.
6266 Here is the general syntax to specify versions with the 6266 Here is the general syntax to specify versions with the
6267 ``RRECOMMENDS`` variable:: 6267 :term:`RRECOMMENDS` variable::
6268 6268
6269 RRECOMMENDS_${PN} = "package (operator version)" 6269 RRECOMMENDS_${PN} = "package (operator version)"
6270 6270
@@ -6286,7 +6286,7 @@ system and gives an overview of their function and contents.
6286 this variable to determine which package should be installed to 6286 this variable to determine which package should be installed to
6287 replace other package(s) during an upgrade. In order to also have the 6287 replace other package(s) during an upgrade. In order to also have the
6288 other package(s) removed at the same time, you must add the name of 6288 other package(s) removed at the same time, you must add the name of
6289 the other package to the ``RCONFLICTS`` variable. 6289 the other package to the :term:`RCONFLICTS` variable.
6290 6290
6291 As with all package-controlling variables, you must use this variable 6291 As with all package-controlling variables, you must use this variable
6292 in conjunction with a package name override. Here is an example:: 6292 in conjunction with a package name override. Here is an example::
@@ -6297,7 +6297,7 @@ system and gives an overview of their function and contents.
6297 specifying versioned replacements. Although the syntax varies 6297 specifying versioned replacements. Although the syntax varies
6298 depending on the packaging format, BitBake hides these differences 6298 depending on the packaging format, BitBake hides these differences
6299 from you. Here is the general syntax to specify versions with the 6299 from you. Here is the general syntax to specify versions with the
6300 ``RREPLACES`` variable:: 6300 :term:`RREPLACES` variable::
6301 6301
6302 RREPLACES_${PN} = "package (operator version)" 6302 RREPLACES_${PN} = "package (operator version)"
6303 6303
@@ -6333,7 +6333,7 @@ system and gives an overview of their function and contents.
6333 version. If the source tarball extracts the code to a directory named 6333 version. If the source tarball extracts the code to a directory named
6334 anything other than ``${BPN}-${PV}``, or if the source code is 6334 anything other than ``${BPN}-${PV}``, or if the source code is
6335 fetched from an SCM such as Git or Subversion, then you must set 6335 fetched from an SCM such as Git or Subversion, then you must set
6336 ``S`` in the recipe so that the OpenEmbedded build system knows where 6336 :term:`S` in the recipe so that the OpenEmbedded build system knows where
6337 to find the unpacked source. 6337 to find the unpacked source.
6338 6338
6339 As an example, assume a :term:`Source Directory` 6339 As an example, assume a :term:`Source Directory`
@@ -6348,7 +6348,7 @@ system and gives an overview of their function and contents.
6348 This next example assumes a Git repository. By default, Git 6348 This next example assumes a Git repository. By default, Git
6349 repositories are cloned to ``${WORKDIR}/git`` during 6349 repositories are cloned to ``${WORKDIR}/git`` during
6350 :ref:`ref-tasks-fetch`. Since this path is different 6350 :ref:`ref-tasks-fetch`. Since this path is different
6351 from the default value of ``S``, you must set it specifically so the 6351 from the default value of :term:`S`, you must set it specifically so the
6352 source can be located:: 6352 source can be located::
6353 6353
6354 SRC_URI = "git://path/to/repo.git" 6354 SRC_URI = "git://path/to/repo.git"
@@ -6365,7 +6365,7 @@ system and gives an overview of their function and contents.
6365 been tested against. Identifiers consist of the host distributor ID 6365 been tested against. Identifiers consist of the host distributor ID
6366 followed by the release, as reported by the ``lsb_release`` tool or 6366 followed by the release, as reported by the ``lsb_release`` tool or
6367 as read from ``/etc/lsb-release``. Separate the list items with 6367 as read from ``/etc/lsb-release``. Separate the list items with
6368 explicit newline characters (``\n``). If ``SANITY_TESTED_DISTROS`` is 6368 explicit newline characters (``\n``). If :term:`SANITY_TESTED_DISTROS` is
6369 not empty and the current value of 6369 not empty and the current value of
6370 :term:`NATIVELSBSTRING` does not appear in the 6370 :term:`NATIVELSBSTRING` does not appear in the
6371 list, then the build system reports a warning that indicates the 6371 list, then the build system reports a warning that indicates the
@@ -6376,7 +6376,7 @@ system and gives an overview of their function and contents.
6376 set this variable. Instead, use :term:`SDKMACHINE`. 6376 set this variable. Instead, use :term:`SDKMACHINE`.
6377 6377
6378 :term:`SDK_CUSTOM_TEMPLATECONF` 6378 :term:`SDK_CUSTOM_TEMPLATECONF`
6379 When building the extensible SDK, if ``SDK_CUSTOM_TEMPLATECONF`` is set to 6379 When building the extensible SDK, if :term:`SDK_CUSTOM_TEMPLATECONF` is set to
6380 "1" and a ``conf/templateconf.conf`` file exists in the build directory 6380 "1" and a ``conf/templateconf.conf`` file exists in the build directory
6381 (:term:`TOPDIR`) then this will be copied into the SDK. 6381 (:term:`TOPDIR`) then this will be copied into the SDK.
6382 6382
@@ -6384,7 +6384,7 @@ system and gives an overview of their function and contents.
6384 The directory set up and used by the 6384 The directory set up and used by the
6385 :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which 6385 :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which
6386 the SDK is deployed. The ``populate_sdk_base`` class defines 6386 the SDK is deployed. The ``populate_sdk_base`` class defines
6387 ``SDK_DEPLOY`` as follows:: 6387 :term:`SDK_DEPLOY` as follows::
6388 6388
6389 SDK_DEPLOY = "${TMPDIR}/deploy/sdk" 6389 SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
6390 6390
@@ -6398,8 +6398,8 @@ system and gives an overview of their function and contents.
6398 6398
6399 .. note:: 6399 .. note::
6400 6400
6401 The ``SDK_DIR`` directory is a temporary directory as it is part of 6401 The :term:`SDK_DIR` directory is a temporary directory as it is part of
6402 ``WORKDIR``. The final output directory is :term:`SDK_DEPLOY`. 6402 :term:`WORKDIR`. The final output directory is :term:`SDK_DEPLOY`.
6403 6403
6404 :term:`SDK_EXT_TYPE` 6404 :term:`SDK_EXT_TYPE`
6405 Controls whether or not shared state artifacts are copied into the 6405 Controls whether or not shared state artifacts are copied into the
@@ -6438,7 +6438,7 @@ system and gives an overview of their function and contents.
6438 6438
6439 .. note:: 6439 .. note::
6440 6440
6441 Enabling the ``SDK_INCLUDE_PKGDATA`` 6441 Enabling the :term:`SDK_INCLUDE_PKGDATA`
6442 variable significantly increases build time because all of world 6442 variable significantly increases build time because all of world
6443 needs to be built. Enabling the variable also slightly increases 6443 needs to be built. Enabling the variable also slightly increases
6444 the size of the extensible SDK. 6444 the size of the extensible SDK.
@@ -6452,9 +6452,9 @@ system and gives an overview of their function and contents.
6452 IDE or from other tools and you do not want to perform additional 6452 IDE or from other tools and you do not want to perform additional
6453 steps to install the toolchain. 6453 steps to install the toolchain.
6454 6454
6455 The ``SDK_INCLUDE_TOOLCHAIN`` variable defaults to "0" if 6455 The :term:`SDK_INCLUDE_TOOLCHAIN` variable defaults to "0" if
6456 ``SDK_EXT_TYPE`` is set to "minimal", and defaults to "1" if 6456 :term:`SDK_EXT_TYPE` is set to "minimal", and defaults to "1" if
6457 ``SDK_EXT_TYPE`` is set to "full". 6457 :term:`SDK_EXT_TYPE` is set to "full".
6458 6458
6459 :term:`SDK_INHERIT_BLACKLIST` 6459 :term:`SDK_INHERIT_BLACKLIST`
6460 A list of classes to remove from the :term:`INHERIT` 6460 A list of classes to remove from the :term:`INHERIT`
@@ -6480,7 +6480,7 @@ system and gives an overview of their function and contents.
6480 build system is running and thus would be potentially problematic 6480 build system is running and thus would be potentially problematic
6481 within the extensible SDK. 6481 within the extensible SDK.
6482 6482
6483 By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the 6483 By default, :term:`SDK_LOCAL_CONF_BLACKLIST` is set in the
6484 :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and 6484 :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
6485 excludes the following variables: 6485 excludes the following variables:
6486 6486
@@ -6542,7 +6542,7 @@ system and gives an overview of their function and contents.
6542 6542
6543 .. note:: 6543 .. note::
6544 6544
6545 The ``SDK_OUTPUT`` directory is a temporary directory as it is part of 6545 The :term:`SDK_OUTPUT` directory is a temporary directory as it is part of
6546 :term:`WORKDIR` by way of :term:`SDK_DIR`. The final output directory is 6546 :term:`WORKDIR` by way of :term:`SDK_DIR`. The final output directory is
6547 :term:`SDK_DEPLOY`. 6547 :term:`SDK_DEPLOY`.
6548 6548
@@ -6550,7 +6550,7 @@ system and gives an overview of their function and contents.
6550 Specifies a list of architectures compatible with the SDK machine. 6550 Specifies a list of architectures compatible with the SDK machine.
6551 This variable is set automatically and should not normally be 6551 This variable is set automatically and should not normally be
6552 hand-edited. Entries are separated using spaces and listed in order 6552 hand-edited. Entries are separated using spaces and listed in order
6553 of priority. The default value for ``SDK_PACKAGE_ARCHS`` is "all any 6553 of priority. The default value for :term:`SDK_PACKAGE_ARCHS` is "all any
6554 noarch ${SDK_ARCH}-${SDKPKGSUFFIX}". 6554 noarch ${SDK_ARCH}-${SDKPKGSUFFIX}".
6555 6555
6556 :term:`SDK_POSTPROCESS_COMMAND` 6556 :term:`SDK_POSTPROCESS_COMMAND`
@@ -6565,7 +6565,7 @@ system and gives an overview of their function and contents.
6565 6565
6566 :term:`SDK_PREFIX` 6566 :term:`SDK_PREFIX`
6567 The toolchain binary prefix used for ``nativesdk`` recipes. The 6567 The toolchain binary prefix used for ``nativesdk`` recipes. The
6568 OpenEmbedded build system uses the ``SDK_PREFIX`` value to set the 6568 OpenEmbedded build system uses the :term:`SDK_PREFIX` value to set the
6569 :term:`TARGET_PREFIX` when building 6569 :term:`TARGET_PREFIX` when building
6570 ``nativesdk`` recipes. The default value is "${SDK_SYS}-". 6570 ``nativesdk`` recipes. The default value is "${SDK_SYS}-".
6571 6571
@@ -6579,9 +6579,9 @@ system and gives an overview of their function and contents.
6579 - do_deploy 6579 - do_deploy
6580 6580
6581 Despite the default value of "" for the 6581 Despite the default value of "" for the
6582 ``SDK_RECRDEP_TASKS`` variable, the above four tasks are always added 6582 :term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
6583 to the SDK. To specify tasks beyond these four, you need to use the 6583 to the SDK. To specify tasks beyond these four, you need to use the
6584 ``SDK_RECRDEP_TASKS`` variable (e.g. you are defining additional 6584 :term:`SDK_RECRDEP_TASKS` variable (e.g. you are defining additional
6585 tasks that are needed in order to build 6585 tasks that are needed in order to build
6586 :term:`SDK_TARGETS`). 6586 :term:`SDK_TARGETS`).
6587 6587
@@ -6592,7 +6592,7 @@ system and gives an overview of their function and contents.
6592 The OpenEmbedded build system automatically sets this variable based 6592 The OpenEmbedded build system automatically sets this variable based
6593 on :term:`SDK_ARCH`, 6593 on :term:`SDK_ARCH`,
6594 :term:`SDK_VENDOR`, and 6594 :term:`SDK_VENDOR`, and
6595 :term:`SDK_OS`. You do not need to set the ``SDK_SYS`` 6595 :term:`SDK_OS`. You do not need to set the :term:`SDK_SYS`
6596 variable yourself. 6596 variable yourself.
6597 6597
6598 :term:`SDK_TARGET_MANIFEST` 6598 :term:`SDK_TARGET_MANIFEST`
@@ -6616,7 +6616,7 @@ system and gives an overview of their function and contents.
6616 standard or extensible SDK installation. The default value is "${PN}" 6616 standard or extensible SDK installation. The default value is "${PN}"
6617 (i.e. the image from which the SDK is built). 6617 (i.e. the image from which the SDK is built).
6618 6618
6619 The ``SDK_TARGETS`` variable is an internal variable and typically 6619 The :term:`SDK_TARGETS` variable is an internal variable and typically
6620 would not be changed. 6620 would not be changed.
6621 6621
6622 :term:`SDK_TITLE` 6622 :term:`SDK_TITLE`
@@ -6629,7 +6629,7 @@ system and gives an overview of their function and contents.
6629 SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" 6629 SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
6630 6630
6631 For the default distribution "poky", 6631 For the default distribution "poky",
6632 ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)". 6632 :term:`SDK_TITLE` is set to "Poky (Yocto Project Reference Distro)".
6633 6633
6634 For information on how to change this default title, see the 6634 For information on how to change this default title, see the
6635 ":ref:`sdk-manual/appendix-customizing:changing the extensible sdk installer title`" 6635 ":ref:`sdk-manual/appendix-customizing:changing the extensible sdk installer title`"
@@ -6647,7 +6647,7 @@ system and gives an overview of their function and contents.
6647 :term:`SDK_VERSION` 6647 :term:`SDK_VERSION`
6648 Specifies the version of the SDK. The Poky distribution configuration file 6648 Specifies the version of the SDK. The Poky distribution configuration file
6649 (``/meta-poky/conf/distro/poky.conf``) sets the default 6649 (``/meta-poky/conf/distro/poky.conf``) sets the default
6650 ``SDK_VERSION`` as follows:: 6650 :term:`SDK_VERSION` as follows::
6651 6651
6652 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}" 6652 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"
6653 6653
@@ -6665,7 +6665,7 @@ system and gives an overview of their function and contents.
6665 SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" 6665 SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
6666 6666
6667 For the 6667 For the
6668 default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk". 6668 default distribution "poky", the :term:`SDKEXTPATH` is set to "poky_sdk".
6669 6669
6670 For information on how to change this default directory, see the 6670 For information on how to change this default directory, see the
6671 ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`" 6671 ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`"
@@ -6673,7 +6673,7 @@ system and gives an overview of their function and contents.
6673 Extensible Software Development Kit (eSDK) manual. 6673 Extensible Software Development Kit (eSDK) manual.
6674 6674
6675 :term:`SDKIMAGE_FEATURES` 6675 :term:`SDKIMAGE_FEATURES`
6676 Equivalent to ``IMAGE_FEATURES``. However, this variable applies to 6676 Equivalent to :term:`IMAGE_FEATURES`. However, this variable applies to
6677 the SDK generated from an image using the following command:: 6677 the SDK generated from an image using the following command::
6678 6678
6679 $ bitbake -c populate_sdk imagename 6679 $ bitbake -c populate_sdk imagename
@@ -6681,7 +6681,7 @@ system and gives an overview of their function and contents.
6681 :term:`SDKMACHINE` 6681 :term:`SDKMACHINE`
6682 The machine for which the SDK is built. In other words, the SDK is 6682 The machine for which the SDK is built. In other words, the SDK is
6683 built such that it runs on the target you specify with the 6683 built such that it runs on the target you specify with the
6684 ``SDKMACHINE`` value. The value points to a corresponding ``.conf`` 6684 :term:`SDKMACHINE` value. The value points to a corresponding ``.conf``
6685 file under ``conf/machine-sdk/``. 6685 file under ``conf/machine-sdk/``.
6686 6686
6687 You can use "i686" and "x86_64" as possible values for this variable. 6687 You can use "i686" and "x86_64" as possible values for this variable.
@@ -6693,7 +6693,7 @@ system and gives an overview of their function and contents.
6693 6693
6694 .. note:: 6694 .. note::
6695 6695
6696 You cannot set the ``SDKMACHINE`` 6696 You cannot set the :term:`SDKMACHINE`
6697 variable in your distribution configuration file. If you do, the 6697 variable in your distribution configuration file. If you do, the
6698 configuration will not take affect. 6698 configuration will not take affect.
6699 6699
@@ -6718,7 +6718,7 @@ system and gives an overview of their function and contents.
6718 building for the target. The flags are passed through the default 6718 building for the target. The flags are passed through the default
6719 value of the :term:`TARGET_CFLAGS` variable. 6719 value of the :term:`TARGET_CFLAGS` variable.
6720 6720
6721 The ``SELECTED_OPTIMIZATION`` variable takes the value of 6721 The :term:`SELECTED_OPTIMIZATION` variable takes the value of
6722 :term:`FULL_OPTIMIZATION` unless :term:`DEBUG_BUILD` = "1", in which 6722 :term:`FULL_OPTIMIZATION` unless :term:`DEBUG_BUILD` = "1", in which
6723 case the value of :term:`DEBUG_OPTIMIZATION` is used. 6723 case the value of :term:`DEBUG_OPTIMIZATION` is used.
6724 6724
@@ -6732,7 +6732,7 @@ system and gives an overview of their function and contents.
6732 6732
6733 .. note:: 6733 .. note::
6734 6734
6735 The ``SERIAL_CONSOLE`` variable is deprecated. Please use the 6735 The :term:`SERIAL_CONSOLE` variable is deprecated. Please use the
6736 :term:`SERIAL_CONSOLES` variable. 6736 :term:`SERIAL_CONSOLES` variable.
6737 6737
6738 :term:`SERIAL_CONSOLES` 6738 :term:`SERIAL_CONSOLES`
@@ -6850,7 +6850,7 @@ system and gives an overview of their function and contents.
6850 6850
6851 :term:`SOURCE_MIRROR_FETCH` 6851 :term:`SOURCE_MIRROR_FETCH`
6852 When you are fetching files to create a mirror of sources (i.e. 6852 When you are fetching files to create a mirror of sources (i.e.
6853 creating a source mirror), setting ``SOURCE_MIRROR_FETCH`` to "1" in 6853 creating a source mirror), setting :term:`SOURCE_MIRROR_FETCH` to "1" in
6854 your ``local.conf`` configuration file ensures the source for all 6854 your ``local.conf`` configuration file ensures the source for all
6855 recipes are fetched regardless of whether or not a recipe is 6855 recipes are fetched regardless of whether or not a recipe is
6856 compatible with the configuration. A recipe is considered 6856 compatible with the configuration. A recipe is considered
@@ -6862,7 +6862,7 @@ system and gives an overview of their function and contents.
6862 6862
6863 .. note:: 6863 .. note::
6864 6864
6865 Do not set the ``SOURCE_MIRROR_FETCH`` 6865 Do not set the :term:`SOURCE_MIRROR_FETCH`
6866 variable unless you are creating a source mirror. In other words, 6866 variable unless you are creating a source mirror. In other words,
6867 do not set the variable during a normal build. 6867 do not set the variable during a normal build.
6868 6868
@@ -6880,11 +6880,11 @@ system and gives an overview of their function and contents.
6880 6880
6881 .. note:: 6881 .. note::
6882 6882
6883 You can specify only a single URL in ``SOURCE_MIRROR_URL``. 6883 You can specify only a single URL in :term:`SOURCE_MIRROR_URL`.
6884 6884
6885 :term:`SPDXLICENSEMAP` 6885 :term:`SPDXLICENSEMAP`
6886 Maps commonly used license names to their SPDX counterparts found in 6886 Maps commonly used license names to their SPDX counterparts found in
6887 ``meta/files/common-licenses/``. For the default ``SPDXLICENSEMAP`` 6887 ``meta/files/common-licenses/``. For the default :term:`SPDXLICENSEMAP`
6888 mappings, see the ``meta/conf/licenses.conf`` file. 6888 mappings, see the ``meta/conf/licenses.conf`` file.
6889 6889
6890 For additional information, see the :term:`LICENSE` 6890 For additional information, see the :term:`LICENSE`
@@ -6915,7 +6915,7 @@ system and gives an overview of their function and contents.
6915 SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" 6915 SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}"
6916 SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}" 6916 SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}"
6917 6917
6918 The ``SPL_BINARY`` variable helps form 6918 The :term:`SPL_BINARY` variable helps form
6919 various ``SPL_*`` variables used by the OpenEmbedded build system. 6919 various ``SPL_*`` variables used by the OpenEmbedded build system.
6920 6920
6921 See the BeagleBone machine configuration example in the 6921 See the BeagleBone machine configuration example in the
@@ -6928,7 +6928,7 @@ system and gives an overview of their function and contents.
6928 OpenEmbedded build system which bits to pull in for the build and how 6928 OpenEmbedded build system which bits to pull in for the build and how
6929 to pull them in. For example, if the recipe or append file only needs 6929 to pull them in. For example, if the recipe or append file only needs
6930 to fetch a tarball from the Internet, the recipe or append file uses 6930 to fetch a tarball from the Internet, the recipe or append file uses
6931 a single ``SRC_URI`` entry. On the other hand, if the recipe or 6931 a single :term:`SRC_URI` entry. On the other hand, if the recipe or
6932 append file needs to fetch a tarball, apply two patches, and include 6932 append file needs to fetch a tarball, apply two patches, and include
6933 a custom file, the recipe or append file would include four instances 6933 a custom file, the recipe or append file would include four instances
6934 of the variable. 6934 of the variable.
@@ -7007,7 +7007,7 @@ system and gives an overview of their function and contents.
7007 7007
7008 - ``az://`` - Fetches files from an Azure Storage account. 7008 - ``az://`` - Fetches files from an Azure Storage account.
7009 7009
7010 There are standard and recipe-specific options for ``SRC_URI``. Here are 7010 There are standard and recipe-specific options for :term:`SRC_URI`. Here are
7011 standard ones: 7011 standard ones:
7012 7012
7013 - ``apply`` - Whether to apply the patch or not. The default 7013 - ``apply`` - Whether to apply the patch or not. The default
@@ -7026,19 +7026,19 @@ system and gives an overview of their function and contents.
7026 :term:`SRCDATE` is equal to or greater than 7026 :term:`SRCDATE` is equal to or greater than
7027 ``mindate``. 7027 ``mindate``.
7028 7028
7029 - ``maxdate`` - Apply the patch only if ``SRCDATE`` is not later 7029 - ``maxdate`` - Apply the patch only if :term:`SRCDATE` is not later
7030 than ``maxdate``. 7030 than ``maxdate``.
7031 7031
7032 - ``minrev`` - Apply the patch only if ``SRCREV`` is equal to or 7032 - ``minrev`` - Apply the patch only if :term:`SRCREV` is equal to or
7033 greater than ``minrev``. 7033 greater than ``minrev``.
7034 7034
7035 - ``maxrev`` - Apply the patch only if ``SRCREV`` is not later 7035 - ``maxrev`` - Apply the patch only if :term:`SRCREV` is not later
7036 than ``maxrev``. 7036 than ``maxrev``.
7037 7037
7038 - ``rev`` - Apply the patch only if ``SRCREV`` is equal to 7038 - ``rev`` - Apply the patch only if :term:`SRCREV` is equal to
7039 ``rev``. 7039 ``rev``.
7040 7040
7041 - ``notrev`` - Apply the patch only if ``SRCREV`` is not equal to 7041 - ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to
7042 ``rev``. 7042 ``rev``.
7043 7043
7044 Here are some additional options worth mentioning: 7044 Here are some additional options worth mentioning:
@@ -7051,19 +7051,19 @@ system and gives an overview of their function and contents.
7051 the Git fetcher is used. 7051 the Git fetcher is used.
7052 7052
7053 - ``subdir`` - Places the file (or extracts its contents) into the 7053 - ``subdir`` - Places the file (or extracts its contents) into the
7054 specified subdirectory of ``WORKDIR`` when the local (``file://``) 7054 specified subdirectory of :term:`WORKDIR` when the local (``file://``)
7055 fetcher is used. 7055 fetcher is used.
7056 7056
7057 - ``localdir`` - Places the file (or extracts its contents) into 7057 - ``localdir`` - Places the file (or extracts its contents) into
7058 the specified subdirectory of ``WORKDIR`` when the CVS fetcher is 7058 the specified subdirectory of :term:`WORKDIR` when the CVS fetcher is
7059 used. 7059 used.
7060 7060
7061 - ``subpath`` - Limits the checkout to a specific subpath of the 7061 - ``subpath`` - Limits the checkout to a specific subpath of the
7062 tree when using the Git fetcher is used. 7062 tree when using the Git fetcher is used.
7063 7063
7064 - ``name`` - Specifies a name to be used for association with 7064 - ``name`` - Specifies a name to be used for association with
7065 ``SRC_URI`` checksums or :term:`SRCREV` when you have more than one 7065 :term:`SRC_URI` checksums or :term:`SRCREV` when you have more than one
7066 file or git repository specified in ``SRC_URI``. For example:: 7066 file or git repository specified in :term:`SRC_URI`. For example::
7067 7067
7068 SRC_URI = "git://example.com/foo.git;name=first \ 7068 SRC_URI = "git://example.com/foo.git;name=first \
7069 git://example.com/bar.git;name=second \ 7069 git://example.com/bar.git;name=second \
@@ -7080,7 +7080,7 @@ system and gives an overview of their function and contents.
7080 :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` 7080 :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH`
7081 By default, the OpenEmbedded build system automatically detects 7081 By default, the OpenEmbedded build system automatically detects
7082 whether ``SRC_URI`` contains files that are machine-specific. If so, 7082 whether ``SRC_URI`` contains files that are machine-specific. If so,
7083 the build system automatically changes ``PACKAGE_ARCH``. Setting this 7083 the build system automatically changes :term:`PACKAGE_ARCH`. Setting this
7084 variable to "0" disables this behavior. 7084 variable to "0" disables this behavior.
7085 7085
7086 :term:`SRCDATE` 7086 :term:`SRCDATE`
@@ -7092,16 +7092,16 @@ system and gives an overview of their function and contents.
7092 Returns the version string of the current package. This string is 7092 Returns the version string of the current package. This string is
7093 used to help define the value of :term:`PV`. 7093 used to help define the value of :term:`PV`.
7094 7094
7095 The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf`` 7095 The :term:`SRCPV` variable is defined in the ``meta/conf/bitbake.conf``
7096 configuration file in the :term:`Source Directory` as 7096 configuration file in the :term:`Source Directory` as
7097 follows:: 7097 follows::
7098 7098
7099 SRCPV = "${@bb.fetch2.get_srcrev(d)}" 7099 SRCPV = "${@bb.fetch2.get_srcrev(d)}"
7100 7100
7101 Recipes that need to define ``PV`` do so with the help of the 7101 Recipes that need to define :term:`PV` do so with the help of the
7102 ``SRCPV``. For example, the ``ofono`` recipe (``ofono_git.bb``) 7102 :term:`SRCPV`. For example, the ``ofono`` recipe (``ofono_git.bb``)
7103 located in ``meta/recipes-connectivity`` in the Source Directory 7103 located in ``meta/recipes-connectivity`` in the Source Directory
7104 defines ``PV`` as follows:: 7104 defines :term:`PV` as follows::
7105 7105
7106 PV = "0.12-git${SRCPV}" 7106 PV = "0.12-git${SRCPV}"
7107 7107
@@ -7110,13 +7110,13 @@ system and gives an overview of their function and contents.
7110 variable applies to Subversion, Git, Mercurial, and Bazaar only. Note 7110 variable applies to Subversion, Git, Mercurial, and Bazaar only. Note
7111 that if you want to build a fixed revision and you want to avoid 7111 that if you want to build a fixed revision and you want to avoid
7112 performing a query on the remote repository every time BitBake parses 7112 performing a query on the remote repository every time BitBake parses
7113 your recipe, you should specify a ``SRCREV`` that is a full revision 7113 your recipe, you should specify a :term:`SRCREV` that is a full revision
7114 identifier and not just a tag. 7114 identifier and not just a tag.
7115 7115
7116 .. note:: 7116 .. note::
7117 7117
7118 For information on limitations when inheriting the latest revision 7118 For information on limitations when inheriting the latest revision
7119 of software using ``SRCREV``, see the :term:`AUTOREV` variable 7119 of software using :term:`SRCREV`, see the :term:`AUTOREV` variable
7120 description and the 7120 description and the
7121 ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`" 7121 ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
7122 section, which is in the Yocto Project Development Tasks Manual. 7122 section, which is in the Yocto Project Development Tasks Manual.
@@ -7151,9 +7151,9 @@ system and gives an overview of their function and contents.
7151 :term:`SSTATE_MIRROR_ALLOW_NETWORK` 7151 :term:`SSTATE_MIRROR_ALLOW_NETWORK`
7152 If set to "1", allows fetches from mirrors that are specified in 7152 If set to "1", allows fetches from mirrors that are specified in
7153 :term:`SSTATE_MIRRORS` to work even when 7153 :term:`SSTATE_MIRRORS` to work even when
7154 fetching from the network is disabled by setting ``BB_NO_NETWORK`` to 7154 fetching from the network is disabled by setting :term:`BB_NO_NETWORK` to
7155 "1". Using the ``SSTATE_MIRROR_ALLOW_NETWORK`` variable is useful if 7155 "1". Using the :term:`SSTATE_MIRROR_ALLOW_NETWORK` variable is useful if
7156 you have set ``SSTATE_MIRRORS`` to point to an internal server for 7156 you have set :term:`SSTATE_MIRRORS` to point to an internal server for
7157 your shared state cache, but you want to disable any other fetching 7157 your shared state cache, but you want to disable any other fetching
7158 from the network. 7158 from the network.
7159 7159
@@ -7171,7 +7171,7 @@ system and gives an overview of their function and contents.
7171 7171
7172 When pointing to sstate build artifacts on another machine that uses 7172 When pointing to sstate build artifacts on another machine that uses
7173 a different GCC version for native builds, you must configure 7173 a different GCC version for native builds, you must configure
7174 ``SSTATE_MIRRORS`` with a regular expression that maps local search 7174 :term:`SSTATE_MIRRORS` with a regular expression that maps local search
7175 paths to server paths. The paths need to take into account 7175 paths to server paths. The paths need to take into account
7176 :term:`NATIVELSBSTRING` set by the 7176 :term:`NATIVELSBSTRING` set by the
7177 :ref:`uninative <ref-classes-uninative>` class. For example, the 7177 :ref:`uninative <ref-classes-uninative>` class. For example, the
@@ -7200,8 +7200,8 @@ system and gives an overview of their function and contents.
7200 (sstate) object during the first stage of preparing the sysroots. 7200 (sstate) object during the first stage of preparing the sysroots.
7201 That object is scanned for hardcoded paths for original installation 7201 That object is scanned for hardcoded paths for original installation
7202 locations. The list of files that are scanned for paths is controlled 7202 locations. The list of files that are scanned for paths is controlled
7203 by the ``SSTATE_SCAN_FILES`` variable. Typically, recipes add files 7203 by the :term:`SSTATE_SCAN_FILES` variable. Typically, recipes add files
7204 they want to be scanned to the value of ``SSTATE_SCAN_FILES`` rather 7204 they want to be scanned to the value of :term:`SSTATE_SCAN_FILES` rather
7205 than the variable being comprehensively set. The 7205 than the variable being comprehensively set. The
7206 :ref:`sstate <ref-classes-sstate>` class specifies the default list 7206 :ref:`sstate <ref-classes-sstate>` class specifies the default list
7207 of files. 7207 of files.
@@ -7263,7 +7263,7 @@ system and gives an overview of their function and contents.
7263 7263
7264 .. note:: 7264 .. note::
7265 7265
7266 Recipes should never write files directly under the ``STAGING_DIR`` 7266 Recipes should never write files directly under the :term:`STAGING_DIR`
7267 directory because the OpenEmbedded build system manages the 7267 directory because the OpenEmbedded build system manages the
7268 directory automatically. Instead, files should be installed to 7268 directory automatically. Instead, files should be installed to
7269 ``${``\ :term:`D`\ ``}`` within your recipe's :ref:`ref-tasks-install` 7269 ``${``\ :term:`D`\ ``}`` within your recipe's :ref:`ref-tasks-install`
@@ -7278,7 +7278,7 @@ system and gives an overview of their function and contents.
7278 files. Exceptions include ``-native`` recipes, where the 7278 files. Exceptions include ``-native`` recipes, where the
7279 ``do_populate_sysroot`` task instead uses 7279 ``do_populate_sysroot`` task instead uses
7280 :term:`STAGING_DIR_NATIVE`. Depending on 7280 :term:`STAGING_DIR_NATIVE`. Depending on
7281 the type of recipe and the build target, ``STAGING_DIR_HOST`` can 7281 the type of recipe and the build target, :term:`STAGING_DIR_HOST` can
7282 have the following values: 7282 have the following values:
7283 7283
7284 - For recipes building for the target machine, the value is 7284 - For recipes building for the target machine, the value is
@@ -7296,7 +7296,7 @@ system and gives an overview of their function and contents.
7296 standard build environment variables such as 7296 standard build environment variables such as
7297 :term:`CPPFLAGS` and 7297 :term:`CPPFLAGS` and
7298 :term:`CFLAGS` are set up so that both host paths 7298 :term:`CFLAGS` are set up so that both host paths
7299 and ``STAGING_DIR_NATIVE`` are searched for libraries and 7299 and :term:`STAGING_DIR_NATIVE` are searched for libraries and
7300 headers using, for example, GCC's ``-isystem`` option. 7300 headers using, for example, GCC's ``-isystem`` option.
7301 7301
7302 Thus, the emphasis is that the ``STAGING_DIR*`` variables 7302 Thus, the emphasis is that the ``STAGING_DIR*`` variables
@@ -7304,7 +7304,7 @@ system and gives an overview of their function and contents.
7304 :ref:`ref-tasks-configure`, 7304 :ref:`ref-tasks-configure`,
7305 :ref:`ref-tasks-compile`, and 7305 :ref:`ref-tasks-compile`, and
7306 :ref:`ref-tasks-install`. Having the real system 7306 :ref:`ref-tasks-install`. Having the real system
7307 root correspond to ``STAGING_DIR_HOST`` makes conceptual sense 7307 root correspond to :term:`STAGING_DIR_HOST` makes conceptual sense
7308 for ``-native`` recipes, as they make use of host headers and 7308 for ``-native`` recipes, as they make use of host headers and
7309 libraries. 7309 libraries.
7310 7310
@@ -7315,7 +7315,7 @@ system and gives an overview of their function and contents.
7315 :term:`STAGING_DIR_TARGET` 7315 :term:`STAGING_DIR_TARGET`
7316 Specifies the path to the sysroot used for the system for which the 7316 Specifies the path to the sysroot used for the system for which the
7317 component generates code. For components that do not generate code, 7317 component generates code. For components that do not generate code,
7318 which is the majority, ``STAGING_DIR_TARGET`` is set to match 7318 which is the majority, :term:`STAGING_DIR_TARGET` is set to match
7319 :term:`STAGING_DIR_HOST`. 7319 :term:`STAGING_DIR_HOST`.
7320 7320
7321 Some recipes build binaries that can run on the target system but 7321 Some recipes build binaries that can run on the target system but
@@ -7324,8 +7324,8 @@ system and gives an overview of their function and contents.
7324 primary system is referred to as the "HOST" and the secondary, or 7324 primary system is referred to as the "HOST" and the secondary, or
7325 different, system is referred to as the "TARGET". Thus, the binaries 7325 different, system is referred to as the "TARGET". Thus, the binaries
7326 run on the "HOST" system and generate binaries for the "TARGET" 7326 run on the "HOST" system and generate binaries for the "TARGET"
7327 system. The ``STAGING_DIR_HOST`` variable points to the sysroot used 7327 system. The :term:`STAGING_DIR_HOST` variable points to the sysroot used
7328 for the "HOST" system, while ``STAGING_DIR_TARGET`` points to the 7328 for the "HOST" system, while :term:`STAGING_DIR_TARGET` points to the
7329 sysroot used for the "TARGET" system. 7329 sysroot used for the "TARGET" system.
7330 7330
7331 :term:`STAGING_ETCDIR_NATIVE` 7331 :term:`STAGING_ETCDIR_NATIVE`
@@ -7350,7 +7350,7 @@ system and gives an overview of their function and contents.
7350 Points to the directory containing the kernel build artifacts. 7350 Points to the directory containing the kernel build artifacts.
7351 Recipes building software that needs to access kernel build artifacts 7351 Recipes building software that needs to access kernel build artifacts
7352 (e.g. ``systemtap-uprobes``) can look in the directory specified with 7352 (e.g. ``systemtap-uprobes``) can look in the directory specified with
7353 the ``STAGING_KERNEL_BUILDDIR`` variable to find these artifacts 7353 the :term:`STAGING_KERNEL_BUILDDIR` variable to find these artifacts
7354 after the kernel has been built. 7354 after the kernel has been built.
7355 7355
7356 :term:`STAGING_KERNEL_DIR` 7356 :term:`STAGING_KERNEL_DIR`
@@ -7370,7 +7370,7 @@ system and gives an overview of their function and contents.
7370 Specifies the base path used to create recipe stamp files. The path 7370 Specifies the base path used to create recipe stamp files. The path
7371 to an actual stamp file is constructed by evaluating this string and 7371 to an actual stamp file is constructed by evaluating this string and
7372 then appending additional information. Currently, the default 7372 then appending additional information. Currently, the default
7373 assignment for ``STAMP`` as set in the ``meta/conf/bitbake.conf`` 7373 assignment for :term:`STAMP` as set in the ``meta/conf/bitbake.conf``
7374 file is:: 7374 file is::
7375 7375
7376 STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}" 7376 STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
@@ -7397,8 +7397,8 @@ system and gives an overview of their function and contents.
7397 :term:`SUMMARY` 7397 :term:`SUMMARY`
7398 The short (72 characters or less) summary of the binary package for 7398 The short (72 characters or less) summary of the binary package for
7399 packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default, 7399 packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default,
7400 ``SUMMARY`` is used to define the 7400 :term:`SUMMARY` is used to define the
7401 :term:`DESCRIPTION` variable if ``DESCRIPTION`` is 7401 :term:`DESCRIPTION` variable if :term:`DESCRIPTION` is
7402 not set in the recipe. 7402 not set in the recipe.
7403 7403
7404 :term:`SVNDIR` 7404 :term:`SVNDIR`
@@ -7528,10 +7528,10 @@ system and gives an overview of their function and contents.
7528 7528
7529 :term:`SYSTEMD_BOOT_CFG` 7529 :term:`SYSTEMD_BOOT_CFG`
7530 When :term:`EFI_PROVIDER` is set to 7530 When :term:`EFI_PROVIDER` is set to
7531 "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the 7531 "systemd-boot", the :term:`SYSTEMD_BOOT_CFG` variable specifies the
7532 configuration file that should be used. By default, the 7532 configuration file that should be used. By default, the
7533 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the 7533 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
7534 ``SYSTEMD_BOOT_CFG`` as follows:: 7534 :term:`SYSTEMD_BOOT_CFG` as follows::
7535 7535
7536 SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf" 7536 SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf"
7537 7537
@@ -7540,11 +7540,11 @@ system and gives an overview of their function and contents.
7540 7540
7541 :term:`SYSTEMD_BOOT_ENTRIES` 7541 :term:`SYSTEMD_BOOT_ENTRIES`
7542 When :term:`EFI_PROVIDER` is set to 7542 When :term:`EFI_PROVIDER` is set to
7543 "systemd-boot", the ``SYSTEMD_BOOT_ENTRIES`` variable specifies a 7543 "systemd-boot", the :term:`SYSTEMD_BOOT_ENTRIES` variable specifies a
7544 list of entry files (``*.conf``) to install that contain one boot 7544 list of entry files (``*.conf``) to install that contain one boot
7545 entry per file. By default, the 7545 entry per file. By default, the
7546 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the 7546 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
7547 ``SYSTEMD_BOOT_ENTRIES`` as follows:: 7547 :term:`SYSTEMD_BOOT_ENTRIES` as follows::
7548 7548
7549 SYSTEMD_BOOT_ENTRIES ?= "" 7549 SYSTEMD_BOOT_ENTRIES ?= ""
7550 7550
@@ -7553,10 +7553,10 @@ system and gives an overview of their function and contents.
7553 7553
7554 :term:`SYSTEMD_BOOT_TIMEOUT` 7554 :term:`SYSTEMD_BOOT_TIMEOUT`
7555 When :term:`EFI_PROVIDER` is set to 7555 When :term:`EFI_PROVIDER` is set to
7556 "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the 7556 "systemd-boot", the :term:`SYSTEMD_BOOT_TIMEOUT` variable specifies the
7557 boot menu timeout in seconds. By default, the 7557 boot menu timeout in seconds. By default, the
7558 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the 7558 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
7559 ``SYSTEMD_BOOT_TIMEOUT`` as follows:: 7559 :term:`SYSTEMD_BOOT_TIMEOUT` as follows::
7560 7560
7561 SYSTEMD_BOOT_TIMEOUT ?= "10" 7561 SYSTEMD_BOOT_TIMEOUT ?= "10"
7562 7562
@@ -7566,14 +7566,14 @@ system and gives an overview of their function and contents.
7566 :term:`SYSTEMD_PACKAGES` 7566 :term:`SYSTEMD_PACKAGES`
7567 When inheriting the :ref:`systemd <ref-classes-systemd>` class, 7567 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
7568 this variable locates the systemd unit files when they are not found 7568 this variable locates the systemd unit files when they are not found
7569 in the main recipe's package. By default, the ``SYSTEMD_PACKAGES`` 7569 in the main recipe's package. By default, the :term:`SYSTEMD_PACKAGES`
7570 variable is set such that the systemd unit files are assumed to 7570 variable is set such that the systemd unit files are assumed to
7571 reside in the recipes main package:: 7571 reside in the recipes main package::
7572 7572
7573 SYSTEMD_PACKAGES ?= "${PN}" 7573 SYSTEMD_PACKAGES ?= "${PN}"
7574 7574
7575 If these unit files are not in this recipe's main package, you need 7575 If these unit files are not in this recipe's main package, you need
7576 to use ``SYSTEMD_PACKAGES`` to list the package or packages in which 7576 to use :term:`SYSTEMD_PACKAGES` to list the package or packages in which
7577 the build system can find the systemd unit files. 7577 the build system can find the systemd unit files.
7578 7578
7579 :term:`SYSTEMD_SERVICE` 7579 :term:`SYSTEMD_SERVICE`
@@ -7594,7 +7594,7 @@ system and gives an overview of their function and contents.
7594 (allowing login), assuming :term:`USE_VT` is not set to 7594 (allowing login), assuming :term:`USE_VT` is not set to
7595 "0". 7595 "0".
7596 7596
7597 The default value for ``SYSVINIT_ENABLED_GETTYS`` is "1" (i.e. only 7597 The default value for :term:`SYSVINIT_ENABLED_GETTYS` is "1" (i.e. only
7598 run a getty on the first virtual terminal). 7598 run a getty on the first virtual terminal).
7599 7599
7600 :term:`T` 7600 :term:`T`
@@ -7608,7 +7608,7 @@ system and gives an overview of their function and contents.
7608 BitBake unpacks and builds the recipe. The default ``bitbake.conf`` 7608 BitBake unpacks and builds the recipe. The default ``bitbake.conf``
7609 file sets this variable. 7609 file sets this variable.
7610 7610
7611 The ``T`` variable is not to be confused with the 7611 The :term:`T` variable is not to be confused with the
7612 :term:`TMPDIR` variable, which points to the root of 7612 :term:`TMPDIR` variable, which points to the root of
7613 the directory tree where BitBake places the output of an entire 7613 the directory tree where BitBake places the output of an entire
7614 build. 7614 build.
@@ -7632,7 +7632,7 @@ system and gives an overview of their function and contents.
7632 7632
7633 :term:`TARGET_AS_ARCH` 7633 :term:`TARGET_AS_ARCH`
7634 Specifies architecture-specific assembler flags for the target 7634 Specifies architecture-specific assembler flags for the target
7635 system. ``TARGET_AS_ARCH`` is initialized from 7635 system. :term:`TARGET_AS_ARCH` is initialized from
7636 :term:`TUNE_ASARGS` by default in the BitBake 7636 :term:`TUNE_ASARGS` by default in the BitBake
7637 configuration file (``meta/conf/bitbake.conf``):: 7637 configuration file (``meta/conf/bitbake.conf``)::
7638 7638
@@ -7640,20 +7640,20 @@ system and gives an overview of their function and contents.
7640 7640
7641 :term:`TARGET_CC_ARCH` 7641 :term:`TARGET_CC_ARCH`
7642 Specifies architecture-specific C compiler flags for the target 7642 Specifies architecture-specific C compiler flags for the target
7643 system. ``TARGET_CC_ARCH`` is initialized from 7643 system. :term:`TARGET_CC_ARCH` is initialized from
7644 :term:`TUNE_CCARGS` by default. 7644 :term:`TUNE_CCARGS` by default.
7645 7645
7646 .. note:: 7646 .. note::
7647 7647
7648 It is a common workaround to append :term:`LDFLAGS` to 7648 It is a common workaround to append :term:`LDFLAGS` to
7649 ``TARGET_CC_ARCH`` in recipes that build software for the target that 7649 :term:`TARGET_CC_ARCH` in recipes that build software for the target that
7650 would not otherwise respect the exported ``LDFLAGS`` variable. 7650 would not otherwise respect the exported :term:`LDFLAGS` variable.
7651 7651
7652 :term:`TARGET_CC_KERNEL_ARCH` 7652 :term:`TARGET_CC_KERNEL_ARCH`
7653 This is a specific kernel compiler flag for a CPU or Application 7653 This is a specific kernel compiler flag for a CPU or Application
7654 Binary Interface (ABI) tune. The flag is used rarely and only for 7654 Binary Interface (ABI) tune. The flag is used rarely and only for
7655 cases where a userspace :term:`TUNE_CCARGS` is not 7655 cases where a userspace :term:`TUNE_CCARGS` is not
7656 compatible with the kernel compilation. The ``TARGET_CC_KERNEL_ARCH`` 7656 compatible with the kernel compilation. The :term:`TARGET_CC_KERNEL_ARCH`
7657 variable allows the kernel (and associated modules) to use a 7657 variable allows the kernel (and associated modules) to use a
7658 different configuration. See the 7658 different configuration. See the
7659 ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the 7659 ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the
@@ -7665,8 +7665,8 @@ system and gives an overview of their function and contents.
7665 :term:`CFLAGS` is set to the value of this variable by 7665 :term:`CFLAGS` is set to the value of this variable by
7666 default. 7666 default.
7667 7667
7668 Additionally, the SDK's environment setup script sets the ``CFLAGS`` 7668 Additionally, the SDK's environment setup script sets the :term:`CFLAGS`
7669 variable in the environment to the ``TARGET_CFLAGS`` value so that 7669 variable in the environment to the :term:`TARGET_CFLAGS` value so that
7670 executables built using the SDK also have the flags applied. 7670 executables built using the SDK also have the flags applied.
7671 7671
7672 :term:`TARGET_CPPFLAGS` 7672 :term:`TARGET_CPPFLAGS`
@@ -7676,7 +7676,7 @@ system and gives an overview of their function and contents.
7676 value of this variable by default. 7676 value of this variable by default.
7677 7677
7678 Additionally, the SDK's environment setup script sets the 7678 Additionally, the SDK's environment setup script sets the
7679 ``CPPFLAGS`` variable in the environment to the ``TARGET_CPPFLAGS`` 7679 :term:`CPPFLAGS` variable in the environment to the :term:`TARGET_CPPFLAGS`
7680 value so that executables built using the SDK also have the flags 7680 value so that executables built using the SDK also have the flags
7681 applied. 7681 applied.
7682 7682
@@ -7687,7 +7687,7 @@ system and gives an overview of their function and contents.
7687 by default. 7687 by default.
7688 7688
7689 Additionally, the SDK's environment setup script sets the 7689 Additionally, the SDK's environment setup script sets the
7690 ``CXXFLAGS`` variable in the environment to the ``TARGET_CXXFLAGS`` 7690 :term:`CXXFLAGS` variable in the environment to the :term:`TARGET_CXXFLAGS`
7691 value so that executables built using the SDK also have the flags 7691 value so that executables built using the SDK also have the flags
7692 applied. 7692 applied.
7693 7693
@@ -7699,7 +7699,7 @@ system and gives an overview of their function and contents.
7699 7699
7700 :term:`TARGET_LD_ARCH` 7700 :term:`TARGET_LD_ARCH`
7701 Specifies architecture-specific linker flags for the target system. 7701 Specifies architecture-specific linker flags for the target system.
7702 ``TARGET_LD_ARCH`` is initialized from 7702 :term:`TARGET_LD_ARCH` is initialized from
7703 :term:`TUNE_LDARGS` by default in the BitBake 7703 :term:`TUNE_LDARGS` by default in the BitBake
7704 configuration file (``meta/conf/bitbake.conf``):: 7704 configuration file (``meta/conf/bitbake.conf``)::
7705 7705
@@ -7713,7 +7713,7 @@ system and gives an overview of their function and contents.
7713 7713
7714 Additionally, the SDK's environment setup script sets the 7714 Additionally, the SDK's environment setup script sets the
7715 :term:`LDFLAGS` variable in the environment to the 7715 :term:`LDFLAGS` variable in the environment to the
7716 ``TARGET_LDFLAGS`` value so that executables built using the SDK also 7716 :term:`TARGET_LDFLAGS` value so that executables built using the SDK also
7717 have the flags applied. 7717 have the flags applied.
7718 7718
7719 :term:`TARGET_OS` 7719 :term:`TARGET_OS`
@@ -7735,7 +7735,7 @@ system and gives an overview of their function and contents.
7735 value of ``BUILD_PREFIX``. 7735 value of ``BUILD_PREFIX``.
7736 7736
7737 - For native SDK recipes (``nativesdk``), the build system sets the 7737 - For native SDK recipes (``nativesdk``), the build system sets the
7738 variable to the value of ``SDK_PREFIX``. 7738 variable to the value of :term:`SDK_PREFIX`.
7739 7739
7740 :term:`TARGET_SYS` 7740 :term:`TARGET_SYS`
7741 Specifies the system, including the architecture and the operating 7741 Specifies the system, including the architecture and the operating
@@ -7749,7 +7749,7 @@ system and gives an overview of their function and contents.
7749 7749
7750 .. note:: 7750 .. note::
7751 7751
7752 You do not need to set the ``TARGET_SYS`` variable yourself. 7752 You do not need to set the :term:`TARGET_SYS` variable yourself.
7753 7753
7754 Consider these two examples: 7754 Consider these two examples:
7755 7755
@@ -7780,11 +7780,11 @@ system and gives an overview of their function and contents.
7780 In the ``defaultsetup.conf`` file, the default value of 7780 In the ``defaultsetup.conf`` file, the default value of
7781 ``TCLIBCAPPEND`` is "-${TCLIBC}". However, distros such as poky, 7781 ``TCLIBCAPPEND`` is "-${TCLIBC}". However, distros such as poky,
7782 which normally only support one ``libc`` variant, set 7782 which normally only support one ``libc`` variant, set
7783 ``TCLIBCAPPEND`` to "" in their distro configuration file resulting 7783 :term:`TCLIBCAPPEND` to "" in their distro configuration file resulting
7784 in no suffix being applied. 7784 in no suffix being applied.
7785 7785
7786 :term:`TCMODE` 7786 :term:`TCMODE`
7787 Specifies the toolchain selector. ``TCMODE`` controls the 7787 Specifies the toolchain selector. :term:`TCMODE` controls the
7788 characteristics of the generated packages and images by telling the 7788 characteristics of the generated packages and images by telling the
7789 OpenEmbedded build system which toolchain profile to use. By default, 7789 OpenEmbedded build system which toolchain profile to use. By default,
7790 the OpenEmbedded build system builds its own internal toolchain. The 7790 the OpenEmbedded build system builds its own internal toolchain. The
@@ -7793,7 +7793,7 @@ system and gives an overview of their function and contents.
7793 7793
7794 .. note:: 7794 .. note::
7795 7795
7796 If ``TCMODE`` is set to a value other than "default", then it is your 7796 If :term:`TCMODE` is set to a value other than "default", then it is your
7797 responsibility to ensure that the toolchain is compatible with the 7797 responsibility to ensure that the toolchain is compatible with the
7798 default toolchain. Using older or newer versions of these 7798 default toolchain. Using older or newer versions of these
7799 components might cause build problems. See the Release Notes for 7799 components might cause build problems. See the Release Notes for
@@ -7803,7 +7803,7 @@ system and gives an overview of their function and contents.
7803 page on the Yocto Project website and click on the "RELEASE 7803 page on the Yocto Project website and click on the "RELEASE
7804 INFORMATION" link for the appropriate release. 7804 INFORMATION" link for the appropriate release.
7805 7805
7806 The ``TCMODE`` variable is similar to :term:`TCLIBC`, 7806 The :term:`TCMODE` variable is similar to :term:`TCLIBC`,
7807 which controls the variant of the GNU standard C library (``libc``) 7807 which controls the variant of the GNU standard C library (``libc``)
7808 used during the build process: ``glibc`` or ``musl``. 7808 used during the build process: ``glibc`` or ``musl``.
7809 7809
@@ -7829,7 +7829,7 @@ system and gives an overview of their function and contents.
7829 the :term:`TEST_EXPORT_ONLY` variable is set 7829 the :term:`TEST_EXPORT_ONLY` variable is set
7830 to "1". 7830 to "1".
7831 7831
7832 The ``TEST_EXPORT_DIR`` variable defaults to 7832 The :term:`TEST_EXPORT_DIR` variable defaults to
7833 ``"${TMPDIR}/testimage/${PN}"``. 7833 ``"${TMPDIR}/testimage/${PN}"``.
7834 7834
7835 :term:`TEST_EXPORT_ONLY` 7835 :term:`TEST_EXPORT_ONLY`
@@ -7839,7 +7839,7 @@ system and gives an overview of their function and contents.
7839 7839
7840 :term:`TEST_LOG_DIR` 7840 :term:`TEST_LOG_DIR`
7841 Holds the SSH log and the boot log for QEMU machines. The 7841 Holds the SSH log and the boot log for QEMU machines. The
7842 ``TEST_LOG_DIR`` variable defaults to ``"${WORKDIR}/testimage"``. 7842 :term:`TEST_LOG_DIR` variable defaults to ``"${WORKDIR}/testimage"``.
7843 7843
7844 .. note:: 7844 .. note::
7845 7845
@@ -7859,7 +7859,7 @@ system and gives an overview of their function and contents.
7859 For automated hardware testing, specifies additional arguments to 7859 For automated hardware testing, specifies additional arguments to
7860 pass through to the command specified in 7860 pass through to the command specified in
7861 :term:`TEST_POWERCONTROL_CMD`. Setting 7861 :term:`TEST_POWERCONTROL_CMD`. Setting
7862 ``TEST_POWERCONTROL_EXTRA_ARGS`` is optional. You can use it if you 7862 :term:`TEST_POWERCONTROL_EXTRA_ARGS` is optional. You can use it if you
7863 wish, for example, to separate the machine-specific and 7863 wish, for example, to separate the machine-specific and
7864 non-machine-specific parts of the arguments. 7864 non-machine-specific parts of the arguments.
7865 7865
@@ -7890,7 +7890,7 @@ system and gives an overview of their function and contents.
7890 For automated hardware testing, specifies additional arguments to 7890 For automated hardware testing, specifies additional arguments to
7891 pass through to the command specified in 7891 pass through to the command specified in
7892 :term:`TEST_SERIALCONTROL_CMD`. Setting 7892 :term:`TEST_SERIALCONTROL_CMD`. Setting
7893 ``TEST_SERIALCONTROL_EXTRA_ARGS`` is optional. You can use it if you 7893 :term:`TEST_SERIALCONTROL_EXTRA_ARGS` is optional. You can use it if you
7894 wish, for example, to separate the machine-specific and 7894 wish, for example, to separate the machine-specific and
7895 non-machine-specific parts of the command. 7895 non-machine-specific parts of the command.
7896 7896
@@ -7902,7 +7902,7 @@ system and gives an overview of their function and contents.
7902 7902
7903 .. note:: 7903 .. note::
7904 7904
7905 The ``TEST_SERVER_IP`` variable is only used for a small number of 7905 The :term:`TEST_SERVER_IP` variable is only used for a small number of
7906 tests such as the "dnf" test suite, which needs to download packages 7906 tests such as the "dnf" test suite, which needs to download packages
7907 from ``WORKDIR/oe-rootfs-repo``. 7907 from ``WORKDIR/oe-rootfs-repo``.
7908 7908
@@ -7919,7 +7919,7 @@ system and gives an overview of their function and contents.
7919 QEMU. 7919 QEMU.
7920 7920
7921 Tests include ``ping``, ``ssh``, ``df`` among others. You can add 7921 Tests include ``ping``, ``ssh``, ``df`` among others. You can add
7922 your own tests to the list of tests by appending ``TEST_SUITES`` as 7922 your own tests to the list of tests by appending :term:`TEST_SUITES` as
7923 follows:: 7923 follows::
7924 7924
7925 TEST_SUITES_append = " mytest" 7925 TEST_SUITES_append = " mytest"
@@ -7958,7 +7958,7 @@ system and gives an overview of their function and contents.
7958 the controllers by adding a module in the layer's 7958 the controllers by adding a module in the layer's
7959 ``/lib/oeqa/controllers`` directory and by inheriting the 7959 ``/lib/oeqa/controllers`` directory and by inheriting the
7960 ``BaseTarget`` class, which is an abstract class that cannot be used 7960 ``BaseTarget`` class, which is an abstract class that cannot be used
7961 as a value of ``TEST_TARGET``. 7961 as a value of :term:`TEST_TARGET`.
7962 7962
7963 You can provide the following arguments with ``TEST_TARGET``: 7963 You can provide the following arguments with ``TEST_TARGET``:
7964 7964
@@ -7983,7 +7983,7 @@ system and gives an overview of their function and contents.
7983 section in the Yocto Project Development Tasks Manual. 7983 section in the Yocto Project Development Tasks Manual.
7984 7984
7985 :term:`TEST_TARGET_IP` 7985 :term:`TEST_TARGET_IP`
7986 The IP address of your hardware under test. The ``TEST_TARGET_IP`` 7986 The IP address of your hardware under test. The :term:`TEST_TARGET_IP`
7987 variable has no effect when :term:`TEST_TARGET` is 7987 variable has no effect when :term:`TEST_TARGET` is
7988 set to "qemu". 7988 set to "qemu".
7989 7989
@@ -8000,7 +8000,7 @@ system and gives an overview of their function and contents.
8000 8000
8001 :term:`TESTIMAGE_AUTO` 8001 :term:`TESTIMAGE_AUTO`
8002 Automatically runs the series of automated tests for images when an 8002 Automatically runs the series of automated tests for images when an
8003 image is successfully built. Setting ``TESTIMAGE_AUTO`` to "1" causes 8003 image is successfully built. Setting :term:`TESTIMAGE_AUTO` to "1" causes
8004 any image that successfully builds to automatically boot under QEMU. 8004 any image that successfully builds to automatically boot under QEMU.
8005 Using the variable also adds in dependencies so that any SDK for 8005 Using the variable also adds in dependencies so that any SDK for
8006 which testing is requested is automatically built first. 8006 which testing is requested is automatically built first.
@@ -8032,7 +8032,7 @@ system and gives an overview of their function and contents.
8032 :term:`TMPDIR` 8032 :term:`TMPDIR`
8033 This variable is the base directory the OpenEmbedded build system 8033 This variable is the base directory the OpenEmbedded build system
8034 uses for all build output and intermediate files (other than the 8034 uses for all build output and intermediate files (other than the
8035 shared state cache). By default, the ``TMPDIR`` variable points to 8035 shared state cache). By default, the :term:`TMPDIR` variable points to
8036 ``tmp`` within the :term:`Build Directory`. 8036 ``tmp`` within the :term:`Build Directory`.
8037 8037
8038 If you want to establish this directory in a location other than the 8038 If you want to establish this directory in a location other than the
@@ -8041,14 +8041,14 @@ system and gives an overview of their function and contents.
8041 8041
8042 #TMPDIR = "${TOPDIR}/tmp" 8042 #TMPDIR = "${TOPDIR}/tmp"
8043 8043
8044 An example use for this scenario is to set ``TMPDIR`` to a local disk, 8044 An example use for this scenario is to set :term:`TMPDIR` to a local disk,
8045 which does not use NFS, while having the Build Directory use NFS. 8045 which does not use NFS, while having the Build Directory use NFS.
8046 8046
8047 The filesystem used by ``TMPDIR`` must have standard filesystem 8047 The filesystem used by :term:`TMPDIR` must have standard filesystem
8048 semantics (i.e. mixed-case files are unique, POSIX file locking, and 8048 semantics (i.e. mixed-case files are unique, POSIX file locking, and
8049 persistent inodes). Due to various issues with NFS and bugs in some 8049 persistent inodes). Due to various issues with NFS and bugs in some
8050 implementations, NFS does not meet this minimum requirement. 8050 implementations, NFS does not meet this minimum requirement.
8051 Consequently, ``TMPDIR`` cannot be on NFS. 8051 Consequently, :term:`TMPDIR` cannot be on NFS.
8052 8052
8053 :term:`TOOLCHAIN_HOST_TASK` 8053 :term:`TOOLCHAIN_HOST_TASK`
8054 This variable lists packages the OpenEmbedded build system uses when 8054 This variable lists packages the OpenEmbedded build system uses when
@@ -8077,7 +8077,7 @@ system and gives an overview of their function and contents.
8077 :term:`TOOLCHAIN_OUTPUTNAME` 8077 :term:`TOOLCHAIN_OUTPUTNAME`
8078 This variable defines the name used for the toolchain output. The 8078 This variable defines the name used for the toolchain output. The
8079 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets 8079 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets
8080 the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:: 8080 the :term:`TOOLCHAIN_OUTPUTNAME` variable as follows::
8081 8081
8082 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" 8082 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
8083 8083
@@ -8113,7 +8113,7 @@ system and gives an overview of their function and contents.
8113 variable is used where the architecture is needed in a value where 8113 variable is used where the architecture is needed in a value where
8114 underscores are not allowed, for example within package filenames. In 8114 underscores are not allowed, for example within package filenames. In
8115 this case, dash characters replace any underscore characters used in 8115 this case, dash characters replace any underscore characters used in
8116 ``TARGET_ARCH``. 8116 :term:`TARGET_ARCH`.
8117 8117
8118 Do not edit this variable. 8118 Do not edit this variable.
8119 8119
@@ -8122,18 +8122,18 @@ system and gives an overview of their function and contents.
8122 ``arm``, ``armeb``, ``mips``, ``mips64``, and so forth). BitBake uses 8122 ``arm``, ``armeb``, ``mips``, ``mips64``, and so forth). BitBake uses
8123 this value to setup configuration. 8123 this value to setup configuration.
8124 8124
8125 ``TUNE_ARCH`` definitions are specific to a given architecture. The 8125 :term:`TUNE_ARCH` definitions are specific to a given architecture. The
8126 definitions can be a single static definition, or can be dynamically 8126 definitions can be a single static definition, or can be dynamically
8127 adjusted. You can see details for a given CPU family by looking at 8127 adjusted. You can see details for a given CPU family by looking at
8128 the architecture's ``README`` file. For example, the 8128 the architecture's ``README`` file. For example, the
8129 ``meta/conf/machine/include/mips/README`` file in the 8129 ``meta/conf/machine/include/mips/README`` file in the
8130 :term:`Source Directory` provides information for 8130 :term:`Source Directory` provides information for
8131 ``TUNE_ARCH`` specific to the ``mips`` architecture. 8131 :term:`TUNE_ARCH` specific to the ``mips`` architecture.
8132 8132
8133 ``TUNE_ARCH`` is tied closely to 8133 :term:`TUNE_ARCH` is tied closely to
8134 :term:`TARGET_ARCH`, which defines the target 8134 :term:`TARGET_ARCH`, which defines the target
8135 machine's architecture. The BitBake configuration file 8135 machine's architecture. The BitBake configuration file
8136 (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows:: 8136 (``meta/conf/bitbake.conf``) sets :term:`TARGET_ARCH` as follows::
8137 8137
8138 TARGET_ARCH = "${TUNE_ARCH}" 8138 TARGET_ARCH = "${TUNE_ARCH}"
8139 8139
@@ -8151,7 +8151,7 @@ system and gives an overview of their function and contents.
8151 :term:`TUNE_ASARGS` 8151 :term:`TUNE_ASARGS`
8152 Specifies architecture-specific assembler flags for the target 8152 Specifies architecture-specific assembler flags for the target
8153 system. The set of flags is based on the selected tune features. 8153 system. The set of flags is based on the selected tune features.
8154 ``TUNE_ASARGS`` is set using the tune include files, which are 8154 :term:`TUNE_ASARGS` is set using the tune include files, which are
8155 typically under ``meta/conf/machine/include/`` and are influenced 8155 typically under ``meta/conf/machine/include/`` and are influenced
8156 through :term:`TUNE_FEATURES`. For example, the 8156 through :term:`TUNE_FEATURES`. For example, the
8157 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags 8157 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
@@ -8168,7 +8168,7 @@ system and gives an overview of their function and contents.
8168 :term:`TUNE_CCARGS` 8168 :term:`TUNE_CCARGS`
8169 Specifies architecture-specific C compiler flags for the target 8169 Specifies architecture-specific C compiler flags for the target
8170 system. The set of flags is based on the selected tune features. 8170 system. The set of flags is based on the selected tune features.
8171 ``TUNE_CCARGS`` is set using the tune include files, which are 8171 :term:`TUNE_CCARGS` is set using the tune include files, which are
8172 typically under ``meta/conf/machine/include/`` and are influenced 8172 typically under ``meta/conf/machine/include/`` and are influenced
8173 through :term:`TUNE_FEATURES`. 8173 through :term:`TUNE_FEATURES`.
8174 8174
@@ -8188,7 +8188,7 @@ system and gives an overview of their function and contents.
8188 are not conflicting and that they are supported. 8188 are not conflicting and that they are supported.
8189 8189
8190 The BitBake configuration file (``meta/conf/bitbake.conf``) defines 8190 The BitBake configuration file (``meta/conf/bitbake.conf``) defines
8191 ``TUNE_FEATURES`` as follows:: 8191 :term:`TUNE_FEATURES` as follows::
8192 8192
8193 TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" 8193 TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
8194 8194
@@ -8197,7 +8197,7 @@ system and gives an overview of their function and contents.
8197 :term:`TUNE_LDARGS` 8197 :term:`TUNE_LDARGS`
8198 Specifies architecture-specific linker flags for the target system. 8198 Specifies architecture-specific linker flags for the target system.
8199 The set of flags is based on the selected tune features. 8199 The set of flags is based on the selected tune features.
8200 ``TUNE_LDARGS`` is set using the tune include files, which are 8200 :term:`TUNE_LDARGS` is set using the tune include files, which are
8201 typically under ``meta/conf/machine/include/`` and are influenced 8201 typically under ``meta/conf/machine/include/`` and are influenced
8202 through :term:`TUNE_FEATURES`. For example, the 8202 through :term:`TUNE_FEATURES`. For example, the
8203 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags 8203 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
@@ -8227,12 +8227,12 @@ system and gives an overview of their function and contents.
8227 :term:`TUNEABI` 8227 :term:`TUNEABI`
8228 An underlying Application Binary Interface (ABI) used by a particular 8228 An underlying Application Binary Interface (ABI) used by a particular
8229 tuning in a given toolchain layer. Providers that use prebuilt 8229 tuning in a given toolchain layer. Providers that use prebuilt
8230 libraries can use the ``TUNEABI``, 8230 libraries can use the :term:`TUNEABI`,
8231 :term:`TUNEABI_OVERRIDE`, and 8231 :term:`TUNEABI_OVERRIDE`, and
8232 :term:`TUNEABI_WHITELIST` variables to check 8232 :term:`TUNEABI_WHITELIST` variables to check
8233 compatibility of tunings against their selection of libraries. 8233 compatibility of tunings against their selection of libraries.
8234 8234
8235 If ``TUNEABI`` is undefined, then every tuning is allowed. See the 8235 If :term:`TUNEABI` is undefined, then every tuning is allowed. See the
8236 :ref:`sanity <ref-classes-sanity>` class to see how the variable is 8236 :ref:`sanity <ref-classes-sanity>` class to see how the variable is
8237 used. 8237 used.
8238 8238
@@ -8240,7 +8240,7 @@ system and gives an overview of their function and contents.
8240 If set, the OpenEmbedded system ignores the 8240 If set, the OpenEmbedded system ignores the
8241 :term:`TUNEABI_WHITELIST` variable. 8241 :term:`TUNEABI_WHITELIST` variable.
8242 Providers that use prebuilt libraries can use the 8242 Providers that use prebuilt libraries can use the
8243 ``TUNEABI_OVERRIDE``, ``TUNEABI_WHITELIST``, and 8243 :term:`TUNEABI_OVERRIDE`, :term:`TUNEABI_WHITELIST`, and
8244 :term:`TUNEABI` variables to check compatibility of a 8244 :term:`TUNEABI` variables to check compatibility of a
8245 tuning against their selection of libraries. 8245 tuning against their selection of libraries.
8246 8246
@@ -8249,9 +8249,9 @@ system and gives an overview of their function and contents.
8249 8249
8250 :term:`TUNEABI_WHITELIST` 8250 :term:`TUNEABI_WHITELIST`
8251 A whitelist of permissible :term:`TUNEABI` values. If 8251 A whitelist of permissible :term:`TUNEABI` values. If
8252 ``TUNEABI_WHITELIST`` is not set, all tunes are allowed. Providers 8252 :term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers
8253 that use prebuilt libraries can use the ``TUNEABI_WHITELIST``, 8253 that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`,
8254 :term:`TUNEABI_OVERRIDE`, and ``TUNEABI`` 8254 :term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI`
8255 variables to check compatibility of a tuning against their selection 8255 variables to check compatibility of a tuning against their selection
8256 of libraries. 8256 of libraries.
8257 8257
@@ -8296,35 +8296,35 @@ system and gives an overview of their function and contents.
8296 UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" 8296 UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"
8297 8297
8298 In this example, "sd" is selected as the configuration of the possible four for the 8298 In this example, "sd" is selected as the configuration of the possible four for the
8299 ``UBOOT_MACHINE``. The "sd" configuration defines 8299 :term:`UBOOT_MACHINE`. The "sd" configuration defines
8300 "mx6qsabreauto_config" as the value for ``UBOOT_MACHINE``, while the 8300 "mx6qsabreauto_config" as the value for :term:`UBOOT_MACHINE`, while the
8301 "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-Boot image. 8301 "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-Boot image.
8302 8302
8303 For more information on how the ``UBOOT_CONFIG`` is handled, see the 8303 For more information on how the :term:`UBOOT_CONFIG` is handled, see the
8304 :ref:`uboot-config <ref-classes-uboot-config>` 8304 :ref:`uboot-config <ref-classes-uboot-config>`
8305 class. 8305 class.
8306 8306
8307 :term:`UBOOT_DTB_LOADADDRESS` 8307 :term:`UBOOT_DTB_LOADADDRESS`
8308 Specifies the load address for the dtb image used by U-Boot. During FIT 8308 Specifies the load address for the dtb image used by U-Boot. During FIT
8309 image creation, the ``UBOOT_DTB_LOADADDRESS`` variable is used in 8309 image creation, the :term:`UBOOT_DTB_LOADADDRESS` variable is used in
8310 :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify 8310 :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify
8311 the load address to be used in 8311 the load address to be used in
8312 creating the dtb sections of Image Tree Source for the FIT image. 8312 creating the dtb sections of Image Tree Source for the FIT image.
8313 8313
8314 :term:`UBOOT_DTBO_LOADADDRESS` 8314 :term:`UBOOT_DTBO_LOADADDRESS`
8315 Specifies the load address for the dtbo image used by U-Boot. During FIT 8315 Specifies the load address for the dtbo image used by U-Boot. During FIT
8316 image creation, the ``UBOOT_DTBO_LOADADDRESS`` variable is used in 8316 image creation, the :term:`UBOOT_DTBO_LOADADDRESS` variable is used in
8317 :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in 8317 :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in
8318 creating the dtbo sections of Image Tree Source for the FIT image. 8318 creating the dtbo sections of Image Tree Source for the FIT image.
8319 8319
8320 :term:`UBOOT_ENTRYPOINT` 8320 :term:`UBOOT_ENTRYPOINT`
8321 Specifies the entry point for the U-Boot image. During U-Boot image 8321 Specifies the entry point for the U-Boot image. During U-Boot image
8322 creation, the ``UBOOT_ENTRYPOINT`` variable is passed as a 8322 creation, the :term:`UBOOT_ENTRYPOINT` variable is passed as a
8323 command-line parameter to the ``uboot-mkimage`` utility. 8323 command-line parameter to the ``uboot-mkimage`` utility.
8324 8324
8325 :term:`UBOOT_LOADADDRESS` 8325 :term:`UBOOT_LOADADDRESS`
8326 Specifies the load address for the U-Boot image. During U-Boot image 8326 Specifies the load address for the U-Boot image. During U-Boot image
8327 creation, the ``UBOOT_LOADADDRESS`` variable is passed as a 8327 creation, the :term:`UBOOT_LOADADDRESS` variable is passed as a
8328 command-line parameter to the ``uboot-mkimage`` utility. 8328 command-line parameter to the ``uboot-mkimage`` utility.
8329 8329
8330 :term:`UBOOT_LOCALVERSION` 8330 :term:`UBOOT_LOCALVERSION`
@@ -8375,7 +8375,7 @@ system and gives an overview of their function and contents.
8375 :term:`UBOOT_RD_ENTRYPOINT` 8375 :term:`UBOOT_RD_ENTRYPOINT`
8376 Specifies the entrypoint for the RAM disk image. 8376 Specifies the entrypoint for the RAM disk image.
8377 During FIT image creation, the 8377 During FIT image creation, the
8378 ``UBOOT_RD_ENTRYPOINT`` variable is used 8378 :term:`UBOOT_RD_ENTRYPOINT` variable is used
8379 in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the 8379 in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
8380 entrypoint to be used in creating the Image Tree Source for 8380 entrypoint to be used in creating the Image Tree Source for
8381 the FIT image. 8381 the FIT image.
@@ -8383,7 +8383,7 @@ system and gives an overview of their function and contents.
8383 :term:`UBOOT_RD_LOADADDRESS` 8383 :term:`UBOOT_RD_LOADADDRESS`
8384 Specifies the load address for the RAM disk image. 8384 Specifies the load address for the RAM disk image.
8385 During FIT image creation, the 8385 During FIT image creation, the
8386 ``UBOOT_RD_LOADADDRESS`` variable is used 8386 :term:`UBOOT_RD_LOADADDRESS` variable is used
8387 in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the 8387 in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
8388 load address to be used in creating the Image Tree Source for 8388 load address to be used in creating the Image Tree Source for
8389 the FIT image. 8389 the FIT image.
@@ -8424,16 +8424,16 @@ system and gives an overview of their function and contents.
8424 However, there are common options that are passed to all 8424 However, there are common options that are passed to all
8425 configure scripts at a class level, but might not be valid for some 8425 configure scripts at a class level, but might not be valid for some
8426 configure scripts. Therefore warnings about these options are useless. 8426 configure scripts. Therefore warnings about these options are useless.
8427 For these cases, the options are added to ``UNKNOWN_CONFIGURE_WHITELIST``. 8427 For these cases, the options are added to :term:`UNKNOWN_CONFIGURE_WHITELIST`.
8428 8428
8429 The configure arguments check that uses 8429 The configure arguments check that uses
8430 ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the 8430 :term:`UNKNOWN_CONFIGURE_WHITELIST` is part of the
8431 :ref:`insane <ref-classes-insane>` class and is only enabled if the 8431 :ref:`insane <ref-classes-insane>` class and is only enabled if the
8432 recipe inherits the :ref:`autotools <ref-classes-autotools>` class. 8432 recipe inherits the :ref:`autotools <ref-classes-autotools>` class.
8433 8433
8434 :term:`UPDATERCPN` 8434 :term:`UPDATERCPN`
8435 For recipes inheriting the 8435 For recipes inheriting the
8436 :ref:`update-rc.d <ref-classes-update-rc.d>` class, ``UPDATERCPN`` 8436 :ref:`update-rc.d <ref-classes-update-rc.d>` class, :term:`UPDATERCPN`
8437 specifies the package that contains the initscript that is enabled. 8437 specifies the package that contains the initscript that is enabled.
8438 8438
8439 The default value is "${PN}". Given that almost all recipes that 8439 The default value is "${PN}". Given that almost all recipes that
@@ -8447,7 +8447,7 @@ system and gives an overview of their function and contents.
8447 OpenEmbedded build system determines the latest upstream version by 8447 OpenEmbedded build system determines the latest upstream version by
8448 picking the latest tag from the list of all repository tags. 8448 picking the latest tag from the list of all repository tags.
8449 8449
8450 You can use the ``UPSTREAM_CHECK_GITTAGREGEX`` variable to provide a 8450 You can use the :term:`UPSTREAM_CHECK_GITTAGREGEX` variable to provide a
8451 regular expression to filter only the relevant tags should the 8451 regular expression to filter only the relevant tags should the
8452 default filter not work correctly. 8452 default filter not work correctly.
8453 :: 8453 ::
@@ -8455,7 +8455,7 @@ system and gives an overview of their function and contents.
8455 UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex" 8455 UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex"
8456 8456
8457 :term:`UPSTREAM_CHECK_REGEX` 8457 :term:`UPSTREAM_CHECK_REGEX`
8458 Use the ``UPSTREAM_CHECK_REGEX`` variable to specify a different 8458 Use the :term:`UPSTREAM_CHECK_REGEX` variable to specify a different
8459 regular expression instead of the default one when the package 8459 regular expression instead of the default one when the package
8460 checking system is parsing the page found using 8460 checking system is parsing the page found using
8461 :term:`UPSTREAM_CHECK_URI`. 8461 :term:`UPSTREAM_CHECK_URI`.
@@ -8469,7 +8469,7 @@ system and gives an overview of their function and contents.
8469 the source code is provided from tarballs, the latest version is 8469 the source code is provided from tarballs, the latest version is
8470 determined by fetching the directory listing where the tarball is and 8470 determined by fetching the directory listing where the tarball is and
8471 attempting to find a later tarball. When this approach does not work, 8471 attempting to find a later tarball. When this approach does not work,
8472 you can use ``UPSTREAM_CHECK_URI`` to provide a different URI that 8472 you can use :term:`UPSTREAM_CHECK_URI` to provide a different URI that
8473 contains the link to the latest tarball. 8473 contains the link to the latest tarball.
8474 :: 8474 ::
8475 8475
@@ -8477,8 +8477,8 @@ system and gives an overview of their function and contents.
8477 8477
8478 :term:`USE_DEVFS` 8478 :term:`USE_DEVFS`
8479 Determines if ``devtmpfs`` is used for ``/dev`` population. The 8479 Determines if ``devtmpfs`` is used for ``/dev`` population. The
8480 default value used for ``USE_DEVFS`` is "1" when no value is 8480 default value used for :term:`USE_DEVFS` is "1" when no value is
8481 specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a 8481 specifically set. Typically, you would set :term:`USE_DEVFS` to "0" for a
8482 statically populated ``/dev`` directory. 8482 statically populated ``/dev`` directory.
8483 8483
8484 See the ":ref:`dev-manual/common-tasks:selecting a device manager`" section in 8484 See the ":ref:`dev-manual/common-tasks:selecting a device manager`" section in
@@ -8493,8 +8493,8 @@ system and gives an overview of their function and contents.
8493 virtual terminals in order to enable logging in through those 8493 virtual terminals in order to enable logging in through those
8494 terminals. 8494 terminals.
8495 8495
8496 The default value used for ``USE_VT`` is "1" when no default value is 8496 The default value used for :term:`USE_VT` is "1" when no default value is
8497 specifically set. Typically, you would set ``USE_VT`` to "0" in the 8497 specifically set. Typically, you would set :term:`USE_VT` to "0" in the
8498 machine configuration file for machines that do not have a graphical 8498 machine configuration file for machines that do not have a graphical
8499 display attached and therefore do not need virtual terminal 8499 display attached and therefore do not need virtual terminal
8500 functionality. 8500 functionality.
@@ -8521,9 +8521,9 @@ system and gives an overview of their function and contents.
8521 8521
8522 The default behavior for the build system is to dynamically apply 8522 The default behavior for the build system is to dynamically apply
8523 ``uid`` and ``gid`` values. Consequently, the 8523 ``uid`` and ``gid`` values. Consequently, the
8524 ``USERADD_ERROR_DYNAMIC`` variable is by default not set. If you plan 8524 :term:`USERADD_ERROR_DYNAMIC` variable is by default not set. If you plan
8525 on using statically assigned ``gid`` and ``uid`` values, you should 8525 on using statically assigned ``gid`` and ``uid`` values, you should
8526 set the ``USERADD_ERROR_DYNAMIC`` variable in your ``local.conf`` 8526 set the :term:`USERADD_ERROR_DYNAMIC` variable in your ``local.conf``
8527 file as follows:: 8527 file as follows::
8528 8528
8529 USERADD_ERROR_DYNAMIC = "error" 8529 USERADD_ERROR_DYNAMIC = "error"
@@ -8538,7 +8538,7 @@ system and gives an overview of their function and contents.
8538 .. note:: 8538 .. note::
8539 8539
8540 There is a difference in behavior between setting 8540 There is a difference in behavior between setting
8541 ``USERADD_ERROR_DYNAMIC`` to ``error`` and setting it to ``warn``. 8541 :term:`USERADD_ERROR_DYNAMIC` to ``error`` and setting it to ``warn``.
8542 When it is set to ``warn``, the build system will report a warning for 8542 When it is set to ``warn``, the build system will report a warning for
8543 every undefined ``uid`` and ``gid`` in any recipe. But when it is set 8543 every undefined ``uid`` and ``gid`` in any recipe. But when it is set
8544 to ``error``, it will only report errors for recipes that are actually 8544 to ``error``, it will only report errors for recipes that are actually
@@ -8577,7 +8577,7 @@ system and gives an overview of their function and contents.
8577 8577
8578 .. note:: 8578 .. note::
8579 8579
8580 It follows that if you are going to use the ``USERADD_PACKAGES`` 8580 It follows that if you are going to use the :term:`USERADD_PACKAGES`
8581 variable, you need to set one or more of the :term:`USERADD_PARAM`, 8581 variable, you need to set one or more of the :term:`USERADD_PARAM`,
8582 :term:`GROUPADD_PARAM`, or :term:`GROUPMEMS_PARAM` variables. 8582 :term:`GROUPADD_PARAM`, or :term:`GROUPMEMS_PARAM` variables.
8583 8583
@@ -8640,7 +8640,7 @@ system and gives an overview of their function and contents.
8640 Specifies the persistence of the target's ``/var/log`` directory, 8640 Specifies the persistence of the target's ``/var/log`` directory,
8641 which is used to house postinstall target log files. 8641 which is used to house postinstall target log files.
8642 8642
8643 By default, ``VOLATILE_LOG_DIR`` is set to "yes", which means the 8643 By default, :term:`VOLATILE_LOG_DIR` is set to "yes", which means the
8644 file is not persistent. You can override this setting by setting the 8644 file is not persistent. You can override this setting by setting the
8645 variable to "no" to make the log directory persistent. 8645 variable to "no" to make the log directory persistent.
8646 8646
@@ -8662,18 +8662,18 @@ system and gives an overview of their function and contents.
8662 8662
8663 :term:`WKS_FILE_DEPENDS` 8663 :term:`WKS_FILE_DEPENDS`
8664 When placed in the recipe that builds your image, this variable lists 8664 When placed in the recipe that builds your image, this variable lists
8665 build-time dependencies. The ``WKS_FILE_DEPENDS`` variable is only 8665 build-time dependencies. The :term:`WKS_FILE_DEPENDS` variable is only
8666 applicable when Wic images are active (i.e. when 8666 applicable when Wic images are active (i.e. when
8667 :term:`IMAGE_FSTYPES` contains entries related 8667 :term:`IMAGE_FSTYPES` contains entries related
8668 to Wic). If your recipe does not create Wic images, the variable has 8668 to Wic). If your recipe does not create Wic images, the variable has
8669 no effect. 8669 no effect.
8670 8670
8671 The ``WKS_FILE_DEPENDS`` variable is similar to the 8671 The :term:`WKS_FILE_DEPENDS` variable is similar to the
8672 :term:`DEPENDS` variable. When you use the variable in 8672 :term:`DEPENDS` variable. When you use the variable in
8673 your recipe that builds the Wic image, dependencies you list in the 8673 your recipe that builds the Wic image, dependencies you list in the
8674 ``WKS_FILE_DEPENDS`` variable are added to the ``DEPENDS`` variable. 8674 :term:`WKS_FILE_DEPENDS` variable are added to the :term:`DEPENDS` variable.
8675 8675
8676 With the ``WKS_FILE_DEPENDS`` variable, you have the possibility to 8676 With the :term:`WKS_FILE_DEPENDS` variable, you have the possibility to
8677 specify a list of additional dependencies (e.g. native tools, 8677 specify a list of additional dependencies (e.g. native tools,
8678 bootloaders, and so forth), that are required to build Wic images. 8678 bootloaders, and so forth), that are required to build Wic images.
8679 Following is an example:: 8679 Following is an example::
@@ -8690,7 +8690,7 @@ system and gives an overview of their function and contents.
8690 :term:`TMPDIR` directory structure and is specific to 8690 :term:`TMPDIR` directory structure and is specific to
8691 the recipe being built and the system for which it is being built. 8691 the recipe being built and the system for which it is being built.
8692 8692
8693 The ``WORKDIR`` directory is defined as follows:: 8693 The :term:`WORKDIR` directory is defined as follows::
8694 8694
8695 ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} 8695 ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
8696 8696
@@ -8720,6 +8720,6 @@ system and gives an overview of their function and contents.
8720 indirectly, includes "x11-base" in 8720 indirectly, includes "x11-base" in
8721 :term:`IMAGE_FEATURES`. 8721 :term:`IMAGE_FEATURES`.
8722 8722
8723 The default value of ``XSERVER``, if not specified in the machine 8723 The default value of :term:`XSERVER`, if not specified in the machine
8724 configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev". 8724 configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev".
8725 8725
diff --git a/documentation/sdk-manual/appendix-customizing-standard.rst b/documentation/sdk-manual/appendix-customizing-standard.rst
index 90b634529e..9bc70cf55c 100644
--- a/documentation/sdk-manual/appendix-customizing-standard.rst
+++ b/documentation/sdk-manual/appendix-customizing-standard.rst
@@ -17,10 +17,10 @@ and
17variables control the set of packages adding to the SDK. 17variables control the set of packages adding to the SDK.
18 18
19If you want to add individual packages to the toolchain that runs on the 19If you want to add individual packages to the toolchain that runs on the
20host, simply add those packages to the ``TOOLCHAIN_HOST_TASK`` variable. 20host, simply add those packages to the :term:`TOOLCHAIN_HOST_TASK` variable.
21Similarly, if you want to add packages to the default set that is part 21Similarly, if you want to add packages to the default set that is part
22of the toolchain that runs on the target, add the packages to the 22of the toolchain that runs on the target, add the packages to the
23``TOOLCHAIN_TARGET_TASK`` variable. 23:term:`TOOLCHAIN_TARGET_TASK` variable.
24 24
25Adding API Documentation to the Standard SDK 25Adding API Documentation to the Standard SDK
26============================================ 26============================================
diff --git a/documentation/sdk-manual/appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst
index c122fb5836..8c635d1662 100644
--- a/documentation/sdk-manual/appendix-customizing.rst
+++ b/documentation/sdk-manual/appendix-customizing.rst
@@ -35,13 +35,13 @@ build system applies them against ``local.conf`` and ``auto.conf``:
35- Variables listed in 35- Variables listed in
36 :term:`SDK_LOCAL_CONF_WHITELIST` 36 :term:`SDK_LOCAL_CONF_WHITELIST`
37 are included. Including a variable in the value of 37 are included. Including a variable in the value of
38 ``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two 38 :term:`SDK_LOCAL_CONF_WHITELIST` overrides either of the previous two
39 filters. The default value is blank. 39 filters. The default value is blank.
40 40
41- Classes inherited globally with 41- Classes inherited globally with
42 :term:`INHERIT` that are listed in 42 :term:`INHERIT` that are listed in
43 :term:`SDK_INHERIT_BLACKLIST` 43 :term:`SDK_INHERIT_BLACKLIST`
44 are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these 44 are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these
45 classes is the typical method to disable classes that are problematic 45 classes is the typical method to disable classes that are problematic
46 or unnecessary in the SDK context. The default value blacklists the 46 or unnecessary in the SDK context. The default value blacklists the
47 :ref:`buildhistory <ref-classes-buildhistory>` 47 :ref:`buildhistory <ref-classes-buildhistory>`
@@ -95,7 +95,7 @@ adjustments:
95 95
96 - Disable the tasks if they are added by a class and you do not need 96 - Disable the tasks if they are added by a class and you do not need
97 the functionality the class provides in the extensible SDK. To 97 the functionality the class provides in the extensible SDK. To
98 disable the tasks, add the class to the ``SDK_INHERIT_BLACKLIST`` 98 disable the tasks, add the class to the :term:`SDK_INHERIT_BLACKLIST`
99 variable as described in the previous section. 99 variable as described in the previous section.
100 100
101- Generally, you want to have a shared state mirror set up so users of 101- Generally, you want to have a shared state mirror set up so users of
@@ -142,12 +142,12 @@ section.
142 142
143By default, this title is derived from 143By default, this title is derived from
144:term:`DISTRO_NAME` when it is 144:term:`DISTRO_NAME` when it is
145set. If the ``DISTRO_NAME`` variable is not set, the title is derived 145set. If the :term:`DISTRO_NAME` variable is not set, the title is derived
146from the :term:`DISTRO` variable. 146from the :term:`DISTRO` variable.
147 147
148The 148The
149:ref:`populate_sdk_base <ref-classes-populate-sdk-*>` 149:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
150class defines the default value of the ``SDK_TITLE`` variable as 150class defines the default value of the :term:`SDK_TITLE` variable as
151follows:: 151follows::
152 152
153 SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" 153 SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
@@ -158,7 +158,7 @@ creates an SDK installer title that applies across your distribution. As
158an example, assume you have your own layer for your distribution named 158an example, assume you have your own layer for your distribution named
159"meta-mydistro" and you are using the same type of file hierarchy as 159"meta-mydistro" and you are using the same type of file hierarchy as
160does the default "poky" distribution. If so, you could update the 160does the default "poky" distribution. If so, you could update the
161``SDK_TITLE`` variable in the 161:term:`SDK_TITLE` variable in the
162``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following 162``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
163form:: 163form::
164 164
@@ -220,7 +220,7 @@ class as follows::
220 220
221You can 221You can
222change this default installation directory by specifically setting the 222change this default installation directory by specifically setting the
223``SDKEXTPATH`` variable. 223:term:`SDKEXTPATH` variable.
224 224
225While there are several ways of setting this variable, 225While there are several ways of setting this variable,
226the method that makes the most sense is to set the variable in your 226the method that makes the most sense is to set the variable in your
@@ -229,7 +229,7 @@ default directory that applies across your distribution. As an example,
229assume you have your own layer for your distribution named 229assume you have your own layer for your distribution named
230"meta-mydistro" and you are using the same type of file hierarchy as 230"meta-mydistro" and you are using the same type of file hierarchy as
231does the default "poky" distribution. If so, you could update the 231does the default "poky" distribution. If so, you could update the
232``SDKEXTPATH`` variable in the 232:term:`SDKEXTPATH` variable in the
233``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following 233``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
234form:: 234form::
235 235
@@ -284,11 +284,11 @@ source, you need to do a number of things:
284 284
285 SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" 285 SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
286 286
287 - Alternatively, if you just want to set the ``SSTATE_MIRRORS`` 287 - Alternatively, if you just want to set the :term:`SSTATE_MIRRORS`
288 variable's value for the SDK alone, create a 288 variable's value for the SDK alone, create a
289 ``conf/sdk-extra.conf`` file either in your 289 ``conf/sdk-extra.conf`` file either in your
290 :term:`Build Directory` or within any 290 :term:`Build Directory` or within any
291 layer and put your ``SSTATE_MIRRORS`` setting within that file. 291 layer and put your :term:`SSTATE_MIRRORS` setting within that file.
292 292
293 .. note:: 293 .. note::
294 294
@@ -333,7 +333,7 @@ following::
333 333
334See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information. 334See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information.
335 335
336Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world" 336Setting the :term:`SDK_INCLUDE_PKGDATA` variable as shown causes the "world"
337target to be built so that information for all of the recipes included 337target to be built so that information for all of the recipes included
338within it are available. Having these recipes available increases build 338within it are available. Having these recipes available increases build
339time significantly and increases the size of the SDK installer by 30-80 339time significantly and increases the size of the SDK installer by 30-80
@@ -358,7 +358,7 @@ You can explicitly control whether or not to include the toolchain when
358you build an SDK by setting the 358you build an SDK by setting the
359:term:`SDK_INCLUDE_TOOLCHAIN` 359:term:`SDK_INCLUDE_TOOLCHAIN`
360variable to "1". In particular, it is useful to include the toolchain 360variable to "1". In particular, it is useful to include the toolchain
361when you have set ``SDK_EXT_TYPE`` to "minimal", which by default, 361when you have set :term:`SDK_EXT_TYPE` to "minimal", which by default,
362excludes the toolchain. Also, it is helpful if you are building a small 362excludes the toolchain. Also, it is helpful if you are building a small
363SDK for use with an IDE or some other tool where you do not want to take 363SDK for use with an IDE or some other tool where you do not want to take
364extra steps to install a toolchain. 364extra steps to install a toolchain.
diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst
index d444cad6ea..33032b42a7 100644
--- a/documentation/sdk-manual/extensible.rst
+++ b/documentation/sdk-manual/extensible.rst
@@ -438,7 +438,7 @@ command:
438 438
439 With this scenario, there is no ``srctree`` argument. Consequently, the 439 With this scenario, there is no ``srctree`` argument. Consequently, the
440 default behavior of the ``devtool modify`` command is to extract 440 default behavior of the ``devtool modify`` command is to extract
441 the source files pointed to by the ``SRC_URI`` statements into a 441 the source files pointed to by the :term:`SRC_URI` statements into a
442 local Git structure. Furthermore, the location for the extracted 442 local Git structure. Furthermore, the location for the extracted
443 source is the default area within the ``devtool`` workspace. The 443 source is the default area within the ``devtool`` workspace. The
444 result is that the command sets up both the source code and an 444 result is that the command sets up both the source code and an
@@ -446,7 +446,7 @@ command:
446 original location. 446 original location.
447 447
448 Additionally, if you have any non-patch local files (i.e. files 448 Additionally, if you have any non-patch local files (i.e. files
449 referred to with ``file://`` entries in ``SRC_URI`` statement 449 referred to with ``file://`` entries in :term:`SRC_URI` statement
450 excluding ``*.patch/`` or ``*.diff``), these files are copied to 450 excluding ``*.patch/`` or ``*.diff``), these files are copied to
451 an ``oe-local-files`` folder under the newly created source tree. 451 an ``oe-local-files`` folder under the newly created source tree.
452 Copying the files here gives you a convenient area from which you 452 Copying the files here gives you a convenient area from which you
@@ -476,7 +476,7 @@ command:
476 devtool 476 devtool
477 command. 477 command.
478 478
479 As with all extractions, the command uses the recipe's ``SRC_URI`` 479 As with all extractions, the command uses the recipe's :term:`SRC_URI`
480 statements to locate the source files and any associated patch 480 statements to locate the source files and any associated patch
481 files. Non-patch files are copied to an ``oe-local-files`` folder 481 files. Non-patch files are copied to an ``oe-local-files`` folder
482 under the newly created source tree. 482 under the newly created source tree.
@@ -655,18 +655,18 @@ The following diagram shows the common development flow used with the
655 don't use "-V", the command upgrades the recipe to the latest 655 don't use "-V", the command upgrades the recipe to the latest
656 version. 656 version.
657 657
658 If the source files pointed to by the ``SRC_URI`` statement in the 658 If the source files pointed to by the :term:`SRC_URI` statement in the
659 recipe are in a Git repository, you must provide the "-S" option and 659 recipe are in a Git repository, you must provide the "-S" option and
660 specify a revision for the software. 660 specify a revision for the software.
661 661
662 Once ``devtool`` locates the recipe, it uses the ``SRC_URI`` variable 662 Once ``devtool`` locates the recipe, it uses the :term:`SRC_URI` variable
663 to locate the source code and any local patch files from other 663 to locate the source code and any local patch files from other
664 developers. The result is that the command sets up the source code, 664 developers. The result is that the command sets up the source code,
665 the new version of the recipe, and an append file all within the 665 the new version of the recipe, and an append file all within the
666 workspace. 666 workspace.
667 667
668 Additionally, if you have any non-patch local files (i.e. files 668 Additionally, if you have any non-patch local files (i.e. files
669 referred to with ``file://`` entries in ``SRC_URI`` statement 669 referred to with ``file://`` entries in :term:`SRC_URI` statement
670 excluding ``*.patch/`` or ``*.diff``), these files are copied to an 670 excluding ``*.patch/`` or ``*.diff``), these files are copied to an
671 ``oe-local-files`` folder under the newly created source tree. 671 ``oe-local-files`` folder under the newly created source tree.
672 Copying the files here gives you a convenient area from which you can 672 Copying the files here gives you a convenient area from which you can
@@ -676,7 +676,7 @@ The following diagram shows the common development flow used with the
676 676
6772. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen 6772. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
678 after upgrading the software to a new version. Conflicts occur 678 after upgrading the software to a new version. Conflicts occur
679 if your recipe specifies some patch files in ``SRC_URI`` that 679 if your recipe specifies some patch files in :term:`SRC_URI` that
680 conflict with changes made in the new version of the software. For 680 conflict with changes made in the new version of the software. For
681 such cases, you need to resolve the conflicts by editing the source 681 such cases, you need to resolve the conflicts by editing the source
682 and following the normal ``git rebase`` conflict resolution process. 682 and following the normal ``git rebase`` conflict resolution process.
@@ -832,7 +832,7 @@ result from naming not being recognized or because the dependency simply
832is not available. For cases where the dependency is not available, you 832is not available. For cases where the dependency is not available, you
833must use the ``devtool add`` command to add an additional recipe that 833must use the ``devtool add`` command to add an additional recipe that
834satisfies the dependency. Once you add that recipe, you need to update 834satisfies the dependency. Once you add that recipe, you need to update
835the ``DEPENDS`` variable in the original recipe to include the new 835the :term:`DEPENDS` variable in the original recipe to include the new
836recipe. 836recipe.
837 837
838If you need to add runtime dependencies, you can do so by adding the 838If you need to add runtime dependencies, you can do so by adding the
@@ -861,7 +861,7 @@ license. If so, the command sets the
861:term:`LICENSE` value accordingly. 861:term:`LICENSE` value accordingly.
862You should double-check the value added by the command against the 862You should double-check the value added by the command against the
863documentation or source files for the software you are building and, if 863documentation or source files for the software you are building and, if
864necessary, update that ``LICENSE`` value. 864necessary, update that :term:`LICENSE` value.
865 865
866The ``devtool add`` command also sets the 866The ``devtool add`` command also sets the
867:term:`LIC_FILES_CHKSUM` 867:term:`LIC_FILES_CHKSUM`
@@ -869,16 +869,16 @@ value to point to all files that appear to be license-related. Realize
869that license statements often appear in comments at the top of source 869that license statements often appear in comments at the top of source
870files or within the documentation. In such cases, the command does not 870files or within the documentation. In such cases, the command does not
871recognize those license statements. Consequently, you might need to 871recognize those license statements. Consequently, you might need to
872amend the ``LIC_FILES_CHKSUM`` variable to point to one or more of those 872amend the :term:`LIC_FILES_CHKSUM` variable to point to one or more of those
873comments if present. Setting ``LIC_FILES_CHKSUM`` is particularly 873comments if present. Setting :term:`LIC_FILES_CHKSUM` is particularly
874important for third-party software. The mechanism attempts to ensure 874important for third-party software. The mechanism attempts to ensure
875correct licensing should you upgrade the recipe to a newer upstream 875correct licensing should you upgrade the recipe to a newer upstream
876version in future. Any change in licensing is detected and you receive 876version in future. Any change in licensing is detected and you receive
877an error prompting you to check the license text again. 877an error prompting you to check the license text again.
878 878
879If the ``devtool add`` command cannot determine licensing information, 879If the ``devtool add`` command cannot determine licensing information,
880``devtool`` sets the ``LICENSE`` value to "CLOSED" and leaves the 880``devtool`` sets the :term:`LICENSE` value to "CLOSED" and leaves the
881``LIC_FILES_CHKSUM`` value unset. This behavior allows you to continue 881:term:`LIC_FILES_CHKSUM` value unset. This behavior allows you to continue
882with development even though the settings are unlikely to be correct in 882with development even though the settings are unlikely to be correct in
883all cases. You should check the documentation or source files for the 883all cases. You should check the documentation or source files for the
884software you are building to determine the actual license. 884software you are building to determine the actual license.
@@ -904,7 +904,7 @@ mind:
904 hardcoding tools within the toolchain such as ``gcc`` and ``g++``. 904 hardcoding tools within the toolchain such as ``gcc`` and ``g++``.
905 905
906- The environment in which Make runs is set up with various standard 906- The environment in which Make runs is set up with various standard
907 variables for compilation (e.g. ``CC``, ``CXX``, and so forth) in a 907 variables for compilation (e.g. :term:`CC`, :term:`CXX`, and so forth) in a
908 similar manner to the environment set up by the SDK's environment 908 similar manner to the environment set up by the SDK's environment
909 setup script. One easy way to see these variables is to run the 909 setup script. One easy way to see these variables is to run the
910 ``devtool build`` command on the recipe and then look in 910 ``devtool build`` command on the recipe and then look in
@@ -920,7 +920,7 @@ mind:
920 the command line, add the variable setting to 920 the command line, add the variable setting to
921 :term:`EXTRA_OEMAKE` or 921 :term:`EXTRA_OEMAKE` or
922 :term:`PACKAGECONFIG_CONFARGS` 922 :term:`PACKAGECONFIG_CONFARGS`
923 within the recipe. Here is an example using ``EXTRA_OEMAKE``:: 923 within the recipe. Here is an example using :term:`EXTRA_OEMAKE`::
924 924
925 EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" 925 EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
926 926
@@ -1086,20 +1086,20 @@ extras specified by
1086:term:`EXTRA_OECONF` or 1086:term:`EXTRA_OECONF` or
1087:term:`PACKAGECONFIG_CONFARGS` 1087:term:`PACKAGECONFIG_CONFARGS`
1088set within the recipe. If you wish to pass additional options, add them 1088set within the recipe. If you wish to pass additional options, add them
1089to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build 1089to :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`. Other supported build
1090tools have similar variables (e.g. 1090tools have similar variables (e.g.
1091:term:`EXTRA_OECMAKE` for 1091:term:`EXTRA_OECMAKE` for
1092CMake, :term:`EXTRA_OESCONS` 1092CMake, :term:`EXTRA_OESCONS`
1093for Scons, and so forth). If you need to pass anything on the ``make`` 1093for Scons, and so forth). If you need to pass anything on the ``make``
1094command line, you can use ``EXTRA_OEMAKE`` or the 1094command line, you can use :term:`EXTRA_OEMAKE` or the
1095:term:`PACKAGECONFIG_CONFARGS` 1095:term:`PACKAGECONFIG_CONFARGS`
1096variables to do so. 1096variables to do so.
1097 1097
1098You can use the ``devtool configure-help`` command to help you set the 1098You can use the ``devtool configure-help`` command to help you set the
1099arguments listed in the previous paragraph. The command determines the 1099arguments listed in the previous paragraph. The command determines the
1100exact options being passed, and shows them to you along with any custom 1100exact options being passed, and shows them to you along with any custom
1101arguments specified through ``EXTRA_OECONF`` or 1101arguments specified through :term:`EXTRA_OECONF` or
1102``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you 1102:term:`PACKAGECONFIG_CONFARGS`. If applicable, the command also shows you
1103the output of the configure script's "--help" option as a 1103the output of the configure script's "--help" option as a
1104reference. 1104reference.
1105 1105
@@ -1151,16 +1151,16 @@ the ``oe-workdir/packages-split`` directory, which contains a
1151subdirectory for each package. Apart from some advanced cases, the 1151subdirectory for each package. Apart from some advanced cases, the
1152:term:`PACKAGES` and 1152:term:`PACKAGES` and
1153:term:`FILES` variables controls 1153:term:`FILES` variables controls
1154splitting. The ``PACKAGES`` variable lists all of the packages to be 1154splitting. The :term:`PACKAGES` variable lists all of the packages to be
1155produced, while the ``FILES`` variable specifies which files to include 1155produced, while the :term:`FILES` variable specifies which files to include
1156in each package by using an override to specify the package. For 1156in each package by using an override to specify the package. For
1157example, ``FILES_${PN}`` specifies the files to go into the main package 1157example, ``FILES_${PN}`` specifies the files to go into the main package
1158(i.e. the main package has the same name as the recipe and 1158(i.e. the main package has the same name as the recipe and
1159``${``\ :term:`PN`\ ``}`` evaluates to the 1159``${``\ :term:`PN`\ ``}`` evaluates to the
1160recipe name). The order of the ``PACKAGES`` value is significant. For 1160recipe name). The order of the :term:`PACKAGES` value is significant. For
1161each installed file, the first package whose ``FILES`` value matches the 1161each installed file, the first package whose :term:`FILES` value matches the
1162file is the package into which the file goes. Both the ``PACKAGES`` and 1162file is the package into which the file goes. Both the :term:`PACKAGES` and
1163``FILES`` variables have default values. Consequently, you might find 1163:term:`FILES` variables have default values. Consequently, you might find
1164you do not even need to set these variables in your recipe unless the 1164you do not even need to set these variables in your recipe unless the
1165software the recipe is building installs files into non-standard 1165software the recipe is building installs files into non-standard
1166locations. 1166locations.
diff --git a/documentation/sdk-manual/working-projects.rst b/documentation/sdk-manual/working-projects.rst
index c482c38c70..27c69ca7dd 100644
--- a/documentation/sdk-manual/working-projects.rst
+++ b/documentation/sdk-manual/working-projects.rst
@@ -278,9 +278,9 @@ example:
278 $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux 278 $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
279 279
2803. *Create the Makefile:* For this example, the Makefile contains 2803. *Create the Makefile:* For this example, the Makefile contains
281 two lines that can be used to set the ``CC`` variable. One line is 281 two lines that can be used to set the :term:`CC` variable. One line is
282 identical to the value that is set when you run the SDK environment 282 identical to the value that is set when you run the SDK environment
283 setup script, and the other line sets ``CC`` to "gcc", the default 283 setup script, and the other line sets :term:`CC` to "gcc", the default
284 GNU compiler on the build host:: 284 GNU compiler on the build host::
285 285
286 # CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux 286 # CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
@@ -297,7 +297,7 @@ example:
297 297
2984. *Make the Project:* Use the ``make`` command to create the binary 2984. *Make the Project:* Use the ``make`` command to create the binary
299 output file. Because variables are commented out in the Makefile, the 299 output file. Because variables are commented out in the Makefile, the
300 value used for ``CC`` is the value set when the SDK environment setup 300 value used for :term:`CC` is the value set when the SDK environment setup
301 file was run:: 301 file was run::
302 302
303 $ make 303 $ make
@@ -306,10 +306,10 @@ example:
306 i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin 306 i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
307 307
308 From the results of the previous command, you can see that 308 From the results of the previous command, you can see that
309 the compiler used was the compiler established through the ``CC`` 309 the compiler used was the compiler established through the :term:`CC`
310 variable defined in the setup script. 310 variable defined in the setup script.
311 311
312 You can override the ``CC`` environment variable with the same 312 You can override the :term:`CC` environment variable with the same
313 variable as set from the Makefile by uncommenting the line in the 313 variable as set from the Makefile by uncommenting the line in the
314 Makefile and running ``make`` again. 314 Makefile and running ``make`` again.
315 :: 315 ::
@@ -333,7 +333,7 @@ example:
333 variable as part of the command line. Go into the Makefile and 333 variable as part of the command line. Go into the Makefile and
334 re-insert the comment character so that running ``make`` uses the 334 re-insert the comment character so that running ``make`` uses the
335 established SDK compiler. However, when you run ``make``, use a 335 established SDK compiler. However, when you run ``make``, use a
336 command-line argument to set ``CC`` to "gcc":: 336 command-line argument to set :term:`CC` to "gcc"::
337 337
338 $ make clean 338 $ make clean
339 rm -rf *.o 339 rm -rf *.o
diff --git a/documentation/toaster-manual/setup-and-use.rst b/documentation/toaster-manual/setup-and-use.rst
index 8f0ec94496..4f71b58418 100644
--- a/documentation/toaster-manual/setup-and-use.rst
+++ b/documentation/toaster-manual/setup-and-use.rst
@@ -625,7 +625,7 @@ To specify ``bash`` 3.2.48 as the version to build, enter
625 :scale: 75% 625 :scale: 75%
626 626
627After clicking the "Add variable" button, the settings for 627After clicking the "Add variable" button, the settings for
628``PREFERRED_VERSION`` are added to the bottom of the BitBake variables 628:term:`PREFERRED_VERSION` are added to the bottom of the BitBake variables
629list. With these settings, the OpenEmbedded build system builds the 629list. With these settings, the OpenEmbedded build system builds the
630desired version of the recipe rather than the default version: 630desired version of the recipe rather than the default version:
631 631
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index abbd74ca1d..f0035bd3af 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -47,7 +47,7 @@ Transitioning to a custom environment for systems development
47#. **Based on the layers you've chosen, make needed changes in your 47#. **Based on the layers you've chosen, make needed changes in your
48 configuration**. 48 configuration**.
49 For instance, you've chosen a machine type and added in the corresponding BSP 49 For instance, you've chosen a machine type and added in the corresponding BSP
50 layer. You'll then need to change the value of the ``MACHINE`` variable in your 50 layer. You'll then need to change the value of the :term:`MACHINE` variable in your
51 configuration file (build/local.conf) to point to that same machine 51 configuration file (build/local.conf) to point to that same machine
52 type. There could be other layer-specific settings you need to change as 52 type. There could be other layer-specific settings you need to change as
53 well. Each layer has a ``README`` document that you can look at for this type of 53 well. Each layer has a ``README`` document that you can look at for this type of