summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorNicolas Dechesne <nicolas.dechesne@linaro.org>2020-07-24 16:27:54 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-09-17 10:09:33 +0100
commitc473fa229239752367c5d573160fc8738cf1907e (patch)
treef8520ba3aa3cf911333dbd31e38e9a52203a0285 /documentation
parent4cd953989de42c7a83f666c23e077d53b016a1f1 (diff)
downloadpoky-c473fa229239752367c5d573160fc8738cf1907e.tar.gz
sphinx: fix internal links
Many of the internal links were not converted probably from DocBook using pandoc. After looking at the various patterns, the follow series of 'naive' Python regexp were used to perform some additional automatic conversion. Also, since we rely on built-in glossary, all links to terms need to use the sphinx :term: syntax. This commit is generated using the following Python series of regexp: line = re.sub("`+(\w+)`* <(\&YOCTO_DOCS_REF_URL;)?#var-\\1>`__", ":term:`\\1`", line) line = re.sub("`+do_([a-z_]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-tasks-\\1>`__", ":ref:`ref-tasks-\\1`", line) line = re.sub("`+([a-z_\-\*\.]+).bbclass`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__", ":ref:`\\1.bbclass <ref-classes-\\1>`", line) line = re.sub("`+([a-z_\-\*\.]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__", ":ref:`\\1 <ref-classes-\\1>`", line) line = re.sub("`Source Directory <(\&YOCTO_DOCS_REF_URL;)?#source-directory>`__", ":term:`Source Directory`", line) line = re.sub("`Build Directory <(\&YOCTO_DOCS_REF_URL;)?#build-directory>`__", ":term:`Build Directory`", line) line = re.sub("`Metadata <(\&YOCTO_DOCS_REF_URL;)?#metadata>`__", ":term:`Metadata`", line) line = re.sub("`BitBake <(\&YOCTO_DOCS_REF_URL;)?#bitbake-term>`__", ":term:`BitBake`", line) line = re.sub("`Images <(\&YOCTO_DOCS_REF_URL;)?#ref-images>`__", ":ref:`ref-manual/ref-images:Images`", line) line = re.sub("`Classes <(\&YOCTO_DOCS_REF_URL;)?#ref-classes>`__", ":ref:`ref-manual/ref-classes:Classes`", line) line = re.sub("`workspace <(\&YOCTO_DOCS_REF_URL;)?#devtool-the-workspace-layer-structure>`__", ":ref:`devtool-the-workspace-layer-structure`", line) line = re.sub("`Open-?Embedded b?B?uild s?S?ystem <(\&YOCTO_DOCS_REF_URL;)?#build-system-term>`__", ":term:`OpenEmbedded Build System`", line) line = re.sub("`(OpenEmbedded-Core )?(\(?OE-Core\)? )?<(\&YOCTO_DOCS_REF_URL;)?#oe-core>`__", ":term:`OpenEmbedded-Core (OE-Core)`", line) It won't catch multiline strings, but it catches a very large number of occurences! (From yocto-docs rev: 3f537d17de5b1fb76ba3bee196481984a4826378) Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/adt-manual/adt-command.rst10
-rw-r--r--documentation/adt-manual/adt-package.rst2
-rw-r--r--documentation/adt-manual/adt-prepare.rst66
-rw-r--r--documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst2
-rw-r--r--documentation/bsp-guide/bsp.rst76
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.rst768
-rw-r--r--documentation/dev-manual/dev-manual-qemu.rst2
-rw-r--r--documentation/dev-manual/dev-manual-start.rst4
-rw-r--r--documentation/kernel-dev/kernel-dev-advanced.rst54
-rw-r--r--documentation/kernel-dev/kernel-dev-common.rst134
-rw-r--r--documentation/kernel-dev/kernel-dev-concepts-appx.rst2
-rw-r--r--documentation/kernel-dev/kernel-dev-faq.rst10
-rw-r--r--documentation/kernel-dev/kernel-dev-intro.rst2
-rw-r--r--documentation/kernel-dev/kernel-dev-maint-appx.rst4
-rw-r--r--documentation/overview-manual/overview-manual-concepts.rst342
-rw-r--r--documentation/overview-manual/overview-manual-development-environment.rst6
-rw-r--r--documentation/overview-manual/overview-manual-yp-intro.rst20
-rw-r--r--documentation/profile-manual/profile-manual-intro.rst4
-rw-r--r--documentation/profile-manual/profile-manual-usage.rst6
-rw-r--r--documentation/ref-manual/faq.rst16
-rw-r--r--documentation/ref-manual/migration.rst508
-rw-r--r--documentation/ref-manual/ref-classes.rst516
-rw-r--r--documentation/ref-manual/ref-devtool-reference.rst10
-rw-r--r--documentation/ref-manual/ref-features.rst30
-rw-r--r--documentation/ref-manual/ref-images.rst2
-rw-r--r--documentation/ref-manual/ref-kickstart.rst2
-rw-r--r--documentation/ref-manual/ref-qa-checks.rst132
-rw-r--r--documentation/ref-manual/ref-release-process.rst10
-rw-r--r--documentation/ref-manual/ref-structure.rst58
-rw-r--r--documentation/ref-manual/ref-tasks.rst126
-rw-r--r--documentation/ref-manual/ref-terms.rst16
-rw-r--r--documentation/ref-manual/ref-variables.rst1336
-rw-r--r--documentation/ref-manual/resources.rst4
-rw-r--r--documentation/sdk-manual/sdk-appendix-customizing-standard.rst6
-rw-r--r--documentation/sdk-manual/sdk-appendix-customizing.rst50
-rw-r--r--documentation/sdk-manual/sdk-appendix-obtain.rst8
-rw-r--r--documentation/sdk-manual/sdk-extensible.rst64
-rw-r--r--documentation/sdk-manual/sdk-intro.rst10
-rw-r--r--documentation/sdk-manual/sdk-working-projects.rst4
-rw-r--r--documentation/test-manual/test-manual-intro.rst14
-rw-r--r--documentation/toaster-manual/toaster-manual-reference.rst2
-rw-r--r--documentation/toaster-manual/toaster-manual-setup-and-use.rst4
42 files changed, 2221 insertions, 2221 deletions
diff --git a/documentation/adt-manual/adt-command.rst b/documentation/adt-manual/adt-command.rst
index 2b81016b68..8b86544f19 100644
--- a/documentation/adt-manual/adt-command.rst
+++ b/documentation/adt-manual/adt-command.rst
@@ -85,7 +85,7 @@ Follow these steps to create a simple Autotools-based project:
85 85
867. *Cross-compile the project:* This command compiles the project using 867. *Cross-compile the project:* This command compiles the project using
87 the cross-compiler. The 87 the cross-compiler. The
88 ```CONFIGURE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS>`__ 88 :term:`CONFIGURE_FLAGS`
89 environment variable provides the minimal arguments for GNU 89 environment variable provides the minimal arguments for GNU
90 configure: $ ./configure ${CONFIGURE_FLAGS} 90 configure: $ ./configure ${CONFIGURE_FLAGS}
91 91
@@ -146,13 +146,13 @@ subject to general ``make`` rules.
146 146
147To illustrate this, consider the following four cross-toolchain 147To illustrate this, consider the following four cross-toolchain
148environment variables: 148environment variables:
149`CC <&YOCTO_DOCS_REF_URL;#var-CC>`__\ =i586-poky-linux-gcc -m32 149:term:`CC`\ =i586-poky-linux-gcc -m32
150-march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux 150-march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
151`LD <&YOCTO_DOCS_REF_URL;#var-LD>`__\ =i586-poky-linux-ld 151:term:`LD`\ =i586-poky-linux-ld
152--sysroot=/opt/poky/1.8/sysroots/i586-poky-linux 152--sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
153`CFLAGS <&YOCTO_DOCS_REF_URL;#var-CFLAGS>`__\ =-O2 -pipe -g 153:term:`CFLAGS`\ =-O2 -pipe -g
154-feliminate-unused-debug-types 154-feliminate-unused-debug-types
155`CXXFLAGS <&YOCTO_DOCS_REF_URL;#var-CXXFLAGS>`__\ =-O2 -pipe -g 155:term:`CXXFLAGS`\ =-O2 -pipe -g
156-feliminate-unused-debug-types Now, consider the following three cases: 156-feliminate-unused-debug-types Now, consider the following three cases:
157 157
158- *Case 1 - No Variables Set in the ``Makefile``:* Because these 158- *Case 1 - No Variables Set in the ``Makefile``:* Because these
diff --git a/documentation/adt-manual/adt-package.rst b/documentation/adt-manual/adt-package.rst
index cea535072d..38823a104f 100644
--- a/documentation/adt-manual/adt-package.rst
+++ b/documentation/adt-manual/adt-package.rst
@@ -38,7 +38,7 @@ Configuring the PMS
38=================== 38===================
39 39
40Whichever PMS you are using, you need to be sure that the 40Whichever PMS you are using, you need to be sure that the
41```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__ 41:term:`PACKAGE_CLASSES`
42variable in the ``conf/local.conf`` file is set to reflect that system. 42variable in the ``conf/local.conf`` file is set to reflect that system.
43The first value you choose for the variable specifies the package file 43The first value you choose for the variable specifies the package file
44format for the root filesystem at sysroot. Additional values specify 44format for the root filesystem at sysroot. Additional values specify
diff --git a/documentation/adt-manual/adt-prepare.rst b/documentation/adt-manual/adt-prepare.rst
index eea12ec0c8..12b1e7918c 100644
--- a/documentation/adt-manual/adt-prepare.rst
+++ b/documentation/adt-manual/adt-prepare.rst
@@ -284,7 +284,7 @@ Follow these steps to generate the toolchain into the Build Directory:
284 Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__. 284 Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__.
285 285
2862. *Check your Local Configuration File:* At this point, you should be 2862. *Check your Local Configuration File:* At this point, you should be
287 sure that the ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ 287 sure that the :term:`MACHINE`
288 variable in the ``local.conf`` file found in the ``conf`` directory 288 variable in the ``local.conf`` file found in the ``conf`` directory
289 of the Build Directory is set for the target architecture. Comments 289 of the Build Directory is set for the target architecture. Comments
290 within the ``local.conf`` file list the values you can use for the 290 within the ``local.conf`` file list the values you can use for the
@@ -345,45 +345,45 @@ setup script for a 64-bit IA-based architecture installed in the default
345installation directory would be the following: 345installation directory would be the following:
346YOCTO_ADTPATH_DIR/environment-setup-x86_64-poky-linux When you run the 346YOCTO_ADTPATH_DIR/environment-setup-x86_64-poky-linux When you run the
347setup script, many environment variables are defined: 347setup script, many environment variables are defined:
348```SDKTARGETSYSROOT`` <&YOCTO_DOCS_REF_URL;#var-SDKTARGETSYSROOT>`__ - 348:term:`SDKTARGETSYSROOT` -
349The path to the sysroot used for cross-compilation 349The path to the sysroot used for cross-compilation
350```PKG_CONFIG_PATH`` <&YOCTO_DOCS_REF_URL;#var-PKG_CONFIG_PATH>`__ - The 350:term:`PKG_CONFIG_PATH` - The
351path to the target pkg-config files 351path to the target pkg-config files
352```CONFIG_SITE`` <&YOCTO_DOCS_REF_URL;#var-CONFIG_SITE>`__ - A GNU 352:term:`CONFIG_SITE` - A GNU
353autoconf site file preconfigured for the target 353autoconf site file preconfigured for the target
354```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ - The minimal command and 354:term:`CC` - The minimal command and
355arguments to run the C compiler 355arguments to run the C compiler
356```CXX`` <&YOCTO_DOCS_REF_URL;#var-CXX>`__ - The minimal command and 356:term:`CXX` - The minimal command and
357arguments to run the C++ compiler 357arguments to run the C++ compiler
358```CPP`` <&YOCTO_DOCS_REF_URL;#var-CPP>`__ - The minimal command and 358:term:`CPP` - The minimal command and
359arguments to run the C preprocessor 359arguments to run the C preprocessor
360```AS`` <&YOCTO_DOCS_REF_URL;#var-AS>`__ - The minimal command and 360:term:`AS` - The minimal command and
361arguments to run the assembler ```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__ 361arguments to run the assembler :term:`LD`
362- The minimal command and arguments to run the linker 362- The minimal command and arguments to run the linker
363```GDB`` <&YOCTO_DOCS_REF_URL;#var-GDB>`__ - The minimal command and 363:term:`GDB` - The minimal command and
364arguments to run the GNU Debugger 364arguments to run the GNU Debugger
365```STRIP`` <&YOCTO_DOCS_REF_URL;#var-STRIP>`__ - The minimal command and 365:term:`STRIP` - The minimal command and
366arguments to run 'strip', which strips symbols 366arguments to run 'strip', which strips symbols
367```RANLIB`` <&YOCTO_DOCS_REF_URL;#var-RANLIB>`__ - The minimal command 367:term:`RANLIB` - The minimal command
368and arguments to run 'ranlib' 368and arguments to run 'ranlib'
369```OBJCOPY`` <&YOCTO_DOCS_REF_URL;#var-OBJCOPY>`__ - The minimal command 369:term:`OBJCOPY` - The minimal command
370and arguments to run 'objcopy' 370and arguments to run 'objcopy'
371```OBJDUMP`` <&YOCTO_DOCS_REF_URL;#var-OBJDUMP>`__ - The minimal command 371:term:`OBJDUMP` - The minimal command
372and arguments to run 'objdump' ```AR`` <&YOCTO_DOCS_REF_URL;#var-AR>`__ 372and arguments to run 'objdump' :term:`AR`
373- The minimal command and arguments to run 'ar' 373- The minimal command and arguments to run 'ar'
374```NM`` <&YOCTO_DOCS_REF_URL;#var-NM>`__ - The minimal command and 374:term:`NM` - The minimal command and
375arguments to run 'nm' 375arguments to run 'nm'
376```TARGET_PREFIX`` <&YOCTO_DOCS_REF_URL;#var-TARGET_PREFIX>`__ - The 376:term:`TARGET_PREFIX` - The
377toolchain binary prefix for the target tools 377toolchain binary prefix for the target tools
378```CROSS_COMPILE`` <&YOCTO_DOCS_REF_URL;#var-CROSS_COMPILE>`__ - The 378:term:`CROSS_COMPILE` - The
379toolchain binary prefix for the target tools 379toolchain binary prefix for the target tools
380```CONFIGURE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS>`__ - The 380:term:`CONFIGURE_FLAGS` - The
381minimal arguments for GNU configure 381minimal arguments for GNU configure
382```CFLAGS`` <&YOCTO_DOCS_REF_URL;#var-CFLAGS>`__ - Suggested C flags 382:term:`CFLAGS` - Suggested C flags
383```CXXFLAGS`` <&YOCTO_DOCS_REF_URL;#var-CXXFLAGS>`__ - Suggested C++ 383:term:`CXXFLAGS` - Suggested C++
384flags ```LDFLAGS`` <&YOCTO_DOCS_REF_URL;#var-LDFLAGS>`__ - Suggested 384flags :term:`LDFLAGS` - Suggested
385linker flags when you use CC to link 385linker flags when you use CC to link
386```CPPFLAGS`` <&YOCTO_DOCS_REF_URL;#var-CPPFLAGS>`__ - Suggested 386:term:`CPPFLAGS` - Suggested
387preprocessor flags 387preprocessor flags
388 388
389Securing Kernel and Filesystem Images 389Securing Kernel and Filesystem Images
@@ -411,7 +411,7 @@ that you can use unaltered in the QEMU emulator. These kernel images
411reside in the release area - ` <&YOCTO_MACHINES_DL_URL;>`__ and are 411reside in the release area - ` <&YOCTO_MACHINES_DL_URL;>`__ and are
412ideal for experimentation using Yocto Project. For information on the 412ideal for experimentation using Yocto Project. For information on the
413image types you can build using the OpenEmbedded build system, see the 413image types you can build using the OpenEmbedded build system, see the
414"`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the Yocto 414":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
415Project Reference Manual. 415Project Reference Manual.
416 416
417If you are planning on developing against your image and you are not 417If you are planning on developing against your image and you are not
@@ -434,7 +434,7 @@ this by including the ``eclipse-debug`` image feature.
434To include the ``eclipse-debug`` image feature, modify your 434To include the ``eclipse-debug`` image feature, modify your
435``local.conf`` file in the `Build 435``local.conf`` file in the `Build
436Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ so that the 436Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ so that the
437```EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES>`__ 437:term:`EXTRA_IMAGE_FEATURES`
438variable includes the "eclipse-debug" feature. After modifying the 438variable includes the "eclipse-debug" feature. After modifying the
439configuration file, you can rebuild the image. Once the image is 439configuration file, you can rebuild the image. Once the image is
440rebuilt, the ``tcf-agent`` will be included in the image and is launched 440rebuilt, the ``tcf-agent`` will be included in the image and is launched
@@ -513,8 +513,8 @@ Another feature is that only one set of cross-canadian toolchain
513binaries are produced per architecture. This feature takes advantage of 513binaries are produced per architecture. This feature takes advantage of
514the fact that the target hardware can be passed to ``gcc`` as a set of 514the fact that the target hardware can be passed to ``gcc`` as a set of
515compiler options. Those options are set up by the environment script and 515compiler options. Those options are set up by the environment script and
516contained in variables such as ```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ 516contained in variables such as :term:`CC`
517and ```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__. This reduces the space 517and :term:`LD`. This reduces the space
518needed for the tools. Understand, however, that a sysroot is still 518needed for the tools. Understand, however, that a sysroot is still
519needed for every target since those binaries are target-specific. 519needed for every target since those binaries are target-specific.
520 520
@@ -524,9 +524,9 @@ environment setup script (i.e.
524```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__) 524```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
525located in the Source Directory and you must make sure your 525located in the Source Directory and you must make sure your
526``conf/local.conf`` variables are correct. In particular, you need to be 526``conf/local.conf`` variables are correct. In particular, you need to be
527sure the ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable 527sure the :term:`MACHINE` variable
528matches the architecture for which you are building and that the 528matches the architecture for which you are building and that the
529```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__ variable is 529:term:`SDKMACHINE` variable is
530correctly set if you are building a toolchain designed to run on an 530correctly set if you are building a toolchain designed to run on an
531architecture that differs from your current development host machine 531architecture that differs from your current development host machine
532(i.e. the build machine). 532(i.e. the build machine).
@@ -565,10 +565,10 @@ follows:
565 565
566- Make sure you add the layer that contains the toolchain to your 566- Make sure you add the layer that contains the toolchain to your
567 ``bblayers.conf`` file through the 567 ``bblayers.conf`` file through the
568 ```BBLAYERS`` <&YOCTO_DOCS_REF_URL;#var-BBLAYERS>`__ variable. 568 :term:`BBLAYERS` variable.
569 569
570- Set the 570- Set the
571 ```EXTERNAL_TOOLCHAIN`` <&YOCTO_DOCS_REF_URL;#var-EXTERNAL_TOOLCHAIN>`__ 571 :term:`EXTERNAL_TOOLCHAIN`
572 variable in your ``local.conf`` file to the location in which you 572 variable in your ``local.conf`` file to the location in which you
573 installed the toolchain. 573 installed the toolchain.
574 574
@@ -577,7 +577,7 @@ Mentor Graphics Sourcery G++ Toolchain. You can see information on how
577to use that particular layer in the ``README`` file at 577to use that particular layer in the ``README`` file at
578` <http://github.com/MentorEmbedded/meta-sourcery/>`__. You can find 578` <http://github.com/MentorEmbedded/meta-sourcery/>`__. You can find
579further information by reading about the 579further information by reading about the
580```TCMODE`` <&YOCTO_DOCS_REF_URL;#var-TCMODE>`__ variable in the Yocto 580:term:`TCMODE` variable in the Yocto
581Project Reference Manual's variable glossary. 581Project Reference Manual's variable glossary.
582 582
583.. _using-pre-built: 583.. _using-pre-built:
@@ -712,7 +712,7 @@ core-image-profile-qemuarch.ext3 core-image-profile-qemuarch.tar.bz2
712Where: profile is the filesystem image's profile: lsb, lsb-dev, lsb-sdk, 712Where: profile is the filesystem image's profile: lsb, lsb-dev, lsb-sdk,
713lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk. For 713lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk. For
714information on these types of image profiles, see the 714information on these types of image profiles, see the
715"`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the Yocto 715":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
716Project Reference Manual. arch is a string representing the target 716Project Reference Manual. arch is a string representing the target
717architecture: x86, x86-64, ppc, mips, or arm. 717architecture: x86, x86-64, ppc, mips, or arm.
718 718
diff --git a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
index f80ec305ab..712d5c7f8e 100644
--- a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
@@ -257,7 +257,7 @@ Follow these steps to add a hardware layer:
257 support hardware from Altera, which is owned by Intel. 257 support hardware from Altera, which is owned by Intel.
258 258
2593. *Change the Configuration to Build for a Specific Machine:* The 2593. *Change the Configuration to Build for a Specific Machine:* The
260 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable in the 260 :term:`MACHINE` variable in the
261 ``local.conf`` file specifies the machine for the build. For this 261 ``local.conf`` file specifies the machine for the build. For this
262 example, set the ``MACHINE`` variable to "cyclone5". These 262 example, set the ``MACHINE`` variable to "cyclone5". These
263 configurations are used: 263 configurations are used:
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 42c8190124..4517604a2a 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -73,7 +73,7 @@ section in the Yocto Project Development Tasks Manual.
73 73
74The BSP layer's base directory (``meta-bsp_root_name``) is the root 74The BSP layer's base directory (``meta-bsp_root_name``) is the root
75directory of that Layer. This directory is what you add to the 75directory of that Layer. This directory is what you add to the
76```BBLAYERS`` <&YOCTO_DOCS_REF_URL;#var-BBLAYERS>`__ variable in the 76:term:`BBLAYERS` variable in the
77``conf/bblayers.conf`` file found in your `Build 77``conf/bblayers.conf`` file found in your `Build
78Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is 78Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
79established after you run the OpenEmbedded build environment setup 79established after you run the OpenEmbedded build environment setup
@@ -466,7 +466,7 @@ This file provides information on where to locate the BSP source files
466used to build the images (if any) that reside in 466used to build the images (if any) that reside in
467``meta-bsp_root_name/binary``. Images in the ``binary`` would be images 467``meta-bsp_root_name/binary``. Images in the ``binary`` would be images
468released with the BSP. The information in the ``README.sources`` file 468released with the BSP. The information in the ``README.sources`` file
469also helps you find the `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ 469also helps you find the :term:`Metadata`
470used to generate the images that ship with the BSP. 470used to generate the images that ship with the BSP.
471 471
472.. note:: 472.. note::
@@ -532,7 +532,7 @@ BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/"
532BBFILE_PRIORITY_raspberrypi = "9" # Additional license directories. 532BBFILE_PRIORITY_raspberrypi = "9" # Additional license directories.
533LICENSE_PATH += "${LAYERDIR}/files/custom-licenses" . . . 533LICENSE_PATH += "${LAYERDIR}/files/custom-licenses" . . .
534 534
535This file simply makes `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ 535This file simply makes :term:`BitBake`
536aware of the recipes and configuration directories. The file must exist 536aware of the recipes and configuration directories. The file must exist
537so that the OpenEmbedded build system can recognize the BSP. 537so that the OpenEmbedded build system can recognize the BSP.
538 538
@@ -549,10 +549,10 @@ in the BSP into a format that the build system can understand. Each BSP
549Layer requires at least one machine file. If the BSP supports multiple 549Layer requires at least one machine file. If the BSP supports multiple
550machines, multiple machine configuration files can exist. These 550machines, multiple machine configuration files can exist. These
551filenames correspond to the values to which users have set the 551filenames correspond to the values to which users have set the
552```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable. 552:term:`MACHINE` variable.
553 553
554These files define things such as the kernel package to use 554These files define things such as the kernel package to use
555(```PREFERRED_PROVIDER`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER>`__ 555(:term:`PREFERRED_PROVIDER`
556of 556of
557`virtual/kernel <&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers>`__), 557`virtual/kernel <&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers>`__),
558the hardware drivers to include in different types of images, any 558the hardware drivers to include in different types of images, any
@@ -565,7 +565,7 @@ optimization flags, which are carefully chosen to give best performance
565on a given processor. 565on a given processor.
566 566
567Tuning files are found in the ``meta/conf/machine/include`` directory 567Tuning files are found in the ``meta/conf/machine/include`` directory
568within the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. 568within the :term:`Source Directory`.
569For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``, 569For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``,
570``tune-1586-nlp.inc``, and so forth) reside in the 570``tune-1586-nlp.inc``, and so forth) reside in the
571``poky/meta/conf/machine/include`` directory. 571``poky/meta/conf/machine/include`` directory.
@@ -599,7 +599,7 @@ DISPLAY_ORIENTATION=0 DISPLAY_DPI=133
599 according to the formfactor configuration file that is installed by 599 according to the formfactor configuration file that is installed by
600 the main formfactor recipe 600 the main formfactor recipe
601 ``meta/recipes-bsp/formfactor/formfactor_0.0.bb``, which is found in 601 ``meta/recipes-bsp/formfactor/formfactor_0.0.bb``, which is found in
602 the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. 602 the :term:`Source Directory`.
603 603
604.. _bsp-filelayout-recipes-graphics: 604.. _bsp-filelayout-recipes-graphics:
605 605
@@ -639,9 +639,9 @@ located in the BSP Layer for your target device (e.g. the
639Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the 639Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the
640kernel. In other words, you have selected the kernel in your 640kernel. In other words, you have selected the kernel in your
641bsp_root_name\ ``.conf`` file by adding 641bsp_root_name\ ``.conf`` file by adding
642```PREFERRED_PROVIDER`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER>`__ 642:term:`PREFERRED_PROVIDER`
643and 643and
644```PREFERRED_VERSION`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION>`__ 644:term:`PREFERRED_VERSION`
645statements as follows: PREFERRED_PROVIDER_virtual/kernel ?= 645statements as follows: PREFERRED_PROVIDER_virtual/kernel ?=
646"linux-yocto" PREFERRED_VERSION_linux-yocto ?= "4.4%" 646"linux-yocto" PREFERRED_VERSION_linux-yocto ?= "4.4%"
647 647
@@ -796,7 +796,7 @@ workflow.
796 796
797 The build process supports several types of images to satisfy 797 The build process supports several types of images to satisfy
798 different needs. See the 798 different needs. See the
799 "`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the Yocto 799 ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
800 Project Reference Manual for information on supported images. 800 Project Reference Manual for information on supported images.
801 801
802Requirements and Recommendations for Released BSPs 802Requirements and Recommendations for Released BSPs
@@ -1038,7 +1038,7 @@ also supports several other machines:
1038 1038
1039 1039
1040 The 1040 The
1041 ```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 1041 :term:`FILESEXTRAPATHS`
1042 variable in the append files extends the search path the build system 1042 variable in the append files extends the search path the build system
1043 uses to find files during the build. Consequently, for this example 1043 uses to find files during the build. Consequently, for this example
1044 you need to have the ``files`` directory in the same location as your 1044 you need to have the ``files`` directory in the same location as your
@@ -1090,11 +1090,11 @@ satisfy the licensing requirements for an encumbered BSP. The following
1090list describes them in order of preference: 1090list describes them in order of preference:
1091 1091
10921. *Use 10921. *Use
1093 the*\ ```LICENSE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS>`__\ *Variable 1093 the*\ :term:`LICENSE_FLAGS`\ *Variable
1094 to Define the Recipes that Have Commercial or Other Types of 1094 to Define the Recipes that Have Commercial or Other Types of
1095 Specially-Licensed Packages:* For each of those recipes, you can 1095 Specially-Licensed Packages:* For each of those recipes, you can
1096 specify a matching license string in a ``local.conf`` variable named 1096 specify a matching license string in a ``local.conf`` variable named
1097 ```LICENSE_FLAGS_WHITELIST`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS_WHITELIST>`__. 1097 :term:`LICENSE_FLAGS_WHITELIST`.
1098 Specifying the matching license string signifies that you agree to 1098 Specifying the matching license string signifies that you agree to
1099 the license. Thus, the build system can build the corresponding 1099 the license. Thus, the build system can build the corresponding
1100 recipe and include the component in the image. See the "`Enabling 1100 recipe and include the component in the image. See the "`Enabling
@@ -1266,12 +1266,12 @@ Project Reference Manual.
1266 "virtual/xserver" is "xserver-xorg", which exists in 1266 "virtual/xserver" is "xserver-xorg", which exists in
1267 ``poky/meta/recipes-graphics/xorg-xserver``. 1267 ``poky/meta/recipes-graphics/xorg-xserver``.
1268 1268
1269- ```XSERVER`` <&YOCTO_DOCS_REF_URL;#var-XSERVER>`__: The packages that 1269- :term:`XSERVER`: The packages that
1270 should be installed to provide an X server and drivers for the 1270 should be installed to provide an X server and drivers for the
1271 machine. In this example, the "xserver-xorg" and 1271 machine. In this example, the "xserver-xorg" and
1272 "xf86-video-modesetting" are installed. 1272 "xf86-video-modesetting" are installed.
1273 1273
1274- ```MACHINE_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS>`__: 1274- :term:`MACHINE_EXTRA_RRECOMMENDS`:
1275 A list of machine-dependent packages not essential for booting the 1275 A list of machine-dependent packages not essential for booting the
1276 image. Thus, the build does not fail if the packages do not exist. 1276 image. Thus, the build does not fail if the packages do not exist.
1277 However, the packages are required for a fully-featured image. 1277 However, the packages are required for a fully-featured image.
@@ -1283,14 +1283,14 @@ Project Reference Manual.
1283 variables exist that help you configure a particular piece of 1283 variables exist that help you configure a particular piece of
1284 hardware. 1284 hardware.
1285 1285
1286- ```EXTRA_IMAGEDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGEDEPENDS>`__: 1286- :term:`EXTRA_IMAGEDEPENDS`:
1287 Recipes to build that do not provide packages for installing into the 1287 Recipes to build that do not provide packages for installing into the
1288 root filesystem but building the image depends on the recipes. 1288 root filesystem but building the image depends on the recipes.
1289 Sometimes a recipe is required to build the final image but is not 1289 Sometimes a recipe is required to build the final image but is not
1290 needed in the root filesystem. In this case, the U-Boot recipe must 1290 needed in the root filesystem. In this case, the U-Boot recipe must
1291 be built for the image. 1291 be built for the image.
1292 1292
1293- ```DEFAULTTUNE`` <&YOCTO_DOCS_REF_URL;#var-DEFAULTTUNE>`__: Machines 1293- :term:`DEFAULTTUNE`: Machines
1294 use tunings to optimize machine, CPU, and application performance. 1294 use tunings to optimize machine, CPU, and application performance.
1295 These features, which are collectively known as "tuning features", 1295 These features, which are collectively known as "tuning features",
1296 exist in the `OpenEmbedded-Core 1296 exist in the `OpenEmbedded-Core
@@ -1306,31 +1306,31 @@ Project Reference Manual.
1306 conf/machine/include/tune-cortexa8.inc 1306 conf/machine/include/tune-cortexa8.inc
1307 file provides many tuning possibilities. 1307 file provides many tuning possibilities.
1308 1308
1309- ```IMAGE_FSTYPES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES>`__: The 1309- :term:`IMAGE_FSTYPES`: The
1310 formats the OpenEmbedded build system uses during the build when 1310 formats the OpenEmbedded build system uses during the build when
1311 creating the root filesystem. In this example, four types of images 1311 creating the root filesystem. In this example, four types of images
1312 are supported. 1312 are supported.
1313 1313
1314- ```EXTRA_IMAGECMD`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGECMD>`__: 1314- :term:`EXTRA_IMAGECMD`:
1315 Specifies additional options for image creation commands. In this 1315 Specifies additional options for image creation commands. In this
1316 example, the "-lnp " option is used when creating the 1316 example, the "-lnp " option is used when creating the
1317 `JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image. 1317 `JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image.
1318 1318
1319- ```WKS_FILE`` <&YOCTO_DOCS_REF_URL;#var-WKS_FILE>`__: The location of 1319- :term:`WKS_FILE`: The location of
1320 the `Wic kickstart <&YOCTO_DOCS_REF_URL;#ref-kickstart>`__ file used 1320 the `Wic kickstart <&YOCTO_DOCS_REF_URL;#ref-kickstart>`__ file used
1321 by the OpenEmbedded build system to create a partitioned image 1321 by the OpenEmbedded build system to create a partitioned image
1322 (image.wic). 1322 (image.wic).
1323 1323
1324- ```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__: 1324- :term:`IMAGE_INSTALL`:
1325 Specifies packages to install into an image through the 1325 Specifies packages to install into an image through the
1326 ```image`` <&YOCTO_DOCS_REF_URL;#ref-classes-image>`__ class. Recipes 1326 :ref:`image <ref-classes-image>` class. Recipes
1327 use the ``IMAGE_INSTALL`` variable. 1327 use the ``IMAGE_INSTALL`` variable.
1328 1328
1329- ``do_image_wic[depends]``: A task that is constructed during the 1329- ``do_image_wic[depends]``: A task that is constructed during the
1330 build. In this example, the task depends on specific tools in order 1330 build. In this example, the task depends on specific tools in order
1331 to create the sysroot when buiding a Wic image. 1331 to create the sysroot when buiding a Wic image.
1332 1332
1333- ```SERIAL_CONSOLES`` <&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLES>`__: 1333- :term:`SERIAL_CONSOLES`:
1334 Defines a serial console (TTY) to enable using getty. In this case, 1334 Defines a serial console (TTY) to enable using getty. In this case,
1335 the baud rate is "115200" and the device name is "ttyO0". 1335 the baud rate is "115200" and the device name is "ttyO0".
1336 1336
@@ -1344,21 +1344,21 @@ Project Reference Manual.
1344 Defines the version of the recipe used to build the kernel, which is 1344 Defines the version of the recipe used to build the kernel, which is
1345 "5.0" in this case. 1345 "5.0" in this case.
1346 1346
1347- ```KERNEL_IMAGETYPE`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE>`__: 1347- :term:`KERNEL_IMAGETYPE`:
1348 The type of kernel to build for the device. In this case, the 1348 The type of kernel to build for the device. In this case, the
1349 OpenEmbedded build system creates a "zImage" image type. 1349 OpenEmbedded build system creates a "zImage" image type.
1350 1350
1351- ```KERNEL_DEVICETREE`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_DEVICETREE>`__: 1351- :term:`KERNEL_DEVICETREE`:
1352 The names of the generated Linux kernel device trees (i.e. the 1352 The names of the generated Linux kernel device trees (i.e. the
1353 ``*.dtb``) files. All the device trees for the various BeagleBone 1353 ``*.dtb``) files. All the device trees for the various BeagleBone
1354 devices are included. 1354 devices are included.
1355 1355
1356- ```KERNEL_EXTRA_ARGS`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_EXTRA_ARGS>`__: 1356- :term:`KERNEL_EXTRA_ARGS`:
1357 Additional ``make`` command-line arguments the OpenEmbedded build 1357 Additional ``make`` command-line arguments the OpenEmbedded build
1358 system passes on when compiling the kernel. In this example, 1358 system passes on when compiling the kernel. In this example,
1359 "LOADADDR=${UBOOT_ENTRYPOINT}" is passed as a command-line argument. 1359 "LOADADDR=${UBOOT_ENTRYPOINT}" is passed as a command-line argument.
1360 1360
1361- ```SPL_BINARY`` <&YOCTO_DOCS_REF_URL;#var-SPL_BINARY>`__: Defines the 1361- :term:`SPL_BINARY`: Defines the
1362 Secondary Program Loader (SPL) binary type. In this case, the SPL 1362 Secondary Program Loader (SPL) binary type. In this case, the SPL
1363 binary is set to "MLO", which stands for Multimedia card LOader. 1363 binary is set to "MLO", which stands for Multimedia card LOader.
1364 1364
@@ -1377,25 +1377,25 @@ Project Reference Manual.
1377 example, a U-Boot image is required to boot the BeagleBone device. 1377 example, a U-Boot image is required to boot the BeagleBone device.
1378 See the following variables for more information: 1378 See the following variables for more information:
1379 1379
1380 - ```UBOOT_SUFFIX`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_SUFFIX>`__: 1380 - :term:`UBOOT_SUFFIX`:
1381 Points to the generated U-Boot extension. 1381 Points to the generated U-Boot extension.
1382 1382
1383 - ```UBOOT_MACHINE`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_MACHINE>`__: 1383 - :term:`UBOOT_MACHINE`:
1384 Specifies the value passed on the make command line when building 1384 Specifies the value passed on the make command line when building
1385 a U-Boot image. 1385 a U-Boot image.
1386 1386
1387 - ```UBOOT_ENTRYPOINT`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_ENTRYPOINT>`__: 1387 - :term:`UBOOT_ENTRYPOINT`:
1388 Specifies the entry point for the U-Boot image. 1388 Specifies the entry point for the U-Boot image.
1389 1389
1390 - ```UBOOT_LOADADDRESS`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_LOADADDRESS>`__: 1390 - :term:`UBOOT_LOADADDRESS`:
1391 Specifies the load address for the U-Boot image. 1391 Specifies the load address for the U-Boot image.
1392 1392
1393- ```MACHINE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES>`__: 1393- :term:`MACHINE_FEATURES`:
1394 Specifies the list of hardware features the BeagleBone device is 1394 Specifies the list of hardware features the BeagleBone device is
1395 capable of supporting. In this case, the device supports "usbgadget 1395 capable of supporting. In this case, the device supports "usbgadget
1396 usbhost vfat alsa". 1396 usbhost vfat alsa".
1397 1397
1398- ```IMAGE_BOOT_FILES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_BOOT_FILES>`__: 1398- :term:`IMAGE_BOOT_FILES`:
1399 Files installed into the device's boot partition when preparing the 1399 Files installed into the device's boot partition when preparing the
1400 image using the Wic tool with the ``bootimg-partition`` or 1400 image using the Wic tool with the ``bootimg-partition`` or
1401 ``bootimg-efi`` source plugin. 1401 ``bootimg-efi`` source plugin.
@@ -1435,21 +1435,21 @@ appended with the "beaglebone-yocto" string. The OpenEmbedded build
1435system uses these statements to override similar statements in the 1435system uses these statements to override similar statements in the
1436kernel recipe: 1436kernel recipe:
1437 1437
1438- ```KBRANCH`` <&YOCTO_DOCS_REF_URL;#var-KBRANCH>`__: Identifies the 1438- :term:`KBRANCH`: Identifies the
1439 kernel branch that is validated, patched, and configured during the 1439 kernel branch that is validated, patched, and configured during the
1440 build. 1440 build.
1441 1441
1442- ```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__: Identifies the 1442- :term:`KMACHINE`: Identifies the
1443 machine name as known by the kernel, which is sometimes a different 1443 machine name as known by the kernel, which is sometimes a different
1444 name than what is known by the OpenEmbedded build system. 1444 name than what is known by the OpenEmbedded build system.
1445 1445
1446- ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__: Identifies the 1446- :term:`SRCREV`: Identifies the
1447 revision of the source code used to build the image. 1447 revision of the source code used to build the image.
1448 1448
1449- ```COMPATIBLE_MACHINE`` <&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE>`__: 1449- :term:`COMPATIBLE_MACHINE`:
1450 A regular expression that resolves to one or more target machines 1450 A regular expression that resolves to one or more target machines
1451 with which the recipe is compatible. 1451 with which the recipe is compatible.
1452 1452
1453- ```LINUX_VERSION`` <&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION>`__: The 1453- :term:`LINUX_VERSION`: The
1454 Linux version from kernel.org used by the OpenEmbedded build system 1454 Linux version from kernel.org used by the OpenEmbedded build system
1455 to build the kernel image. 1455 to build the kernel image.
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index 133a3dd31c..ae26172f6c 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -14,7 +14,7 @@ Understanding and Creating Layers
14================================= 14=================================
15 15
16The OpenEmbedded build system supports organizing 16The OpenEmbedded build system supports organizing
17`Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ into multiple layers. 17:term:`Metadata` into multiple layers.
18Layers allow you to isolate different types of customizations from each 18Layers allow you to isolate different types of customizations from each
19other. For introductory information on the Yocto Project Layer Model, 19other. For introductory information on the Yocto Project Layer Model,
20see the "`The Yocto Project Layer 20see the "`The Yocto Project Layer
@@ -81,7 +81,7 @@ Follow these general steps to create your layer without using tools:
81 = "4" LAYERSERIES_COMPAT_yoctobsp = "DISTRO_NAME_NO_CAP" Following is 81 = "4" LAYERSERIES_COMPAT_yoctobsp = "DISTRO_NAME_NO_CAP" Following is
82 an explanation of the layer configuration file: 82 an explanation of the layer configuration file:
83 83
84 - ```BBPATH`` <&YOCTO_DOCS_REF_URL;#var-BBPATH>`__: Adds the layer's 84 - :term:`BBPATH`: Adds the layer's
85 root directory to BitBake's search path. Through the use of the 85 root directory to BitBake's search path. Through the use of the
86 ``BBPATH`` variable, BitBake locates class files (``.bbclass``), 86 ``BBPATH`` variable, BitBake locates class files (``.bbclass``),
87 configuration files, and files that are included with ``include`` 87 configuration files, and files that are included with ``include``
@@ -91,35 +91,35 @@ Follow these general steps to create your layer without using tools:
91 is recommended, therefore, that you use unique class and 91 is recommended, therefore, that you use unique class and
92 configuration filenames in your custom layer. 92 configuration filenames in your custom layer.
93 93
94 - ```BBFILES`` <&YOCTO_DOCS_REF_URL;#var-BBFILES>`__: Defines the 94 - :term:`BBFILES`: Defines the
95 location for all recipes in the layer. 95 location for all recipes in the layer.
96 96
97 - ```BBFILE_COLLECTIONS`` <&YOCTO_DOCS_REF_URL;#var-BBFILE_COLLECTIONS>`__: 97 - :term:`BBFILE_COLLECTIONS`:
98 Establishes the current layer through a unique identifier that is 98 Establishes the current layer through a unique identifier that is
99 used throughout the OpenEmbedded build system to refer to the 99 used throughout the OpenEmbedded build system to refer to the
100 layer. In this example, the identifier "yoctobsp" is the 100 layer. In this example, the identifier "yoctobsp" is the
101 representation for the container layer named "meta-yocto-bsp". 101 representation for the container layer named "meta-yocto-bsp".
102 102
103 - ```BBFILE_PATTERN`` <&YOCTO_DOCS_REF_URL;#var-BBFILE_PATTERN>`__: 103 - :term:`BBFILE_PATTERN`:
104 Expands immediately during parsing to provide the directory of the 104 Expands immediately during parsing to provide the directory of the
105 layer. 105 layer.
106 106
107 - ```BBFILE_PRIORITY`` <&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY>`__: 107 - :term:`BBFILE_PRIORITY`:
108 Establishes a priority to use for recipes in the layer when the 108 Establishes a priority to use for recipes in the layer when the
109 OpenEmbedded build finds recipes of the same name in different 109 OpenEmbedded build finds recipes of the same name in different
110 layers. 110 layers.
111 111
112 - ```LAYERVERSION`` <&YOCTO_DOCS_REF_URL;#var-LAYERVERSION>`__: 112 - :term:`LAYERVERSION`:
113 Establishes a version number for the layer. You can use this 113 Establishes a version number for the layer. You can use this
114 version number to specify this exact version of the layer as a 114 version number to specify this exact version of the layer as a
115 dependency when using the 115 dependency when using the
116 ```LAYERDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-LAYERDEPENDS>`__ 116 :term:`LAYERDEPENDS`
117 variable. 117 variable.
118 118
119 - ```LAYERDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-LAYERDEPENDS>`__: 119 - :term:`LAYERDEPENDS`:
120 Lists all layers on which this layer depends (if any). 120 Lists all layers on which this layer depends (if any).
121 121
122 - ```LAYERSERIES_COMPAT`` <&YOCTO_DOCS_REF_URL;#var-LAYERSERIES_COMPAT>`__: 122 - :term:`LAYERSERIES_COMPAT`:
123 Lists the `Yocto Project <&YOCTO_WIKI_URL;/wiki/Releases>`__ 123 Lists the `Yocto Project <&YOCTO_WIKI_URL;/wiki/Releases>`__
124 releases for which the current version is compatible. This 124 releases for which the current version is compatible. This
125 variable is a good way to indicate if your particular layer is 125 variable is a good way to indicate if your particular layer is
@@ -184,7 +184,7 @@ following list:
184 have a layer named ``meta-one`` that adds support for building 184 have a layer named ``meta-one`` that adds support for building
185 machine "one". To do so, you use an append file named 185 machine "one". To do so, you use an append file named
186 ``base-files.bbappend`` and create a dependency on "foo" by 186 ``base-files.bbappend`` and create a dependency on "foo" by
187 altering the ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ 187 altering the :term:`DEPENDS`
188 variable: DEPENDS = "foo" The dependency is created during any 188 variable: DEPENDS = "foo" The dependency is created during any
189 build that includes the layer ``meta-one``. However, you might not 189 build that includes the layer ``meta-one``. However, you might not
190 want this dependency for all machines. For example, suppose you 190 want this dependency for all machines. For example, suppose you
@@ -221,13 +221,13 @@ following list:
221 221
222 - *Place Machine-Specific Files in Machine-Specific Locations:* When 222 - *Place Machine-Specific Files in Machine-Specific Locations:* When
223 you have a base recipe, such as ``base-files.bb``, that contains a 223 you have a base recipe, such as ``base-files.bb``, that contains a
224 ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statement to a 224 :term:`SRC_URI` statement to a
225 file, you can use an append file to cause the build to use your 225 file, you can use an append file to cause the build to use your
226 own version of the file. For example, an append file in your layer 226 own version of the file. For example, an append file in your layer
227 at ``meta-one/recipes-core/base-files/base-files.bbappend`` could 227 at ``meta-one/recipes-core/base-files/base-files.bbappend`` could
228 extend ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ 228 extend :term:`FILESPATH`
229 using 229 using
230 ```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 230 :term:`FILESEXTRAPATHS`
231 as follows: FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" The 231 as follows: FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" The
232 build for machine "one" will pick up your machine-specific file as 232 build for machine "one" will pick up your machine-specific file as
233 long as you have the file in 233 long as you have the file in
@@ -401,7 +401,7 @@ Enabling Your Layer
401Before the OpenEmbedded build system can use your new layer, you need to 401Before the OpenEmbedded build system can use your new layer, you need to
402enable it. To enable your layer, simply add your layer's path to the 402enable it. To enable your layer, simply add your layer's path to the
403``BBLAYERS`` variable in your ``conf/bblayers.conf`` file, which is 403``BBLAYERS`` variable in your ``conf/bblayers.conf`` file, which is
404found in the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 404found in the :term:`Build Directory`.
405The following example shows how to enable a layer named 405The following example shows how to enable a layer named
406``meta-mylayer``: # POKY_BBLAYERS_CONF_VERSION is increased each time 406``meta-mylayer``: # POKY_BBLAYERS_CONF_VERSION is increased each time
407build/conf/bblayers.conf # changes incompatibly 407build/conf/bblayers.conf # changes incompatibly
@@ -445,7 +445,7 @@ newer version, you must also rename and possibly update the
445corresponding ``.bbappend`` as well. During the build process, BitBake 445corresponding ``.bbappend`` as well. During the build process, BitBake
446displays an error on starting if it detects a ``.bbappend`` file that 446displays an error on starting if it detects a ``.bbappend`` file that
447does not have a corresponding recipe with a matching name. See the 447does not have a corresponding recipe with a matching name. See the
448```BB_DANGLINGAPPENDS_WARNONLY`` <&YOCTO_DOCS_REF_URL;#var-BB_DANGLINGAPPENDS_WARNONLY>`__ 448:term:`BB_DANGLINGAPPENDS_WARNONLY`
449variable for information on how to handle this error. 449variable for information on how to handle this error.
450 450
451As an example, consider the main formfactor recipe and a corresponding 451As an example, consider the main formfactor recipe and a corresponding
@@ -462,7 +462,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}" INHIBIT_DEFAULT_DEPS = "1" do_install()
462${D}${sysconfdir}/formfactor/ install -m 0644 ${S}/config 462${D}${sysconfdir}/formfactor/ install -m 0644 ${S}/config
463${D}${sysconfdir}/formfactor/ if [ -s "${S}/machconfig" ]; then install 463${D}${sysconfdir}/formfactor/ if [ -s "${S}/machconfig" ]; then install
464-m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/ fi } In the main 464-m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/ fi } In the main
465recipe, note the ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ 465recipe, note the :term:`SRC_URI`
466variable, which tells the OpenEmbedded build system where to find files 466variable, which tells the OpenEmbedded build system where to find files
467during the build. 467during the build.
468 468
@@ -472,15 +472,15 @@ file is in the layer at ``recipes-bsp/formfactor``:
472FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 472FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
473 473
474By default, the build system uses the 474By default, the build system uses the
475```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ variable to 475:term:`FILESPATH` variable to
476locate files. This append file extends the locations by setting the 476locate files. This append file extends the locations by setting the
477```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 477:term:`FILESEXTRAPATHS`
478variable. Setting this variable in the ``.bbappend`` file is the most 478variable. Setting this variable in the ``.bbappend`` file is the most
479reliable and recommended method for adding directories to the search 479reliable and recommended method for adding directories to the search
480path used by the build system to find files. 480path used by the build system to find files.
481 481
482The statement in this example extends the directories to include 482The statement in this example extends the directories to include
483``${``\ ```THISDIR`` <&YOCTO_DOCS_REF_URL;#var-THISDIR>`__\ ``}/${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}``, 483``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``,
484which resolves to a directory named ``formfactor`` in the same directory 484which resolves to a directory named ``formfactor`` in the same directory
485in which the append file resides (i.e. 485in which the append file resides (i.e.
486``meta-raspberrypi/recipes-bsp/formfactor``. This implies that you must 486``meta-raspberrypi/recipes-bsp/formfactor``. This implies that you must
@@ -514,13 +514,13 @@ applied. You can either specify the priority manually, or allow the
514build system to calculate it based on the layer's dependencies. 514build system to calculate it based on the layer's dependencies.
515 515
516To specify the layer's priority manually, use the 516To specify the layer's priority manually, use the
517```BBFILE_PRIORITY`` <&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY>`__ 517:term:`BBFILE_PRIORITY`
518variable and append the layer's root name: BBFILE_PRIORITY_mylayer = "1" 518variable and append the layer's root name: BBFILE_PRIORITY_mylayer = "1"
519 519
520.. note:: 520.. note::
521 521
522 It is possible for a recipe with a lower version number 522 It is possible for a recipe with a lower version number
523 ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ in a layer that has a higher 523 :term:`PV` in a layer that has a higher
524 priority to take precedence. 524 priority to take precedence.
525 525
526 Also, the layer priority does not currently affect the precedence 526 Also, the layer priority does not currently affect the precedence
@@ -665,7 +665,7 @@ meta-scottrif'
665If you want to set the priority of the layer to other than the default 665If you want to set the priority of the layer to other than the default
666value of "6", you can either use the ``DASHDASHpriority`` option or you 666value of "6", you can either use the ``DASHDASHpriority`` option or you
667can edit the 667can edit the
668```BBFILE_PRIORITY`` <&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY>`__ value 668:term:`BBFILE_PRIORITY` value
669in the ``conf/layer.conf`` after the script creates it. Furthermore, if 669in the ``conf/layer.conf`` after the script creates it. Furthermore, if
670you want to give the example recipe file some name other than the 670you want to give the example recipe file some name other than the
671default, you can use the ``DASHDASHexample-recipe-name`` option. 671default, you can use the ``DASHDASHexample-recipe-name`` option.
@@ -764,8 +764,8 @@ Customizing Images Using Custom ``IMAGE_FEATURES`` and ``EXTRA_IMAGE_FEATURES``
764 764
765Another method for customizing your image is to enable or disable 765Another method for customizing your image is to enable or disable
766high-level image features by using the 766high-level image features by using the
767```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__ and 767:term:`IMAGE_FEATURES` and
768```EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES>`__ 768:term:`EXTRA_IMAGE_FEATURES`
769variables. Although the functions for both variables are nearly 769variables. Although the functions for both variables are nearly
770equivalent, best practices dictate using ``IMAGE_FEATURES`` from within 770equivalent, best practices dictate using ``IMAGE_FEATURES`` from within
771a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your 771a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your
@@ -782,7 +782,7 @@ In summary, the file looks at the contents of the ``IMAGE_FEATURES``
782variable and then maps or configures the feature accordingly. Based on 782variable and then maps or configures the feature accordingly. Based on
783this information, the build system automatically adds the appropriate 783this information, the build system automatically adds the appropriate
784packages or configurations to the 784packages or configurations to the
785```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__ variable. 785:term:`IMAGE_INSTALL` variable.
786Effectively, you are enabling extra features by extending the class or 786Effectively, you are enabling extra features by extending the class or
787creating a custom class for use with specialized image ``.bb`` files. 787creating a custom class for use with specialized image ``.bb`` files.
788 788
@@ -893,7 +893,7 @@ Customizing an Image Hostname
893 893
894By default, the configured hostname (i.e. ``/etc/hostname``) in an image 894By default, the configured hostname (i.e. ``/etc/hostname``) in an image
895is the same as the machine name. For example, if 895is the same as the machine name. For example, if
896```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ equals "qemux86", the 896:term:`MACHINE` equals "qemux86", the
897configured hostname written to ``/etc/hostname`` is "qemux86". 897configured hostname written to ``/etc/hostname`` is "qemux86".
898 898
899You can customize this name by altering the value of the "hostname" 899You can customize this name by altering the value of the "hostname"
@@ -1072,7 +1072,7 @@ the recipe.
1072 1072
1073- *Storing Your Recipe:* The OpenEmbedded build system locates your 1073- *Storing Your Recipe:* The OpenEmbedded build system locates your
1074 recipe through the layer's ``conf/layer.conf`` file and the 1074 recipe through the layer's ``conf/layer.conf`` file and the
1075 ```BBFILES`` <&YOCTO_DOCS_REF_URL;#var-BBFILES>`__ variable. This 1075 :term:`BBFILES` variable. This
1076 variable sets up a path from which the build system can locate 1076 variable sets up a path from which the build system can locate
1077 recipes. Here is the typical use: BBFILES += 1077 recipes. Here is the typical use: BBFILES +=
1078 "${LAYERDIR}/recipes-*/*/*.bb \\ ${LAYERDIR}/recipes-*/*/*.bbappend" 1078 "${LAYERDIR}/recipes-*/*/*.bb \\ ${LAYERDIR}/recipes-*/*/*.bbappend"
@@ -1101,14 +1101,14 @@ progressively discover and add information to the recipe file.
1101 1101
1102Assuming you have sourced the build environment setup script (i.e. 1102Assuming you have sourced the build environment setup script (i.e.
1103````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__) and you are in 1103````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__) and you are in
1104the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, use 1104the :term:`Build Directory`, use
1105BitBake to process your recipe. All you need to provide is the 1105BitBake to process your recipe. All you need to provide is the
1106``basename`` of the recipe as described in the previous section: $ 1106``basename`` of the recipe as described in the previous section: $
1107bitbake basename 1107bitbake basename
1108 1108
1109During the build, the OpenEmbedded build system creates a temporary work 1109During the build, the OpenEmbedded build system creates a temporary work
1110directory for each recipe 1110directory for each recipe
1111(``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}``) 1111(``${``\ :term:`WORKDIR`\ ``}``)
1112where it keeps extracted source files, log files, intermediate 1112where it keeps extracted source files, log files, intermediate
1113compilation and packaging files, and so forth. 1113compilation and packaging files, and so forth.
1114 1114
@@ -1154,26 +1154,26 @@ Fetching Code
1154 1154
1155The first thing your recipe must do is specify how to fetch the source 1155The first thing your recipe must do is specify how to fetch the source
1156files. Fetching is controlled mainly through the 1156files. Fetching is controlled mainly through the
1157```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ variable. Your recipe 1157:term:`SRC_URI` variable. Your recipe
1158must have a ``SRC_URI`` variable that points to where the source is 1158must have a ``SRC_URI`` variable that points to where the source is
1159located. For a graphical representation of source locations, see the 1159located. For a graphical representation of source locations, see the
1160"`Sources <&YOCTO_DOCS_OM_URL;#sources-dev-environment>`__" section in 1160"`Sources <&YOCTO_DOCS_OM_URL;#sources-dev-environment>`__" section in
1161the Yocto Project Overview and Concepts Manual. 1161the Yocto Project Overview and Concepts Manual.
1162 1162
1163The ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__ task uses 1163The :ref:`ref-tasks-fetch` task uses
1164the prefix of each entry in the ``SRC_URI`` variable value to determine 1164the prefix of each entry in the ``SRC_URI`` variable value to determine
1165which `fetcher <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ to use to get your 1165which `fetcher <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ to use to get your
1166source files. It is the ``SRC_URI`` variable that triggers the fetcher. 1166source files. It is the ``SRC_URI`` variable that triggers the fetcher.
1167The ```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task uses 1167The :ref:`ref-tasks-patch` task uses
1168the variable after source is fetched to apply patches. The OpenEmbedded 1168the variable after source is fetched to apply patches. The OpenEmbedded
1169build system uses 1169build system uses
1170```FILESOVERRIDES`` <&YOCTO_DOCS_REF_URL;#var-FILESOVERRIDES>`__ for 1170:term:`FILESOVERRIDES` for
1171scanning directory locations for local files in ``SRC_URI``. 1171scanning directory locations for local files in ``SRC_URI``.
1172 1172
1173The ``SRC_URI`` variable in your recipe must define each unique location 1173The ``SRC_URI`` variable in your recipe must define each unique location
1174for your source files. It is good practice to not hard-code version 1174for your source files. It is good practice to not hard-code version
1175numbers in a URL used in ``SRC_URI``. Rather than hard-code these 1175numbers in a URL used in ``SRC_URI``. Rather than hard-code these
1176values, use ``${``\ ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__\ ``}``, 1176values, use ``${``\ :term:`PV`\ ``}``,
1177which causes the fetch process to use the version specified in the 1177which causes the fetch process to use the version specified in the
1178recipe filename. Specifying the version in this manner means that 1178recipe filename. Specifying the version in this manner means that
1179upgrading the recipe to a future version is as simple as renaming the 1179upgrading the recipe to a future version is as simple as renaming the
@@ -1182,20 +1182,20 @@ recipe to match the new version.
1182Here is a simple example from the 1182Here is a simple example from the
1183``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source 1183``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
1184comes from a single tarball. Notice the use of the 1184comes from a single tarball. Notice the use of the
1185```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ variable: SRC_URI = 1185:term:`PV` variable: SRC_URI =
1186"https://strace.io/files/${PV}/strace-${PV}.tar.xz \\ 1186"https://strace.io/files/${PV}/strace-${PV}.tar.xz \\
1187 1187
1188Files mentioned in ``SRC_URI`` whose names end in a typical archive 1188Files mentioned in ``SRC_URI`` whose names end in a typical archive
1189extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so 1189extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so
1190forth), are automatically extracted during the 1190forth), are automatically extracted during the
1191```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__ task. For 1191:ref:`ref-tasks-unpack` task. For
1192another example that specifies these types of files, see the 1192another example that specifies these types of files, see the
1193"`Autotooled Package <#new-recipe-autotooled-package>`__" section. 1193"`Autotooled Package <#new-recipe-autotooled-package>`__" section.
1194 1194
1195Another way of specifying source is from an SCM. For Git repositories, 1195Another way of specifying source is from an SCM. For Git repositories,
1196you must specify ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__ and 1196you must specify :term:`SRCREV` and
1197you should specify ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ to include 1197you should specify :term:`PV` to include
1198the revision with ```SRCPV`` <&YOCTO_DOCS_REF_URL;#var-SRCPV>`__. Here 1198the revision with :term:`SRCPV`. Here
1199is an example from the recipe 1199is an example from the recipe
1200``meta/recipes-kernel/blktrace/blktrace_git.bb``: SRCREV = 1200``meta/recipes-kernel/blktrace/blktrace_git.bb``: SRCREV =
1201"d6918c8832793b4205ed3bfede78c2f915c23385" PR = "r6" PV = 1201"d6918c8832793b4205ed3bfede78c2f915c23385" PR = "r6" PV =
@@ -1254,10 +1254,10 @@ file://xwc.patch \\ file://rxvt.desktop \\ file://rxvt.png"
1254 1254
1255When you specify local files using the ``file://`` URI protocol, the 1255When you specify local files using the ``file://`` URI protocol, the
1256build system fetches files from the local machine. The path is relative 1256build system fetches files from the local machine. The path is relative
1257to the ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ variable 1257to the :term:`FILESPATH` variable
1258and searches specific directories in a certain order: 1258and searches specific directories in a certain order:
1259``${``\ ```BP`` <&YOCTO_DOCS_REF_URL;#var-BP>`__\ ``}``, 1259``${``\ :term:`BP`\ ``}``,
1260``${``\ ```BPN`` <&YOCTO_DOCS_REF_URL;#var-BPN>`__\ ``}``, and 1260``${``\ :term:`BPN`\ ``}``, and
1261``files``. The directories are assumed to be subdirectories of the 1261``files``. The directories are assumed to be subdirectories of the
1262directory in which the recipe or append file resides. For another 1262directory in which the recipe or append file resides. For another
1263example that specifies these types of files, see the "`Single .c File 1263example that specifies these types of files, see the "`Single .c File
@@ -1276,14 +1276,14 @@ Unpacking Code
1276-------------- 1276--------------
1277 1277
1278During the build, the 1278During the build, the
1279```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__ task unpacks 1279:ref:`ref-tasks-unpack` task unpacks
1280the source with ``${``\ ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__\ ``}`` 1280the source with ``${``\ :term:`S`\ ``}``
1281pointing to where it is unpacked. 1281pointing to where it is unpacked.
1282 1282
1283If you are fetching your source files from an upstream source archived 1283If you are fetching your source files from an upstream source archived
1284tarball and the tarball's internal structure matches the common 1284tarball and the tarball's internal structure matches the common
1285convention of a top-level subdirectory named 1285convention of a top-level subdirectory named
1286``${``\ ```BPN`` <&YOCTO_DOCS_REF_URL;#var-BPN>`__\ ``}-${``\ ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__\ ``}``, 1286``${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
1287then you do not need to set ``S``. However, if ``SRC_URI`` specifies to 1287then you do not need to set ``S``. However, if ``SRC_URI`` specifies to
1288fetch source from an archive that does not use this convention, or from 1288fetch source from an archive that does not use this convention, or from
1289an SCM like Git or Subversion, your recipe needs to define ``S``. 1289an SCM like Git or Subversion, your recipe needs to define ``S``.
@@ -1301,7 +1301,7 @@ Sometimes it is necessary to patch code after it has been fetched. Any
1301files mentioned in ``SRC_URI`` whose names end in ``.patch`` or 1301files mentioned in ``SRC_URI`` whose names end in ``.patch`` or
1302``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz`` are 1302``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz`` are
1303treated as patches. The 1303treated as patches. The
1304```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task 1304:ref:`ref-tasks-patch` task
1305automatically applies these patches. 1305automatically applies these patches.
1306 1306
1307The build system should be able to apply patches with the "-p1" option 1307The build system should be able to apply patches with the "-p1" option
@@ -1313,11 +1313,11 @@ specific subdirectory that is not specified in the patch file, use the
1313"patchdir" option in the entry. 1313"patchdir" option in the entry.
1314 1314
1315As with all local files referenced in 1315As with all local files referenced in
1316```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ using ``file://``, 1316:term:`SRC_URI` using ``file://``,
1317you should place patch files in a directory next to the recipe either 1317you should place patch files in a directory next to the recipe either
1318named the same as the base name of the recipe 1318named the same as the base name of the recipe
1319(```BP`` <&YOCTO_DOCS_REF_URL;#var-BP>`__ and 1319(:term:`BP` and
1320```BPN`` <&YOCTO_DOCS_REF_URL;#var-BPN>`__) or "files". 1320:term:`BPN`) or "files".
1321 1321
1322.. _new-recipe-licensing: 1322.. _new-recipe-licensing:
1323 1323
@@ -1325,8 +1325,8 @@ Licensing
1325--------- 1325---------
1326 1326
1327Your recipe needs to have both the 1327Your recipe needs to have both the
1328```LICENSE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ and 1328:term:`LICENSE` and
1329```LIC_FILES_CHKSUM`` <&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM>`__ 1329:term:`LIC_FILES_CHKSUM`
1330variables: 1330variables:
1331 1331
1332- *``LICENSE``:* This variable specifies the license for the software. 1332- *``LICENSE``:* This variable specifies the license for the software.
@@ -1383,15 +1383,15 @@ software is built; and runtime dependencies, which are required to be
1383installed on the target in order for the software to run. 1383installed on the target in order for the software to run.
1384 1384
1385Within a recipe, you specify build-time dependencies using the 1385Within a recipe, you specify build-time dependencies using the
1386```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ variable. Although 1386:term:`DEPENDS` variable. Although
1387nuances exist, items specified in ``DEPENDS`` should be names of other 1387nuances exist, items specified in ``DEPENDS`` should be names of other
1388recipes. It is important that you specify all build-time dependencies 1388recipes. It is important that you specify all build-time dependencies
1389explicitly. If you do not, due to the parallel nature of BitBake's 1389explicitly. If you do not, due to the parallel nature of BitBake's
1390execution, you can end up with a race condition where the dependency is 1390execution, you can end up with a race condition where the dependency is
1391present for one task of a recipe (e.g. 1391present for one task of a recipe (e.g.
1392```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__) and 1392:ref:`ref-tasks-configure`) and
1393then gone when the next task runs (e.g. 1393then gone when the next task runs (e.g.
1394```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__). 1394:ref:`ref-tasks-compile`).
1395 1395
1396Another consideration is that configure scripts might automatically 1396Another consideration is that configure scripts might automatically
1397check for optional dependencies and enable corresponding functionality 1397check for optional dependencies and enable corresponding functionality
@@ -1402,18 +1402,18 @@ configure script explicitly to disable the functionality. If you wish to
1402make a recipe that is more generally useful (e.g. publish the recipe in 1402make a recipe that is more generally useful (e.g. publish the recipe in
1403a layer for others to use), instead of hard-disabling the functionality, 1403a layer for others to use), instead of hard-disabling the functionality,
1404you can use the 1404you can use the
1405```PACKAGECONFIG`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG>`__ variable 1405:term:`PACKAGECONFIG` variable
1406to allow functionality and the corresponding dependencies to be enabled 1406to allow functionality and the corresponding dependencies to be enabled
1407and disabled easily by other users of the recipe. 1407and disabled easily by other users of the recipe.
1408 1408
1409Similar to build-time dependencies, you specify runtime dependencies 1409Similar to build-time dependencies, you specify runtime dependencies
1410through a variable - 1410through a variable -
1411```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__, which is 1411:term:`RDEPENDS`, which is
1412package-specific. All variables that are package-specific need to have 1412package-specific. All variables that are package-specific need to have
1413the name of the package added to the end as an override. Since the main 1413the name of the package added to the end as an override. Since the main
1414package for a recipe has the same name as the recipe, and the recipe's 1414package for a recipe has the same name as the recipe, and the recipe's
1415name can be found through the 1415name can be found through the
1416``${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}`` variable, then 1416``${``\ :term:`PN`\ ``}`` variable, then
1417you specify the dependencies for the main package by setting 1417you specify the dependencies for the main package by setting
1418``RDEPENDS_${PN}``. If the package were named ``${PN}-tools``, then you 1418``RDEPENDS_${PN}``. If the package were named ``${PN}-tools``, then you
1419would set ``RDEPENDS_${PN}-tools``, and so forth. 1419would set ``RDEPENDS_${PN}-tools``, and so forth.
@@ -1455,7 +1455,7 @@ A major part of build-time configuration is about checking for
1455build-time dependencies and possibly enabling optional functionality as 1455build-time dependencies and possibly enabling optional functionality as
1456a result. You need to specify any build-time dependencies for the 1456a result. You need to specify any build-time dependencies for the
1457software you are building in your recipe's 1457software you are building in your recipe's
1458```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ value, in terms of 1458:term:`DEPENDS` value, in terms of
1459other recipes that satisfy those dependencies. You can often find 1459other recipes that satisfy those dependencies. You can often find
1460build-time or runtime dependencies described in the software's 1460build-time or runtime dependencies described in the software's
1461documentation. 1461documentation.
@@ -1468,13 +1468,13 @@ your software is built:
1468 need to worry about modifying the configuration. 1468 need to worry about modifying the configuration.
1469 1469
1470 When using Autotools, your recipe needs to inherit the 1470 When using Autotools, your recipe needs to inherit the
1471 ```autotools`` <&YOCTO_DOCS_REF_URL;#ref-classes-autotools>`__ class 1471 :ref:`autotools <ref-classes-autotools>` class
1472 and your recipe does not have to contain a 1472 and your recipe does not have to contain a
1473 ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ task. 1473 :ref:`ref-tasks-configure` task.
1474 However, you might still want to make some adjustments. For example, 1474 However, you might still want to make some adjustments. For example,
1475 you can set 1475 you can set
1476 ```EXTRA_OECONF`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF>`__ or 1476 :term:`EXTRA_OECONF` or
1477 ```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ 1477 :term:`PACKAGECONFIG_CONFARGS`
1478 to pass any needed configure options that are specific to the recipe. 1478 to pass any needed configure options that are specific to the recipe.
1479 1479
1480- *CMake:* If your source files have a ``CMakeLists.txt`` file, then 1480- *CMake:* If your source files have a ``CMakeLists.txt`` file, then
@@ -1482,11 +1482,11 @@ your software is built:
1482 need to worry about modifying the configuration. 1482 need to worry about modifying the configuration.
1483 1483
1484 When you use CMake, your recipe needs to inherit the 1484 When you use CMake, your recipe needs to inherit the
1485 ```cmake`` <&YOCTO_DOCS_REF_URL;#ref-classes-cmake>`__ class and your 1485 :ref:`cmake <ref-classes-cmake>` class and your
1486 recipe does not have to contain a 1486 recipe does not have to contain a
1487 ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ task. 1487 :ref:`ref-tasks-configure` task.
1488 You can make some adjustments by setting 1488 You can make some adjustments by setting
1489 ```EXTRA_OECMAKE`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE>`__ to 1489 :term:`EXTRA_OECMAKE` to
1490 pass any needed configure options that are specific to the recipe. 1490 pass any needed configure options that are specific to the recipe.
1491 1491
1492 .. note:: 1492 .. note::
@@ -1503,7 +1503,7 @@ your software is built:
1503 ``CMakeLists.txt`` file, then your software is built using some 1503 ``CMakeLists.txt`` file, then your software is built using some
1504 method other than Autotools or CMake. If this is the case, you 1504 method other than Autotools or CMake. If this is the case, you
1505 normally need to provide a 1505 normally need to provide a
1506 ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ task 1506 :ref:`ref-tasks-configure` task
1507 in your recipe unless, of course, there is nothing to configure. 1507 in your recipe unless, of course, there is nothing to configure.
1508 1508
1509 Even if your software is not being built by Autotools or CMake, you 1509 Even if your software is not being built by Autotools or CMake, you
@@ -1591,7 +1591,7 @@ Consider a case where your kernel is older and you need an older
1591standard mainline kernel, not your own custom one. 1591standard mainline kernel, not your own custom one.
1592 1592
1593When you use custom kernel headers you need to get them from 1593When you use custom kernel headers you need to get them from
1594```STAGING_KERNEL_DIR`` <&YOCTO_DOCS_REF_URL;#var-STAGING_KERNEL_DIR>`__, 1594:term:`STAGING_KERNEL_DIR`,
1595which is the directory with kernel headers that are required to build 1595which is the directory with kernel headers that are required to build
1596out-of-tree modules. Your recipe will also need the following: 1596out-of-tree modules. Your recipe will also need the following:
1597do_configure[depends] += "virtual/kernel:do_shared_workdir" 1597do_configure[depends] += "virtual/kernel:do_shared_workdir"
@@ -1629,7 +1629,7 @@ Here are some common issues that cause failures.
1629 To fix the problem, you need to either satisfy the missing dependency 1629 To fix the problem, you need to either satisfy the missing dependency
1630 in the Makefile or whatever script produced the Makefile, or (as a 1630 in the Makefile or whatever script produced the Makefile, or (as a
1631 workaround) set 1631 workaround) set
1632 ```PARALLEL_MAKE`` <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE>`__ to an 1632 :term:`PARALLEL_MAKE` to an
1633 empty string: PARALLEL_MAKE = "" 1633 empty string: PARALLEL_MAKE = ""
1634 1634
1635 For information on parallel Makefile issues, see the "`Debugging 1635 For information on parallel Makefile issues, see the "`Debugging
@@ -1647,7 +1647,7 @@ Here are some common issues that cause failures.
1647 1647
1648- *Failure to find required libraries/headers:* If a build-time 1648- *Failure to find required libraries/headers:* If a build-time
1649 dependency is missing because it has not been declared in 1649 dependency is missing because it has not been declared in
1650 ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__, or because the 1650 :term:`DEPENDS`, or because the
1651 dependency exists but the path used by the build process to find the 1651 dependency exists but the path used by the build process to find the
1652 file is incorrect and the configure step did not detect it, the 1652 file is incorrect and the configure step did not detect it, the
1653 compilation process could fail. For either of these failures, the 1653 compilation process could fail. For either of these failures, the
@@ -1671,10 +1671,10 @@ Installing
1671During ``do_install``, the task copies the built files along with their 1671During ``do_install``, the task copies the built files along with their
1672hierarchy to locations that would mirror their locations on the target 1672hierarchy to locations that would mirror their locations on the target
1673device. The installation process copies files from the 1673device. The installation process copies files from the
1674``${``\ ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__\ ``}``, 1674``${``\ :term:`S`\ ``}``,
1675``${``\ ```B`` <&YOCTO_DOCS_REF_URL;#var-B>`__\ ``}``, and 1675``${``\ :term:`B`\ ``}``, and
1676``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}`` 1676``${``\ :term:`WORKDIR`\ ``}``
1677directories to the ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}`` 1677directories to the ``${``\ :term:`D`\ ``}``
1678directory to create the structure as it should appear on the target 1678directory to create the structure as it should appear on the target
1679system. 1679system.
1680 1680
@@ -1707,7 +1707,7 @@ the software being built:
1707- *Manual:* You need to define a ``do_install`` function in your 1707- *Manual:* You need to define a ``do_install`` function in your
1708 recipe. The function must first use ``install -d`` to create the 1708 recipe. The function must first use ``install -d`` to create the
1709 directories under 1709 directories under
1710 ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}``. Once the 1710 ``${``\ :term:`D`\ ``}``. Once the
1711 directories exist, your function can use ``install`` to manually 1711 directories exist, your function can use ``install`` to manually
1712 install the built software into the directories. 1712 install the built software into the directories.
1713 1713
@@ -1734,21 +1734,21 @@ installed correctly.
1734 1734
1735 - ``oe_runmake install``, which can be run directly or can be run 1735 - ``oe_runmake install``, which can be run directly or can be run
1736 indirectly by the 1736 indirectly by the
1737 ```autotools`` <&YOCTO_DOCS_REF_URL;#ref-classes-autotools>`__ and 1737 :ref:`autotools <ref-classes-autotools>` and
1738 ```cmake`` <&YOCTO_DOCS_REF_URL;#ref-classes-cmake>`__ classes, 1738 :ref:`cmake <ref-classes-cmake>` classes,
1739 runs ``make install`` in parallel. Sometimes, a Makefile can have 1739 runs ``make install`` in parallel. Sometimes, a Makefile can have
1740 missing dependencies between targets that can result in race 1740 missing dependencies between targets that can result in race
1741 conditions. If you experience intermittent failures during 1741 conditions. If you experience intermittent failures during
1742 ``do_install``, you might be able to work around them by disabling 1742 ``do_install``, you might be able to work around them by disabling
1743 parallel Makefile installs by adding the following to the recipe: 1743 parallel Makefile installs by adding the following to the recipe:
1744 PARALLEL_MAKEINST = "" See 1744 PARALLEL_MAKEINST = "" See
1745 ```PARALLEL_MAKEINST`` <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST>`__ 1745 :term:`PARALLEL_MAKEINST`
1746 for additional information. 1746 for additional information.
1747 1747
1748 - If you need to install one or more custom CMake toolchain files 1748 - If you need to install one or more custom CMake toolchain files
1749 that are supplied by the application you are building, install the 1749 that are supplied by the application you are building, install the
1750 files to ``${D}${datadir}/cmake/`` Modules during 1750 files to ``${D}${datadir}/cmake/`` Modules during
1751 ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__. 1751 :ref:`ref-tasks-install`.
1752 1752
1753.. _new-recipe-enabling-system-services: 1753.. _new-recipe-enabling-system-services:
1754 1754
@@ -1781,15 +1781,15 @@ different ways:
1781 shutdown of all other programs. 1781 shutdown of all other programs.
1782 1782
1783 To enable a service using SysVinit, your recipe needs to inherit the 1783 To enable a service using SysVinit, your recipe needs to inherit the
1784 ```update-rc.d`` <&YOCTO_DOCS_REF_URL;#ref-classes-update-rc.d>`__ 1784 :ref:`update-rc.d <ref-classes-update-rc.d>`
1785 class. The class helps facilitate safely installing the package on 1785 class. The class helps facilitate safely installing the package on
1786 the target. 1786 the target.
1787 1787
1788 You will need to set the 1788 You will need to set the
1789 ```INITSCRIPT_PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_PACKAGES>`__, 1789 :term:`INITSCRIPT_PACKAGES`,
1790 ```INITSCRIPT_NAME`` <&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_NAME>`__, 1790 :term:`INITSCRIPT_NAME`,
1791 and 1791 and
1792 ```INITSCRIPT_PARAMS`` <&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_PARAMS>`__ 1792 :term:`INITSCRIPT_PARAMS`
1793 variables within your recipe. 1793 variables within your recipe.
1794 1794
1795- *systemd:* System Management Daemon (systemd) was designed to replace 1795- *systemd:* System Management Daemon (systemd) was designed to replace
@@ -1798,7 +1798,7 @@ different ways:
1798 ` <http://freedesktop.org/wiki/Software/systemd/>`__. 1798 ` <http://freedesktop.org/wiki/Software/systemd/>`__.
1799 1799
1800 To enable a service using systemd, your recipe needs to inherit the 1800 To enable a service using systemd, your recipe needs to inherit the
1801 ```systemd`` <&YOCTO_DOCS_REF_URL;#ref-classes-systemd>`__ class. See 1801 :ref:`systemd <ref-classes-systemd>` class. See
1802 the ``systemd.bbclass`` file located in your `Source 1802 the ``systemd.bbclass`` file located in your `Source
1803 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. section for 1803 Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. section for
1804 more information. 1804 more information.
@@ -1819,24 +1819,24 @@ take. The following list describes the process:
1819 task ensures that files are split up and packaged correctly. 1819 task ensures that files are split up and packaged correctly.
1820 1820
1821- *Running QA Checks*: The 1821- *Running QA Checks*: The
1822 ```insane`` <&YOCTO_DOCS_REF_URL;#ref-classes-insane>`__ class adds a 1822 :ref:`insane <ref-classes-insane>` class adds a
1823 step to the package generation process so that output quality 1823 step to the package generation process so that output quality
1824 assurance checks are generated by the OpenEmbedded build system. This 1824 assurance checks are generated by the OpenEmbedded build system. This
1825 step performs a range of checks to be sure the build's output is free 1825 step performs a range of checks to be sure the build's output is free
1826 of common problems that show up during runtime. For information on 1826 of common problems that show up during runtime. For information on
1827 these checks, see the 1827 these checks, see the
1828 ```insane`` <&YOCTO_DOCS_REF_URL;#ref-classes-insane>`__ class and 1828 :ref:`insane <ref-classes-insane>` class and
1829 the "`QA Error and Warning 1829 the "`QA Error and Warning
1830 Messages <&YOCTO_DOCS_REF_URL;#ref-qa-checks>`__" chapter in the 1830 Messages <&YOCTO_DOCS_REF_URL;#ref-qa-checks>`__" chapter in the
1831 Yocto Project Reference Manual. 1831 Yocto Project Reference Manual.
1832 1832
1833- *Hand-Checking Your Packages*: After you build your software, you 1833- *Hand-Checking Your Packages*: After you build your software, you
1834 need to be sure your packages are correct. Examine the 1834 need to be sure your packages are correct. Examine the
1835 ``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}/packages-split`` 1835 ``${``\ :term:`WORKDIR`\ ``}/packages-split``
1836 directory and make sure files are where you expect them to be. If you 1836 directory and make sure files are where you expect them to be. If you
1837 discover problems, you can set 1837 discover problems, you can set
1838 ```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__, 1838 :term:`PACKAGES`,
1839 ```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__, 1839 :term:`FILES`,
1840 ``do_install(_append)``, and so forth as needed. 1840 ``do_install(_append)``, and so forth as needed.
1841 1841
1842- *Splitting an Application into Multiple Packages*: If you need to 1842- *Splitting an Application into Multiple Packages*: If you need to
@@ -1858,7 +1858,7 @@ take. The following list describes the process:
1858 By default, packages apply to any machine with the same architecture 1858 By default, packages apply to any machine with the same architecture
1859 as the target machine. When a recipe produces packages that are 1859 as the target machine. When a recipe produces packages that are
1860 machine-specific (e.g. the 1860 machine-specific (e.g. the
1861 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ value is passed 1861 :term:`MACHINE` value is passed
1862 into the configure script or a patch is applied only for a particular 1862 into the configure script or a patch is applied only for a particular
1863 machine), you should mark them as such by adding the following to the 1863 machine), you should mark them as such by adding the following to the
1864 recipe: PACKAGE_ARCH = "${MACHINE_ARCH}" 1864 recipe: PACKAGE_ARCH = "${MACHINE_ARCH}"
@@ -1867,7 +1867,7 @@ take. The following list describes the process:
1867 contain anything specific to the target machine or architecture at 1867 contain anything specific to the target machine or architecture at
1868 all (e.g. recipes that simply package script files or configuration 1868 all (e.g. recipes that simply package script files or configuration
1869 files), you should use the 1869 files), you should use the
1870 ```allarch`` <&YOCTO_DOCS_REF_URL;#ref-classes-allarch>`__ class to 1870 :ref:`allarch <ref-classes-allarch>` class to
1871 do this for you by adding this to your recipe: inherit allarch 1871 do this for you by adding this to your recipe: inherit allarch
1872 Ensuring that the package architecture is correct is not critical 1872 Ensuring that the package architecture is correct is not critical
1873 while you are doing the first few builds of your recipe. However, it 1873 while you are doing the first few builds of your recipe. However, it
@@ -1900,28 +1900,28 @@ recipe has two sysroots in its work directory, one for target files
1900Recipes should never populate the sysroot directly (i.e. write files 1900Recipes should never populate the sysroot directly (i.e. write files
1901into sysroot). Instead, files should be installed into standard 1901into sysroot). Instead, files should be installed into standard
1902locations during the 1902locations during the
1903```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task within 1903:ref:`ref-tasks-install` task within
1904the ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}`` directory. The 1904the ``${``\ :term:`D`\ ``}`` directory. The
1905reason for this limitation is that almost all files that populate the 1905reason for this limitation is that almost all files that populate the
1906sysroot are cataloged in manifests in order to ensure the files can be 1906sysroot are cataloged in manifests in order to ensure the files can be
1907removed later when a recipe is either modified or removed. Thus, the 1907removed later when a recipe is either modified or removed. Thus, the
1908sysroot is able to remain free from stale files. 1908sysroot is able to remain free from stale files.
1909 1909
1910A subset of the files installed by the 1910A subset of the files installed by the
1911```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task are 1911:ref:`ref-tasks-install` task are
1912used by the 1912used by the
1913```do_populate_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot>`__ 1913:ref:`ref-tasks-populate_sysroot`
1914task as defined by the the 1914task as defined by the the
1915```SYSROOT_DIRS`` <&YOCTO_DOCS_REF_URL;#var-SYSROOT_DIRS>`__ variable to 1915:term:`SYSROOT_DIRS` variable to
1916automatically populate the sysroot. It is possible to modify the list of 1916automatically populate the sysroot. It is possible to modify the list of
1917directories that populate the sysroot. The following example shows how 1917directories that populate the sysroot. The following example shows how
1918you could add the ``/opt`` directory to the list of directories within a 1918you could add the ``/opt`` directory to the list of directories within a
1919recipe: SYSROOT_DIRS += "/opt" 1919recipe: SYSROOT_DIRS += "/opt"
1920 1920
1921For a more complete description of the 1921For a more complete description of the
1922```do_populate_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot>`__ 1922:ref:`ref-tasks-populate_sysroot`
1923task and its associated functions, see the 1923task and its associated functions, see the
1924```staging`` <&YOCTO_DOCS_REF_URL;#ref-classes-staging>`__ class. 1924:ref:`staging <ref-classes-staging>` class.
1925 1925
1926.. _metadata-virtual-providers: 1926.. _metadata-virtual-providers:
1927 1927
@@ -1935,12 +1935,12 @@ determined at build-time.
1935 1935
1936A common scenario where a virtual provider is used would be for the 1936A common scenario where a virtual provider is used would be for the
1937kernel recipe. Suppose you have three kernel recipes whose 1937kernel recipe. Suppose you have three kernel recipes whose
1938```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__ values map to ``kernel-big``, 1938:term:`PN` values map to ``kernel-big``,
1939``kernel-mid``, and ``kernel-small``. Furthermore, each of these recipes 1939``kernel-mid``, and ``kernel-small``. Furthermore, each of these recipes
1940in some way uses a ```PROVIDES`` <&YOCTO_DOCS_REF_URL;#var-PROVIDES>`__ 1940in some way uses a :term:`PROVIDES`
1941statement that essentially identifies itself as being able to provide 1941statement that essentially identifies itself as being able to provide
1942``virtual/kernel``. Here is one way through the 1942``virtual/kernel``. Here is one way through the
1943```kernel`` <&YOCTO_DOCS_REF_URL;#ref-classes-kernel>`__ class: PROVIDES 1943:ref:`kernel <ref-classes-kernel>` class: PROVIDES
1944+= "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == 1944+= "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") ==
1945"kernel") else "" }" Any recipe that inherits the ``kernel`` class is 1945"kernel") else "" }" Any recipe that inherits the ``kernel`` class is
1946going to utilize a ``PROVIDES`` statement that identifies that recipe as 1946going to utilize a ``PROVIDES`` statement that identifies that recipe as
@@ -1949,11 +1949,11 @@ being able to provide the ``virtual/kernel`` item.
1949Now comes the time to actually build an image and you need a kernel 1949Now comes the time to actually build an image and you need a kernel
1950recipe, but which one? You can configure your build to call out the 1950recipe, but which one? You can configure your build to call out the
1951kernel recipe you want by using the 1951kernel recipe you want by using the
1952```PREFERRED_PROVIDER`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER>`__ 1952:term:`PREFERRED_PROVIDER`
1953variable. As an example, consider the 1953variable. As an example, consider the
1954```x86-base.inc`` <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/x86-base.inc>`__ 1954```x86-base.inc`` <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/x86-base.inc>`__
1955include file, which is a machine (i.e. 1955include file, which is a machine (i.e.
1956```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__) configuration file. 1956:term:`MACHINE`) configuration file.
1957This include file is the reason all x86-based machines use the 1957This include file is the reason all x86-based machines use the
1958``linux-yocto`` kernel. Here are the relevant lines from the include 1958``linux-yocto`` kernel. Here are the relevant lines from the include
1959file: PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto" 1959file: PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
@@ -1961,7 +1961,7 @@ PREFERRED_VERSION_linux-yocto ??= "4.15%"
1961 1961
1962When you use a virtual provider, you do not have to "hard code" a recipe 1962When you use a virtual provider, you do not have to "hard code" a recipe
1963name as a build dependency. You can use the 1963name as a build dependency. You can use the
1964```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ variable to state the 1964:term:`DEPENDS` variable to state the
1965build is dependent on ``virtual/kernel`` for example: DEPENDS = 1965build is dependent on ``virtual/kernel`` for example: DEPENDS =
1966"virtual/kernel" During the build, the OpenEmbedded build system picks 1966"virtual/kernel" During the build, the OpenEmbedded build system picks
1967the correct recipe needed for the ``virtual/kernel`` dependency based on 1967the correct recipe needed for the ``virtual/kernel`` dependency based on
@@ -2014,7 +2014,7 @@ build system and package managers, so the resulting packages will not
2014correctly trigger an upgrade. 2014correctly trigger an upgrade.
2015 2015
2016In order to ensure the versions compare properly, the recommended 2016In order to ensure the versions compare properly, the recommended
2017convention is to set ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ within the 2017convention is to set :term:`PV` within the
2018recipe to "previous_version+current_version". You can use an additional 2018recipe to "previous_version+current_version". You can use an additional
2019variable so that you can use the current version elsewhere. Here is an 2019variable so that you can use the current version elsewhere. Here is an
2020example: REALPV = "0.8.16-rc1" PV = "0.8.15+${REALPV}" 2020example: REALPV = "0.8.16-rc1" PV = "0.8.15+${REALPV}"
@@ -2032,7 +2032,7 @@ image. To add a post-installation script to a package, add a
2032to attach to the ``postinst`` script. To apply the post-installation 2032to attach to the ``postinst`` script. To apply the post-installation
2033script to the main package for the recipe, which is usually what is 2033script to the main package for the recipe, which is usually what is
2034required, specify 2034required, specify
2035``${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}`` in place of 2035``${``\ :term:`PN`\ ``}`` in place of
2036PACKAGENAME. 2036PACKAGENAME.
2037 2037
2038A post-installation function has the following structure: 2038A post-installation function has the following structure:
@@ -2057,12 +2057,12 @@ target. You can use ``pkg_postinst_ontarget()`` or call
2057``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``. Any 2057``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``. Any
2058failure of a ``pkg_postinst()`` script (including exit 1) triggers an 2058failure of a ``pkg_postinst()`` script (including exit 1) triggers an
2059error during the 2059error during the
2060```do_rootfs`` <&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs>`__ task. 2060:ref:`ref-tasks-rootfs` task.
2061 2061
2062If you have recipes that use ``pkg_postinst`` function and they require 2062If you have recipes that use ``pkg_postinst`` function and they require
2063the use of non-standard native tools that have dependencies during 2063the use of non-standard native tools that have dependencies during
2064rootfs construction, you need to use the 2064rootfs construction, you need to use the
2065```PACKAGE_WRITE_DEPS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_WRITE_DEPS>`__ 2065:term:`PACKAGE_WRITE_DEPS`
2066variable in your recipe to list these tools. If you do not use this 2066variable in your recipe to list these tools. If you do not use this
2067variable, the tools might be missing and execution of the 2067variable, the tools might be missing and execution of the
2068post-installation script is deferred until first boot. Deferring the 2068post-installation script is deferred until first boot. Deferring the
@@ -2126,7 +2126,7 @@ under ``files``) requires a recipe that has the file listed in the
2126``SRC_URI`` variable. Additionally, you need to manually write the 2126``SRC_URI`` variable. Additionally, you need to manually write the
2127``do_compile`` and ``do_install`` tasks. The ``S`` variable defines the 2127``do_compile`` and ``do_install`` tasks. The ``S`` variable defines the
2128directory containing the source code, which is set to 2128directory containing the source code, which is set to
2129```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__ in this case - the 2129:term:`WORKDIR` in this case - the
2130directory BitBake uses for the build. SUMMARY = "Simple helloworld 2130directory BitBake uses for the build. SUMMARY = "Simple helloworld
2131application" SECTION = "examples" LICENSE = "MIT" LIC_FILES_CHKSUM = 2131application" SECTION = "examples" LICENSE = "MIT" LIC_FILES_CHKSUM =
2132"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" 2132"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
@@ -2148,7 +2148,7 @@ Autotooled Package
2148Applications that use Autotools such as ``autoconf`` and ``automake`` 2148Applications that use Autotools such as ``autoconf`` and ``automake``
2149require a recipe that has a source archive listed in ``SRC_URI`` and 2149require a recipe that has a source archive listed in ``SRC_URI`` and
2150also inherit the 2150also inherit the
2151```autotools`` <&YOCTO_DOCS_REF_URL;#ref-classes-autotools>`__ class, 2151:ref:`autotools <ref-classes-autotools>` class,
2152which contains the definitions of all the steps needed to build an 2152which contains the definitions of all the steps needed to build an
2153Autotool-based application. The result of the build is automatically 2153Autotool-based application. The result of the build is automatically
2154packaged. And, if the application uses NLS for localization, packages 2154packaged. And, if the application uses NLS for localization, packages
@@ -2174,8 +2174,8 @@ source archive listed in ``SRC_URI``. You do not need to add a
2174``do_compile`` step since by default BitBake starts the ``make`` command 2174``do_compile`` step since by default BitBake starts the ``make`` command
2175to compile the application. If you need additional ``make`` options, you 2175to compile the application. If you need additional ``make`` options, you
2176should store them in the 2176should store them in the
2177```EXTRA_OEMAKE`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OEMAKE>`__ or 2177:term:`EXTRA_OEMAKE` or
2178```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ 2178:term:`PACKAGECONFIG_CONFARGS`
2179variables. BitBake passes these options into the GNU ``make`` 2179variables. BitBake passes these options into the GNU ``make``
2180invocation. Note that a ``do_install`` task is still required. 2180invocation. Note that a ``do_install`` task is still required.
2181Otherwise, BitBake runs an empty ``do_install`` task by default. 2181Otherwise, BitBake runs an empty ``do_install`` task by default.
@@ -2242,7 +2242,7 @@ needs to use those binaries as part of an image that you are building
2242using the OpenEmbedded build system. Since you only have the binaries 2242using the OpenEmbedded build system. Since you only have the binaries
2243and not the source code, you cannot use a typical recipe that expects to 2243and not the source code, you cannot use a typical recipe that expects to
2244fetch the source specified in 2244fetch the source specified in
2245```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ and then compile it. 2245:term:`SRC_URI` and then compile it.
2246 2246
2247One method is to package the binaries and then install them as part of 2247One method is to package the binaries and then install them as part of
2248the image. Generally, it is not a good idea to package binaries since, 2248the image. Generally, it is not a good idea to package binaries since,
@@ -2256,23 +2256,23 @@ and to be sure that you are using default locations for build artifacts.
2256In most cases, the ``bin_package`` class handles "skipping" the 2256In most cases, the ``bin_package`` class handles "skipping" the
2257configure and compile steps as well as sets things up to grab packages 2257configure and compile steps as well as sets things up to grab packages
2258from the appropriate area. In particular, this class sets ``noexec`` on 2258from the appropriate area. In particular, this class sets ``noexec`` on
2259both the ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ 2259both the :ref:`ref-tasks-configure`
2260and ```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__ tasks, 2260and :ref:`ref-tasks-compile` tasks,
2261sets ``FILES_${PN}`` to "/" so that it picks up all files, and sets up a 2261sets ``FILES_${PN}`` to "/" so that it picks up all files, and sets up a
2262```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task, which 2262:ref:`ref-tasks-install` task, which
2263effectively copies all files from ``${S}`` to ``${D}``. The 2263effectively copies all files from ``${S}`` to ``${D}``. The
2264``bin_package`` class works well when the files extracted into ``${S}`` 2264``bin_package`` class works well when the files extracted into ``${S}``
2265are already laid out in the way they should be laid out on the target. 2265are already laid out in the way they should be laid out on the target.
2266For more information on these variables, see the 2266For more information on these variables, see the
2267```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__, 2267:term:`FILES`,
2268```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__, 2268:term:`PN`,
2269```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__, and 2269:term:`S`, and
2270```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__ variables in the Yocto Project 2270:term:`D` variables in the Yocto Project
2271Reference Manual's variable glossary. 2271Reference Manual's variable glossary.
2272 2272
2273.. note:: 2273.. note::
2274 2274
2275 - Using ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ is a good 2275 - Using :term:`DEPENDS` is a good
2276 idea even for components distributed in binary form, and is often 2276 idea even for components distributed in binary form, and is often
2277 necessary for shared libraries. For a shared library, listing the 2277 necessary for shared libraries. For a shared library, listing the
2278 library dependencies in ``DEPENDS`` makes sure that the libraries 2278 library dependencies in ``DEPENDS`` makes sure that the libraries
@@ -2291,12 +2291,12 @@ If you cannot use the ``bin_package`` class, you need to be sure you are
2291doing the following: 2291doing the following:
2292 2292
2293- Create a recipe where the 2293- Create a recipe where the
2294 ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ and 2294 :ref:`ref-tasks-configure` and
2295 ```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__ tasks do 2295 :ref:`ref-tasks-compile` tasks do
2296 nothing: It is usually sufficient to just not define these tasks in 2296 nothing: It is usually sufficient to just not define these tasks in
2297 the recipe, because the default implementations do nothing unless a 2297 the recipe, because the default implementations do nothing unless a
2298 Makefile is found in 2298 Makefile is found in
2299 ``${``\ ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__\ ``}``. 2299 ``${``\ :term:`S`\ ``}``.
2300 2300
2301 If ``${S}`` might contain a Makefile, or if you inherit some class 2301 If ``${S}`` might contain a Makefile, or if you inherit some class
2302 that replaces ``do_configure`` and ``do_compile`` with custom 2302 that replaces ``do_configure`` and ``do_compile`` with custom
@@ -2306,17 +2306,17 @@ doing the following:
2306 = "1" do_compile[noexec] = "1" Unlike 2306 = "1" do_compile[noexec] = "1" Unlike
2307 ```deleting the tasks`` <&YOCTO_DOCS_BB_URL;#deleting-a-task>`__, 2307 ```deleting the tasks`` <&YOCTO_DOCS_BB_URL;#deleting-a-task>`__,
2308 using the flag preserves the dependency chain from the 2308 using the flag preserves the dependency chain from the
2309 ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__, 2309 :ref:`ref-tasks-fetch`,
2310 ```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__, and 2310 :ref:`ref-tasks-unpack`, and
2311 ```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ tasks to the 2311 :ref:`ref-tasks-patch` tasks to the
2312 ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task. 2312 :ref:`ref-tasks-install` task.
2313 2313
2314- Make sure your ``do_install`` task installs the binaries 2314- Make sure your ``do_install`` task installs the binaries
2315 appropriately. 2315 appropriately.
2316 2316
2317- Ensure that you set up ```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ 2317- Ensure that you set up :term:`FILES`
2318 (usually 2318 (usually
2319 ``FILES_${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}``) to 2319 ``FILES_${``\ :term:`PN`\ ``}``) to
2320 point to the files you have installed, which of course depends on 2320 point to the files you have installed, which of course depends on
2321 where you have installed them and whether those files are in 2321 where you have installed them and whether those files are in
2322 different locations than the defaults. 2322 different locations than the defaults.
@@ -2482,16 +2482,16 @@ in the BitBake User Manual.
2482 2482
2483- *Overrides:* You can use overrides to set a value conditionally, 2483- *Overrides:* You can use overrides to set a value conditionally,
2484 typically based on how the recipe is being built. For example, to set 2484 typically based on how the recipe is being built. For example, to set
2485 the ```KBRANCH`` <&YOCTO_DOCS_REF_URL;#var-KBRANCH>`__ variable's 2485 the :term:`KBRANCH` variable's
2486 value to "standard/base" for any target 2486 value to "standard/base" for any target
2487 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__, except for 2487 :term:`MACHINE`, except for
2488 qemuarm where it should be set to "standard/arm-versatile-926ejs", 2488 qemuarm where it should be set to "standard/arm-versatile-926ejs",
2489 you would do the following: KBRANCH = "standard/base" KBRANCH_qemuarm 2489 you would do the following: KBRANCH = "standard/base" KBRANCH_qemuarm
2490 = "standard/arm-versatile-926ejs" Overrides are also used to separate 2490 = "standard/arm-versatile-926ejs" Overrides are also used to separate
2491 alternate values of a variable in other situations. For example, when 2491 alternate values of a variable in other situations. For example, when
2492 setting variables such as 2492 setting variables such as
2493 ```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ and 2493 :term:`FILES` and
2494 ```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__ that are 2494 :term:`RDEPENDS` that are
2495 specific to individual packages produced by a recipe, you should 2495 specific to individual packages produced by a recipe, you should
2496 always use an override that specifies the name of the package. 2496 always use an override that specifies the name of the package.
2497 2497
@@ -2713,7 +2713,7 @@ The following steps describe how to set up the AUH utility:
2713 499), reused 703 (delta 434) Receiving objects: 100% (768/768), 2713 499), reused 703 (delta 434) Receiving objects: 100% (768/768),
2714 191.47 KiB \| 98.00 KiB/s, done. Resolving deltas: 100% (499/499), 2714 191.47 KiB \| 98.00 KiB/s, done. Resolving deltas: 100% (499/499),
2715 done. Checking connectivity... done. AUH is not part of the 2715 done. Checking connectivity... done. AUH is not part of the
2716 `OpenEmbedded-Core (OE-Core) <&YOCTO_DOCS_REF_URL;#oe-core>`__ or 2716 :term:`OpenEmbedded-Core (OE-Core)` or
2717 `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ repositories. 2717 `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ repositories.
2718 2718
27194. *Create a Dedicated Build Directory:* Run the 27194. *Create a Dedicated Build Directory:* Run the
@@ -2956,13 +2956,13 @@ edit the recipe files to upgrade the versions.
2956To manually upgrade recipe versions, follow these general steps: 2956To manually upgrade recipe versions, follow these general steps:
2957 2957
29581. *Change the Version:* Rename the recipe such that the version (i.e. 29581. *Change the Version:* Rename the recipe such that the version (i.e.
2959 the ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ part of the recipe name) 2959 the :term:`PV` part of the recipe name)
2960 changes appropriately. If the version is not part of the recipe name, 2960 changes appropriately. If the version is not part of the recipe name,
2961 change the value as it is set for ``PV`` within the recipe itself. 2961 change the value as it is set for ``PV`` within the recipe itself.
2962 2962
29632. *Update ``SRCREV`` if Needed:* If the source code your recipe builds 29632. *Update ``SRCREV`` if Needed:* If the source code your recipe builds
2964 is fetched from Git or some other version control system, update 2964 is fetched from Git or some other version control system, update
2965 ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__ to point to the 2965 :term:`SRCREV` to point to the
2966 commit hash that matches the new version. 2966 commit hash that matches the new version.
2967 2967
29683. *Build the Software:* Try to build the recipe using BitBake. Typical 29683. *Build the Software:* Try to build the recipe using BitBake. Typical
@@ -2970,8 +2970,8 @@ To manually upgrade recipe versions, follow these general steps:
2970 2970
2971 - License statements were updated for the new version. For this 2971 - License statements were updated for the new version. For this
2972 case, you need to review any changes to the license and update the 2972 case, you need to review any changes to the license and update the
2973 values of ```LICENSE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ and 2973 values of :term:`LICENSE` and
2974 ```LIC_FILES_CHKSUM`` <&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM>`__ 2974 :term:`LIC_FILES_CHKSUM`
2975 as needed. 2975 as needed.
2976 2976
2977 .. note:: 2977 .. note::
@@ -2989,7 +2989,7 @@ To manually upgrade recipe versions, follow these general steps:
29894. *Optionally Attempt to Build for Several Architectures:* Once you 29894. *Optionally Attempt to Build for Several Architectures:* Once you
2990 successfully build the new software for a given architecture, you 2990 successfully build the new software for a given architecture, you
2991 could test the build for other architectures by changing the 2991 could test the build for other architectures by changing the
2992 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable and 2992 :term:`MACHINE` variable and
2993 rebuilding the software. This optional step is especially important 2993 rebuilding the software. This optional step is especially important
2994 if the recipe is to be released publicly. 2994 if the recipe is to be released publicly.
2995 2995
@@ -3022,7 +3022,7 @@ patches.
3022 3022
3023During a build, the unpacked temporary source code used by recipes to 3023During a build, the unpacked temporary source code used by recipes to
3024build packages is available in the Build Directory as defined by the 3024build packages is available in the Build Directory as defined by the
3025```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__ variable. Below is the default 3025:term:`S` variable. Below is the default
3026value for the ``S`` variable as defined in the 3026value for the ``S`` variable as defined in the
3027``meta/conf/bitbake.conf`` configuration file in the `Source 3027``meta/conf/bitbake.conf`` configuration file in the `Source
3028Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: S = 3028Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: S =
@@ -3042,26 +3042,26 @@ usually set ``S`` to ``${WORKDIR}/git``.
3042 3042
3043 3043
3044The path to the work directory for the recipe 3044The path to the work directory for the recipe
3045(```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__) is defined as 3045(:term:`WORKDIR`) is defined as
3046follows: 3046follows:
3047${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} The 3047${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} The
3048actual directory depends on several things: 3048actual directory depends on several things:
3049 3049
3050- ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__: The top-level build 3050- :term:`TMPDIR`: The top-level build
3051 output directory. 3051 output directory.
3052 3052
3053- ```MULTIMACH_TARGET_SYS`` <&YOCTO_DOCS_REF_URL;#var-MULTIMACH_TARGET_SYS>`__: 3053- :term:`MULTIMACH_TARGET_SYS`:
3054 The target system identifier. 3054 The target system identifier.
3055 3055
3056- ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__: The recipe name. 3056- :term:`PN`: The recipe name.
3057 3057
3058- ```EXTENDPE`` <&YOCTO_DOCS_REF_URL;#var-EXTENDPE>`__: The epoch - (if 3058- :term:`EXTENDPE`: The epoch - (if
3059 ```PE`` <&YOCTO_DOCS_REF_URL;#var-PE>`__ is not specified, which is 3059 :term:`PE` is not specified, which is
3060 usually the case for most recipes, then ``EXTENDPE`` is blank). 3060 usually the case for most recipes, then ``EXTENDPE`` is blank).
3061 3061
3062- ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__: The recipe version. 3062- :term:`PV`: The recipe version.
3063 3063
3064- ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__: The recipe revision. 3064- :term:`PR`: The recipe revision.
3065 3065
3066As an example, assume a Source Directory top-level folder named 3066As an example, assume a Source Directory top-level folder named
3067``poky``, a default Build Directory at ``poky/build``, and a 3067``poky``, a default Build Directory at ``poky/build``, and a
@@ -3105,7 +3105,7 @@ Follow these general steps:
3105 3105
31062. *Change Your Working Directory:* You need to be in the directory that 31062. *Change Your Working Directory:* You need to be in the directory that
3107 has the temporary source code. That directory is defined by the 3107 has the temporary source code. That directory is defined by the
3108 ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__ variable. 3108 :term:`S` variable.
3109 3109
31103. *Create a New Patch:* Before modifying source code, you need to 31103. *Create a New Patch:* Before modifying source code, you need to
3111 create a new patch. To create a new patch file, use ``quilt new`` as 3111 create a new patch. To create a new patch file, use ``quilt new`` as
@@ -3170,9 +3170,9 @@ Using a Development Shell
3170When debugging certain commands or even when just editing packages, 3170When debugging certain commands or even when just editing packages,
3171``devshell`` can be a useful tool. When you invoke ``devshell``, all 3171``devshell`` can be a useful tool. When you invoke ``devshell``, all
3172tasks up to and including 3172tasks up to and including
3173```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ are run for the 3173:ref:`ref-tasks-patch` are run for the
3174specified target. Then, a new terminal is opened and you are placed in 3174specified target. Then, a new terminal is opened and you are placed in
3175``${``\ ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__\ ``}``, the source 3175``${``\ :term:`S`\ ``}``, the source
3176directory. In the new terminal, all the OpenEmbedded build-related 3176directory. In the new terminal, all the OpenEmbedded build-related
3177environment variables are still defined so you can use commands such as 3177environment variables are still defined so you can use commands such as
3178``configure`` and ``make``. The commands execute just as if the 3178``configure`` and ``make``. The commands execute just as if the
@@ -3185,7 +3185,7 @@ Following is an example that uses ``devshell`` on a target named
3185 3185
3186This command spawns a terminal with a shell prompt within the 3186This command spawns a terminal with a shell prompt within the
3187OpenEmbedded build environment. The 3187OpenEmbedded build environment. The
3188```OE_TERMINAL`` <&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL>`__ variable 3188:term:`OE_TERMINAL` variable
3189controls what type of shell is opened. 3189controls what type of shell is opened.
3190 3190
3191For spawned terminals, the following occurs: 3191For spawned terminals, the following occurs:
@@ -3200,11 +3200,11 @@ For spawned terminals, the following occurs:
3200Within this environment, you can run configure or compile commands as if 3200Within this environment, you can run configure or compile commands as if
3201they were being run by the OpenEmbedded build system itself. As noted 3201they were being run by the OpenEmbedded build system itself. As noted
3202earlier, the working directory also automatically changes to the Source 3202earlier, the working directory also automatically changes to the Source
3203Directory (```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__). 3203Directory (:term:`S`).
3204 3204
3205To manually run a specific task using ``devshell``, run the 3205To manually run a specific task using ``devshell``, run the
3206corresponding ``run.*`` script in the 3206corresponding ``run.*`` script in the
3207``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}/temp`` 3207``${``\ :term:`WORKDIR`\ ``}/temp``
3208directory (e.g., ``run.do_configure.``\ pid). If a task's script does 3208directory (e.g., ``run.do_configure.``\ pid). If a task's script does
3209not exist, which would be the case if the task was skipped by way of the 3209not exist, which would be the case if the task was skipped by way of the
3210sstate cache, you can create the task by first running it outside of the 3210sstate cache, you can create the task by first running it outside of the
@@ -3250,7 +3250,7 @@ previous section, you can also spawn and work within an interactive
3250Python development shell. When debugging certain commands or even when 3250Python development shell. When debugging certain commands or even when
3251just editing packages, ``devpyshell`` can be a useful tool. When you 3251just editing packages, ``devpyshell`` can be a useful tool. When you
3252invoke ``devpyshell``, all tasks up to and including 3252invoke ``devpyshell``, all tasks up to and including
3253```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ are run for the 3253:ref:`ref-tasks-patch` are run for the
3254specified target. Then a new terminal is opened. Additionally, key 3254specified target. Then a new terminal is opened. Additionally, key
3255Python objects and code are available in the same way they are to 3255Python objects and code are available in the same way they are to
3256BitBake tasks, in particular, the data store 'd'. So, commands such as 3256BitBake tasks, in particular, the data store 'd'. So, commands such as
@@ -3270,7 +3270,7 @@ Following is an example that uses ``devpyshell`` on a target named
3270 3270
3271This command spawns a terminal and places you in an interactive Python 3271This command spawns a terminal and places you in an interactive Python
3272interpreter within the OpenEmbedded build environment. The 3272interpreter within the OpenEmbedded build environment. The
3273```OE_TERMINAL`` <&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL>`__ variable 3273:term:`OE_TERMINAL` variable
3274controls what type of shell is opened. 3274controls what type of shell is opened.
3275 3275
3276When you are finished using ``devpyshell``, you can exit the shell 3276When you are finished using ``devpyshell``, you can exit the shell
@@ -3357,9 +3357,9 @@ The following figure and list overviews the build process:
3357 of the build environment including the target machine architecture 3357 of the build environment including the target machine architecture
3358 through the ``MACHINE`` variable, the packaging format used during 3358 through the ``MACHINE`` variable, the packaging format used during
3359 the build 3359 the build
3360 (```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__), 3360 (:term:`PACKAGE_CLASSES`),
3361 and a centralized tarball download directory through the 3361 and a centralized tarball download directory through the
3362 ```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__ variable. 3362 :term:`DL_DIR` variable.
3363 3363
33644. *Build the Image:* Build the image using the ``bitbake`` command: $ 33644. *Build the Image:* Build the image using the ``bitbake`` command: $
3365 bitbake target 3365 bitbake target
@@ -3377,7 +3377,7 @@ The following figure and list overviews the build process:
3377 can be the name of a recipe for a specific piece of software such as 3377 can be the name of a recipe for a specific piece of software such as
3378 BusyBox. For more details about the images the OpenEmbedded build 3378 BusyBox. For more details about the images the OpenEmbedded build
3379 system supports, see the 3379 system supports, see the
3380 "`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the Yocto 3380 ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
3381 Project Reference Manual. 3381 Project Reference Manual.
3382 3382
3383 As an example, the following command builds the 3383 As an example, the following command builds the
@@ -3413,7 +3413,7 @@ Setting Up and Running a Multiple Configuration Build
3413 3413
3414To accomplish a multiple configuration build, you must define each 3414To accomplish a multiple configuration build, you must define each
3415target's configuration separately using a parallel configuration file in 3415target's configuration separately using a parallel configuration file in
3416the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, and you 3416the :term:`Build Directory`, and you
3417must follow a required file hierarchy. Additionally, you must enable the 3417must follow a required file hierarchy. Additionally, you must enable the
3418multiple configuration builds in your ``local.conf`` file. 3418multiple configuration builds in your ``local.conf`` file.
3419 3419
@@ -3426,9 +3426,9 @@ Follow these steps to set up and execute multiple configuration builds:
3426 dictates that you do not overlap the temporary directories used 3426 dictates that you do not overlap the temporary directories used
3427 during the builds. However, it is possible that you can share the 3427 during the builds. However, it is possible that you can share the
3428 temporary directory 3428 temporary directory
3429 (```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__). For example, 3429 (:term:`TMPDIR`). For example,
3430 consider a scenario with two different multiconfigs for the same 3430 consider a scenario with two different multiconfigs for the same
3431 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__: "qemux86" built 3431 :term:`MACHINE`: "qemux86" built
3432 for two distributions such as "poky" and "poky-lsb". In this case, 3432 for two distributions such as "poky" and "poky-lsb". In this case,
3433 you might want to use the same ``TMPDIR``. 3433 you might want to use the same ``TMPDIR``.
3434 3434
@@ -3450,7 +3450,7 @@ Follow these steps to set up and execute multiple configuration builds:
3450 3450
3451- *Add the BitBake Multi-configuration Variable to the Local 3451- *Add the BitBake Multi-configuration Variable to the Local
3452 Configuration File*: Use the 3452 Configuration File*: Use the
3453 ```BBMULTICONFIG`` <&YOCTO_DOCS_REF_URL;#var-BBMULTICONFIG>`__ 3453 :term:`BBMULTICONFIG`
3454 variable in your ``conf/local.conf`` configuration file to specify 3454 variable in your ``conf/local.conf`` configuration file to specify
3455 each multiconfig. Continuing with the example from the previous 3455 each multiconfig. Continuing with the example from the previous
3456 figure, the ``BBMULTICONFIG`` variable needs to enable two 3456 figure, the ``BBMULTICONFIG`` variable needs to enable two
@@ -3498,9 +3498,9 @@ multiple configuration build. For example, suppose that in order to
3498build a ``core-image-sato`` image for an "x86" multiconfig, the root 3498build a ``core-image-sato`` image for an "x86" multiconfig, the root
3499filesystem of an "arm" multiconfig must exist. This dependency is 3499filesystem of an "arm" multiconfig must exist. This dependency is
3500essentially that the 3500essentially that the
3501```do_image`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__ task in the 3501:ref:`ref-tasks-image` task in the
3502``core-image-sato`` recipe depends on the completion of the 3502``core-image-sato`` recipe depends on the completion of the
3503```do_rootfs`` <&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs>`__ task of the 3503:ref:`ref-tasks-rootfs` task of the
3504``core-image-minimal`` recipe. 3504``core-image-minimal`` recipe.
3505 3505
3506To enable dependencies in a multiple configuration build, you must 3506To enable dependencies in a multiple configuration build, you must
@@ -3533,7 +3533,7 @@ create the ``core-image-minimal`` image for the "arm" build since the
3533Because "x86" and "arm" are enabled for multiple configuration builds 3533Because "x86" and "arm" are enabled for multiple configuration builds
3534and have separate configuration files, BitBake places the artifacts for 3534and have separate configuration files, BitBake places the artifacts for
3535each build in the respective temporary build directories (i.e. 3535each build in the respective temporary build directories (i.e.
3536```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__). 3536:term:`TMPDIR`).
3537 3537
3538.. _building-an-initramfs-image: 3538.. _building-an-initramfs-image:
3539 3539
@@ -3564,9 +3564,9 @@ Follow these steps to create an initramfs image:
35642. *Decide if You Need to Bundle the initramfs Image Into the Kernel 35642. *Decide if You Need to Bundle the initramfs Image Into the Kernel
3565 Image:* If you want the initramfs image that is built to be bundled 3565 Image:* If you want the initramfs image that is built to be bundled
3566 in with the kernel image, set the 3566 in with the kernel image, set the
3567 ```INITRAMFS_IMAGE_BUNDLE`` <&YOCTO_DOCS_REF_URL;#var-INITRAMFS_IMAGE_BUNDLE>`__ 3567 :term:`INITRAMFS_IMAGE_BUNDLE`
3568 variable to "1" in your ``local.conf`` configuration file and set the 3568 variable to "1" in your ``local.conf`` configuration file and set the
3569 ```INITRAMFS_IMAGE`` <&YOCTO_DOCS_REF_URL;#var-INITRAMFS_IMAGE>`__ 3569 :term:`INITRAMFS_IMAGE`
3570 variable in the recipe that builds the kernel image. 3570 variable in the recipe that builds the kernel image.
3571 3571
3572 .. note:: 3572 .. note::
@@ -3579,7 +3579,7 @@ Follow these steps to create an initramfs image:
3579 Setting the ``INITRAMFS_IMAGE_BUNDLE`` flag causes the initramfs 3579 Setting the ``INITRAMFS_IMAGE_BUNDLE`` flag causes the initramfs
3580 image to be unpacked into the ``${B}/usr/`` directory. The unpacked 3580 image to be unpacked into the ``${B}/usr/`` directory. The unpacked
3581 initramfs image is then passed to the kernel's ``Makefile`` using the 3581 initramfs image is then passed to the kernel's ``Makefile`` using the
3582 ```CONFIG_INITRAMFS_SOURCE`` <&YOCTO_DOCS_REF_URL;#var-CONFIG_INITRAMFS_SOURCE>`__ 3582 :term:`CONFIG_INITRAMFS_SOURCE`
3583 variable, allowing the initramfs image to be built into the kernel 3583 variable, allowing the initramfs image to be built into the kernel
3584 normally. 3584 normally.
3585 3585
@@ -3601,20 +3601,20 @@ Follow these steps to create an initramfs image:
36013. *Optionally Add Items to the initramfs Image Through the initramfs 36013. *Optionally Add Items to the initramfs Image Through the initramfs
3602 Image Recipe:* If you add items to the initramfs image by way of its 3602 Image Recipe:* If you add items to the initramfs image by way of its
3603 recipe, you should use 3603 recipe, you should use
3604 ```PACKAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_INSTALL>`__ 3604 :term:`PACKAGE_INSTALL`
3605 rather than 3605 rather than
3606 ```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__. 3606 :term:`IMAGE_INSTALL`.
3607 ``PACKAGE_INSTALL`` gives more direct control of what is added to the 3607 ``PACKAGE_INSTALL`` gives more direct control of what is added to the
3608 image as compared to the defaults you might not necessarily want that 3608 image as compared to the defaults you might not necessarily want that
3609 are set by the ```image`` <&YOCTO_DOCS_REF_URL;#ref-classes-image>`__ 3609 are set by the :ref:`image <ref-classes-image>`
3610 or ```core-image`` <&YOCTO_DOCS_REF_URL;#ref-classes-core-image>`__ 3610 or :ref:`core-image <ref-classes-core-image>`
3611 classes. 3611 classes.
3612 3612
36134. *Build the Kernel Image and the initramfs Image:* Build your kernel 36134. *Build the Kernel Image and the initramfs Image:* Build your kernel
3614 image using BitBake. Because the initramfs image recipe is a 3614 image using BitBake. Because the initramfs image recipe is a
3615 dependency of the kernel image, the initramfs image is built as well 3615 dependency of the kernel image, the initramfs image is built as well
3616 and bundled with the kernel image if you used the 3616 and bundled with the kernel image if you used the
3617 ```INITRAMFS_IMAGE_BUNDLE`` <&YOCTO_DOCS_REF_URL;#var-INITRAMFS_IMAGE_BUNDLE>`__ 3617 :term:`INITRAMFS_IMAGE_BUNDLE`
3618 variable described earlier. 3618 variable described earlier.
3619 3619
3620Building a Tiny System 3620Building a Tiny System
@@ -3850,7 +3850,7 @@ dependencies as well as removing the package management data itself.
3850 3850
3851To eliminate all the packaging requirements for an image, be sure that 3851To eliminate all the packaging requirements for an image, be sure that
3852"package-management" is not part of your 3852"package-management" is not part of your
3853```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__ 3853:term:`IMAGE_FEATURES`
3854statement for the image. When you remove this feature, you are removing 3854statement for the image. When you remove this feature, you are removing
3855the package manager as well as its dependencies from the root 3855the package manager as well as its dependencies from the root
3856filesystem. 3856filesystem.
@@ -3866,7 +3866,7 @@ are a couple of areas to experiment with:
3866- ``glibc``: In general, follow this process: 3866- ``glibc``: In general, follow this process:
3867 3867
3868 1. Remove ``glibc`` features from 3868 1. Remove ``glibc`` features from
3869 ```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__ 3869 :term:`DISTRO_FEATURES`
3870 that you think you do not need. 3870 that you think you do not need.
3871 3871
3872 2. Build your distribution. 3872 2. Build your distribution.
@@ -3913,7 +3913,7 @@ that are extremely specific to a CPU core used in a system might enable
3913some micro optimizations in GCC for that particular system but would 3913some micro optimizations in GCC for that particular system but would
3914otherwise not gain you much of a performance difference across the other 3914otherwise not gain you much of a performance difference across the other
3915systems as compared to using a more general tuning across all the builds 3915systems as compared to using a more general tuning across all the builds
3916(e.g. setting ```DEFAULTTUNE`` <&YOCTO_DOCS_REF_URL;#var-DEFAULTTUNE>`__ 3916(e.g. setting :term:`DEFAULTTUNE`
3917specifically for each machine's build). Rather than "max out" each 3917specifically for each machine's build). Rather than "max out" each
3918build's tunings, you can take steps that cause the OpenEmbedded build 3918build's tunings, you can take steps that cause the OpenEmbedded build
3919system to reuse software across the various machines where it makes 3919system to reuse software across the various machines where it makes
@@ -3924,9 +3924,9 @@ should consider the points in this section that can help you optimize
3924your tunings to best consider build times and package feed maintenance. 3924your tunings to best consider build times and package feed maintenance.
3925 3925
3926- *Share the Build Directory:* If at all possible, share the 3926- *Share the Build Directory:* If at all possible, share the
3927 ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__ across builds. The 3927 :term:`TMPDIR` across builds. The
3928 Yocto Project supports switching between different 3928 Yocto Project supports switching between different
3929 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ values in the same 3929 :term:`MACHINE` values in the same
3930 ``TMPDIR``. This practice is well supported and regularly used by 3930 ``TMPDIR``. This practice is well supported and regularly used by
3931 developers when building for multiple machines. When you use the same 3931 developers when building for multiple machines. When you use the same
3932 ``TMPDIR`` for multiple machine builds, the OpenEmbedded build system 3932 ``TMPDIR`` for multiple machine builds, the OpenEmbedded build system
@@ -3958,7 +3958,7 @@ your tunings to best consider build times and package feed maintenance.
3958 A recipe that just generates scripts can enable "all" architecture 3958 A recipe that just generates scripts can enable "all" architecture
3959 because there are no binaries to build. To specifically enable "all" 3959 because there are no binaries to build. To specifically enable "all"
3960 architecture, be sure your recipe inherits the 3960 architecture, be sure your recipe inherits the
3961 ```allarch`` <&YOCTO_DOCS_REF_URL;#ref-classes-allarch>`__ class. 3961 :ref:`allarch <ref-classes-allarch>` class.
3962 This class is useful for "all" architectures because it configures 3962 This class is useful for "all" architectures because it configures
3963 many variables so packages can be used across multiple architectures. 3963 many variables so packages can be used across multiple architectures.
3964 3964
@@ -3967,12 +3967,12 @@ your tunings to best consider build times and package feed maintenance.
3967 machine-architecture dependent, which makes your recipe also 3967 machine-architecture dependent, which makes your recipe also
3968 machine-architecture dependent, make sure your recipe enables the 3968 machine-architecture dependent, make sure your recipe enables the
3969 "machine" package architecture through the 3969 "machine" package architecture through the
3970 ```MACHINE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ARCH>`__ 3970 :term:`MACHINE_ARCH`
3971 variable: PACKAGE_ARCH = "${MACHINE_ARCH}" When you do not 3971 variable: PACKAGE_ARCH = "${MACHINE_ARCH}" When you do not
3972 specifically enable a package architecture through the 3972 specifically enable a package architecture through the
3973 ```PACKAGE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH>`__, The 3973 :term:`PACKAGE_ARCH`, The
3974 OpenEmbedded build system defaults to the 3974 OpenEmbedded build system defaults to the
3975 ```TUNE_PKGARCH`` <&YOCTO_DOCS_REF_URL;#var-TUNE_PKGARCH>`__ setting: 3975 :term:`TUNE_PKGARCH` setting:
3976 PACKAGE_ARCH = "${TUNE_PKGARCH}" 3976 PACKAGE_ARCH = "${TUNE_PKGARCH}"
3977 3977
3978- *Choose a Generic Tuning File if Possible:* Some tunes are more 3978- *Choose a Generic Tuning File if Possible:* Some tunes are more
@@ -4001,11 +4001,11 @@ your tunings to best consider build times and package feed maintenance.
4001 boards share the Vivante GPU. This class inspects the BitBake 4001 boards share the Vivante GPU. This class inspects the BitBake
4002 datastore to identify if the package provides or depends on one of 4002 datastore to identify if the package provides or depends on one of
4003 the sub-architecture values. If so, the class sets the 4003 the sub-architecture values. If so, the class sets the
4004 ```PACKAGE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH>`__ value 4004 :term:`PACKAGE_ARCH` value
4005 based on the ``MACHINE_SUBARCH`` value. If the package does not 4005 based on the ``MACHINE_SUBARCH`` value. If the package does not
4006 provide or depend on one of the sub-architecture values but it 4006 provide or depend on one of the sub-architecture values but it
4007 matches a value in the machine-specific filter, it sets 4007 matches a value in the machine-specific filter, it sets
4008 ```MACHINE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ARCH>`__. This 4008 :term:`MACHINE_ARCH`. This
4009 behavior reduces the number of packages built and saves build time by 4009 behavior reduces the number of packages built and saves build time by
4010 reusing binaries. 4010 reusing binaries.
4011 4011
@@ -4014,18 +4014,18 @@ your tunings to best consider build times and package feed maintenance.
4014 example, the OpenEmbedded build system might not be using shared 4014 example, the OpenEmbedded build system might not be using shared
4015 state between machines when you think it should be. These types of 4015 state between machines when you think it should be. These types of
4016 situations are usually due to references to machine-specific 4016 situations are usually due to references to machine-specific
4017 variables such as ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__, 4017 variables such as :term:`MACHINE`,
4018 ```SERIAL_CONSOLES`` <&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLES>`__, 4018 :term:`SERIAL_CONSOLES`,
4019 ```XSERVER`` <&YOCTO_DOCS_REF_URL;#var-XSERVER>`__, 4019 :term:`XSERVER`,
4020 ```MACHINE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES>`__, 4020 :term:`MACHINE_FEATURES`,
4021 and so forth in code that is supposed to only be tune-specific or 4021 and so forth in code that is supposed to only be tune-specific or
4022 when the recipe depends 4022 when the recipe depends
4023 (```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__, 4023 (:term:`DEPENDS`,
4024 ```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__, 4024 :term:`RDEPENDS`,
4025 ```RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS>`__, 4025 :term:`RRECOMMENDS`,
4026 ```RSUGGESTS`` <&YOCTO_DOCS_REF_URL;#var-RSUGGESTS>`__, and so forth) 4026 :term:`RSUGGESTS`, and so forth)
4027 on some other recipe that already has 4027 on some other recipe that already has
4028 ```PACKAGE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH>`__ defined 4028 :term:`PACKAGE_ARCH` defined
4029 as "${MACHINE_ARCH}". 4029 as "${MACHINE_ARCH}".
4030 4030
4031 .. note:: 4031 .. note::
@@ -4062,14 +4062,14 @@ build system to the development team so that they can focus on their
4062project and maintain everyone's workflow as much as possible. In this 4062project and maintain everyone's workflow as much as possible. In this
4063case, you want a kernel source directory on the development machine 4063case, you want a kernel source directory on the development machine
4064where the development occurs. You want the recipe's 4064where the development occurs. You want the recipe's
4065```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ variable to point to 4065:term:`SRC_URI` variable to point to
4066the external directory and use it as is, not copy it. 4066the external directory and use it as is, not copy it.
4067 4067
4068To build from software that comes from an external source, all you need 4068To build from software that comes from an external source, all you need
4069to do is inherit the 4069to do is inherit the
4070```externalsrc`` <&YOCTO_DOCS_REF_URL;#ref-classes-externalsrc>`__ class 4070:ref:`externalsrc <ref-classes-externalsrc>` class
4071and then set the 4071and then set the
4072```EXTERNALSRC`` <&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC>`__ variable to 4072:term:`EXTERNALSRC` variable to
4073point to your external source code. Here are the statements to put in 4073point to your external source code. Here are the statements to put in
4074your ``local.conf`` file: INHERIT += "externalsrc" 4074your ``local.conf`` file: INHERIT += "externalsrc"
4075EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree" 4075EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
@@ -4087,10 +4087,10 @@ EXTERNALSRC = "path" EXTERNALSRC_BUILD = "path"
4087 4087
4088By default, ``externalsrc.bbclass`` builds the source code in a 4088By default, ``externalsrc.bbclass`` builds the source code in a
4089directory separate from the external source directory as specified by 4089directory separate from the external source directory as specified by
4090```EXTERNALSRC`` <&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC>`__. If you need 4090:term:`EXTERNALSRC`. If you need
4091to have the source built in the same directory in which it resides, or 4091to have the source built in the same directory in which it resides, or
4092some other nominated directory, you can set 4092some other nominated directory, you can set
4093```EXTERNALSRC_BUILD`` <&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC_BUILD>`__ 4093:term:`EXTERNALSRC_BUILD`
4094to point to that directory: EXTERNALSRC_BUILD_pn-myrecipe = 4094to point to that directory: EXTERNALSRC_BUILD_pn-myrecipe =
4095"path-to-your-source-tree" 4095"path-to-your-source-tree"
4096 4096
@@ -4107,7 +4107,7 @@ build.
4107Follow these steps to populate your Downloads directory: 4107Follow these steps to populate your Downloads directory:
4108 4108
41091. *Create a Clean Downloads Directory:* Start with an empty downloads 41091. *Create a Clean Downloads Directory:* Start with an empty downloads
4110 directory (```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__). You 4110 directory (:term:`DL_DIR`). You
4111 start with an empty downloads directory by either removing the files 4111 start with an empty downloads directory by either removing the files
4112 in the existing directory or by setting ``DL_DIR`` to point to either 4112 in the existing directory or by setting ``DL_DIR`` to point to either
4113 an empty location or one that does not yet exist. 4113 an empty location or one that does not yet exist.
@@ -4118,7 +4118,7 @@ Follow these steps to populate your Downloads directory:
4118 the fetch process in the next step, BitBake gathers the source files 4118 the fetch process in the next step, BitBake gathers the source files
4119 and creates tarballs in the directory pointed to by ``DL_DIR``. See 4119 and creates tarballs in the directory pointed to by ``DL_DIR``. See
4120 the 4120 the
4121 ```BB_GENERATE_MIRROR_TARBALLS`` <&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS>`__ 4121 :term:`BB_GENERATE_MIRROR_TARBALLS`
4122 variable for more information. 4122 variable for more information.
4123 4123
41243. *Populate Your Downloads Directory Without Building:* Use BitBake to 41243. *Populate Your Downloads Directory Without Building:* Use BitBake to
@@ -4142,9 +4142,9 @@ Follow these steps to build your target using the files in the downloads
4142directory: 4142directory:
4143 4143
41441. *Using Local Files Only:* Inside your ``local.conf`` file, add the 41441. *Using Local Files Only:* Inside your ``local.conf`` file, add the
4145 ```SOURCE_MIRROR_URL`` <&YOCTO_DOCS_REF_URL;#var-SOURCE_MIRROR_URL>`__ 4145 :term:`SOURCE_MIRROR_URL`
4146 variable, inherit the 4146 variable, inherit the
4147 ```own-mirrors`` <&YOCTO_DOCS_REF_URL;#ref-classes-own-mirrors>`__ 4147 :ref:`own-mirrors <ref-classes-own-mirrors>`
4148 class, and use the 4148 class, and use the
4149 ```BB_NO_NETWORK`` <&YOCTO_DOCS_BB_URL;#var-bb-BB_NO_NETWORK>`__ 4149 ```BB_NO_NETWORK`` <&YOCTO_DOCS_BB_URL;#var-bb-BB_NO_NETWORK>`__
4150 variable to your ``local.conf``. SOURCE_MIRROR_URL ?= 4150 variable to your ``local.conf``. SOURCE_MIRROR_URL ?=
@@ -4157,7 +4157,7 @@ directory:
4157 4157
41582. *Start With a Clean Build:* You can start with a clean build by 41582. *Start With a Clean Build:* You can start with a clean build by
4159 removing the 4159 removing the
4160 ``${``\ ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__\ ``}`` 4160 ``${``\ :term:`TMPDIR`\ ``}``
4161 directory or using a new `Build 4161 directory or using a new `Build
4162 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 4162 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
4163 4163
@@ -4170,8 +4170,8 @@ directory:
4170 4170
4171 The offline build does not work if recipes attempt to find the 4171 The offline build does not work if recipes attempt to find the
4172 latest version of software by setting 4172 latest version of software by setting
4173 ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__ to 4173 :term:`SRCREV` to
4174 ``${``\ ```AUTOREV`` <&YOCTO_DOCS_REF_URL;#var-AUTOREV>`__\ ``}``: 4174 ``${``\ :term:`AUTOREV`\ ``}``:
4175 SRCREV = "${AUTOREV}" When a recipe sets ``SRCREV`` to 4175 SRCREV = "${AUTOREV}" When a recipe sets ``SRCREV`` to
4176 ``${AUTOREV}``, the build system accesses the network in an 4176 ``${AUTOREV}``, the build system accesses the network in an
4177 attempt to determine the latest version of software from the SCM. 4177 attempt to determine the latest version of software from the SCM.
@@ -4214,12 +4214,12 @@ variable for more information:
4214 4214
4215- ```PARALLEL_MAKE``: <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE>`__ Extra 4215- ```PARALLEL_MAKE``: <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE>`__ Extra
4216 options passed to the ``make`` command during the 4216 options passed to the ``make`` command during the
4217 ```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__ task in 4217 :ref:`ref-tasks-compile` task in
4218 order to specify parallel compilation on the local build host. 4218 order to specify parallel compilation on the local build host.
4219 4219
4220- ```PARALLEL_MAKEINST``: <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST>`__ 4220- ```PARALLEL_MAKEINST``: <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST>`__
4221 Extra options passed to the ``make`` command during the 4221 Extra options passed to the ``make`` command during the
4222 ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task in 4222 :ref:`ref-tasks-install` task in
4223 order to specify parallel installation on the local build host. 4223 order to specify parallel installation on the local build host.
4224 4224
4225As mentioned, these variables all scale to the number of processor cores 4225As mentioned, these variables all scale to the number of processor cores
@@ -4249,12 +4249,12 @@ Following are additional factors that can affect build speed:
4249 IPK is the fastest. Additionally, selecting a singular packaging 4249 IPK is the fastest. Additionally, selecting a singular packaging
4250 backend also helps. 4250 backend also helps.
4251 4251
4252- Using ``tmpfs`` for ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__ 4252- Using ``tmpfs`` for :term:`TMPDIR`
4253 as a temporary file system: While this can help speed up the build, 4253 as a temporary file system: While this can help speed up the build,
4254 the benefits are limited due to the compiler using ``-pipe``. The 4254 the benefits are limited due to the compiler using ``-pipe``. The
4255 build system goes to some lengths to avoid ``sync()`` calls into the 4255 build system goes to some lengths to avoid ``sync()`` calls into the
4256 file system on the principle that if there was a significant failure, 4256 file system on the principle that if there was a significant failure,
4257 the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ 4257 the :term:`Build Directory`
4258 contents could easily be rebuilt. 4258 contents could easily be rebuilt.
4259 4259
4260- Inheriting the 4260- Inheriting the
@@ -4262,7 +4262,7 @@ Following are additional factors that can affect build speed:
4262 Inheriting this class has shown to speed up builds due to 4262 Inheriting this class has shown to speed up builds due to
4263 significantly lower amounts of data stored in the data cache as well 4263 significantly lower amounts of data stored in the data cache as well
4264 as on disk. Inheriting this class also makes cleanup of 4264 as on disk. Inheriting this class also makes cleanup of
4265 ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__ faster, at the 4265 :term:`TMPDIR` faster, at the
4266 expense of being easily able to dive into the source code. File 4266 expense of being easily able to dive into the source code. File
4267 system maintainers have recommended that the fastest way to clean up 4267 system maintainers have recommended that the fastest way to clean up
4268 large numbers of files is to reformat partitions rather than delete 4268 large numbers of files is to reformat partitions rather than delete
@@ -4274,14 +4274,14 @@ Aside from the previous list, you should keep some trade offs in mind
4274that can help you speed up the build: 4274that can help you speed up the build:
4275 4275
4276- Remove items from 4276- Remove items from
4277 ```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__ 4277 :term:`DISTRO_FEATURES`
4278 that you might not need. 4278 that you might not need.
4279 4279
4280- Exclude debug symbols and other debug information: If you do not need 4280- Exclude debug symbols and other debug information: If you do not need
4281 these symbols and other debug information, disabling the ``*-dbg`` 4281 these symbols and other debug information, disabling the ``*-dbg``
4282 package generation can speed up the build. You can disable this 4282 package generation can speed up the build. You can disable this
4283 generation by setting the 4283 generation by setting the
4284 ```INHIBIT_PACKAGE_DEBUG_SPLIT`` <&YOCTO_DOCS_REF_URL;#var-INHIBIT_PACKAGE_DEBUG_SPLIT>`__ 4284 :term:`INHIBIT_PACKAGE_DEBUG_SPLIT`
4285 variable to "1". 4285 variable to "1".
4286 4286
4287- Disable static library generation for recipes derived from 4287- Disable static library generation for recipes derived from
@@ -4328,7 +4328,7 @@ If you are building a library and the library offers static linking, you
4328can control which static library files (``*.a`` files) get included in 4328can control which static library files (``*.a`` files) get included in
4329the built library. 4329the built library.
4330 4330
4331The ```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__ and 4331The :term:`PACKAGES` and
4332```FILES_*`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ variables in the 4332```FILES_*`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ variables in the
4333``meta/conf/bitbake.conf`` configuration file define how files installed 4333``meta/conf/bitbake.conf`` configuration file define how files installed
4334by the ``do_install`` task are packaged. By default, the ``PACKAGES`` 4334by the ``do_install`` task are packaged. By default, the ``PACKAGES``
@@ -4391,7 +4391,7 @@ libraries could differ in architecture, compiler options, or other
4391optimizations. 4391optimizations.
4392 4392
4393Several examples exist in the ``meta-skeleton`` layer found in the 4393Several examples exist in the ``meta-skeleton`` layer found in the
4394`Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: 4394:term:`Source Directory`:
4395 4395
4396- ``conf/multilib-example.conf`` configuration file 4396- ``conf/multilib-example.conf`` configuration file
4397 4397
@@ -4412,7 +4412,7 @@ already extended and support multiple libraries. You can check in the
4412``meta/conf/multilib.conf`` configuration file in the `Source 4412``meta/conf/multilib.conf`` configuration file in the `Source
4413Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ to see how this is 4413Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ to see how this is
4414done using the 4414done using the
4415```BBCLASSEXTEND`` <&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND>`__ variable. 4415:term:`BBCLASSEXTEND` variable.
4416Eventually, all recipes will be covered and this list will not be 4416Eventually, all recipes will be covered and this list will not be
4417needed. 4417needed.
4418 4418
@@ -4420,12 +4420,12 @@ For the most part, the Multilib class extension works automatically to
4420extend the package name from ``${PN}`` to ``${MLPREFIX}${PN}``, where 4420extend the package name from ``${PN}`` to ``${MLPREFIX}${PN}``, where
4421``MLPREFIX`` is the particular multilib (e.g. "lib32-" or "lib64-"). 4421``MLPREFIX`` is the particular multilib (e.g. "lib32-" or "lib64-").
4422Standard variables such as 4422Standard variables such as
4423```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__, 4423:term:`DEPENDS`,
4424```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__, 4424:term:`RDEPENDS`,
4425```RPROVIDES`` <&YOCTO_DOCS_REF_URL;#var-RPROVIDES>`__, 4425:term:`RPROVIDES`,
4426```RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS>`__, 4426:term:`RRECOMMENDS`,
4427```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__, and 4427:term:`PACKAGES`, and
4428```PACKAGES_DYNAMIC`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES_DYNAMIC>`__ are 4428:term:`PACKAGES_DYNAMIC` are
4429automatically extended by the system. If you are extending any manual 4429automatically extended by the system. If you are extending any manual
4430code in the recipe, you can use the ``${MLPREFIX}`` variable to ensure 4430code in the recipe, you can use the ``${MLPREFIX}`` variable to ensure
4431those names are extended correctly. This automatic extension code 4431those names are extended correctly. This automatic extension code
@@ -4462,12 +4462,12 @@ that exist regardless of the package management system:
4462 4462
4463- The typical convention used for the class extension code as used by 4463- The typical convention used for the class extension code as used by
4464 Multilib assumes that all package names specified in 4464 Multilib assumes that all package names specified in
4465 ```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__ that contain 4465 :term:`PACKAGES` that contain
4466 ``${PN}`` have ``${PN}`` at the start of the name. When that 4466 ``${PN}`` have ``${PN}`` at the start of the name. When that
4467 convention is not followed and ``${PN}`` appears at the middle or the 4467 convention is not followed and ``${PN}`` appears at the middle or the
4468 end of a name, problems occur. 4468 end of a name, problems occur.
4469 4469
4470- The ```TARGET_VENDOR`` <&YOCTO_DOCS_REF_URL;#var-TARGET_VENDOR>`__ 4470- The :term:`TARGET_VENDOR`
4471 value under Multilib will be extended to "-vendormlmultilib" (e.g. 4471 value under Multilib will be extended to "-vendormlmultilib" (e.g.
4472 "-pokymllib32" for a "lib32" Multilib with Poky). The reason for this 4472 "-pokymllib32" for a "lib32" Multilib with Poky). The reason for this
4473 slightly unwieldy contraction is that any "-" characters in the 4473 slightly unwieldy contraction is that any "-" characters in the
@@ -4479,7 +4479,7 @@ details exist:
4479 4479
4480- A unique architecture is defined for the Multilib packages, along 4480- A unique architecture is defined for the Multilib packages, along
4481 with creating a unique deploy folder under ``tmp/deploy/rpm`` in the 4481 with creating a unique deploy folder under ``tmp/deploy/rpm`` in the
4482 `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. For 4482 :term:`Build Directory`. For
4483 example, consider ``lib32`` in a ``qemux86-64`` image. The possible 4483 example, consider ``lib32`` in a ``qemux86-64`` image. The possible
4484 architectures in the system are "all", "qemux86_64", 4484 architectures in the system are "all", "qemux86_64",
4485 "lib32_qemux86_64", and "lib32_x86". 4485 "lib32_qemux86_64", and "lib32_x86".
@@ -4525,7 +4525,7 @@ versions of the same library in parallel on the same system.
4525The process is straightforward as long as the libraries use proper 4525The process is straightforward as long as the libraries use proper
4526versioning. With properly versioned libraries, all you need to do to 4526versioning. With properly versioned libraries, all you need to do to
4527individually specify the libraries is create separate, appropriately 4527individually specify the libraries is create separate, appropriately
4528named recipes where the ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__ part of 4528named recipes where the :term:`PN` part of
4529the name includes a portion that differentiates each library version 4529the name includes a portion that differentiates each library version
4530(e.g.the major part of the version number). Thus, instead of having a 4530(e.g.the major part of the version number). Thus, instead of having a
4531single recipe that loads one version of a library (e.g. ``clutter``), 4531single recipe that loads one version of a library (e.g. ``clutter``),
@@ -4534,7 +4534,7 @@ libraries you want. As an example, the following two recipes would allow
4534the two separate versions of the ``clutter`` library to co-exist on the 4534the two separate versions of the ``clutter`` library to co-exist on the
4535same system: clutter-1.6_1.6.20.bb clutter-1.8_1.8.4.bb Additionally, if 4535same system: clutter-1.6_1.6.20.bb clutter-1.8_1.8.4.bb Additionally, if
4536you have other recipes that depend on a given library, you need to use 4536you have other recipes that depend on a given library, you need to use
4537the ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ variable to 4537the :term:`DEPENDS` variable to
4538create the dependency. Continuing with the same example, if you want to 4538create the dependency. Continuing with the same example, if you want to
4539have a recipe depend on the 1.8 version of the ``clutter`` library, use 4539have a recipe depend on the 1.8 version of the ``clutter`` library, use
4540the following in your recipe: DEPENDS = "clutter-1.8" 4540the following in your recipe: DEPENDS = "clutter-1.8"
@@ -4625,15 +4625,15 @@ Enabling the generation of introspection data (GIR files) in your
4625library package involves the following: 4625library package involves the following:
4626 4626
46271. Inherit the 46271. Inherit the
4628 ```gobject-introspection`` <&YOCTO_DOCS_REF_URL;#ref-classes-gobject-introspection>`__ 4628 :ref:`gobject-introspection <ref-classes-gobject-introspection>`
4629 class. 4629 class.
4630 4630
46312. Make sure introspection is not disabled anywhere in the recipe or 46312. Make sure introspection is not disabled anywhere in the recipe or
4632 from anything the recipe includes. Also, make sure that 4632 from anything the recipe includes. Also, make sure that
4633 "gobject-introspection-data" is not in 4633 "gobject-introspection-data" is not in
4634 ```DISTRO_FEATURES_BACKFILL_CONSIDERED`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES_BACKFILL_CONSIDERED>`__ 4634 :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
4635 and that "qemu-usermode" is not in 4635 and that "qemu-usermode" is not in
4636 ```MACHINE_FEATURES_BACKFILL_CONSIDERED`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES_BACKFILL_CONSIDERED>`__. 4636 :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`.
4637 If either of these conditions exist, nothing will happen. 4637 If either of these conditions exist, nothing will happen.
4638 4638
46393. Try to build the recipe. If you encounter build errors that look like 46393. Try to build the recipe. If you encounter build errors that look like
@@ -4699,9 +4699,9 @@ Use the following procedure to test if generating introspection data is
4699working in an image: 4699working in an image:
4700 4700
47011. Make sure that "gobject-introspection-data" is not in 47011. Make sure that "gobject-introspection-data" is not in
4702 ```DISTRO_FEATURES_BACKFILL_CONSIDERED`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES_BACKFILL_CONSIDERED>`__ 4702 :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
4703 and that "qemu-usermode" is not in 4703 and that "qemu-usermode" is not in
4704 ```MACHINE_FEATURES_BACKFILL_CONSIDERED`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES_BACKFILL_CONSIDERED>`__. 4704 :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`.
4705 4705
47062. Build ``core-image-sato``. 47062. Build ``core-image-sato``.
4707 4707
@@ -4750,7 +4750,7 @@ follows:
4750 4750
4751- Make sure you add the layer that contains the toolchain to your 4751- Make sure you add the layer that contains the toolchain to your
4752 ``bblayers.conf`` file through the 4752 ``bblayers.conf`` file through the
4753 ```BBLAYERS`` <&YOCTO_DOCS_REF_URL;#var-BBLAYERS>`__ variable. 4753 :term:`BBLAYERS` variable.
4754 4754
4755- Set the ``EXTERNAL_TOOLCHAIN`` variable in your ``local.conf`` file 4755- Set the ``EXTERNAL_TOOLCHAIN`` variable in your ``local.conf`` file
4756 to the location in which you installed the toolchain. 4756 to the location in which you installed the toolchain.
@@ -4760,7 +4760,7 @@ Mentor Graphics Sourcery G++ Toolchain. You can see information on how
4760to use that particular layer in the ``README`` file at 4760to use that particular layer in the ``README`` file at
4761` <http://github.com/MentorEmbedded/meta-sourcery/>`__. You can find 4761` <http://github.com/MentorEmbedded/meta-sourcery/>`__. You can find
4762further information by reading about the 4762further information by reading about the
4763```TCMODE`` <&YOCTO_DOCS_REF_URL;#var-TCMODE>`__ variable in the Yocto 4763:term:`TCMODE` variable in the Yocto
4764Project Reference Manual's variable glossary. 4764Project Reference Manual's variable glossary.
4765 4765
4766Creating Partitioned Images Using Wic 4766Creating Partitioned Images Using Wic
@@ -4827,7 +4827,7 @@ this information is required to use Wic, you might find it interesting.
4827- Wic is a completely independent standalone utility that initially 4827- Wic is a completely independent standalone utility that initially
4828 provides easier-to-use and more flexible replacements for an existing 4828 provides easier-to-use and more flexible replacements for an existing
4829 functionality in OE-Core's 4829 functionality in OE-Core's
4830 ```image-live`` <&YOCTO_DOCS_REF_URL;#ref-classes-image-live>`__ 4830 :ref:`image-live <ref-classes-image-live>`
4831 class. The difference between Wic and those examples is that with Wic 4831 class. The difference between Wic and those examples is that with Wic
4832 the functionality of those scripts is implemented by a 4832 the functionality of those scripts is implemented by a
4833 general-purpose partitioning language, which is based on Redhat 4833 general-purpose partitioning language, which is based on Redhat
@@ -4852,7 +4852,7 @@ system needs to meet the following requirements:
4852 4852
4853- You must have sourced the build environment setup script (i.e. 4853- You must have sourced the build environment setup script (i.e.
4854 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__) found in the 4854 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__) found in the
4855 `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 4855 :term:`Build Directory`.
4856 4856
4857- You need to have the build artifacts already available, which 4857- You need to have the build artifacts already available, which
4858 typically means that you must have already created an image using the 4858 typically means that you must have already created an image using the
@@ -4865,12 +4865,12 @@ system needs to meet the following requirements:
4865 build system: $ bitbake parted-native dosfstools-native mtools-native 4865 build system: $ bitbake parted-native dosfstools-native mtools-native
4866 4866
4867- Include "wic" as part of the 4867- Include "wic" as part of the
4868 ```IMAGE_FSTYPES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES>`__ 4868 :term:`IMAGE_FSTYPES`
4869 variable. 4869 variable.
4870 4870
4871- Include the name of the `wic kickstart 4871- Include the name of the `wic kickstart
4872 file <&YOCTO_DOCS_REF_URL;#openembedded-kickstart-wks-reference>`__ 4872 file <&YOCTO_DOCS_REF_URL;#openembedded-kickstart-wks-reference>`__
4873 as part of the ```WKS_FILE`` <&YOCTO_DOCS_REF_URL;#var-WKS_FILE>`__ 4873 as part of the :term:`WKS_FILE`
4874 variable 4874 variable
4875 4875
4876.. _wic-getting-help: 4876.. _wic-getting-help:
@@ -4923,7 +4923,7 @@ for creating the image: Raw and Cooked:
4923 command-line arguments. 4923 command-line arguments.
4924 4924
4925- *Cooked Mode:* The current 4925- *Cooked Mode:* The current
4926 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ setting and image 4926 :term:`MACHINE` setting and image
4927 name are used to automatically locate and provide the build 4927 name are used to automatically locate and provide the build
4928 artifacts. You just supply a kickstart file and the name of the image 4928 artifacts. You just supply a kickstart file and the name of the image
4929 from which to use artifacts. 4929 from which to use artifacts.
@@ -5172,7 +5172,7 @@ INFO: The image(s) were created using OE kickstart file:
5172The previous example shows the easiest way to create an image by running 5172The previous example shows the easiest way to create an image by running
5173in cooked mode and supplying a kickstart file and the "-e" option to 5173in cooked mode and supplying a kickstart file and the "-e" option to
5174point to the existing build artifacts. Your ``local.conf`` file needs to 5174point to the existing build artifacts. Your ``local.conf`` file needs to
5175have the ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable set 5175have the :term:`MACHINE` variable set
5176to the machine you are using, which is "qemux86" in this example. 5176to the machine you are using, which is "qemux86" in this example.
5177 5177
5178Once the image builds, the output provides image location, artifact use, 5178Once the image builds, the output provides image location, artifact use,
@@ -5234,7 +5234,7 @@ untouched: part /boot --source bootimg-pcbios --ondisk sdb --label boot
5234--label platform --align 1024 --use-uuid Once the lines are changed, the 5234--label platform --align 1024 --use-uuid Once the lines are changed, the
5235example generates the ``directdisksdb-gpt`` image. The command points 5235example generates the ``directdisksdb-gpt`` image. The command points
5236the process at the ``core-image-minimal`` artifacts for the Next Unit of 5236the process at the ``core-image-minimal`` artifacts for the Next Unit of
5237Computing (nuc) ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ the 5237Computing (nuc) :term:`MACHINE` the
5238``local.conf``. $ wic create directdisksdb-gpt -e core-image-minimal 5238``local.conf``. $ wic create directdisksdb-gpt -e core-image-minimal
5239INFO: Building wic-tools... . . . Initialising tasks: 100% 5239INFO: Building wic-tools... . . . Initialising tasks: 100%
5240\|#######################################\| Time: 0:00:01 NOTE: 5240\|#######################################\| Time: 0:00:01 NOTE:
@@ -5287,7 +5287,7 @@ NATIVE_SYSROOT:
5287/home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native 5287/home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
5288INFO: The image(s) were created using OE kickstart file: 5288INFO: The image(s) were created using OE kickstart file:
5289/home/stephano/my_yocto/test.wks For this example, 5289/home/stephano/my_yocto/test.wks For this example,
5290```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ did not have to be 5290:term:`MACHINE` did not have to be
5291specified in the ``local.conf`` file since the artifact is manually 5291specified in the ``local.conf`` file since the artifact is manually
5292specified. 5292specified.
5293 5293
@@ -5419,7 +5419,7 @@ any type of image. Use these steps to flash an image using Bmaptool:
5419 += "wic wic.bmap" 5419 += "wic wic.bmap"
5420 5420
54212. *Get Your Image:* Either have your image ready (pre-built with the 54212. *Get Your Image:* Either have your image ready (pre-built with the
5422 ```IMAGE_FSTYPES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES>`__ 5422 :term:`IMAGE_FSTYPES`
5423 setting previously mentioned) or take the step to build the image: $ 5423 setting previously mentioned) or take the step to build the image: $
5424 bitbake image 5424 bitbake image
5425 5425
@@ -5540,10 +5540,10 @@ You can take some steps that are specific to the OpenEmbedded build
5540system to make your images more secure: 5540system to make your images more secure:
5541 5541
5542- Ensure "debug-tweaks" is not one of your selected 5542- Ensure "debug-tweaks" is not one of your selected
5543 ```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__. 5543 :term:`IMAGE_FEATURES`.
5544 When creating a new project, the default is to provide you with an 5544 When creating a new project, the default is to provide you with an
5545 initial ``local.conf`` file that enables this feature using the 5545 initial ``local.conf`` file that enables this feature using the
5546 ```EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES>`__ 5546 :term:`EXTRA_IMAGE_FEATURES`
5547 variable with the line: EXTRA_IMAGE_FEATURES = "debug-tweaks" To 5547 variable with the line: EXTRA_IMAGE_FEATURES = "debug-tweaks" To
5548 disable that feature, simply comment out that line in your 5548 disable that feature, simply comment out that line in your
5549 ``local.conf`` file, or make sure ``IMAGE_FEATURES`` does not contain 5549 ``local.conf`` file, or make sure ``IMAGE_FEATURES`` does not contain
@@ -5558,7 +5558,7 @@ system to make your images more secure:
5558 users, you should not duplicate passwords. 5558 users, you should not duplicate passwords.
5559 5559
5560 To set up passwords, use the 5560 To set up passwords, use the
5561 ```extrausers`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__ 5561 :ref:`extrausers <ref-classes-extrausers>`
5562 class, which is the preferred method. For an example on how to set up 5562 class, which is the preferred method. For an example on how to set up
5563 both root and user passwords, see the 5563 both root and user passwords, see the
5564 "```extrausers.bbclass`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__" 5564 "```extrausers.bbclass`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__"
@@ -5591,7 +5591,7 @@ Creating Your Own Distribution
5591============================== 5591==============================
5592 5592
5593When you build an image using the Yocto Project and do not alter any 5593When you build an image using the Yocto Project and do not alter any
5594distribution `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__, you are 5594distribution :term:`Metadata`, you are
5595creating a Poky distribution. If you wish to gain more control over 5595creating a Poky distribution. If you wish to gain more control over
5596package alternative selections, compile-time options, and other 5596package alternative selections, compile-time options, and other
5597low-level configurations, you can create your own distribution. 5597low-level configurations, you can create your own distribution.
@@ -5633,14 +5633,14 @@ layer. The following steps provide some more detail:
5633 desired version and revisions for individual recipes. 5633 desired version and revisions for individual recipes.
5634 5634
5635 Your configuration file needs to set the following required 5635 Your configuration file needs to set the following required
5636 variables: ```DISTRO_NAME`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME>`__ 5636 variables: :term:`DISTRO_NAME`
5637 ```DISTRO_VERSION`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_VERSION>`__ 5637 :term:`DISTRO_VERSION`
5638 These following variables are optional and you typically set them 5638 These following variables are optional and you typically set them
5639 from the distribution configuration file: 5639 from the distribution configuration file:
5640 ```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__ 5640 :term:`DISTRO_FEATURES`
5641 ```DISTRO_EXTRA_RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_EXTRA_RDEPENDS>`__ 5641 :term:`DISTRO_EXTRA_RDEPENDS`
5642 ```DISTRO_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_EXTRA_RRECOMMENDS>`__ 5642 :term:`DISTRO_EXTRA_RRECOMMENDS`
5643 ```TCLIBC`` <&YOCTO_DOCS_REF_URL;#var-TCLIBC>`__ 5643 :term:`TCLIBC`
5644 5644
5645 .. tip:: 5645 .. tip::
5646 5646
@@ -5665,7 +5665,7 @@ layer. The following steps provide some more detail:
5665- *Point to Your distribution configuration file:* In your 5665- *Point to Your distribution configuration file:* In your
5666 ``local.conf`` file in the `Build 5666 ``local.conf`` file in the `Build
5667 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, set your 5667 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, set your
5668 ```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__ variable to point to 5668 :term:`DISTRO` variable to point to
5669 your distribution's configuration file. For example, if your 5669 your distribution's configuration file. For example, if your
5670 distribution's configuration file is named ``mydistro.conf``, then 5670 distribution's configuration file is named ``mydistro.conf``, then
5671 you point to it as follows: DISTRO = "mydistro" 5671 you point to it as follows: DISTRO = "mydistro"
@@ -5719,7 +5719,7 @@ To override these default configuration files with configurations you
5719want used within every new Build Directory, simply set the 5719want used within every new Build Directory, simply set the
5720``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF`` 5720``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF``
5721variable is set in the ``.templateconf`` file, which is in the top-level 5721variable is set in the ``.templateconf`` file, which is in the top-level
5722`Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ folder 5722:term:`Source Directory` folder
5723(e.g. ``poky``). Edit the ``.templateconf`` so that it can locate your 5723(e.g. ``poky``). Edit the ``.templateconf`` so that it can locate your
5724directory. 5724directory.
5725 5725
@@ -5758,7 +5758,7 @@ Conserving Disk Space During Builds
5758 5758
5759To help conserve disk space during builds, you can add the following 5759To help conserve disk space during builds, you can add the following
5760statement to your project's ``local.conf`` configuration file found in 5760statement to your project's ``local.conf`` configuration file found in
5761the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT 5761the :term:`Build Directory`: INHERIT
5762+= "rm_work" Adding this statement deletes the work directory used for 5762+= "rm_work" Adding this statement deletes the work directory used for
5763building a recipe once the recipe is built. For more information on 5763building a recipe once the recipe is built. For more information on
5764"rm_work", see the 5764"rm_work", see the
@@ -5810,15 +5810,15 @@ or attach them to a specific image recipe by using a recipe name
5810override. For more detail on the variables, see the descriptions in the 5810override. For more detail on the variables, see the descriptions in the
5811Yocto Project Reference Manual's glossary chapter. 5811Yocto Project Reference Manual's glossary chapter.
5812 5812
5813- ```BAD_RECOMMENDATIONS`` <&YOCTO_DOCS_REF_URL;#var-BAD_RECOMMENDATIONS>`__: 5813- :term:`BAD_RECOMMENDATIONS`:
5814 Use this variable to specify "recommended-only" packages that you do 5814 Use this variable to specify "recommended-only" packages that you do
5815 not want installed. 5815 not want installed.
5816 5816
5817- ```NO_RECOMMENDATIONS`` <&YOCTO_DOCS_REF_URL;#var-NO_RECOMMENDATIONS>`__: 5817- :term:`NO_RECOMMENDATIONS`:
5818 Use this variable to prevent all "recommended-only" packages from 5818 Use this variable to prevent all "recommended-only" packages from
5819 being installed. 5819 being installed.
5820 5820
5821- ```PACKAGE_EXCLUDE`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_EXCLUDE>`__: 5821- :term:`PACKAGE_EXCLUDE`:
5822 Use this variable to prevent specific packages from being installed 5822 Use this variable to prevent specific packages from being installed
5823 regardless of whether they are "recommended-only" or not. You need to 5823 regardless of whether they are "recommended-only" or not. You need to
5824 realize that the build process could fail with an error when you 5824 realize that the build process could fail with an error when you
@@ -5852,8 +5852,8 @@ the following:
5852 . 5852 .
5853 5853
5854 The version and revision are taken from the 5854 The version and revision are taken from the
5855 ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ and 5855 :term:`PV` and
5856 ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__ variables, respectively. 5856 :term:`PR` variables, respectively.
5857 5857
5858- ``PV``: The recipe version. ``PV`` represents the version of the 5858- ``PV``: The recipe version. ``PV`` represents the version of the
5859 software being packaged. Do not confuse ``PV`` with the binary 5859 software being packaged. Do not confuse ``PV`` with the binary
@@ -5861,7 +5861,7 @@ the following:
5861 5861
5862- ``PR``: The recipe revision. 5862- ``PR``: The recipe revision.
5863 5863
5864- ```SRCPV`` <&YOCTO_DOCS_REF_URL;#var-SRCPV>`__: The OpenEmbedded 5864- :term:`SRCPV`: The OpenEmbedded
5865 build system uses this string to help define the value of ``PV`` when 5865 build system uses this string to help define the value of ``PV`` when
5866 the source code revision needs to be included in it. 5866 the source code revision needs to be included in it.
5867 5867
@@ -5899,7 +5899,7 @@ Working With a PR Service
5899~~~~~~~~~~~~~~~~~~~~~~~~~ 5899~~~~~~~~~~~~~~~~~~~~~~~~~
5900 5900
5901As mentioned, attempting to maintain revision numbers in the 5901As mentioned, attempting to maintain revision numbers in the
5902`Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ is error prone, inaccurate, 5902:term:`Metadata` is error prone, inaccurate,
5903and causes problems for people submitting recipes. Conversely, the PR 5903and causes problems for people submitting recipes. Conversely, the PR
5904Service automatically generates increasing numbers, particularly the 5904Service automatically generates increasing numbers, particularly the
5905revision field, which removes the human element. 5905revision field, which removes the human element.
@@ -5912,9 +5912,9 @@ revision field, which removes the human element.
5912 5912
5913The Yocto Project uses variables in order of decreasing priority to 5913The Yocto Project uses variables in order of decreasing priority to
5914facilitate revision numbering (i.e. 5914facilitate revision numbering (i.e.
5915```PE`` <&YOCTO_DOCS_REF_URL;#var-PE>`__, 5915:term:`PE`,
5916```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__, and 5916:term:`PV`, and
5917```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__ for epoch, version, and 5917:term:`PR` for epoch, version, and
5918revision, respectively). The values are highly dependent on the policies 5918revision, respectively). The values are highly dependent on the policies
5919and procedures of a given distribution and package feed. 5919and procedures of a given distribution and package feed.
5920 5920
@@ -5946,7 +5946,7 @@ be consistent and correct with the latest changes.
5946The simplest form for a PR Service is for it to exist for a single host 5946The simplest form for a PR Service is for it to exist for a single host
5947development system that builds the package feed (building system). For 5947development system that builds the package feed (building system). For
5948this scenario, you can enable a local PR Service by setting 5948this scenario, you can enable a local PR Service by setting
5949```PRSERV_HOST`` <&YOCTO_DOCS_REF_URL;#var-PRSERV_HOST>`__ in your 5949:term:`PRSERV_HOST` in your
5950``local.conf`` file in the `Build 5950``local.conf`` file in the `Build
5951Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: PRSERV_HOST = 5951Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: PRSERV_HOST =
5952"localhost:0" Once the service is started, packages will automatically 5952"localhost:0" Once the service is started, packages will automatically
@@ -5988,7 +5988,7 @@ Manually Bumping PR
5988~~~~~~~~~~~~~~~~~~~ 5988~~~~~~~~~~~~~~~~~~~
5989 5989
5990The alternative to setting up a PR Service is to manually "bump" the 5990The alternative to setting up a PR Service is to manually "bump" the
5991```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__ variable. 5991:term:`PR` variable.
5992 5992
5993If a committed change results in changing the package output, then the 5993If a committed change results in changing the package output, then the
5994value of the PR variable needs to be increased (or "bumped") as part of 5994value of the PR variable needs to be increased (or "bumped") as part of
@@ -6027,10 +6027,10 @@ Automatically Incrementing a Package Version Number
6027~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6027~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6028 6028
6029When fetching a repository, BitBake uses the 6029When fetching a repository, BitBake uses the
6030```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__ variable to determine 6030:term:`SRCREV` variable to determine
6031the specific source code revision from which to build. You set the 6031the specific source code revision from which to build. You set the
6032``SRCREV`` variable to 6032``SRCREV`` variable to
6033```AUTOREV`` <&YOCTO_DOCS_REF_URL;#var-AUTOREV>`__ to cause the 6033:term:`AUTOREV` to cause the
6034OpenEmbedded build system to automatically use the latest revision of 6034OpenEmbedded build system to automatically use the latest revision of
6035the software: SRCREV = "${AUTOREV}" 6035the software: SRCREV = "${AUTOREV}"
6036 6036
@@ -6043,7 +6043,7 @@ with a number. The number used depends on the state of the PR Service:
6043 6043
6044- If PR Service is enabled, the build system increments the number, 6044- If PR Service is enabled, the build system increments the number,
6045 which is similar to the behavior of 6045 which is similar to the behavior of
6046 ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__. This behavior results in 6046 :term:`PR`. This behavior results in
6047 linearly increasing package versions, which is desirable. Here is an 6047 linearly increasing package versions, which is desirable. Here is an
6048 example: hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk 6048 example: hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
6049 hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk 6049 hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk
@@ -6087,7 +6087,7 @@ To ensure the module packaging actually gets done, you use the
6087function in your recipe. The ``do_split_packages`` function searches for 6087function in your recipe. The ``do_split_packages`` function searches for
6088a pattern of files or directories under a specified path and creates a 6088a pattern of files or directories under a specified path and creates a
6089package for each one it finds by appending to the 6089package for each one it finds by appending to the
6090```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__ variable and 6090:term:`PACKAGES` variable and
6091setting the appropriate values for ``FILES_packagename``, 6091setting the appropriate values for ``FILES_packagename``,
6092``RDEPENDS_packagename``, ``DESCRIPTION_packagename``, and so forth. 6092``RDEPENDS_packagename``, ``DESCRIPTION_packagename``, and so forth.
6093Here is an example from the ``lighttpd`` recipe: python 6093Here is an example from the ``lighttpd`` recipe: python
@@ -6112,7 +6112,7 @@ previous example specifies a number of things in the call to
6112 dependency on the main ``lighttpd`` package. Thus, if a file in 6112 dependency on the main ``lighttpd`` package. Thus, if a file in
6113 ``${libdir}`` called ``mod_alias.so`` is found, a package called 6113 ``${libdir}`` called ``mod_alias.so`` is found, a package called
6114 ``lighttpd-module-alias`` is created for it and the 6114 ``lighttpd-module-alias`` is created for it and the
6115 ```DESCRIPTION`` <&YOCTO_DOCS_REF_URL;#var-DESCRIPTION>`__ is set to 6115 :term:`DESCRIPTION` is set to
6116 "Lighttpd module for alias". 6116 "Lighttpd module for alias".
6117 6117
6118Often, packaging modules is as simple as the previous example. However, 6118Often, packaging modules is as simple as the previous example. However,
@@ -6165,13 +6165,13 @@ Satisfying Dependencies
6165The second part for handling optional module packaging is to ensure that 6165The second part for handling optional module packaging is to ensure that
6166any dependencies on optional modules from other recipes are satisfied by 6166any dependencies on optional modules from other recipes are satisfied by
6167your recipe. You can be sure these dependencies are satisfied by using 6167your recipe. You can be sure these dependencies are satisfied by using
6168the ```PACKAGES_DYNAMIC`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES_DYNAMIC>`__ 6168the :term:`PACKAGES_DYNAMIC`
6169variable. Here is an example that continues with the ``lighttpd`` recipe 6169variable. Here is an example that continues with the ``lighttpd`` recipe
6170shown earlier: PACKAGES_DYNAMIC = "lighttpd-module-.*" The name 6170shown earlier: PACKAGES_DYNAMIC = "lighttpd-module-.*" The name
6171specified in the regular expression can of course be anything. In this 6171specified in the regular expression can of course be anything. In this
6172example, it is ``lighttpd-module-`` and is specified as the prefix to 6172example, it is ``lighttpd-module-`` and is specified as the prefix to
6173ensure that any ```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__ and 6173ensure that any :term:`RDEPENDS` and
6174```RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS>`__ on a package 6174:term:`RRECOMMENDS` on a package
6175name starting with the prefix are satisfied during build time. If you 6175name starting with the prefix are satisfied during build time. If you
6176are using ``do_split_packages`` as described in the previous section, 6176are using ``do_split_packages`` as described in the previous section,
6177the value you put in ``PACKAGES_DYNAMIC`` should correspond to the name 6177the value you put in ``PACKAGES_DYNAMIC`` should correspond to the name
@@ -6250,7 +6250,7 @@ aware in order to provide support for runtime package management.
6250 6250
6251When BitBake generates packages, it needs to know what format or formats 6251When BitBake generates packages, it needs to know what format or formats
6252to use. In your configuration, you use the 6252to use. In your configuration, you use the
6253```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__ 6253:term:`PACKAGE_CLASSES`
6254variable to specify the format: 6254variable to specify the format:
6255 6255
62561. Open the ``local.conf`` file inside your `Build 62561. Open the ``local.conf`` file inside your `Build
@@ -6272,7 +6272,7 @@ If you would like your image to start off with a basic package database
6272containing the packages in your current build as well as to have the 6272containing the packages in your current build as well as to have the
6273relevant tools available on the target for runtime package management, 6273relevant tools available on the target for runtime package management,
6274you can include "package-management" in the 6274you can include "package-management" in the
6275```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__ 6275:term:`IMAGE_FEATURES`
6276variable. Including "package-management" in this configuration variable 6276variable. Including "package-management" in this configuration variable
6277ensures that when the image is assembled for your target, the image 6277ensures that when the image is assembled for your target, the image
6278includes the currently-known package databases as well as the 6278includes the currently-known package databases as well as the
@@ -6281,7 +6281,7 @@ performed on the target. However, this is not strictly necessary. You
6281could start your image off without any databases but only include the 6281could start your image off without any databases but only include the
6282required on-target package tool(s). As an example, you could include 6282required on-target package tool(s). As an example, you could include
6283"opkg" in your 6283"opkg" in your
6284```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__ variable 6284:term:`IMAGE_INSTALL` variable
6285if you are using the IPK package format. You can then initialize your 6285if you are using the IPK package format. You can then initialize your
6286target's package database(s) later once your image is up and running. 6286target's package database(s) later once your image is up and running.
6287 6287
@@ -6298,10 +6298,10 @@ Thus, be sure to run the package update step separately after building
6298any packages. 6298any packages.
6299 6299
6300You can use the 6300You can use the
6301```PACKAGE_FEED_ARCHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_ARCHS>`__, 6301:term:`PACKAGE_FEED_ARCHS`,
6302```PACKAGE_FEED_BASE_PATHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_BASE_PATHS>`__, 6302:term:`PACKAGE_FEED_BASE_PATHS`,
6303and 6303and
6304```PACKAGE_FEED_URIS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_URIS>`__ 6304:term:`PACKAGE_FEED_URIS`
6305variables to pre-configure target images to use a package feed. If you 6305variables to pre-configure target images to use a package feed. If you
6306do not define these variables, then manual steps as described in the 6306do not define these variables, then manual steps as described in the
6307subsequent sections are necessary to configure the target. You should 6307subsequent sections are necessary to configure the target. You should
@@ -6310,7 +6310,7 @@ correctly configured image.
6310 6310
6311When your build is complete, your packages reside in the 6311When your build is complete, your packages reside in the
6312``${TMPDIR}/deploy/packageformat`` directory. For example, if 6312``${TMPDIR}/deploy/packageformat`` directory. For example, if
6313``${``\ ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__\ ``}`` is 6313``${``\ :term:`TMPDIR`\ ``}`` is
6314``tmp`` and your selected package type is RPM, then your RPM packages 6314``tmp`` and your selected package type is RPM, then your RPM packages
6315are available in ``tmp/deploy/rpm``. 6315are available in ``tmp/deploy/rpm``.
6316 6316
@@ -6333,7 +6333,7 @@ Lighttpd, or Nginx), take the appropriate steps to do so.
6333 6333
6334From within the build directory where you have built an image based on 6334From within the build directory where you have built an image based on
6335your packaging choice (i.e. the 6335your packaging choice (i.e. the
6336```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__ 6336:term:`PACKAGE_CLASSES`
6337setting), simply start the server. The following example assumes a build 6337setting), simply start the server. The following example assumes a build
6338directory of ``~/poky/build/tmp/deploy/rpm`` and a ``PACKAGE_CLASSES`` 6338directory of ``~/poky/build/tmp/deploy/rpm`` and a ``PACKAGE_CLASSES``
6339setting of "package_rpm": $ cd ~/poky/build/tmp/deploy/rpm $ python -m 6339setting of "package_rpm": $ cd ~/poky/build/tmp/deploy/rpm $ python -m
@@ -6431,10 +6431,10 @@ Using IPK
6431The ``opkg`` application performs runtime package management of IPK 6431The ``opkg`` application performs runtime package management of IPK
6432packages. You must perform an initial setup for ``opkg`` on the target 6432packages. You must perform an initial setup for ``opkg`` on the target
6433machine if the 6433machine if the
6434```PACKAGE_FEED_ARCHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_ARCHS>`__, 6434:term:`PACKAGE_FEED_ARCHS`,
6435```PACKAGE_FEED_BASE_PATHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_BASE_PATHS>`__, 6435:term:`PACKAGE_FEED_BASE_PATHS`,
6436and 6436and
6437```PACKAGE_FEED_URIS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_URIS>`__ 6437:term:`PACKAGE_FEED_URIS`
6438variables have not been set or the target image was built before the 6438variables have not been set or the target image was built before the
6439variables were set. 6439variables were set.
6440 6440
@@ -6463,10 +6463,10 @@ The ``apt`` application performs runtime package management of DEB
6463packages. This application uses a source list file to find available 6463packages. This application uses a source list file to find available
6464package databases. You must perform an initial setup for ``apt`` on the 6464package databases. You must perform an initial setup for ``apt`` on the
6465target machine if the 6465target machine if the
6466```PACKAGE_FEED_ARCHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_ARCHS>`__, 6466:term:`PACKAGE_FEED_ARCHS`,
6467```PACKAGE_FEED_BASE_PATHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_BASE_PATHS>`__, 6467:term:`PACKAGE_FEED_BASE_PATHS`,
6468and 6468and
6469```PACKAGE_FEED_URIS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_FEED_URIS>`__ 6469:term:`PACKAGE_FEED_URIS`
6470variables have not been set or the target image was built before the 6470variables have not been set or the target image was built before the
6471variables were set. 6471variables were set.
6472 6472
@@ -6580,8 +6580,8 @@ Adding ptest to Your Build
6580~~~~~~~~~~~~~~~~~~~~~~~~~~ 6580~~~~~~~~~~~~~~~~~~~~~~~~~~
6581 6581
6582To add package testing to your build, add the 6582To add package testing to your build, add the
6583```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__ and 6583:term:`DISTRO_FEATURES` and
6584```EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES>`__ 6584:term:`EXTRA_IMAGE_FEATURES`
6585variables to your ``local.conf`` file, which is found in the `Build 6585variables to your ``local.conf`` file, which is found in the `Build
6586Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: 6586Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__:
6587DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs" 6587DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs"
@@ -6604,20 +6604,20 @@ you need to prepare the recipes that build the packages you want to
6604test. Here is what you have to do for each recipe: 6604test. Here is what you have to do for each recipe:
6605 6605
6606- *Be sure the recipe inherits 6606- *Be sure the recipe inherits
6607 the*\ ```ptest`` <&YOCTO_DOCS_REF_URL;#ref-classes-ptest>`__\ *class:* 6607 the*\ :ref:`ptest <ref-classes-ptest>`\ *class:*
6608 Include the following line in each recipe: inherit ptest 6608 Include the following line in each recipe: inherit ptest
6609 6609
6610- *Create ``run-ptest``:* This script starts your test. Locate the 6610- *Create ``run-ptest``:* This script starts your test. Locate the
6611 script where you will refer to it using 6611 script where you will refer to it using
6612 ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__. Here is an 6612 :term:`SRC_URI`. Here is an
6613 example that starts a test for ``dbus``: #!/bin/sh cd test make -k 6613 example that starts a test for ``dbus``: #!/bin/sh cd test make -k
6614 runtest-TESTS 6614 runtest-TESTS
6615 6615
6616- *Ensure dependencies are met:* If the test adds build or runtime 6616- *Ensure dependencies are met:* If the test adds build or runtime
6617 dependencies that normally do not exist for the package (such as 6617 dependencies that normally do not exist for the package (such as
6618 requiring "make" to run the test suite), use the 6618 requiring "make" to run the test suite), use the
6619 ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ and 6619 :term:`DEPENDS` and
6620 ```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__ variables in 6620 :term:`RDEPENDS` variables in
6621 your recipe in order for the package to meet the dependencies. Here 6621 your recipe in order for the package to meet the dependencies. Here
6622 is an example where the package has a runtime dependency on "make": 6622 is an example where the package has a runtime dependency on "make":
6623 RDEPENDS_${PN}-ptest += "make" 6623 RDEPENDS_${PN}-ptest += "make"
@@ -6732,9 +6732,9 @@ possible. The result is a generated recipe.
6732 6732
6733The recipe file is fairly simple and contains every license that 6733The recipe file is fairly simple and contains every license that
6734``recipetool`` finds and includes the licenses in the recipe's 6734``recipetool`` finds and includes the licenses in the recipe's
6735```LIC_FILES_CHKSUM`` <&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM>`__ 6735:term:`LIC_FILES_CHKSUM`
6736variables. You need to examine the variables and look for those with 6736variables. You need to examine the variables and look for those with
6737"unknown" in the ```LICENSE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ 6737"unknown" in the :term:`LICENSE`
6738field. You need to track down the license information for "unknown" 6738field. You need to track down the license information for "unknown"
6739modules and manually add the information to the recipe. 6739modules and manually add the information to the recipe.
6740 6740
@@ -6764,7 +6764,7 @@ inherit npm LICENSE_${PN} = "MIT" LICENSE_${PN}-accepts = "MIT"
6764LICENSE_${PN}-array-flatten = "MIT" ... LICENSE_${PN}-vary = "MIT" Three 6764LICENSE_${PN}-array-flatten = "MIT" ... LICENSE_${PN}-vary = "MIT" Three
6765key points exist in the previous example: 6765key points exist in the previous example:
6766 6766
6767- ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ uses the NPM 6767- :term:`SRC_URI` uses the NPM
6768 scheme so that the NPM fetcher is used. 6768 scheme so that the NPM fetcher is used.
6769 6769
6770- ``recipetool`` collects all the license information. If a 6770- ``recipetool`` collects all the license information. If a
@@ -6772,7 +6772,7 @@ key points exist in the previous example:
6772 the comments. 6772 the comments.
6773 6773
6774- The ``inherit npm`` statement causes the 6774- The ``inherit npm`` statement causes the
6775 ```npm`` <&YOCTO_DOCS_REF_URL;#ref-classes-npm>`__ class to package 6775 :ref:`npm <ref-classes-npm>` class to package
6776 up all the modules. 6776 up all the modules.
6777 6777
6778You can run the following command to build the ``cute-files`` package: $ 6778You can run the following command to build the ``cute-files`` package: $
@@ -6828,7 +6828,7 @@ Adding custom metadata to packages
6828---------------------------------- 6828----------------------------------
6829 6829
6830The variable 6830The variable
6831```PACKAGE_ADD_METADATA`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ADD_METADATA>`__ 6831:term:`PACKAGE_ADD_METADATA`
6832can be used to add additional metadata to packages. This is reflected in 6832can be used to add additional metadata to packages. This is reflected in
6833the package control/spec file. To take the ipk format for example, the 6833the package control/spec file. To take the ipk format for example, the
6834CONTROL file stored inside would contain the additional metadata as 6834CONTROL file stored inside would contain the additional metadata as
@@ -6869,7 +6869,7 @@ Efficiently Fetching Source Files During a Build
6869================================================ 6869================================================
6870 6870
6871The OpenEmbedded build system works with source files located through 6871The OpenEmbedded build system works with source files located through
6872the ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ variable. When 6872the :term:`SRC_URI` variable. When
6873you build something using BitBake, a big part of the operation is 6873you build something using BitBake, a big part of the operation is
6874locating and downloading all the source tarballs. For images, 6874locating and downloading all the source tarballs. For images,
6875downloading all the source for various packages can take a significant 6875downloading all the source for various packages can take a significant
@@ -6896,15 +6896,15 @@ SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/" INHERIT +=
6896"own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" # BB_NO_NETWORK = "1" 6896"own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" # BB_NO_NETWORK = "1"
6897 6897
6898In the previous example, the 6898In the previous example, the
6899```BB_GENERATE_MIRROR_TARBALLS`` <&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS>`__ 6899:term:`BB_GENERATE_MIRROR_TARBALLS`
6900variable causes the OpenEmbedded build system to generate tarballs of 6900variable causes the OpenEmbedded build system to generate tarballs of
6901the Git repositories and store them in the 6901the Git repositories and store them in the
6902```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__ directory. Due to 6902:term:`DL_DIR` directory. Due to
6903performance reasons, generating and storing these tarballs is not the 6903performance reasons, generating and storing these tarballs is not the
6904build system's default behavior. 6904build system's default behavior.
6905 6905
6906You can also use the 6906You can also use the
6907```PREMIRRORS`` <&YOCTO_DOCS_REF_URL;#var-PREMIRRORS>`__ variable. For 6907:term:`PREMIRRORS` variable. For
6908an example, see the variable's glossary entry in the Yocto Project 6908an example, see the variable's glossary entry in the Yocto Project
6909Reference Manual. 6909Reference Manual.
6910 6910
@@ -6917,7 +6917,7 @@ actually starting a build. This technique lets you work through any
6917download issues and ultimately gathers all the source files into your 6917download issues and ultimately gathers all the source files into your
6918download directory 6918download directory
6919```build/downloads`` <&YOCTO_DOCS_REF_URL;#structure-build-downloads>`__, 6919```build/downloads`` <&YOCTO_DOCS_REF_URL;#structure-build-downloads>`__,
6920which is located with ```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__. 6920which is located with :term:`DL_DIR`.
6921 6921
6922Use the following BitBake command form to fetch all the necessary 6922Use the following BitBake command form to fetch all the necessary
6923sources without starting the build: $ bitbake target --runall=fetch This 6923sources without starting the build: $ bitbake target --runall=fetch This
@@ -6974,7 +6974,7 @@ To remove initscripts from your image altogether, set this variable
6974also: VIRTUAL-RUNTIME_initscripts = "" 6974also: VIRTUAL-RUNTIME_initscripts = ""
6975 6975
6976For information on the backfill variable, see 6976For information on the backfill variable, see
6977```DISTRO_FEATURES_BACKFILL_CONSIDERED`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES_BACKFILL_CONSIDERED>`__. 6977:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
6978 6978
6979Using systemd for the Main Image and Using SysVinit for the Rescue Image 6979Using systemd for the Main Image and Using SysVinit for the Rescue Image
6980------------------------------------------------------------------------ 6980------------------------------------------------------------------------
@@ -7011,12 +7011,12 @@ Using Persistent and Pre-Populated\ ``/dev``
7011-------------------------------------------- 7011--------------------------------------------
7012 7012
7013To use the static method for device population, you need to set the 7013To use the static method for device population, you need to set the
7014```USE_DEVFS`` <&YOCTO_DOCS_REF_URL;#var-USE_DEVFS>`__ variable to "0" 7014:term:`USE_DEVFS` variable to "0"
7015as follows: USE_DEVFS = "0" 7015as follows: USE_DEVFS = "0"
7016 7016
7017The content of the resulting ``/dev`` directory is defined in a Device 7017The content of the resulting ``/dev`` directory is defined in a Device
7018Table file. The 7018Table file. The
7019```IMAGE_DEVICE_TABLES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_DEVICE_TABLES>`__ 7019:term:`IMAGE_DEVICE_TABLES`
7020variable defines the Device Table to use and should be set in the 7020variable defines the Device Table to use and should be set in the
7021machine or distro configuration file. Alternatively, you can set this 7021machine or distro configuration file. Alternatively, you can set this
7022variable in your ``local.conf`` configuration file. 7022variable in your ``local.conf`` configuration file.
@@ -7034,7 +7034,7 @@ Using ``devtmpfs`` and a Device Manager
7034--------------------------------------- 7034---------------------------------------
7035 7035
7036To use the dynamic method for device population, you need to use (or be 7036To use the dynamic method for device population, you need to use (or be
7037sure to set) the ```USE_DEVFS`` <&YOCTO_DOCS_REF_URL;#var-USE_DEVFS>`__ 7037sure to set) the :term:`USE_DEVFS`
7038variable to "1", which is the default: USE_DEVFS = "1" With this 7038variable to "1", which is the default: USE_DEVFS = "1" With this
7039setting, the resulting ``/dev`` directory is populated by the kernel 7039setting, the resulting ``/dev`` directory is populated by the kernel
7040using ``devtmpfs``. Make sure the corresponding kernel configuration 7040using ``devtmpfs``. Make sure the corresponding kernel configuration
@@ -7065,12 +7065,12 @@ This only works for SCMs from which it is possible to get a sensible
7065revision number for changes. Currently, you can do this with Apache 7065revision number for changes. Currently, you can do this with Apache
7066Subversion (SVN), Git, and Bazaar (BZR) repositories. 7066Subversion (SVN), Git, and Bazaar (BZR) repositories.
7067 7067
7068To enable this behavior, the ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ of 7068To enable this behavior, the :term:`PV` of
7069the recipe needs to reference 7069the recipe needs to reference
7070```SRCPV`` <&YOCTO_DOCS_REF_URL;#var-SRCPV>`__. Here is an example: PV = 7070:term:`SRCPV`. Here is an example: PV =
7071"1.2.3+git${SRCPV}" Then, you can add the following to your 7071"1.2.3+git${SRCPV}" Then, you can add the following to your
7072``local.conf``: SRCREV_pn-PN = "${AUTOREV}" 7072``local.conf``: SRCREV_pn-PN = "${AUTOREV}"
7073```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__ is the name of the recipe for 7073:term:`PN` is the name of the recipe for
7074which you want to enable automatic source revision updating. 7074which you want to enable automatic source revision updating.
7075 7075
7076If you do not want to update your local configuration file, you can add 7076If you do not want to update your local configuration file, you can add
@@ -7135,8 +7135,8 @@ For more information on how to use these variables, see the
7135"`Customizing Images Using Custom ``IMAGE_FEATURES`` and 7135"`Customizing Images Using Custom ``IMAGE_FEATURES`` and
7136``EXTRA_IMAGE_FEATURES`` <#usingpoky-extend-customimage-imagefeatures>`__" 7136``EXTRA_IMAGE_FEATURES`` <#usingpoky-extend-customimage-imagefeatures>`__"
7137section. For information on the variables, see 7137section. For information on the variables, see
7138```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__ and 7138:term:`IMAGE_FEATURES` and
7139```EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES>`__. 7139:term:`EXTRA_IMAGE_FEATURES`.
7140 7140
7141Post-Installation Scripts 7141Post-Installation Scripts
7142------------------------- 7142-------------------------
@@ -7163,7 +7163,7 @@ Here are some common problems that prevent post-installation scripts
7163from running during root filesystem creation: 7163from running during root filesystem creation:
7164 7164
7165- *Not using $D in front of absolute paths:* The build system defines 7165- *Not using $D in front of absolute paths:* The build system defines
7166 ``$``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__ when the root 7166 ``$``\ :term:`D` when the root
7167 filesystem is created. Furthermore, ``$D`` is blank when the script 7167 filesystem is created. Furthermore, ``$D`` is blank when the script
7168 is run on the target device. This implies two purposes for ``$D``: 7168 is run on the target device. This implies two purposes for ``$D``:
7169 ensuring paths are valid in both the host and target environments, 7169 ensuring paths are valid in both the host and target environments,
@@ -7175,7 +7175,7 @@ from running during root filesystem creation:
7175 native tools, which run on the host system, to accomplish the same 7175 native tools, which run on the host system, to accomplish the same
7176 tasks, or by alternatively running the processes under QEMU, which 7176 tasks, or by alternatively running the processes under QEMU, which
7177 has the ``qemu_run_binary`` function. For more information, see the 7177 has the ``qemu_run_binary`` function. For more information, see the
7178 ```qemu`` <&YOCTO_DOCS_REF_URL;#ref-classes-qemu>`__ class. 7178 :ref:`qemu <ref-classes-qemu>` class.
7179 7179
7180Areas With Write Access 7180Areas With Write Access
7181----------------------- 7181-----------------------
@@ -7200,7 +7200,7 @@ has already been built when the software is building, the software will
7200link to the built library and that library will be pulled into your 7200link to the built library and that library will be pulled into your
7201image along with the new software even if you did not want the library. 7201image along with the new software even if you did not want the library.
7202 7202
7203The ```buildhistory`` <&YOCTO_DOCS_REF_URL;#ref-classes-buildhistory>`__ 7203The :ref:`buildhistory <ref-classes-buildhistory>`
7204class exists to help you maintain the quality of your build output. You 7204class exists to help you maintain the quality of your build output. You
7205can use the class to highlight unexpected and possibly unwanted changes 7205can use the class to highlight unexpected and possibly unwanted changes
7206in the build output. When you enable build history, it records 7206in the build output. When you enable build history, it records
@@ -7224,9 +7224,9 @@ Enabling and Disabling Build History
7224 7224
7225Build history is disabled by default. To enable it, add the following 7225Build history is disabled by default. To enable it, add the following
7226``INHERIT`` statement and set the 7226``INHERIT`` statement and set the
7227```BUILDHISTORY_COMMIT`` <&YOCTO_DOCS_REF_URL;#var-BUILDHISTORY_COMMIT>`__ 7227:term:`BUILDHISTORY_COMMIT`
7228variable to "1" at the end of your ``conf/local.conf`` file found in the 7228variable to "1" at the end of your ``conf/local.conf`` file found in the
7229`Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT += 7229:term:`Build Directory`: INHERIT +=
7230"buildhistory" BUILDHISTORY_COMMIT = "1" Enabling build history as 7230"buildhistory" BUILDHISTORY_COMMIT = "1" Enabling build history as
7231previously described causes the OpenEmbedded build system to collect 7231previously described causes the OpenEmbedded build system to collect
7232build output information and commit it as a single commit to a local 7232build output information and commit it as a single commit to a local
@@ -7245,9 +7245,9 @@ Understanding What the Build History Contains
7245--------------------------------------------- 7245---------------------------------------------
7246 7246
7247Build history information is kept in 7247Build history information is kept in
7248``${``\ ```TOPDIR`` <&YOCTO_DOCS_REF_URL;#var-TOPDIR>`__\ ``}/buildhistory`` 7248``${``\ :term:`TOPDIR`\ ``}/buildhistory``
7249in the Build Directory as defined by the 7249in the Build Directory as defined by the
7250```BUILDHISTORY_DIR`` <&YOCTO_DOCS_REF_URL;#var-BUILDHISTORY_DIR>`__ 7250:term:`BUILDHISTORY_DIR`
7251variable. The following is an example abbreviated listing: 7251variable. The following is an example abbreviated listing:
7252 7252
7253At the top level, a ``metadata-revs`` file exists that lists the 7253At the top level, a ``metadata-revs`` file exists that lists the
@@ -7353,7 +7353,7 @@ The files produced for each image are as follows:
7353 7353
7354- ``image-files:`` A directory containing selected files from the root 7354- ``image-files:`` A directory containing selected files from the root
7355 filesystem. The files are defined by 7355 filesystem. The files are defined by
7356 ```BUILDHISTORY_IMAGE_FILES`` <&YOCTO_DOCS_REF_URL;#var-BUILDHISTORY_IMAGE_FILES>`__. 7356 :term:`BUILDHISTORY_IMAGE_FILES`.
7357 7357
7358- ``build-id.txt:`` Human-readable information about the build 7358- ``build-id.txt:`` Human-readable information about the build
7359 configuration and metadata source revisions. This file contains the 7359 configuration and metadata source revisions. This file contains the
@@ -7411,7 +7411,7 @@ following to your ``conf/local.conf`` file found in the `Build
7411Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT += 7411Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT +=
7412"buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image" 7412"buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image"
7413Here, you set the 7413Here, you set the
7414```BUILDHISTORY_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-BUILDHISTORY_FEATURES>`__ 7414:term:`BUILDHISTORY_FEATURES`
7415variable to use the image feature only. 7415variable to use the image feature only.
7416 7416
7417Build History SDK Information 7417Build History SDK Information
@@ -7491,7 +7491,7 @@ You can examine build history output from the command line or from a web
7491interface. 7491interface.
7492 7492
7493To see any changes that have occurred (assuming you have 7493To see any changes that have occurred (assuming you have
7494```BUILDHISTORY_COMMIT`` <&YOCTO_DOCS_REF_URL;#var-BUILDHISTORY_COMMIT>`__\ `` = "1"``), 7494:term:`BUILDHISTORY_COMMIT`\ `` = "1"``),
7495you can simply use any Git command that allows you to view the history 7495you can simply use any Git command that allows you to view the history
7496of a repository. Here is one method: $ git log -p You need to realize, 7496of a repository. Here is one method: $ git log -p You need to realize,
7497however, that this method does show changes that are not significant 7497however, that this method does show changes that are not significant
@@ -7635,7 +7635,7 @@ Once you start running the tests, the following happens:
76353. A default timeout of 500 seconds occurs to allow for the boot process 76353. A default timeout of 500 seconds occurs to allow for the boot process
7636 to reach the login prompt. You can change the timeout period by 7636 to reach the login prompt. You can change the timeout period by
7637 setting 7637 setting
7638 ```TEST_QEMUBOOT_TIMEOUT`` <&YOCTO_DOCS_REF_URL;#var-TEST_QEMUBOOT_TIMEOUT>`__ 7638 :term:`TEST_QEMUBOOT_TIMEOUT`
7639 in the ``local.conf`` file. 7639 in the ``local.conf`` file.
7640 7640
76414. Once the boot process is reached and the login prompt appears, the 76414. Once the boot process is reached and the login prompt appears, the
@@ -7815,7 +7815,7 @@ wish to experiment with automated hardware testing, you can use the
7815dialog-power-control script that shows a dialog prompting you to perform 7815dialog-power-control script that shows a dialog prompting you to perform
7816the required power action. This script requires either KDialog or Zenity 7816the required power action. This script requires either KDialog or Zenity
7817to be installed. To use this script, set the 7817to be installed. To use this script, set the
7818```TEST_POWERCONTROL_CMD`` <&YOCTO_DOCS_REF_URL;#var-TEST_POWERCONTROL_CMD>`__ 7818:term:`TEST_POWERCONTROL_CMD`
7819variable as follows: TEST_POWERCONTROL_CMD = 7819variable as follows: TEST_POWERCONTROL_CMD =
7820"${COREBASE}/scripts/contrib/dialog-power-control" 7820"${COREBASE}/scripts/contrib/dialog-power-control"
7821 7821
@@ -7826,9 +7826,9 @@ For test target classes requiring a serial console to interact with the
7826bootloader (e.g. BeagleBoneTarget, EdgeRouterTarget, and GrubTarget), 7826bootloader (e.g. BeagleBoneTarget, EdgeRouterTarget, and GrubTarget),
7827you need to specify a command to use to connect to the serial console of 7827you need to specify a command to use to connect to the serial console of
7828the target machine by using the 7828the target machine by using the
7829```TEST_SERIALCONTROL_CMD`` <&YOCTO_DOCS_REF_URL;#var-TEST_SERIALCONTROL_CMD>`__ 7829:term:`TEST_SERIALCONTROL_CMD`
7830variable and optionally the 7830variable and optionally the
7831```TEST_SERIALCONTROL_EXTRA_ARGS`` <&YOCTO_DOCS_REF_URL;#var-TEST_SERIALCONTROL_EXTRA_ARGS>`__ 7831:term:`TEST_SERIALCONTROL_EXTRA_ARGS`
7832variable. 7832variable.
7833 7833
7834These cases could be a serial terminal program if the machine is 7834These cases could be a serial terminal program if the machine is
@@ -7855,7 +7855,7 @@ You can start the tests automatically or manually:
7855- *Automatically running tests:* To run the tests automatically after 7855- *Automatically running tests:* To run the tests automatically after
7856 the OpenEmbedded build system successfully creates an image, first 7856 the OpenEmbedded build system successfully creates an image, first
7857 set the 7857 set the
7858 ```TESTIMAGE_AUTO`` <&YOCTO_DOCS_REF_URL;#var-TESTIMAGE_AUTO>`__ 7858 :term:`TESTIMAGE_AUTO`
7859 variable to "1" in your ``local.conf`` file in the `Build 7859 variable to "1" in your ``local.conf`` file in the `Build
7860 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: TESTIMAGE_AUTO = 7860 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: TESTIMAGE_AUTO =
7861 "1" Next, build your image. If the image successfully builds, the 7861 "1" Next, build your image. If the image successfully builds, the
@@ -7874,7 +7874,7 @@ individual tests. Tests are usually grouped together by the area tested
7874(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``). 7874(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``).
7875 7875
7876You can add tests to any layer provided you place them in the proper 7876You can add tests to any layer provided you place them in the proper
7877area and you extend ```BBPATH`` <&YOCTO_DOCS_REF_URL;#var-BBPATH>`__ in 7877area and you extend :term:`BBPATH` in
7878the ``local.conf`` file as normal. Be sure that tests reside in 7878the ``local.conf`` file as normal. Be sure that tests reside in
7879``layer/lib/oeqa/runtime``. 7879``layer/lib/oeqa/runtime``.
7880 7880
@@ -7886,7 +7886,7 @@ the ``local.conf`` file as normal. Be sure that tests reside in
7886 . 7886 .
7887 7887
7888You can change the set of tests run by appending or overriding 7888You can change the set of tests run by appending or overriding
7889```TEST_SUITES`` <&YOCTO_DOCS_REF_URL;#var-TEST_SUITES>`__ variable in 7889:term:`TEST_SUITES` variable in
7890``local.conf``. Each name in ``TEST_SUITES`` represents a required test 7890``local.conf``. Each name in ``TEST_SUITES`` represents a required test
7891for the image. Test modules named within ``TEST_SUITES`` cannot be 7891for the image. Test modules named within ``TEST_SUITES`` cannot be
7892skipped even if a test is not suitable for an image (e.g. running the 7892skipped even if a test is not suitable for an image (e.g. running the
@@ -7927,7 +7927,7 @@ Exporting Tests
7927You can export tests so that they can run independently of the build 7927You can export tests so that they can run independently of the build
7928system. Exporting tests is required if you want to be able to hand the 7928system. Exporting tests is required if you want to be able to hand the
7929test execution off to a scheduler. You can only export tests that are 7929test execution off to a scheduler. You can only export tests that are
7930defined in ```TEST_SUITES`` <&YOCTO_DOCS_REF_URL;#var-TEST_SUITES>`__. 7930defined in :term:`TEST_SUITES`.
7931 7931
7932If your image is already built, make sure the following are set in your 7932If your image is already built, make sure the following are set in your
7933``local.conf`` file: INHERIT +="testexport" TEST_TARGET_IP = 7933``local.conf`` file: INHERIT +="testexport" TEST_TARGET_IP =
@@ -7958,7 +7958,7 @@ As mentioned previously, all new test files need to be in the proper
7958place for the build system to find them. New tests for additional 7958place for the build system to find them. New tests for additional
7959functionality outside of the core should be added to the layer that adds 7959functionality outside of the core should be added to the layer that adds
7960the functionality, in ``layer/lib/oeqa/runtime`` (as long as 7960the functionality, in ``layer/lib/oeqa/runtime`` (as long as
7961```BBPATH`` <&YOCTO_DOCS_REF_URL;#var-BBPATH>`__ is extended in the 7961:term:`BBPATH` is extended in the
7962layer's ``layer.conf`` file as normal). Just remember the following: 7962layer's ``layer.conf`` file as normal). Just remember the following:
7963 7963
7964- Filenames need to map directly to test (module) names. 7964- Filenames need to map directly to test (module) names.
@@ -7998,8 +7998,8 @@ Class methods are as follows:
7998 is generated during the ``do_rootfs`` task. 7998 is generated during the ``do_rootfs`` task.
7999 7999
8000- *``hasFeature(feature)``:* Returns "True" if the feature is in 8000- *``hasFeature(feature)``:* Returns "True" if the feature is in
8001 ```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__ or 8001 :term:`IMAGE_FEATURES` or
8002 ```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__. 8002 :term:`DISTRO_FEATURES`.
8003 8003
8004.. _qemu-image-writing-tests-class-attributes: 8004.. _qemu-image-writing-tests-class-attributes:
8005 8005
@@ -8147,7 +8147,7 @@ section:
8147- "`Viewing Package Information with 8147- "`Viewing Package Information with
8148 ``oe-pkgdata-util`` <#viewing-package-information-with-oe-pkgdata-util>`__" 8148 ``oe-pkgdata-util`` <#viewing-package-information-with-oe-pkgdata-util>`__"
8149 describes how to use the ``oe-pkgdata-util`` utility to query 8149 describes how to use the ``oe-pkgdata-util`` utility to query
8150 ```PKGDATA_DIR`` <&YOCTO_DOCS_REF_URL;#var-PKGDATA_DIR>`__ and 8150 :term:`PKGDATA_DIR` and
8151 display package-related information for built packages. 8151 display package-related information for built packages.
8152 8152
8153- "`Viewing Dependencies Between Recipes and 8153- "`Viewing Dependencies Between Recipes and
@@ -8203,12 +8203,12 @@ Viewing Logs from Failed Tasks
8203------------------------------ 8203------------------------------
8204 8204
8205You can find the log for a task in the file 8205You can find the log for a task in the file
8206``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}/temp/log.do_``\ taskname. 8206``${``\ :term:`WORKDIR`\ ``}/temp/log.do_``\ taskname.
8207For example, the log for the 8207For example, the log for the
8208```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__ task of the 8208:ref:`ref-tasks-compile` task of the
8209QEMU minimal image for the x86 machine (``qemux86``) might be in 8209QEMU minimal image for the x86 machine (``qemux86``) might be in
8210``tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile``. 8210``tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile``.
8211To see the commands `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ ran 8211To see the commands :term:`BitBake` ran
8212to generate a log, look at the corresponding ``run.do_``\ taskname file 8212to generate a log, look at the corresponding ``run.do_``\ taskname file
8213in the same directory. 8213in the same directory.
8214 8214
@@ -8269,7 +8269,7 @@ In addition to variable values, the output of the ``bitbake -e`` and
8269 system (including the behavior of the `normal recipe build 8269 system (including the behavior of the `normal recipe build
8270 tasks <&YOCTO_DOCS_REF_URL;#normal-recipe-build-tasks>`__) is 8270 tasks <&YOCTO_DOCS_REF_URL;#normal-recipe-build-tasks>`__) is
8271 implemented in the 8271 implemented in the
8272 ```base`` <&YOCTO_DOCS_REF_URL;#ref-classes-base>`__ class and the 8272 :ref:`base <ref-classes-base>` class and the
8273 classes it inherits, rather than being built into BitBake itself. 8273 classes it inherits, rather than being built into BitBake itself.
8274 8274
8275- After the variable values, all functions appear in the output. For 8275- After the variable values, all functions appear in the output. For
@@ -8282,7 +8282,7 @@ Viewing Package Information with ``oe-pkgdata-util``
8282---------------------------------------------------- 8282----------------------------------------------------
8283 8283
8284You can use the ``oe-pkgdata-util`` command-line utility to query 8284You can use the ``oe-pkgdata-util`` command-line utility to query
8285```PKGDATA_DIR`` <&YOCTO_DOCS_REF_URL;#var-PKGDATA_DIR>`__ and display 8285:term:`PKGDATA_DIR` and display
8286various package-related information. When you use the utility, you must 8286various package-related information. When you use the utility, you must
8287use it to view information on packages that have already been built. 8287use it to view information on packages that have already been built.
8288 8288
@@ -8304,10 +8304,10 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands.
8304 8304
8305 A different way to view the contents of a package is to look at 8305 A different way to view the contents of a package is to look at
8306 the 8306 the
8307 ``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}/packages-split`` 8307 ``${``\ :term:`WORKDIR`\ ``}/packages-split``
8308 directory of the recipe that generates the package. This directory 8308 directory of the recipe that generates the package. This directory
8309 is created by the 8309 is created by the
8310 ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ task 8310 :ref:`ref-tasks-package` task
8311 and has one subdirectory for each package the recipe generates, 8311 and has one subdirectory for each package the recipe generates,
8312 which contains the files stored in that package. 8312 which contains the files stored in that package.
8313 8313
@@ -8346,7 +8346,7 @@ in the current directory:
8346 recipename. "Involved" here means that at least one task from the 8346 recipename. "Involved" here means that at least one task from the
8347 recipe needs to run when building recipename from scratch. Targets 8347 recipe needs to run when building recipename from scratch. Targets
8348 that are in 8348 that are in
8349 ```ASSUME_PROVIDED`` <&YOCTO_DOCS_REF_URL;#var-ASSUME_PROVIDED>`__ 8349 :term:`ASSUME_PROVIDED`
8350 are not listed. 8350 are not listed.
8351 8351
8352- ``task-depends.dot``: A graph showing dependencies between tasks. 8352- ``task-depends.dot``: A graph showing dependencies between tasks.
@@ -8369,11 +8369,11 @@ format and can be converted to images (e.g. using the ``dot`` tool from
8369 as the following: "libxslt.do_configure" -> 8369 as the following: "libxslt.do_configure" ->
8370 "libxml2.do_populate_sysroot" The above example line reveals that 8370 "libxml2.do_populate_sysroot" The above example line reveals that
8371 the 8371 the
8372 ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ 8372 :ref:`ref-tasks-configure`
8373 task in ``libxslt`` depends on the 8373 task in ``libxslt`` depends on the
8374 ```do_populate_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot>`__ 8374 :ref:`ref-tasks-populate_sysroot`
8375 task in ``libxml2``, which is a normal 8375 task in ``libxml2``, which is a normal
8376 ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ dependency 8376 :term:`DEPENDS` dependency
8377 between the two recipes. 8377 between the two recipes.
8378 8378
8379 - For an example of how ``.dot`` files can be processed, see the 8379 - For an example of how ``.dot`` files can be processed, see the
@@ -8407,19 +8407,19 @@ BitBake has determined by doing the following:
8407 8407
84081. Build the recipe containing the task: $ bitbake recipename 84081. Build the recipe containing the task: $ bitbake recipename
8409 8409
84102. Inside the ```STAMPS_DIR`` <&YOCTO_DOCS_REF_URL;#var-STAMPS_DIR>`__ 84102. Inside the :term:`STAMPS_DIR`
8411 directory, find the signature data (``sigdata``) file that 8411 directory, find the signature data (``sigdata``) file that
8412 corresponds to the task. The ``sigdata`` files contain a pickled 8412 corresponds to the task. The ``sigdata`` files contain a pickled
8413 Python database of all the metadata that went into creating the input 8413 Python database of all the metadata that went into creating the input
8414 checksum for the task. As an example, for the 8414 checksum for the task. As an example, for the
8415 ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__ task of the 8415 :ref:`ref-tasks-fetch` task of the
8416 ``db`` recipe, the ``sigdata`` file might be found in the following 8416 ``db`` recipe, the ``sigdata`` file might be found in the following
8417 location: 8417 location:
8418 ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1 8418 ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
8419 For tasks that are accelerated through the shared state 8419 For tasks that are accelerated through the shared state
8420 (`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache, an 8420 (`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache, an
8421 additional ``siginfo`` file is written into 8421 additional ``siginfo`` file is written into
8422 ```SSTATE_DIR`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR>`__ along with 8422 :term:`SSTATE_DIR` along with
8423 the cached task output. The ``siginfo`` files contain exactly the 8423 the cached task output. The ``siginfo`` files contain exactly the
8424 same information as ``sigdata`` files. 8424 same information as ``sigdata`` files.
8425 8425
@@ -8475,7 +8475,7 @@ Viewing Metadata Used to Create the Input Signature of a Shared State Task
8475Seeing what metadata went into creating the input signature of a shared 8475Seeing what metadata went into creating the input signature of a shared
8476state (sstate) task can be a useful debugging aid. This information is 8476state (sstate) task can be a useful debugging aid. This information is
8477available in signature information (``siginfo``) files in 8477available in signature information (``siginfo``) files in
8478```SSTATE_DIR`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR>`__. For 8478:term:`SSTATE_DIR`. For
8479information on how to view and interpret information in ``siginfo`` 8479information on how to view and interpret information in ``siginfo``
8480files, see the "`Viewing Task Variable 8480files, see the "`Viewing Task Variable
8481Dependencies <#dev-viewing-task-variable-dependencies>`__" section. 8481Dependencies <#dev-viewing-task-variable-dependencies>`__" section.
@@ -8521,7 +8521,7 @@ invalidate the cache and force the tasks to run. The steps you can take
8521are as simple as changing a function's comments in the source code. For 8521are as simple as changing a function's comments in the source code. For
8522example, to invalidate package shared state files, change the comment 8522example, to invalidate package shared state files, change the comment
8523statements of 8523statements of
8524```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ or the 8524:ref:`ref-tasks-package` or the
8525comments of one of the functions it calls. Even though the change is 8525comments of one of the functions it calls. Even though the change is
8526purely cosmetic, it causes the checksum to be recalculated and forces 8526purely cosmetic, it causes the checksum to be recalculated and forces
8527the build system to run the task again. 8527the build system to run the task again.
@@ -8559,7 +8559,7 @@ BitBake determines whether a task is "out of date".
8559 8559
8560If you want to force an up-to-date task to be rerun (e.g. because you 8560If you want to force an up-to-date task to be rerun (e.g. because you
8561made manual modifications to the recipe's 8561made manual modifications to the recipe's
8562```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__ that you want to try 8562:term:`WORKDIR` that you want to try
8563out), then you can use the ``-f`` option. 8563out), then you can use the ``-f`` option.
8564 8564
8565.. note:: 8565.. note::
@@ -8595,7 +8595,7 @@ it is to use the ``-C`` option.
8595 option, which is lower-cased. 8595 option, which is lower-cased.
8596 8596
8597Using this option invalidates the given task and then runs the 8597Using this option invalidates the given task and then runs the
8598```do_build`` <&YOCTO_DOCS_REF_URL;#ref-tasks-build>`__ task, which is 8598:ref:`ref-tasks-build` task, which is
8599the default task if no task is given, and the tasks on which it depends. 8599the default task if no task is given, and the tasks on which it depends.
8600You could replace the final two commands in the previous example with 8600You could replace the final two commands in the previous example with
8601the following single command: $ bitbake matchbox-desktop -C compile 8601the following single command: $ bitbake matchbox-desktop -C compile
@@ -8702,7 +8702,7 @@ log to ``${T}/log.do_``\ task, and can also log to standard output
8702The same logging functions are also available in shell functions, under 8702The same logging functions are also available in shell functions, under
8703the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``, 8703the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
8704and ``bbfatal``. The 8704and ``bbfatal``. The
8705```logging`` <&YOCTO_DOCS_REF_URL;#ref-classes-logging>`__ class 8705:ref:`logging <ref-classes-logging>` class
8706implements these functions. See that class in the ``meta/classes`` 8706implements these functions. See that class in the ``meta/classes``
8707folder of the `Source 8707folder of the `Source
8708Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ for information. 8708Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ for information.
@@ -8717,7 +8717,7 @@ in the log, use the "debug" loglevel.
8717 8717
8718Following is an example written in Python. The code handles logging for 8718Following is an example written in Python. The code handles logging for
8719a function that determines the number of tasks needed to be run. See the 8719a function that determines the number of tasks needed to be run. See the
8720"```do_listtasks`` <&YOCTO_DOCS_REF_URL;#ref-tasks-listtasks>`__" 8720":ref:`ref-tasks-listtasks`"
8721section for additional information: python do_listtasks() { bb.debug(2, 8721section for additional information: python do_listtasks() { bb.debug(2,
8722"Starting to figure out the task list") if noteworthy_condition: 8722"Starting to figure out the task list") if noteworthy_condition:
8723bb.note("There are 47 tasks to run") bb.debug(2, "Got to point xyz") if 8723bb.note("There are 47 tasks to run") bb.debug(2, "Got to point xyz") if
@@ -8851,7 +8851,7 @@ exists. Thus, once the error surfaces, you need a way to reproduce it.
8851In this example, compiling the "neard" package is causing the problem. 8851In this example, compiling the "neard" package is causing the problem.
8852So the first thing to do is build "neard" locally. Before you start the 8852So the first thing to do is build "neard" locally. Before you start the
8853build, set the 8853build, set the
8854```PARALLEL_MAKE`` <&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE>`__ variable 8854:term:`PARALLEL_MAKE` variable
8855in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a 8855in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a
8856high value for ``PARALLEL_MAKE`` increases the chances of the race 8856high value for ``PARALLEL_MAKE`` increases the chances of the race
8857condition showing up: $ bitbake neard 8857condition showing up: $ bitbake neard
@@ -8895,7 +8895,7 @@ Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ named ``poky``: $
8895cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard 8895cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
8896The final thing you need to do to implement the fix in the build is to 8896The final thing you need to do to implement the fix in the build is to
8897update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the 8897update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
8898```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statement includes 8898:term:`SRC_URI` statement includes
8899the patch file. The recipe file is in the folder above the patch. Here 8899the patch file. The recipe file is in the folder above the patch. Here
8900is what the edited ``SRC_URI`` statement would look like: SRC_URI = 8900is what the edited ``SRC_URI`` statement would look like: SRC_URI =
8901"${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \\ 8901"${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \\
@@ -8930,7 +8930,7 @@ GDB allows you to examine running programs, which in turn helps you to
8930understand and fix problems. It also allows you to perform post-mortem 8930understand and fix problems. It also allows you to perform post-mortem
8931style analysis of program crashes. GDB is available as a package within 8931style analysis of program crashes. GDB is available as a package within
8932the Yocto Project and is installed in SDK images by default. See the 8932the Yocto Project and is installed in SDK images by default. See the
8933"`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the Yocto 8933":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
8934Project Reference Manual for a description of these images. You can find 8934Project Reference Manual for a description of these images. You can find
8935information on GDB at ` <http://sourceware.org/gdb/>`__. 8935information on GDB at ` <http://sourceware.org/gdb/>`__.
8936 8936
@@ -9114,10 +9114,10 @@ debug on the target hardware.
9114To support this kind of debugging, you need do the following: 9114To support this kind of debugging, you need do the following:
9115 9115
9116- Ensure that GDB is on the target. You can do this by adding "gdb" to 9116- Ensure that GDB is on the target. You can do this by adding "gdb" to
9117 ```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__: 9117 :term:`IMAGE_INSTALL`:
9118 IMAGE_INSTALL_append = " gdb" Alternatively, you can add 9118 IMAGE_INSTALL_append = " gdb" Alternatively, you can add
9119 "tools-debug" to 9119 "tools-debug" to
9120 ```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__: 9120 :term:`IMAGE_FEATURES`:
9121 IMAGE_FEATURES_append = " tools-debug" 9121 IMAGE_FEATURES_append = " tools-debug"
9122 9122
9123- Ensure that debug symbols are present. You can make sure these 9123- Ensure that debug symbols are present. You can make sure these
@@ -9162,12 +9162,12 @@ Here are some other tips that you might find useful:
9162 is also possible to switch out of the splashscreen by switching the 9162 is also possible to switch out of the splashscreen by switching the
9163 virtual console (e.g. Fn+Left or Fn+Right on a Zaurus). 9163 virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
9164 9164
9165- Removing ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__ (usually 9165- Removing :term:`TMPDIR` (usually
9166 ``tmp/``, within the `Build 9166 ``tmp/``, within the `Build
9167 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__) can often fix 9167 Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__) can often fix
9168 temporary build issues. Removing ``TMPDIR`` is usually a relatively 9168 temporary build issues. Removing ``TMPDIR`` is usually a relatively
9169 cheap operation, because task output will be cached in 9169 cheap operation, because task output will be cached in
9170 ```SSTATE_DIR`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR>`__ (usually 9170 :term:`SSTATE_DIR` (usually
9171 ``sstate-cache/``, which is also in the Build Directory). 9171 ``sstate-cache/``, which is also in the Build Directory).
9172 9172
9173 .. note:: 9173 .. note::
@@ -9654,7 +9654,7 @@ Tracking License Changes
9654 9654
9655The license of an upstream project might change in the future. In order 9655The license of an upstream project might change in the future. In order
9656to prevent these changes going unnoticed, the 9656to prevent these changes going unnoticed, the
9657```LIC_FILES_CHKSUM`` <&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM>`__ 9657:term:`LIC_FILES_CHKSUM`
9658variable tracks changes to the license text. The checksums are validated 9658variable tracks changes to the license text. The checksums are validated
9659at the end of the configure step, and if the checksums do not match, the 9659at the end of the configure step, and if the checksums do not match, the
9660build will fail. 9660build will fail.
@@ -9682,7 +9682,7 @@ file://licfile2.txt;endline=50;md5=zzzz \\ ..."
9682 as part of the QA message. Using this output, you can determine 9682 as part of the QA message. Using this output, you can determine
9683 the exact start and finish for the needed license text. 9683 the exact start and finish for the needed license text.
9684 9684
9685The build system uses the ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__ 9685The build system uses the :term:`S`
9686variable as the default directory when searching files listed in 9686variable as the default directory when searching files listed in
9687``LIC_FILES_CHKSUM``. The previous example employs the default 9687``LIC_FILES_CHKSUM``. The previous example employs the default
9688directory. 9688directory.
@@ -9694,7 +9694,7 @@ md5=bb14ed3c4cda583abc85401304b5cd4e" LIC_FILES_CHKSUM =
9694 9694
9695The first line locates a file in ``${S}/src/ls.c`` and isolates lines 9695The first line locates a file in ``${S}/src/ls.c`` and isolates lines
9696five through 16 as license text. The second line refers to a file in 9696five through 16 as license text. The second line refers to a file in
9697```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__. 9697:term:`WORKDIR`.
9698 9698
9699Note that ``LIC_FILES_CHKSUM`` variable is mandatory for all recipes, 9699Note that ``LIC_FILES_CHKSUM`` variable is mandatory for all recipes,
9700unless the ``LICENSE`` variable is set to "CLOSED". 9700unless the ``LICENSE`` variable is set to "CLOSED".
@@ -9733,7 +9733,7 @@ long as it is kept up to date.
9733.. note:: 9733.. note::
9734 9734
9735 - If you specify an empty or invalid "md5" parameter, 9735 - If you specify an empty or invalid "md5" parameter,
9736 `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ returns an md5 9736 :term:`BitBake` returns an md5
9737 mis-match error and displays the correct "md5" parameter value 9737 mis-match error and displays the correct "md5" parameter value
9738 during the build. The correct parameter is also captured in the 9738 during the build. The correct parameter is also captured in the
9739 build log. 9739 build log.
@@ -9747,7 +9747,7 @@ Enabling Commercially Licensed Recipes
9747By default, the OpenEmbedded build system disables components that have 9747By default, the OpenEmbedded build system disables components that have
9748commercial or other special licensing requirements. Such requirements 9748commercial or other special licensing requirements. Such requirements
9749are defined on a recipe-by-recipe basis through the 9749are defined on a recipe-by-recipe basis through the
9750```LICENSE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS>`__ variable 9750:term:`LICENSE_FLAGS` variable
9751definition in the affected recipe. For instance, the 9751definition in the affected recipe. For instance, the
9752``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe 9752``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe
9753contains the following statement: LICENSE_FLAGS = "commercial" Here is a 9753contains the following statement: LICENSE_FLAGS = "commercial" Here is a
@@ -9756,7 +9756,7 @@ name and version (after variable expansion): LICENSE_FLAGS =
9756"license_${PN}_${PV}" In order for a component restricted by a 9756"license_${PN}_${PV}" In order for a component restricted by a
9757``LICENSE_FLAGS`` definition to be enabled and included in an image, it 9757``LICENSE_FLAGS`` definition to be enabled and included in an image, it
9758needs to have a matching entry in the global 9758needs to have a matching entry in the global
9759```LICENSE_FLAGS_WHITELIST`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS_WHITELIST>`__ 9759:term:`LICENSE_FLAGS_WHITELIST`
9760variable, which is a variable typically defined in your ``local.conf`` 9760variable, which is a variable typically defined in your ``local.conf``
9761file. For example, to enable the 9761file. For example, to enable the
9762``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you 9762``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you
@@ -9930,14 +9930,14 @@ for most compliance groups - providing the source. The Yocto Project has
9930a few ways of meeting this requirement. 9930a few ways of meeting this requirement.
9931 9931
9932One of the easiest ways to meet this requirement is to provide the 9932One of the easiest ways to meet this requirement is to provide the
9933entire ```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__ used by the 9933entire :term:`DL_DIR` used by the
9934build. This method, however, has a few issues. The most obvious is the 9934build. This method, however, has a few issues. The most obvious is the
9935size of the directory since it includes all sources used in the build 9935size of the directory since it includes all sources used in the build
9936and not just the source used in the released image. It will include 9936and not just the source used in the released image. It will include
9937toolchain source, and other artifacts, which you would not generally 9937toolchain source, and other artifacts, which you would not generally
9938release. However, the more serious issue for most companies is 9938release. However, the more serious issue for most companies is
9939accidental release of proprietary software. The Yocto Project provides 9939accidental release of proprietary software. The Yocto Project provides
9940an ```archiver`` <&YOCTO_DOCS_REF_URL;#ref-classes-archiver>`__ class to 9940an :ref:`archiver <ref-classes-archiver>` class to
9941help avoid some of these concerns. 9941help avoid some of these concerns.
9942 9942
9943Before you employ ``DL_DIR`` or the ``archiver`` class, you need to 9943Before you employ ``DL_DIR`` or the ``archiver`` class, you need to
@@ -9952,7 +9952,7 @@ Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT +=
9952"archiver" ARCHIVER_MODE[src] = "original" During the creation of your 9952"archiver" ARCHIVER_MODE[src] = "original" During the creation of your
9953image, the source from all recipes that deploy packages to the image is 9953image, the source from all recipes that deploy packages to the image is
9954placed within subdirectories of ``DEPLOY_DIR/sources`` based on the 9954placed within subdirectories of ``DEPLOY_DIR/sources`` based on the
9955```LICENSE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ for each recipe. 9955:term:`LICENSE` for each recipe.
9956Releasing the entire directory enables you to comply with requirements 9956Releasing the entire directory enables you to comply with requirements
9957concerning providing the unmodified source. It is important to note that 9957concerning providing the unmodified source. It is important to note that
9958the size of the directory can get large. 9958the size of the directory can get large.
@@ -9997,11 +9997,11 @@ generation are included on your image.
9997 ``/usr/share/license``. 9997 ``/usr/share/license``.
9998 9998
9999 The reason for this behavior is because 9999 The reason for this behavior is because
10000 ```COPY_LIC_DIRS`` <&YOCTO_DOCS_REF_URL;#var-COPY_LIC_DIRS>`__ and 10000 :term:`COPY_LIC_DIRS` and
10001 ```COPY_LIC_MANIFEST`` <&YOCTO_DOCS_REF_URL;#var-COPY_LIC_MANIFEST>`__ 10001 :term:`COPY_LIC_MANIFEST`
10002 add a copy of the license when the image is built but do not offer a 10002 add a copy of the license when the image is built but do not offer a
10003 path for adding licenses for newly installed packages to an image. 10003 path for adding licenses for newly installed packages to an image.
10004 ```LICENSE_CREATE_PACKAGE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_CREATE_PACKAGE>`__ 10004 :term:`LICENSE_CREATE_PACKAGE`
10005 adds a separate package and an upgrade path for adding licenses to an 10005 adds a separate package and an upgrade path for adding licenses to an
10006 image. 10006 image.
10007 10007
@@ -10043,7 +10043,7 @@ is increased each time build/conf/bblayers.conf # changes incompatibly
10043POKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BBFILES ?= "" 10043POKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BBFILES ?= ""
10044BBLAYERS ?= " \\ ##OEROOT##/meta \\ ##OEROOT##/meta-poky \\ 10044BBLAYERS ?= " \\ ##OEROOT##/meta \\ ##OEROOT##/meta-poky \\
10045##OEROOT##/meta-yocto-bsp \\ ##OEROOT##/meta-mylayer \\ " Creating and 10045##OEROOT##/meta-yocto-bsp \\ ##OEROOT##/meta-mylayer \\ " Creating and
10046providing an archive of the `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ 10046providing an archive of the :term:`Metadata`
10047layers (recipes, configuration files, and so forth) enables you to meet 10047layers (recipes, configuration files, and so forth) enables you to meet
10048your requirements to include the scripts to control compilation as well 10048your requirements to include the scripts to control compilation as well
10049as any modifications to the original source. 10049as any modifications to the original source.
@@ -10055,7 +10055,7 @@ Some packages, such as the linux-firmware package, have many licenses
10055that are not in any way common. You can avoid adding a lot of these 10055that are not in any way common. You can avoid adding a lot of these
10056types of common license files, which are only applicable to a specific 10056types of common license files, which are only applicable to a specific
10057package, by using the 10057package, by using the
10058```NO_GENERIC_LICENSE`` <&YOCTO_DOCS_REF_URL;#var-NO_GENERIC_LICENSE>`__ 10058:term:`NO_GENERIC_LICENSE`
10059variable. Using this variable also avoids QA errors when you use a 10059variable. Using this variable also avoids QA errors when you use a
10060non-common, non-CLOSED license in a recipe. 10060non-common, non-CLOSED license in a recipe.
10061 10061
@@ -10091,14 +10091,14 @@ Enabling and Using the Tool
10091 10091
10092By default, the error reporting tool is disabled. You can enable it by 10092By default, the error reporting tool is disabled. You can enable it by
10093inheriting the 10093inheriting the
10094```report-error`` <&YOCTO_DOCS_REF_URL;#ref-classes-report-error>`__ 10094:ref:`report-error <ref-classes-report-error>`
10095class by adding the following statement to the end of your 10095class by adding the following statement to the end of your
10096``local.conf`` file in your `Build 10096``local.conf`` file in your `Build
10097Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT += 10097Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT +=
10098"report-error" 10098"report-error"
10099 10099
10100By default, the error reporting feature stores information in 10100By default, the error reporting feature stores information in
10101``${``\ ```LOG_DIR`` <&YOCTO_DOCS_REF_URL;#var-LOG_DIR>`__\ ``}/error-report``. 10101``${``\ :term:`LOG_DIR`\ ``}/error-report``.
10102However, you can specify a directory to use by adding the following to 10102However, you can specify a directory to use by adding the following to
10103your ``local.conf`` file: ERR_REPORT_DIR = "path" Enabling error 10103your ``local.conf`` file: ERR_REPORT_DIR = "path" Enabling error
10104reporting causes the build process to collect the errors and store them 10104reporting causes the build process to collect the errors and store them
@@ -10127,7 +10127,7 @@ Disabling the Tool
10127 10127
10128To disable the error reporting feature, simply remove or comment out the 10128To disable the error reporting feature, simply remove or comment out the
10129following statement from the end of your ``local.conf`` file in your 10129following statement from the end of your ``local.conf`` file in your
10130`Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT += 10130:term:`Build Directory`. INHERIT +=
10131"report-error" 10131"report-error"
10132 10132
10133Setting Up Your Own Error Reporting Server 10133Setting Up Your Own Error Reporting Server
@@ -10191,7 +10191,7 @@ To cause Mesa to build the ``wayland-egl`` platform and Weston to build
10191Wayland with Kernel Mode Setting 10191Wayland with Kernel Mode Setting
10192(`KMS <https://wiki.archlinux.org/index.php/Kernel_Mode_Setting>`__) 10192(`KMS <https://wiki.archlinux.org/index.php/Kernel_Mode_Setting>`__)
10193support, include the "wayland" flag in the 10193support, include the "wayland" flag in the
10194```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__ 10194:term:`DISTRO_FEATURES`
10195statement in your ``local.conf`` file: DISTRO_FEATURES_append = " 10195statement in your ``local.conf`` file: DISTRO_FEATURES_append = "
10196wayland" 10196wayland"
10197 10197
@@ -10207,7 +10207,7 @@ Installing
10207 10207
10208To install the Wayland feature into an image, you must include the 10208To install the Wayland feature into an image, you must include the
10209following 10209following
10210```CORE_IMAGE_EXTRA_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-CORE_IMAGE_EXTRA_INSTALL>`__ 10210:term:`CORE_IMAGE_EXTRA_INSTALL`
10211statement in your ``local.conf`` file: CORE_IMAGE_EXTRA_INSTALL += 10211statement in your ``local.conf`` file: CORE_IMAGE_EXTRA_INSTALL +=
10212"wayland weston" 10212"wayland weston"
10213 10213
diff --git a/documentation/dev-manual/dev-manual-qemu.rst b/documentation/dev-manual/dev-manual-qemu.rst
index 9bae9eaa68..653f90573e 100644
--- a/documentation/dev-manual/dev-manual-qemu.rst
+++ b/documentation/dev-manual/dev-manual-qemu.rst
@@ -75,7 +75,7 @@ available. Follow these general steps to run QEMU:
75 75
76 - If you have previously built an image for QEMU (e.g. ``qemux86``, 76 - If you have previously built an image for QEMU (e.g. ``qemux86``,
77 ``qemuarm``, and so forth), then the artifacts are in place in 77 ``qemuarm``, and so forth), then the artifacts are in place in
78 your `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 78 your :term:`Build Directory`.
79 79
80 - If you have not built an image, you can go to the 80 - If you have not built an image, you can go to the
81 `machines/qemu <&YOCTO_MACHINES_DL_URL;>`__ area and download a 81 `machines/qemu <&YOCTO_MACHINES_DL_URL;>`__ area and download a
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst
index 2dd426b29f..fadc0bff3e 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/dev-manual-start.rst
@@ -75,7 +75,7 @@ particular working environment and set of practices.
75 development environment. 75 development environment.
76 76
774. *Use Git as Your Source Control Manager (SCM):* Keeping your 774. *Use Git as Your Source Control Manager (SCM):* Keeping your
78 `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ (i.e. recipes, 78 :term:`Metadata` (i.e. recipes,
79 configuration files, classes, and so forth) and any software you are 79 configuration files, classes, and so forth) and any software you are
80 developing under the control of an SCM system that is compatible 80 developing under the control of an SCM system that is compatible
81 with the OpenEmbedded build system is advisable. Of all of the SCMs 81 with the OpenEmbedded build system is advisable. Of all of the SCMs
@@ -248,7 +248,7 @@ particular working environment and set of practices.
248 for related upstream Yocto Project Git repositories. 248 for related upstream Yocto Project Git repositories.
249 249
250 - Set up the directory for the shared state cache 250 - Set up the directory for the shared state cache
251 (```SSTATE_DIR`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR>`__) where 251 (:term:`SSTATE_DIR`) where
252 it makes sense. For example, set up the sstate cache on a system 252 it makes sense. For example, set up the sstate cache on a system
253 used by developers in the same organization and share the same 253 used by developers in the same organization and share the same
254 source directories on their machines. 254 source directories on their machines.
diff --git a/documentation/kernel-dev/kernel-dev-advanced.rst b/documentation/kernel-dev/kernel-dev-advanced.rst
index 90323d3e2a..36a34ca28c 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/documentation/kernel-dev/kernel-dev-advanced.rst
@@ -11,7 +11,7 @@ Overview
11 11
12In addition to supporting configuration fragments and patches, the Yocto 12In addition to supporting configuration fragments and patches, the Yocto
13Project kernel tools also support rich 13Project kernel tools also support rich
14`Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ that you can use to define 14:term:`Metadata` that you can use to define
15complex policies and Board Support Package (BSP) support. The purpose of 15complex policies and Board Support Package (BSP) support. The purpose of
16the Metadata and the tools that manage it is to help you manage the 16the Metadata and the tools that manage it is to help you manage the
17complexity of the configuration and sources used to support multiple 17complexity of the configuration and sources used to support multiple
@@ -27,7 +27,7 @@ Kernel development tools ("kern-tools") exist also in the Yocto Project
27Source Repositories under the "Yocto Linux Kernel" heading in the 27Source Repositories under the "Yocto Linux Kernel" heading in the
28``yocto-kernel-tools`` Git repository. The recipe that builds these 28``yocto-kernel-tools`` Git repository. The recipe that builds these
29tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in 29tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in
30the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. 30the :term:`Source Directory` (e.g.
31``poky``). 31``poky``).
32 32
33Using Kernel Metadata in a Recipe 33Using Kernel Metadata in a Recipe
@@ -49,9 +49,9 @@ linux-yocto recipe.
49 file) is said to be a "linux-yocto style" recipe. 49 file) is said to be a "linux-yocto style" recipe.
50 50
51Every linux-yocto style recipe must define the 51Every linux-yocto style recipe must define the
52```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__ variable. This 52:term:`KMACHINE` variable. This
53variable is typically set to the same value as the ``MACHINE`` variable, 53variable is typically set to the same value as the ``MACHINE`` variable,
54which is used by `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__. 54which is used by :term:`BitBake`.
55However, in some cases, the variable might instead refer to the 55However, in some cases, the variable might instead refer to the
56underlying platform of the ``MACHINE``. 56underlying platform of the ``MACHINE``.
57 57
@@ -65,7 +65,7 @@ Descriptions <#bsp-descriptions>`__ section for more information.
65 65
66Every linux-yocto style recipe must also indicate the Linux kernel 66Every linux-yocto style recipe must also indicate the Linux kernel
67source repository branch used to build the Linux kernel. The 67source repository branch used to build the Linux kernel. The
68```KBRANCH`` <&YOCTO_DOCS_REF_URL;#var-KBRANCH>`__ variable must be set 68:term:`KBRANCH` variable must be set
69to indicate the branch. 69to indicate the branch.
70 70
71.. note:: 71.. note::
@@ -84,7 +84,7 @@ to indicate the branch.
84The linux-yocto style recipes can optionally define the following 84The linux-yocto style recipes can optionally define the following
85variables: KERNEL_FEATURES LINUX_KERNEL_TYPE 85variables: KERNEL_FEATURES LINUX_KERNEL_TYPE
86 86
87```LINUX_KERNEL_TYPE`` <&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE>`__ 87:term:`LINUX_KERNEL_TYPE`
88defines the kernel type to be used in assembling the configuration. If 88defines the kernel type to be used in assembling the configuration. If
89you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard". 89you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard".
90Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search 90Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search
@@ -103,10 +103,10 @@ a match, they issue a warning.
103The tools first search for the ``KMACHINE`` and then for the 103The tools first search for the ``KMACHINE`` and then for the
104``LINUX_KERNEL_TYPE``. If the tools cannot find a partial match, they 104``LINUX_KERNEL_TYPE``. If the tools cannot find a partial match, they
105will use the sources from the ``KBRANCH`` and any configuration 105will use the sources from the ``KBRANCH`` and any configuration
106specified in the ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__. 106specified in the :term:`SRC_URI`.
107 107
108You can use the 108You can use the
109```KERNEL_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES>`__ 109:term:`KERNEL_FEATURES`
110variable to include features (configuration fragments, patches, or both) 110variable to include features (configuration fragments, patches, or both)
111that are not already included by the ``KMACHINE`` and 111that are not already included by the ``KMACHINE`` and
112``LINUX_KERNEL_TYPE`` variable combination. For example, to include a 112``LINUX_KERNEL_TYPE`` variable combination. For example, to include a
@@ -185,7 +185,7 @@ contain "features" as far as the kernel tools are concerned.
185 185
186Paths used in kernel Metadata files are relative to base, which is 186Paths used in kernel Metadata files are relative to base, which is
187either 187either
188```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ if 188:term:`FILESEXTRAPATHS` if
189you are creating Metadata in `recipe-space <#recipe-space-metadata>`__, 189you are creating Metadata in `recipe-space <#recipe-space-metadata>`__,
190or the top level of 190or the top level of
191```yocto-kernel-cache`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache/tree/>`__ 191```yocto-kernel-cache`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache/tree/>`__
@@ -218,7 +218,7 @@ fragment files in the "`Creating Configuration
218Fragments <#creating-config-fragments>`__" section. 218Fragments <#creating-config-fragments>`__" section.
219 219
220Within the ``smp.scc`` file, the 220Within the ``smp.scc`` file, the
221```KFEATURE_DESCRIPTION`` <&YOCTO_DOCS_REF_URL;#var-KFEATURE_DESCRIPTION>`__ 221:term:`KFEATURE_DESCRIPTION`
222statement provides a short description of the fragment. Higher level 222statement provides a short description of the fragment. Higher level
223kernel tools use this description. 223kernel tools use this description.
224 224
@@ -312,7 +312,7 @@ non-hardware configuration fragments with patches you want to use when
312building a Linux kernel of a specific type (e.g. a real-time kernel). 312building a Linux kernel of a specific type (e.g. a real-time kernel).
313Syntactically, kernel types are no different than features as described 313Syntactically, kernel types are no different than features as described
314in the "`Features <#features>`__" section. The 314in the "`Features <#features>`__" section. The
315```LINUX_KERNEL_TYPE`` <&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE>`__ 315:term:`LINUX_KERNEL_TYPE`
316variable in the kernel recipe selects the kernel type. For example, in 316variable in the kernel recipe selects the kernel type. For example, in
317the ``linux-yocto_4.12.bb`` kernel recipe found in 317the ``linux-yocto_4.12.bb`` kernel recipe found in
318``poky/meta/recipes-kernel/linux``, a 318``poky/meta/recipes-kernel/linux``, a
@@ -432,9 +432,9 @@ ktypes/standard/standard.scc branch beaglebone include beaglebone.scc #
432default policy for standard kernels include 432default policy for standard kernels include
433features/latencytop/latencytop.scc include 433features/latencytop/latencytop.scc include
434features/profiling/profiling.scc Every top-level BSP description file 434features/profiling/profiling.scc Every top-level BSP description file
435should define the ```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__, 435should define the :term:`KMACHINE`,
436```KTYPE`` <&YOCTO_DOCS_REF_URL;#var-KTYPE>`__, and 436:term:`KTYPE`, and
437```KARCH`` <&YOCTO_DOCS_REF_URL;#var-KARCH>`__ variables. These 437:term:`KARCH` variables. These
438variables allow the OpenEmbedded build system to identify the 438variables allow the OpenEmbedded build system to identify the
439description as meeting the criteria set by the recipe being built. This 439description as meeting the criteria set by the recipe being built. This
440example supports the "beaglebone" machine for the "standard" kernel and 440example supports the "beaglebone" machine for the "standard" kernel and
@@ -444,7 +444,7 @@ Be aware that a hard link between the ``KTYPE`` variable and a kernel
444type description file does not exist. Thus, if you do not have the 444type description file does not exist. Thus, if you do not have the
445kernel type defined in your kernel Metadata as it is here, you only need 445kernel type defined in your kernel Metadata as it is here, you only need
446to ensure that the 446to ensure that the
447```LINUX_KERNEL_TYPE`` <&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE>`__ 447:term:`LINUX_KERNEL_TYPE`
448variable in the kernel recipe and the ``KTYPE`` variable in the BSP 448variable in the kernel recipe and the ``KTYPE`` variable in the BSP
449description file match. 449description file match.
450 450
@@ -529,9 +529,9 @@ with the most basic functionality of the system as defined in the base
529"minnow" description file. 529"minnow" description file.
530 530
531Notice again the three critical variables: 531Notice again the three critical variables:
532```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__, 532:term:`KMACHINE`,
533```KTYPE`` <&YOCTO_DOCS_REF_URL;#var-KTYPE>`__, and 533:term:`KTYPE`, and
534```KARCH`` <&YOCTO_DOCS_REF_URL;#var-KARCH>`__. Of these variables, only 534:term:`KARCH`. Of these variables, only
535``KTYPE`` has changed to specify the "tiny" kernel type. 535``KTYPE`` has changed to specify the "tiny" kernel type.
536 536
537Kernel Metadata Location 537Kernel Metadata Location
@@ -564,12 +564,12 @@ Recipe-Space Metadata
564 564
565When stored in recipe-space, the kernel Metadata files reside in a 565When stored in recipe-space, the kernel Metadata files reside in a
566directory hierarchy below 566directory hierarchy below
567```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__. For 567:term:`FILESEXTRAPATHS`. For
568a linux-yocto recipe or for a Linux kernel recipe derived by copying and 568a linux-yocto recipe or for a Linux kernel recipe derived by copying and
569modifying 569modifying
570``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to 570``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
571a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to 571a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to
572``${``\ ```THISDIR`` <&YOCTO_DOCS_REF_URL;#var-THISDIR>`__\ ``}/${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}``. 572``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
573See the "`Modifying an Existing 573See the "`Modifying an Existing
574Recipe <#modifying-an-existing-recipe>`__" section for more information. 574Recipe <#modifying-an-existing-recipe>`__" section for more information.
575 575
@@ -582,10 +582,10 @@ When the Metadata is stored in recipe-space, you must take steps to
582ensure BitBake has the necessary information to decide what files to 582ensure BitBake has the necessary information to decide what files to
583fetch and when they need to be fetched again. It is only necessary to 583fetch and when they need to be fetched again. It is only necessary to
584specify the ``.scc`` files on the 584specify the ``.scc`` files on the
585```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__. BitBake parses them 585:term:`SRC_URI`. BitBake parses them
586and fetches any files referenced in the ``.scc`` files by the 586and fetches any files referenced in the ``.scc`` files by the
587``include``, ``patch``, or ``kconf`` commands. Because of this, it is 587``include``, ``patch``, or ``kconf`` commands. Because of this, it is
588necessary to bump the recipe ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__ 588necessary to bump the recipe :term:`PR`
589value when changing the content of files not explicitly listed in the 589value when changing the content of files not explicitly listed in the
590``SRC_URI``. 590``SRC_URI``.
591 591
@@ -600,7 +600,7 @@ Metadata Outside the Recipe-Space
600When stored outside of the recipe-space, the kernel Metadata files 600When stored outside of the recipe-space, the kernel Metadata files
601reside in a separate repository. The OpenEmbedded build system adds the 601reside in a separate repository. The OpenEmbedded build system adds the
602Metadata to the build as a "type=kmeta" repository through the 602Metadata to the build as a "type=kmeta" repository through the
603```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ variable. As an 603:term:`SRC_URI` variable. As an
604example, consider the following ``SRC_URI`` statement from the 604example, consider the following ``SRC_URI`` statement from the
605``linux-yocto_4.12.bb`` kernel recipe: SRC_URI = 605``linux-yocto_4.12.bb`` kernel recipe: SRC_URI =
606"git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; 606"git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH};
@@ -742,10 +742,10 @@ within an SCC description file (``.scc``):
742 "ref" if specified. 742 "ref" if specified.
743 743
744- ``define``: Defines variables, such as 744- ``define``: Defines variables, such as
745 ```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__, 745 :term:`KMACHINE`,
746 ```KTYPE`` <&YOCTO_DOCS_REF_URL;#var-KTYPE>`__, 746 :term:`KTYPE`,
747 ```KARCH`` <&YOCTO_DOCS_REF_URL;#var-KARCH>`__, and 747 :term:`KARCH`, and
748 ```KFEATURE_DESCRIPTION`` <&YOCTO_DOCS_REF_URL;#var-KFEATURE_DESCRIPTION>`__. 748 :term:`KFEATURE_DESCRIPTION`.
749 749
750- ``include SCC_FILE``: Includes an SCC file in the current file. The 750- ``include SCC_FILE``: Includes an SCC file in the current file. The
751 file is parsed as if you had inserted it inline. 751 file is parsed as if you had inserted it inline.
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst
index 085c6d396c..b5f794e733 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/kernel-dev-common.rst
@@ -72,7 +72,7 @@ section:
72 "poky". 72 "poky".
73 73
742. *Prepare Your ``local.conf`` File:* By default, the 742. *Prepare Your ``local.conf`` File:* By default, the
75 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable is set to 75 :term:`MACHINE` variable is set to
76 "qemux86-64", which is fine if you are building for the QEMU emulator 76 "qemux86-64", which is fine if you are building for the QEMU emulator
77 in 64-bit mode. However, if you are not, you need to set the 77 in 64-bit mode. However, if you are not, you need to set the
78 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file 78 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file
@@ -82,7 +82,7 @@ section:
82 82
83 Also, since you are preparing to work on the kernel image, you need 83 Also, since you are preparing to work on the kernel image, you need
84 to set the 84 to set the
85 ```MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS>`__ 85 :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
86 variable to include kernel modules. 86 variable to include kernel modules.
87 87
88 In this example we wish to build for qemux86 so we must set the 88 In this example we wish to build for qemux86 so we must set the
@@ -115,7 +115,7 @@ section:
115 115
1164. *Inform the BitBake Build Environment About Your Layer:* As directed 1164. *Inform the BitBake Build Environment About Your Layer:* As directed
117 when you created your layer, you need to add the layer to the 117 when you created your layer, you need to add the layer to the
118 ```BBLAYERS`` <&YOCTO_DOCS_REF_URL;#var-BBLAYERS>`__ variable in the 118 :term:`BBLAYERS` variable in the
119 ``bblayers.conf`` file as follows: $ cd ~/poky/build $ bitbake-layers 119 ``bblayers.conf`` file as follows: $ cd ~/poky/build $ bitbake-layers
120 add-layer ../../meta-mylayer NOTE: Starting bitbake server... $ 120 add-layer ../../meta-mylayer NOTE: Starting bitbake server... $
121 121
@@ -236,7 +236,7 @@ section:
236 "poky". 236 "poky".
237 237
2382. *Prepare Your ``local.conf`` File:* By default, the 2382. *Prepare Your ``local.conf`` File:* By default, the
239 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable is set to 239 :term:`MACHINE` variable is set to
240 "qemux86-64", which is fine if you are building for the QEMU emulator 240 "qemux86-64", which is fine if you are building for the QEMU emulator
241 in 64-bit mode. However, if you are not, you need to set the 241 in 64-bit mode. However, if you are not, you need to set the
242 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file 242 ``MACHINE`` variable appropriately in your ``conf/local.conf`` file
@@ -246,7 +246,7 @@ section:
246 246
247 Also, since you are preparing to work on the kernel image, you need 247 Also, since you are preparing to work on the kernel image, you need
248 to set the 248 to set the
249 ```MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS>`__ 249 :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
250 variable to include kernel modules. 250 variable to include kernel modules.
251 251
252 In this example we wish to build for qemux86 so we must set the 252 In this example we wish to build for qemux86 so we must set the
@@ -279,7 +279,7 @@ section:
279 279
2804. *Inform the BitBake Build Environment About Your Layer:* As directed 2804. *Inform the BitBake Build Environment About Your Layer:* As directed
281 when you created your layer, you need to add the layer to the 281 when you created your layer, you need to add the layer to the
282 ```BBLAYERS`` <&YOCTO_DOCS_REF_URL;#var-BBLAYERS>`__ variable in the 282 :term:`BBLAYERS` variable in the
283 ``bblayers.conf`` file as follows: $ cd ~/poky/build $ bitbake-layers 283 ``bblayers.conf`` file as follows: $ cd ~/poky/build $ bitbake-layers
284 add-layer ../../meta-mylayer NOTE: Starting bitbake server ... $ 284 add-layer ../../meta-mylayer NOTE: Starting bitbake server ... $
285 285
@@ -343,7 +343,7 @@ Creating and Preparing a Layer
343 343
344If you are going to be modifying kernel recipes, it is recommended that 344If you are going to be modifying kernel recipes, it is recommended that
345you create and prepare your own layer in which to do your work. Your 345you create and prepare your own layer in which to do your work. Your
346layer contains its own `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ 346layer contains its own :term:`BitBake`
347append files (``.bbappend``) and provides a convenient mechanism to 347append files (``.bbappend``) and provides a convenient mechanism to
348create your own recipe files (``.bb``) as well as store and use kernel 348create your own recipe files (``.bb``) as well as store and use kernel
349patch files. For background information on working with layers, see the 349patch files. For background information on working with layers, see the
@@ -393,8 +393,8 @@ home directory:
393 "${THISDIR}/${PN}:" SRC_URI_append = " file://patch-file-one" 393 "${THISDIR}/${PN}:" SRC_URI_append = " file://patch-file-one"
394 SRC_URI_append = " file://patch-file-two" SRC_URI_append = " 394 SRC_URI_append = " file://patch-file-two" SRC_URI_append = "
395 file://patch-file-three" The 395 file://patch-file-three" The
396 ```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 396 :term:`FILESEXTRAPATHS`
397 and ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements 397 and :term:`SRC_URI` statements
398 enable the OpenEmbedded build system to find patch files. For more 398 enable the OpenEmbedded build system to find patch files. For more
399 information on using append files, see the "`Using .bbappend Files in 399 information on using append files, see the "`Using .bbappend Files in
400 Your Layer <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in 400 Your Layer <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in
@@ -406,7 +406,7 @@ Modifying an Existing Recipe
406In many cases, you can customize an existing linux-yocto recipe to meet 406In many cases, you can customize an existing linux-yocto recipe to meet
407the needs of your project. Each release of the Yocto Project provides a 407the needs of your project. Each release of the Yocto Project provides a
408few Linux kernel recipes from which you can choose. These are located in 408few Linux kernel recipes from which you can choose. These are located in
409the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in 409the :term:`Source Directory` in
410``meta/recipes-kernel/linux``. 410``meta/recipes-kernel/linux``.
411 411
412Modifying an existing recipe can consist of the following: 412Modifying an existing recipe can consist of the following:
@@ -431,12 +431,12 @@ modifying the ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` recipe,
431the append file will typically be located as follows within your custom 431the append file will typically be located as follows within your custom
432layer: your-layer/recipes-kernel/linux/linux-yocto_4.12.bbappend The 432layer: your-layer/recipes-kernel/linux/linux-yocto_4.12.bbappend The
433append file should initially extend the 433append file should initially extend the
434```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ search path by 434:term:`FILESPATH` search path by
435prepending the directory that contains your files to the 435prepending the directory that contains your files to the
436```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 436:term:`FILESEXTRAPATHS`
437variable as follows: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" The 437variable as follows: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" The
438path 438path
439``${``\ ```THISDIR`` <&YOCTO_DOCS_REF_URL;#var-THISDIR>`__\ ``}/${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}`` 439``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
440expands to "linux-yocto" in the current directory for this example. If 440expands to "linux-yocto" in the current directory for this example. If
441you add any new files that modify the kernel recipe and you have 441you add any new files that modify the kernel recipe and you have
442extended ``FILESPATH`` as described above, you must place the files in 442extended ``FILESPATH`` as described above, you must place the files in
@@ -472,16 +472,16 @@ COMPATIBLE_MACHINE_beaglebone = "beaglebone" LINUX_VERSION_genericx86 =
472= "4.12.10" LINUX_VERSION_beaglebone = "4.12.10" This append file 472= "4.12.10" LINUX_VERSION_beaglebone = "4.12.10" This append file
473contains statements used to support several BSPs that ship with the 473contains statements used to support several BSPs that ship with the
474Yocto Project. The file defines machines using the 474Yocto Project. The file defines machines using the
475```COMPATIBLE_MACHINE`` <&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE>`__ 475:term:`COMPATIBLE_MACHINE`
476variable and uses the 476variable and uses the
477```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__ variable to ensure 477:term:`KMACHINE` variable to ensure
478the machine name used by the OpenEmbedded build system maps to the 478the machine name used by the OpenEmbedded build system maps to the
479machine name used by the Linux Yocto kernel. The file also uses the 479machine name used by the Linux Yocto kernel. The file also uses the
480optional ```KBRANCH`` <&YOCTO_DOCS_REF_URL;#var-KBRANCH>`__ variable to 480optional :term:`KBRANCH` variable to
481ensure the build process uses the appropriate kernel branch. 481ensure the build process uses the appropriate kernel branch.
482 482
483Although this particular example does not use it, the 483Although this particular example does not use it, the
484```KERNEL_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES>`__ 484:term:`KERNEL_FEATURES`
485variable could be used to enable features specific to the kernel. The 485variable could be used to enable features specific to the kernel. The
486append file points to specific commits in the `Source 486append file points to specific commits in the `Source
487Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ Git repository and 487Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ Git repository and
@@ -497,7 +497,7 @@ accomplish this definition by putting the configurations in a file or a
497set of files inside a directory located at the same level as your 497set of files inside a directory located at the same level as your
498kernel's append file and having the same name as the kernel's main 498kernel's append file and having the same name as the kernel's main
499recipe file. With all these conditions met, simply reference those files 499recipe file. With all these conditions met, simply reference those files
500in the ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statement in 500in the :term:`SRC_URI` statement in
501the append file. 501the append file.
502 502
503For example, suppose you had some configuration options in a file called 503For example, suppose you had some configuration options in a file called
@@ -515,7 +515,7 @@ the following in your append file: SRC_URI += "file://myconfig.cfg \\
515file://eth.cfg \\ file://gfx.cfg" 515file://eth.cfg \\ file://gfx.cfg"
516 516
517Another variable you can use in your kernel recipe append file is the 517Another variable you can use in your kernel recipe append file is the
518```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 518:term:`FILESEXTRAPATHS`
519variable. When you use this statement, you are extending the locations 519variable. When you use this statement, you are extending the locations
520used by the OpenEmbedded system to look for files and patches as the 520used by the OpenEmbedded system to look for files and patches as the
521recipe is processed. 521recipe is processed.
@@ -546,9 +546,9 @@ Applying Patches
546If you have a single patch or a small series of patches that you want to 546If you have a single patch or a small series of patches that you want to
547apply to the Linux kernel source, you can do so just as you would with 547apply to the Linux kernel source, you can do so just as you would with
548any other recipe. You first copy the patches to the path added to 548any other recipe. You first copy the patches to the path added to
549```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ in 549:term:`FILESEXTRAPATHS` in
550your ``.bbappend`` file as described in the previous section, and then 550your ``.bbappend`` file as described in the previous section, and then
551reference them in ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ 551reference them in :term:`SRC_URI`
552statements. 552statements.
553 553
554For example, you can apply a three-patch series by adding the following 554For example, you can apply a three-patch series by adding the following
@@ -572,7 +572,7 @@ Changing the Configuration
572You can make wholesale or incremental changes to the final ``.config`` 572You can make wholesale or incremental changes to the final ``.config``
573file used for the eventual Linux kernel configuration by including a 573file used for the eventual Linux kernel configuration by including a
574``defconfig`` file and by specifying configuration fragments in the 574``defconfig`` file and by specifying configuration fragments in the
575```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ to be applied to that 575:term:`SRC_URI` to be applied to that
576file. 576file.
577 577
578If you have a complete, working Linux kernel ``.config`` file you want 578If you have a complete, working Linux kernel ``.config`` file you want
@@ -583,8 +583,8 @@ following lines to the linux-yocto ``.bbappend`` file in your layer:
583FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += 583FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI +=
584"file://defconfig" The ``SRC_URI`` tells the build system how to search 584"file://defconfig" The ``SRC_URI`` tells the build system how to search
585for the file, while the 585for the file, while the
586```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 586:term:`FILESEXTRAPATHS`
587extends the ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ 587extends the :term:`FILESPATH`
588variable (search directories) to include the ``${PN}`` directory you 588variable (search directories) to include the ``${PN}`` directory you
589created to hold the configuration changes. 589created to hold the configuration changes.
590 590
@@ -631,7 +631,7 @@ looks for ``defconfig`` files in the layer used for Metadata, which is
631``defconfig`` files in your layer but would rather allow users to use 631``defconfig`` files in your layer but would rather allow users to use
632the default configuration from the kernel tree and still be able to add 632the default configuration from the kernel tree and still be able to add
633configuration fragments to the 633configuration fragments to the
634```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ through, for example, 634:term:`SRC_URI` through, for example,
635append files, you can direct the OpenEmbedded build system to use a 635append files, you can direct the OpenEmbedded build system to use a
636``defconfig`` file that is "in-tree". 636``defconfig`` file that is "in-tree".
637 637
@@ -651,7 +651,7 @@ build system detects a statement that identifies an "out-of-tree"
651``KBUILD_DEFCONFIG`` variable. 651``KBUILD_DEFCONFIG`` variable.
652 652
653See the 653See the
654```KBUILD_DEFCONFIG`` <&YOCTO_DOCS_REF_URL;#var-KBUILD_DEFCONFIG>`__ 654:term:`KBUILD_DEFCONFIG`
655variable description for more information. 655variable description for more information.
656 656
657Using ``devtool`` to Patch the Kernel 657Using ``devtool`` to Patch the Kernel
@@ -844,8 +844,8 @@ Section.
844 addition to your ``local.conf`` file specifying to use 844 addition to your ``local.conf`` file specifying to use
845 "kernel-modules" and the "qemux86" machine, it must also point to the 845 "kernel-modules" and the "qemux86" machine, it must also point to the
846 updated kernel source files. Add 846 updated kernel source files. Add
847 ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ and 847 :term:`SRC_URI` and
848 ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__ statements similar 848 :term:`SRCREV` statements similar
849 to the following to your ``local.conf``: $ cd ~/poky/build/conf Add 849 to the following to your ``local.conf``: $ cd ~/poky/build/conf Add
850 the following to the ``local.conf``: SRC_URI_pn-linux-yocto = 850 the following to the ``local.conf``: SRC_URI_pn-linux-yocto =
851 "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; 851 "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base;
@@ -907,8 +907,8 @@ Section.
907 contents: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 907 contents: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
908 SRC_URI_append = " 908 SRC_URI_append = "
909 file://0001-calibrate.c-Added-some-printk-statements.patch" The 909 file://0001-calibrate.c-Added-some-printk-statements.patch" The
910 ```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 910 :term:`FILESEXTRAPATHS`
911 and ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements 911 and :term:`SRC_URI` statements
912 enable the OpenEmbedded build system to find the patch file. 912 enable the OpenEmbedded build system to find the patch file.
913 913
914 For more information on append files and patches, see the "`Creating 914 For more information on append files and patches, see the "`Creating
@@ -968,16 +968,16 @@ environment, you must do the following:
968- Because you launch ``menuconfig`` using BitBake, you must be sure to 968- Because you launch ``menuconfig`` using BitBake, you must be sure to
969 set up your environment by running the 969 set up your environment by running the
970 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ script found in 970 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ script found in
971 the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 971 the :term:`Build Directory`.
972 972
973- You must be sure of the state of your build's configuration in the 973- You must be sure of the state of your build's configuration in the
974 `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. 974 :term:`Source Directory`.
975 975
976- Your build host must have the following two packages installed: 976- Your build host must have the following two packages installed:
977 libncurses5-dev libtinfo-dev 977 libncurses5-dev libtinfo-dev
978 978
979The following commands initialize the BitBake environment, run the 979The following commands initialize the BitBake environment, run the
980```do_kernel_configme`` <&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configme>`__ 980:ref:`ref-tasks-kernel_configme`
981task, and launch ``menuconfig``. These commands assume the Source 981task, and launch ``menuconfig``. These commands assume the Source
982Directory's top-level folder is ``~/poky``: $ cd poky $ source 982Directory's top-level folder is ``~/poky``: $ cd poky $ source
983oe-init-build-env $ bitbake linux-yocto -c kernel_configme -f $ bitbake 983oe-init-build-env $ bitbake linux-yocto -c kernel_configme -f $ bitbake
@@ -1089,17 +1089,17 @@ which the OpenEmbedded build system can draw to create the final
1089 1089
1090To create a ``defconfig``, start with a complete, working Linux kernel 1090To create a ``defconfig``, start with a complete, working Linux kernel
1091``.config`` file. Copy that file to the appropriate 1091``.config`` file. Copy that file to the appropriate
1092``${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}`` directory in 1092``${``\ :term:`PN`\ ``}`` directory in
1093your layer's ``recipes-kernel/linux`` directory, and rename the copied 1093your layer's ``recipes-kernel/linux`` directory, and rename the copied
1094file to "defconfig" (e.g. 1094file to "defconfig" (e.g.
1095``~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig``). Then, 1095``~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig``). Then,
1096add the following lines to the linux-yocto ``.bbappend`` file in your 1096add the following lines to the linux-yocto ``.bbappend`` file in your
1097layer: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += 1097layer: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI +=
1098"file://defconfig" The 1098"file://defconfig" The
1099```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ tells the build 1099:term:`SRC_URI` tells the build
1100system how to search for the file, while the 1100system how to search for the file, while the
1101```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__ 1101:term:`FILESEXTRAPATHS`
1102extends the ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ 1102extends the :term:`FILESPATH`
1103variable (search directories) to include the ``${PN}`` directory you 1103variable (search directories) to include the ``${PN}`` directory you
1104created to hold the configuration changes. 1104created to hold the configuration changes.
1105 1105
@@ -1179,7 +1179,7 @@ steps:
11793. *Create the Configuration Fragment:* Run the ``diffconfig`` command 11793. *Create the Configuration Fragment:* Run the ``diffconfig`` command
1180 to prepare a configuration fragment. The resulting file 1180 to prepare a configuration fragment. The resulting file
1181 ``fragment.cfg`` is placed in the 1181 ``fragment.cfg`` is placed in the
1182 ``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}`` 1182 ``${``\ :term:`WORKDIR`\ ``}``
1183 directory: $ bitbake linux-yocto -c diffconfig 1183 directory: $ bitbake linux-yocto -c diffconfig
1184 1184
1185The ``diffconfig`` command creates a file that is a list of Linux kernel 1185The ``diffconfig`` command creates a file that is a list of Linux kernel
@@ -1196,7 +1196,7 @@ information on how to use the output as a configuration fragment.
1196 1196
1197Where do you put your configuration fragment files? You can place these 1197Where do you put your configuration fragment files? You can place these
1198files in an area pointed to by 1198files in an area pointed to by
1199```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ as directed by your 1199:term:`SRC_URI` as directed by your
1200``bblayers.conf`` file, which is located in your layer. The OpenEmbedded 1200``bblayers.conf`` file, which is located in your layer. The OpenEmbedded
1201build system picks up the configuration and adds it to the kernel's 1201build system picks up the configuration and adds it to the kernel's
1202configuration. For example, suppose you had a set of configuration 1202configuration. For example, suppose you had a set of configuration
@@ -1219,7 +1219,7 @@ Validating Configuration
1219------------------------ 1219------------------------
1220 1220
1221You can use the 1221You can use the
1222```do_kernel_configcheck`` <&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configcheck>`__ 1222:ref:`ref-tasks-kernel_configcheck`
1223task to provide configuration validation: $ bitbake linux-yocto -c 1223task to provide configuration validation: $ bitbake linux-yocto -c
1224kernel_configcheck -f Running this task produces warnings for when a 1224kernel_configcheck -f Running this task produces warnings for when a
1225requested configuration does not appear in the final ``.config`` file or 1225requested configuration does not appear in the final ``.config`` file or
@@ -1268,9 +1268,9 @@ The output describes the various problems that you can encounter along
1268with where to find the offending configuration items. You can use the 1268with where to find the offending configuration items. You can use the
1269information in the logs to adjust your configuration files and then 1269information in the logs to adjust your configuration files and then
1270repeat the 1270repeat the
1271```do_kernel_configme`` <&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configme>`__ 1271:ref:`ref-tasks-kernel_configme`
1272and 1272and
1273```do_kernel_configcheck`` <&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configcheck>`__ 1273:ref:`ref-tasks-kernel_configcheck`
1274tasks until they produce no warnings. 1274tasks until they produce no warnings.
1275 1275
1276For more information on how to use the ``menuconfig`` tool, see the 1276For more information on how to use the ``menuconfig`` tool, see the
@@ -1395,7 +1395,7 @@ If you cannot work with one of the Linux kernel versions supported by
1395existing linux-yocto recipes, you can still make use of the Yocto 1395existing linux-yocto recipes, you can still make use of the Yocto
1396Project Linux kernel tooling by working with your own sources. When you 1396Project Linux kernel tooling by working with your own sources. When you
1397use your own sources, you will not be able to leverage the existing 1397use your own sources, you will not be able to leverage the existing
1398kernel `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ and stabilization 1398kernel :term:`Metadata` and stabilization
1399work of the linux-yocto sources. However, you will be able to manage 1399work of the linux-yocto sources. However, you will be able to manage
1400your own Metadata in the same format as the linux-yocto sources. 1400your own Metadata in the same format as the linux-yocto sources.
1401Maintaining format compatibility facilitates converging with linux-yocto 1401Maintaining format compatibility facilitates converging with linux-yocto
@@ -1428,7 +1428,7 @@ Here are some basic steps you can use to work with your own sources:
1428 the following: $ make defconfig After running the command, copy the 1428 the following: $ make defconfig After running the command, copy the
1429 resulting ``.config`` file to the ``files`` directory in your layer 1429 resulting ``.config`` file to the ``files`` directory in your layer
1430 as "defconfig" and then add it to the 1430 as "defconfig" and then add it to the
1431 ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ variable in the 1431 :term:`SRC_URI` variable in the
1432 recipe. 1432 recipe.
1433 1433
1434 Running the ``make defconfig`` command results in the default 1434 Running the ``make defconfig`` command results in the default
@@ -1445,7 +1445,7 @@ Here are some basic steps you can use to work with your own sources:
14454. *Edit the Recipe:* Edit the following variables in your recipe as 14454. *Edit the Recipe:* Edit the following variables in your recipe as
1446 appropriate for your project: 1446 appropriate for your project:
1447 1447
1448 - ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__: The 1448 - :term:`SRC_URI`: The
1449 ``SRC_URI`` should specify a Git repository that uses one of the 1449 ``SRC_URI`` should specify a Git repository that uses one of the
1450 supported Git fetcher protocols (i.e. ``file``, ``git``, ``http``, 1450 supported Git fetcher protocols (i.e. ``file``, ``git``, ``http``,
1451 and so forth). The ``SRC_URI`` variable should also specify either 1451 and so forth). The ``SRC_URI`` variable should also specify either
@@ -1453,32 +1453,32 @@ Here are some basic steps you can use to work with your own sources:
1453 skeleton recipe provides an example ``SRC_URI`` as a syntax 1453 skeleton recipe provides an example ``SRC_URI`` as a syntax
1454 reference. 1454 reference.
1455 1455
1456 - ```LINUX_VERSION`` <&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION>`__: 1456 - :term:`LINUX_VERSION`:
1457 The Linux kernel version you are using (e.g. "4.12"). 1457 The Linux kernel version you are using (e.g. "4.12").
1458 1458
1459 - ```LINUX_VERSION_EXTENSION`` <&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION>`__: 1459 - :term:`LINUX_VERSION_EXTENSION`:
1460 The Linux kernel ``CONFIG_LOCALVERSION`` that is compiled into the 1460 The Linux kernel ``CONFIG_LOCALVERSION`` that is compiled into the
1461 resulting kernel and visible through the ``uname`` command. 1461 resulting kernel and visible through the ``uname`` command.
1462 1462
1463 - ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__: The commit ID 1463 - :term:`SRCREV`: The commit ID
1464 from which you want to build. 1464 from which you want to build.
1465 1465
1466 - ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__: Treat this variable the 1466 - :term:`PR`: Treat this variable the
1467 same as you would in any other recipe. Increment the variable to 1467 same as you would in any other recipe. Increment the variable to
1468 indicate to the OpenEmbedded build system that the recipe has 1468 indicate to the OpenEmbedded build system that the recipe has
1469 changed. 1469 changed.
1470 1470
1471 - ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__: The default ``PV`` 1471 - :term:`PV`: The default ``PV``
1472 assignment is typically adequate. It combines the 1472 assignment is typically adequate. It combines the
1473 ``LINUX_VERSION`` with the Source Control Manager (SCM) revision 1473 ``LINUX_VERSION`` with the Source Control Manager (SCM) revision
1474 as derived from the ```SRCPV`` <&YOCTO_DOCS_REF_URL;#var-SRCPV>`__ 1474 as derived from the :term:`SRCPV`
1475 variable. The combined results are a string with the following 1475 variable. The combined results are a string with the following
1476 form: 1476 form:
1477 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 1477 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
1478 While lengthy, the extra verbosity in ``PV`` helps ensure you are 1478 While lengthy, the extra verbosity in ``PV`` helps ensure you are
1479 using the exact sources from which you intend to build. 1479 using the exact sources from which you intend to build.
1480 1480
1481 - ```COMPATIBLE_MACHINE`` <&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE>`__: 1481 - :term:`COMPATIBLE_MACHINE`:
1482 A list of the machines supported by your new recipe. This variable 1482 A list of the machines supported by your new recipe. This variable
1483 in the example recipe is set by default to a regular expression 1483 in the example recipe is set by default to a regular expression
1484 that matches only the empty string, "(^$)". This default setting 1484 that matches only the empty string, "(^$)". This default setting
@@ -1546,13 +1546,13 @@ or other files necessary for building the module that do not come with
1546the sources. Finally, update the recipe as needed for the module. 1546the sources. Finally, update the recipe as needed for the module.
1547Typically, you will need to set the following variables: 1547Typically, you will need to set the following variables:
1548 1548
1549- ```DESCRIPTION`` <&YOCTO_DOCS_REF_URL;#var-DESCRIPTION>`__ 1549- :term:`DESCRIPTION`
1550 1550
1551- ```LICENSE*`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ 1551- ```LICENSE*`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__
1552 1552
1553- ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ 1553- :term:`SRC_URI`
1554 1554
1555- ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__ 1555- :term:`PV`
1556 1556
1557Depending on the build system used by the module sources, you might need 1557Depending on the build system used by the module sources, you might need
1558to make some adjustments. For example, a typical module ``Makefile`` 1558to make some adjustments. For example, a typical module ``Makefile``
@@ -1561,14 +1561,14 @@ looks much like the one provided with the ``hello-mod`` template: obj-m
1561modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install ... 1561modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install ...
1562 1562
1563The important point to note here is the 1563The important point to note here is the
1564```KERNEL_SRC`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_SRC>`__ variable. The 1564:term:`KERNEL_SRC` variable. The
1565```module`` <&YOCTO_DOCS_REF_URL;#ref-classes-module>`__ class sets this 1565:ref:`module <ref-classes-module>` class sets this
1566variable and the 1566variable and the
1567```KERNEL_PATH`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_PATH>`__ variable to 1567:term:`KERNEL_PATH` variable to
1568``${STAGING_KERNEL_DIR}`` with the necessary Linux kernel build 1568``${STAGING_KERNEL_DIR}`` with the necessary Linux kernel build
1569information to build modules. If your module ``Makefile`` uses a 1569information to build modules. If your module ``Makefile`` uses a
1570different variable, you might want to override the 1570different variable, you might want to override the
1571```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__ step, or 1571:ref:`ref-tasks-compile` step, or
1572create a patch to the ``Makefile`` to work with the more typical 1572create a patch to the ``Makefile`` to work with the more typical
1573``KERNEL_SRC`` or ``KERNEL_PATH`` variables. 1573``KERNEL_SRC`` or ``KERNEL_PATH`` variables.
1574 1574
@@ -1577,13 +1577,13 @@ module in your images. To do this, see the documentation for the
1577following variables in the Yocto Project Reference Manual and set one of 1577following variables in the Yocto Project Reference Manual and set one of
1578them appropriately for your machine configuration file: 1578them appropriately for your machine configuration file:
1579 1579
1580- ```MACHINE_ESSENTIAL_EXTRA_RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS>`__ 1580- :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
1581 1581
1582- ```MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS>`__ 1582- :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
1583 1583
1584- ```MACHINE_EXTRA_RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RDEPENDS>`__ 1584- :term:`MACHINE_EXTRA_RDEPENDS`
1585 1585
1586- ```MACHINE_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS>`__ 1586- :term:`MACHINE_EXTRA_RRECOMMENDS`
1587 1587
1588Modules are often not required for boot and can be excluded from certain 1588Modules are often not required for boot and can be excluded from certain
1589build configurations. The following allows for the most flexibility: 1589build configurations. The following allows for the most flexibility:
@@ -1592,8 +1592,8 @@ derived by appending the module filename without the ``.ko`` extension
1592to the string "kernel-module-". 1592to the string "kernel-module-".
1593 1593
1594Because the variable is 1594Because the variable is
1595```RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS>`__ and not a 1595:term:`RRECOMMENDS` and not a
1596```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__ variable, the build 1596:term:`RDEPENDS` variable, the build
1597will not fail if this module is not available to include in the image. 1597will not fail if this module is not available to include in the image.
1598 1598
1599Inspecting Changes and Commits 1599Inspecting Changes and Commits
@@ -1661,9 +1661,9 @@ Adding Recipe-Space Kernel Features
1661 1661
1662You can add kernel features in the 1662You can add kernel features in the
1663`recipe-space <#recipe-space-metadata>`__ by using the 1663`recipe-space <#recipe-space-metadata>`__ by using the
1664```KERNEL_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES>`__ 1664:term:`KERNEL_FEATURES`
1665variable and by specifying the feature's ``.scc`` file path in the 1665variable and by specifying the feature's ``.scc`` file path in the
1666```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statement. When you 1666:term:`SRC_URI` statement. When you
1667add features using this method, the OpenEmbedded build system checks to 1667add features using this method, the OpenEmbedded build system checks to
1668be sure the features are present. If the features are not present, the 1668be sure the features are present. If the features are not present, the
1669build stops. Kernel features are the last elements processed for 1669build stops. Kernel features are the last elements processed for
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
index f3349a6be4..ed1486b65d 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
@@ -313,7 +313,7 @@ The temporary kernel source files resulting from a build using BitBake
313have a particular hierarchy. When you build the kernel on your 313have a particular hierarchy. When you build the kernel on your
314development system, all files needed for the build are taken from the 314development system, all files needed for the build are taken from the
315source repositories pointed to by the 315source repositories pointed to by the
316```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ variable and gathered 316:term:`SRC_URI` variable and gathered
317in a temporary work area where they are subsequently used to create the 317in a temporary work area where they are subsequently used to create the
318unique kernel. Thus, in a sense, the process constructs a local source 318unique kernel. Thus, in a sense, the process constructs a local source
319tree specific to your kernel from which to generate the new kernel 319tree specific to your kernel from which to generate the new kernel
diff --git a/documentation/kernel-dev/kernel-dev-faq.rst b/documentation/kernel-dev/kernel-dev-faq.rst
index 9ae93506e9..fd9f8ce33d 100644
--- a/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/documentation/kernel-dev/kernel-dev-faq.rst
@@ -28,12 +28,12 @@ append file to override metadata. How do I install a specific kernel
28module? Linux kernel modules are packaged individually. To ensure a 28module? Linux kernel modules are packaged individually. To ensure a
29specific kernel module is included in an image, include it in the 29specific kernel module is included in an image, include it in the
30appropriate machine 30appropriate machine
31```RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS>`__ variable. 31:term:`RRECOMMENDS` variable.
32These other variables are useful for installing specific modules: 32These other variables are useful for installing specific modules:
33```MACHINE_ESSENTIAL_EXTRA_RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS>`__ 33:term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
34```MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS>`__ 34:term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
35```MACHINE_EXTRA_RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RDEPENDS>`__ 35:term:`MACHINE_EXTRA_RDEPENDS`
36```MACHINE_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS>`__ 36:term:`MACHINE_EXTRA_RRECOMMENDS`
37For example, set the following in the ``qemux86.conf`` file to include 37For example, set the following in the ``qemux86.conf`` file to include
38the ``ab123`` kernel modules with images built for the ``qemux86`` 38the ``ab123`` kernel modules with images built for the ``qemux86``
39machine: MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123" For more 39machine: MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123" For more
diff --git a/documentation/kernel-dev/kernel-dev-intro.rst b/documentation/kernel-dev/kernel-dev-intro.rst
index 82a77913b7..cb4ffcf13b 100644
--- a/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/documentation/kernel-dev/kernel-dev-intro.rst
@@ -13,7 +13,7 @@ Regardless of how you intend to make use of the Yocto Project, chances
13are you will work with the Linux kernel. This manual describes how to 13are you will work with the Linux kernel. This manual describes how to
14set up your build host to support kernel development, introduces the 14set up your build host to support kernel development, introduces the
15kernel development process, provides background information on the Yocto 15kernel development process, provides background information on the Yocto
16Linux kernel `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__, describes 16Linux kernel :term:`Metadata`, describes
17common tasks you can perform using the kernel tools, shows you how to 17common tasks you can perform using the kernel tools, shows you how to
18use the kernel Metadata needed to work with the kernel inside the Yocto 18use the kernel Metadata needed to work with the kernel inside the Yocto
19Project, and provides insight into how the Yocto Project team develops 19Project, and provides insight into how the Yocto Project team develops
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.rst b/documentation/kernel-dev/kernel-dev-maint-appx.rst
index b4e5f199c9..d76e789d56 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.rst
@@ -111,7 +111,7 @@ patch, or BSP:
111 111
1124. *Append Extra Features:* Extra features are appended to the top-level 1124. *Append Extra Features:* Extra features are appended to the top-level
113 feature description. These features can come from the 113 feature description. These features can come from the
114 ```KERNEL_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES>`__ 114 :term:`KERNEL_FEATURES`
115 variable in recipes. 115 variable in recipes.
116 116
1175. *Locate, Expand, and Append Each Feature:* Each extra feature is 1175. *Locate, Expand, and Append Each Feature:* Each extra feature is
@@ -172,7 +172,7 @@ can consider the compilation phase of kernel development, which is
172building a kernel image. Some prerequisites exist that are validated by 172building a kernel image. Some prerequisites exist that are validated by
173the build process before compilation starts: 173the build process before compilation starts:
174 174
175- The ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ points to the 175- The :term:`SRC_URI` points to the
176 kernel Git repository. 176 kernel Git repository.
177 177
178- A BSP build branch with Metadata exists in the ``yocto-kernel-cache`` 178- A BSP build branch with Metadata exists in the ``yocto-kernel-cache``
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index 3f4aa4f4c4..59096fbebf 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -14,9 +14,9 @@ explained.
14Yocto Project Components 14Yocto Project Components
15======================== 15========================
16 16
17The `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ task executor 17The :term:`BitBake` task executor
18together with various types of configuration files form the 18together with various types of configuration files form the
19`OpenEmbedded-Core <&YOCTO_DOCS_REF_URL;#oe-core>`__. This section 19:term:`OpenEmbedded-Core (OE-Core)`. This section
20overviews these components by describing their use and how they 20overviews these components by describing their use and how they
21interact. 21interact.
22 22
@@ -50,7 +50,7 @@ BitBake
50 50
51BitBake is the tool at the heart of the `OpenEmbedded build 51BitBake is the tool at the heart of the `OpenEmbedded build
52system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible 52system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible
53for parsing the `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__, generating 53for parsing the :term:`Metadata`, generating
54a list of tasks from it, and then executing those tasks. 54a list of tasks from it, and then executing those tasks.
55 55
56This section briefly introduces BitBake. If you want more information on 56This section briefly introduces BitBake. If you want more information on
@@ -107,7 +107,7 @@ Classes
107 107
108Class files (``.bbclass``) contain information that is useful to share 108Class files (``.bbclass``) contain information that is useful to share
109between recipes files. An example is the 109between recipes files. An example is the
110```autotools`` <&YOCTO_DOCS_REF_URL;#ref-classes-autotools>`__ class, 110:ref:`autotools <ref-classes-autotools>` class,
111which contains common settings for any application that Autotools uses. 111which contains common settings for any application that Autotools uses.
112The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the 112The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the
113Yocto Project Reference Manual provides details about classes and how to 113Yocto Project Reference Manual provides details about classes and how to
@@ -187,7 +187,7 @@ In general, the build's workflow consists of several functional areas:
187- *Source Files:* Upstream releases, local projects, and SCMs. 187- *Source Files:* Upstream releases, local projects, and SCMs.
188 188
189- *Build System:* Processes under the control of 189- *Build System:* Processes under the control of
190 `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__. This block expands 190 :term:`BitBake`. This block expands
191 on how BitBake fetches source, applies patches, completes 191 on how BitBake fetches source, applies patches, completes
192 compilation, analyzes output for package generation, creates and 192 compilation, analyzes output for package generation, creates and
193 tests packages, generates images, and generates cross-development 193 tests packages, generates images, and generates cross-development
@@ -253,7 +253,7 @@ source the build environment setup script.
253Because the Poky repository is fundamentally an aggregation of existing 253Because the Poky repository is fundamentally an aggregation of existing
254repositories, some users might be familiar with running the ```` script 254repositories, some users might be familiar with running the ```` script
255in the context of separate 255in the context of separate
256`OpenEmbedded-Core <&YOCTO_DOCS_REF_URL;#oe-core>`__ and BitBake 256:term:`OpenEmbedded-Core (OE-Core)` and BitBake
257repositories rather than a single Poky repository. This discussion 257repositories rather than a single Poky repository. This discussion
258assumes the script is executed from within a cloned or unpacked version 258assumes the script is executed from within a cloned or unpacked version
259of Poky. 259of Poky.
@@ -281,29 +281,29 @@ script, see the
281in the ``meta-poky`` layer: 281in the ``meta-poky`` layer:
282 282
283- *Target Machine Selection:* Controlled by the 283- *Target Machine Selection:* Controlled by the
284 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable. 284 :term:`MACHINE` variable.
285 285
286- *Download Directory:* Controlled by the 286- *Download Directory:* Controlled by the
287 ```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__ variable. 287 :term:`DL_DIR` variable.
288 288
289- *Shared State Directory:* Controlled by the 289- *Shared State Directory:* Controlled by the
290 ```SSTATE_DIR`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR>`__ variable. 290 :term:`SSTATE_DIR` variable.
291 291
292- *Build Output:* Controlled by the 292- *Build Output:* Controlled by the
293 ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__ variable. 293 :term:`TMPDIR` variable.
294 294
295- *Distribution Policy:* Controlled by the 295- *Distribution Policy:* Controlled by the
296 ```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__ variable. 296 :term:`DISTRO` variable.
297 297
298- *Packaging Format:* Controlled by the 298- *Packaging Format:* Controlled by the
299 ```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__ 299 :term:`PACKAGE_CLASSES`
300 variable. 300 variable.
301 301
302- *SDK Target Architecture:* Controlled by the 302- *SDK Target Architecture:* Controlled by the
303 ```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__ variable. 303 :term:`SDKMACHINE` variable.
304 304
305- *Extra Image Packages:* Controlled by the 305- *Extra Image Packages:* Controlled by the
306 ```EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES>`__ 306 :term:`EXTRA_IMAGE_FEATURES`
307 variable. 307 variable.
308 308
309.. note:: 309.. note::
@@ -334,11 +334,11 @@ created by an autobuilder:
334 you had several build environments and they shared some common 334 you had several build environments and they shared some common
335 features. You can set these default build properties here. A good 335 features. You can set these default build properties here. A good
336 example is perhaps the packaging format to use through the 336 example is perhaps the packaging format to use through the
337 ```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__ 337 :term:`PACKAGE_CLASSES`
338 variable. 338 variable.
339 339
340 One useful scenario for using the ``conf/site.conf`` file is to 340 One useful scenario for using the ``conf/site.conf`` file is to
341 extend your ```BBPATH`` <&YOCTO_DOCS_REF_URL;#var-BBPATH>`__ variable 341 extend your :term:`BBPATH` variable
342 to include the path to a ``conf/site.conf``. Then, when BitBake looks 342 to include the path to a ``conf/site.conf``. Then, when BitBake looks
343 for Metadata using ``BBPATH``, it finds the ``conf/site.conf`` file 343 for Metadata using ``BBPATH``, it finds the ``conf/site.conf`` file
344 and applies your common configurations found in the file. To override 344 and applies your common configurations found in the file. To override
@@ -543,18 +543,18 @@ to build software. Finally, a combination of the two might exist, which
543would give the consumer a choice when deciding where to get source 543would give the consumer a choice when deciding where to get source
544files. 544files.
545 545
546BitBake uses the ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ 546BitBake uses the :term:`SRC_URI`
547variable to point to source files regardless of their location. Each 547variable to point to source files regardless of their location. Each
548recipe must have a ``SRC_URI`` variable that points to the source. 548recipe must have a ``SRC_URI`` variable that points to the source.
549 549
550Another area that plays a significant role in where source files come 550Another area that plays a significant role in where source files come
551from is pointed to by the 551from is pointed to by the
552```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__ variable. This area is 552:term:`DL_DIR` variable. This area is
553a cache that can hold previously downloaded source. You can also 553a cache that can hold previously downloaded source. You can also
554instruct the OpenEmbedded build system to create tarballs from Git 554instruct the OpenEmbedded build system to create tarballs from Git
555repositories, which is not the default behavior, and store them in the 555repositories, which is not the default behavior, and store them in the
556``DL_DIR`` by using the 556``DL_DIR`` by using the
557```BB_GENERATE_MIRROR_TARBALLS`` <&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS>`__ 557:term:`BB_GENERATE_MIRROR_TARBALLS`
558variable. 558variable.
559 559
560Judicious use of a ``DL_DIR`` directory can save the build system a trip 560Judicious use of a ``DL_DIR`` directory can save the build system a trip
@@ -588,7 +588,7 @@ user checks in items (e.g. a local directory containing a development
588source tree used by the group). 588source tree used by the group).
589 589
590The canonical method through which to include a local project is to use 590The canonical method through which to include a local project is to use
591the ```externalsrc`` <&YOCTO_DOCS_REF_URL;#ref-classes-externalsrc>`__ 591the :ref:`externalsrc <ref-classes-externalsrc>`
592class to include that local project. You use either the ``local.conf`` 592class to include that local project. You use either the ``local.conf``
593or a recipe's append file to override or set the recipe to point to the 593or a recipe's append file to override or set the recipe to point to the
594local directory on your disk to pull in the whole source tree. 594local directory on your disk to pull in the whole source tree.
@@ -602,8 +602,8 @@ Another place from which the build system can get source files is with
602`fetchers <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ employing various Source 602`fetchers <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ employing various Source
603Control Managers (SCMs) such as Git or Subversion. In such cases, a 603Control Managers (SCMs) such as Git or Subversion. In such cases, a
604repository is cloned or checked out. The 604repository is cloned or checked out. The
605```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__ task inside 605:ref:`ref-tasks-fetch` task inside
606BitBake uses the ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ 606BitBake uses the :term:`SRC_URI`
607variable and the argument's prefix to determine the correct fetcher 607variable and the argument's prefix to determine the correct fetcher
608module. 608module.
609 609
@@ -617,19 +617,19 @@ module.
617 variable in the Yocto Project Reference Manual. 617 variable in the Yocto Project Reference Manual.
618 618
619When fetching a repository, BitBake uses the 619When fetching a repository, BitBake uses the
620```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__ variable to determine 620:term:`SRCREV` variable to determine
621the specific revision from which to build. 621the specific revision from which to build.
622 622
623Source Mirror(s) 623Source Mirror(s)
624~~~~~~~~~~~~~~~~ 624~~~~~~~~~~~~~~~~
625 625
626Two kinds of mirrors exist: pre-mirrors and regular mirrors. The 626Two kinds of mirrors exist: pre-mirrors and regular mirrors. The
627```PREMIRRORS`` <&YOCTO_DOCS_REF_URL;#var-PREMIRRORS>`__ and 627:term:`PREMIRRORS` and
628```MIRRORS`` <&YOCTO_DOCS_REF_URL;#var-MIRRORS>`__ variables point to 628:term:`MIRRORS` variables point to
629these, respectively. BitBake checks pre-mirrors before looking upstream 629these, respectively. BitBake checks pre-mirrors before looking upstream
630for any source files. Pre-mirrors are appropriate when you have a shared 630for any source files. Pre-mirrors are appropriate when you have a shared
631directory that is not a directory defined by the 631directory that is not a directory defined by the
632```DL_DIR`` <&YOCTO_DOCS_REF_URL;#var-DL_DIR>`__ variable. A Pre-mirror 632:term:`DL_DIR` variable. A Pre-mirror
633typically points to a shared directory that is local to your 633typically points to a shared directory that is local to your
634organization. 634organization.
635 635
@@ -657,10 +657,10 @@ the build system. Here is a more detailed look at the area:
657Package feeds are an intermediary step in the build process. The 657Package feeds are an intermediary step in the build process. The
658OpenEmbedded build system provides classes to generate different package 658OpenEmbedded build system provides classes to generate different package
659types, and you specify which classes to enable through the 659types, and you specify which classes to enable through the
660```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__ 660:term:`PACKAGE_CLASSES`
661variable. Before placing the packages into package feeds, the build 661variable. Before placing the packages into package feeds, the build
662process validates them with generated output quality assurance checks 662process validates them with generated output quality assurance checks
663through the ```insane`` <&YOCTO_DOCS_REF_URL;#ref-classes-insane>`__ 663through the :ref:`insane <ref-classes-insane>`
664class. 664class.
665 665
666The package feed area resides in the Build Directory. The directory the 666The package feed area resides in the Build Directory. The directory the
@@ -670,19 +670,19 @@ the "Package Feeds" box in the illustration and note the information to
670the right of that area. In particular, the following defines where 670the right of that area. In particular, the following defines where
671package files are kept: 671package files are kept:
672 672
673- ```DEPLOY_DIR`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR>`__: Defined as 673- :term:`DEPLOY_DIR`: Defined as
674 ``tmp/deploy`` in the Build Directory. 674 ``tmp/deploy`` in the Build Directory.
675 675
676- ``DEPLOY_DIR_*``: Depending on the package manager used, the package 676- ``DEPLOY_DIR_*``: Depending on the package manager used, the package
677 type sub-folder. Given RPM, IPK, or DEB packaging and tarball 677 type sub-folder. Given RPM, IPK, or DEB packaging and tarball
678 creation, the 678 creation, the
679 ```DEPLOY_DIR_RPM`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_RPM>`__, 679 :term:`DEPLOY_DIR_RPM`,
680 ```DEPLOY_DIR_IPK`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_IPK>`__, 680 :term:`DEPLOY_DIR_IPK`,
681 ```DEPLOY_DIR_DEB`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_DEB>`__, or 681 :term:`DEPLOY_DIR_DEB`, or
682 ```DEPLOY_DIR_TAR`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_TAR>`__, 682 :term:`DEPLOY_DIR_TAR`,
683 variables are used, respectively. 683 variables are used, respectively.
684 684
685- ```PACKAGE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH>`__: Defines 685- :term:`PACKAGE_ARCH`: Defines
686 architecture-specific sub-folders. For example, packages could exist 686 architecture-specific sub-folders. For example, packages could exist
687 for the i586 or qemux86 architectures. 687 for the i586 or qemux86 architectures.
688 688
@@ -690,11 +690,11 @@ BitBake uses the
690```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ 690```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
691tasks to generate packages and place them into the package holding area 691tasks to generate packages and place them into the package holding area
692(e.g. ``do_package_write_ipk`` for IPK packages). See the 692(e.g. ``do_package_write_ipk`` for IPK packages). See the
693"```do_package_write_deb`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__", 693":ref:`ref-tasks-package_write_deb`",
694"```do_package_write_ipk`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_ipk>`__", 694":ref:`ref-tasks-package_write_ipk`",
695"```do_package_write_rpm`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_rpm>`__", 695":ref:`ref-tasks-package_write_rpm`",
696and 696and
697"```do_package_write_tar`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_tar>`__" 697":ref:`ref-tasks-package_write_tar`"
698sections in the Yocto Project Reference Manual for additional 698sections in the Yocto Project Reference Manual for additional
699information. As an example, consider a scenario where an IPK packaging 699information. As an example, consider a scenario where an IPK packaging
700manager is being used and package architecture support for both i586 and 700manager is being used and package architecture support for both i586 and
@@ -708,7 +708,7 @@ BitBake
708------- 708-------
709 709
710The OpenEmbedded build system uses 710The OpenEmbedded build system uses
711`BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ to produce images and 711:term:`BitBake` to produce images and
712Software Development Kits (SDKs). You can see from the `general workflow 712Software Development Kits (SDKs). You can see from the `general workflow
713figure <#general-workflow-figure>`__, the BitBake area consists of 713figure <#general-workflow-figure>`__, the BitBake area consists of
714several functional areas. This section takes a closer look at each of 714several functional areas. This section takes a closer look at each of
@@ -731,8 +731,8 @@ code:
731.. image:: figures/source-fetching.png 731.. image:: figures/source-fetching.png
732 :align: center 732 :align: center
733 733
734The ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__ and 734The :ref:`ref-tasks-fetch` and
735```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__ tasks fetch 735:ref:`ref-tasks-unpack` tasks fetch
736the source files and unpack them into the `Build 736the source files and unpack them into the `Build
737Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. 737Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
738 738
@@ -756,17 +756,17 @@ Directory, see the
756the Yocto Project Reference Manual. 756the Yocto Project Reference Manual.
757 757
758Each recipe has an area in the Build Directory where the unpacked source 758Each recipe has an area in the Build Directory where the unpacked source
759code resides. The ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__ variable points 759code resides. The :term:`S` variable points
760to this area for a recipe's unpacked source code. The name of that 760to this area for a recipe's unpacked source code. The name of that
761directory for any given recipe is defined from several different 761directory for any given recipe is defined from several different
762variables. The preceding figure and the following list describe the 762variables. The preceding figure and the following list describe the
763Build Directory's hierarchy: 763Build Directory's hierarchy:
764 764
765- ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__: The base directory 765- :term:`TMPDIR`: The base directory
766 where the OpenEmbedded build system performs all its work during the 766 where the OpenEmbedded build system performs all its work during the
767 build. The default base directory is the ``tmp`` directory. 767 build. The default base directory is the ``tmp`` directory.
768 768
769- ```PACKAGE_ARCH`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH>`__: The 769- :term:`PACKAGE_ARCH`: The
770 architecture of the built package or packages. Depending on the 770 architecture of the built package or packages. Depending on the
771 eventual destination of the package or packages (i.e. machine 771 eventual destination of the package or packages (i.e. machine
772 architecture, `build 772 architecture, `build
@@ -774,33 +774,33 @@ Build Directory's hierarchy:
774 specific machine), ``PACKAGE_ARCH`` varies. See the variable's 774 specific machine), ``PACKAGE_ARCH`` varies. See the variable's
775 description for details. 775 description for details.
776 776
777- ```TARGET_OS`` <&YOCTO_DOCS_REF_URL;#var-TARGET_OS>`__: The operating 777- :term:`TARGET_OS`: The operating
778 system of the target device. A typical value would be "linux" (e.g. 778 system of the target device. A typical value would be "linux" (e.g.
779 "qemux86-poky-linux"). 779 "qemux86-poky-linux").
780 780
781- ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__: The name of the recipe used 781- :term:`PN`: The name of the recipe used
782 to build the package. This variable can have multiple meanings. 782 to build the package. This variable can have multiple meanings.
783 However, when used in the context of input files, ``PN`` represents 783 However, when used in the context of input files, ``PN`` represents
784 the the name of the recipe. 784 the the name of the recipe.
785 785
786- ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__: The location 786- :term:`WORKDIR`: The location
787 where the OpenEmbedded build system builds a recipe (i.e. does the 787 where the OpenEmbedded build system builds a recipe (i.e. does the
788 work to create the package). 788 work to create the package).
789 789
790 - ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__: The version of the 790 - :term:`PV`: The version of the
791 recipe used to build the package. 791 recipe used to build the package.
792 792
793 - ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__: The revision of the 793 - :term:`PR`: The revision of the
794 recipe used to build the package. 794 recipe used to build the package.
795 795
796- ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__: Contains the unpacked source 796- :term:`S`: Contains the unpacked source
797 files for a given recipe. 797 files for a given recipe.
798 798
799 - ```BPN`` <&YOCTO_DOCS_REF_URL;#var-BPN>`__: The name of the recipe 799 - :term:`BPN`: The name of the recipe
800 used to build the package. The ``BPN`` variable is a version of 800 used to build the package. The ``BPN`` variable is a version of
801 the ``PN`` variable but with common prefixes and suffixes removed. 801 the ``PN`` variable but with common prefixes and suffixes removed.
802 802
803 - ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__: The version of the 803 - :term:`PV`: The version of the
804 recipe used to build the package. 804 recipe used to build the package.
805 805
806.. note:: 806.. note::
@@ -825,15 +825,15 @@ and applies them to the source files:
825.. image:: figures/patching.png 825.. image:: figures/patching.png
826 :align: center 826 :align: center
827 827
828The ```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task uses a 828The :ref:`ref-tasks-patch` task uses a
829recipe's ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements 829recipe's :term:`SRC_URI` statements
830and the ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ variable 830and the :term:`FILESPATH` variable
831to locate applicable patch files. 831to locate applicable patch files.
832 832
833Default processing for patch files assumes the files have either 833Default processing for patch files assumes the files have either
834``*.patch`` or ``*.diff`` file types. You can use ``SRC_URI`` parameters 834``*.patch`` or ``*.diff`` file types. You can use ``SRC_URI`` parameters
835to change the way the build system recognizes patch files. See the 835to change the way the build system recognizes patch files. See the
836```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task for more 836:ref:`ref-tasks-patch` task for more
837information. 837information.
838 838
839BitBake finds and applies multiple patches for a single recipe in the 839BitBake finds and applies multiple patches for a single recipe in the
@@ -841,7 +841,7 @@ order in which it locates the patches. The ``FILESPATH`` variable
841defines the default set of directories that the build system uses to 841defines the default set of directories that the build system uses to
842search for patch files. Once found, patches are applied to the recipe's 842search for patch files. Once found, patches are applied to the recipe's
843source files, which are located in the 843source files, which are located in the
844```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__ directory. 844:term:`S` directory.
845 845
846For more information on how the source directories are created, see the 846For more information on how the source directories are created, see the
847"`Source Fetching <#source-fetching-dev-environment>`__" section. For 847"`Source Fetching <#source-fetching-dev-environment>`__" section. For
@@ -871,13 +871,13 @@ to a holding area (staged) in preparation for packaging:
871 871
872This step in the build process consists of the following tasks: 872This step in the build process consists of the following tasks:
873 873
874- ```do_prepare_recipe_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-prepare_recipe_sysroot>`__: 874- :ref:`ref-tasks-prepare_recipe_sysroot`:
875 This task sets up the two sysroots in 875 This task sets up the two sysroots in
876 ``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}`` 876 ``${``\ :term:`WORKDIR`\ ``}``
877 (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that 877 (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that
878 during the packaging phase the sysroots can contain the contents of 878 during the packaging phase the sysroots can contain the contents of
879 the 879 the
880 ```do_populate_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot>`__ 880 :ref:`ref-tasks-populate_sysroot`
881 tasks of the recipes on which the recipe containing the tasks 881 tasks of the recipes on which the recipe containing the tasks
882 depends. A sysroot exists for both the target and for the native 882 depends. A sysroot exists for both the target and for the native
883 binaries, which run on the host system. 883 binaries, which run on the host system.
@@ -889,32 +889,32 @@ This step in the build process consists of the following tasks:
889 configure itself depending on the target for which it is being built. 889 configure itself depending on the target for which it is being built.
890 890
891 The configurations handled by the 891 The configurations handled by the
892 ```do_configure`` <&YOCTO_DOCS_REF_URL;#ref-tasks-configure>`__ task 892 :ref:`ref-tasks-configure` task
893 are specific to configurations for the source code being built by the 893 are specific to configurations for the source code being built by the
894 recipe. 894 recipe.
895 895
896 If you are using the 896 If you are using the
897 ```autotools`` <&YOCTO_DOCS_REF_URL;#ref-classes-autotools>`__ class, 897 :ref:`autotools <ref-classes-autotools>` class,
898 you can add additional configuration options by using the 898 you can add additional configuration options by using the
899 ```EXTRA_OECONF`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF>`__ or 899 :term:`EXTRA_OECONF` or
900 ```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ 900 :term:`PACKAGECONFIG_CONFARGS`
901 variables. For information on how this variable works within that 901 variables. For information on how this variable works within that
902 class, see the 902 class, see the
903 ```autotools`` <&YOCTO_DOCS_REF_URL;#ref-classes-autotools>`__ class 903 :ref:`autotools <ref-classes-autotools>` class
904 `here <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass>`__. 904 `here <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass>`__.
905 905
906- *``do_compile``*: Once a configuration task has been satisfied, 906- *``do_compile``*: Once a configuration task has been satisfied,
907 BitBake compiles the source using the 907 BitBake compiles the source using the
908 ```do_compile`` <&YOCTO_DOCS_REF_URL;#ref-tasks-compile>`__ task. 908 :ref:`ref-tasks-compile` task.
909 Compilation occurs in the directory pointed to by the 909 Compilation occurs in the directory pointed to by the
910 ```B`` <&YOCTO_DOCS_REF_URL;#var-B>`__ variable. Realize that the 910 :term:`B` variable. Realize that the
911 ``B`` directory is, by default, the same as the 911 ``B`` directory is, by default, the same as the
912 ```S`` <&YOCTO_DOCS_REF_URL;#var-S>`__ directory. 912 :term:`S` directory.
913 913
914- *``do_install``*: After compilation completes, BitBake executes the 914- *``do_install``*: After compilation completes, BitBake executes the
915 ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task. 915 :ref:`ref-tasks-install` task.
916 This task copies files from the ``B`` directory and places them in a 916 This task copies files from the ``B`` directory and places them in a
917 holding area pointed to by the ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__ 917 holding area pointed to by the :term:`D`
918 variable. Packaging occurs later using files from this holding 918 variable. Packaging occurs later using files from this holding
919 directory. 919 directory.
920 920
@@ -929,10 +929,10 @@ analyzes the results and splits the output into packages:
929.. image:: figures/analysis-for-package-splitting.png 929.. image:: figures/analysis-for-package-splitting.png
930 :align: center 930 :align: center
931 931
932The ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ and 932The :ref:`ref-tasks-package` and
933```do_packagedata`` <&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata>`__ 933:ref:`ref-tasks-packagedata`
934tasks combine to analyze the files found in the 934tasks combine to analyze the files found in the
935```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__ directory and split them into 935:term:`D` directory and split them into
936subsets based on available packages and files. Analysis involves the 936subsets based on available packages and files. Analysis involves the
937following as well as other items: splitting out debugging symbols, 937following as well as other items: splitting out debugging symbols,
938looking at shared library dependencies between packages, and looking at 938looking at shared library dependencies between packages, and looking at
@@ -940,46 +940,46 @@ package relationships.
940 940
941The ``do_packagedata`` task creates package metadata based on the 941The ``do_packagedata`` task creates package metadata based on the
942analysis such that the build system can generate the final packages. The 942analysis such that the build system can generate the final packages. The
943```do_populate_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot>`__ 943:ref:`ref-tasks-populate_sysroot`
944task stages (copies) a subset of the files installed by the 944task stages (copies) a subset of the files installed by the
945```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task into 945:ref:`ref-tasks-install` task into
946the appropriate sysroot. Working, staged, and intermediate results of 946the appropriate sysroot. Working, staged, and intermediate results of
947the analysis and package splitting process use several areas: 947the analysis and package splitting process use several areas:
948 948
949- ```PKGD`` <&YOCTO_DOCS_REF_URL;#var-PKGD>`__: The destination 949- :term:`PKGD`: The destination
950 directory (i.e. ``package``) for packages before they are split into 950 directory (i.e. ``package``) for packages before they are split into
951 individual packages. 951 individual packages.
952 952
953- ```PKGDESTWORK`` <&YOCTO_DOCS_REF_URL;#var-PKGDESTWORK>`__: A 953- :term:`PKGDESTWORK`: A
954 temporary work area (i.e. ``pkgdata``) used by the ``do_package`` 954 temporary work area (i.e. ``pkgdata``) used by the ``do_package``
955 task to save package metadata. 955 task to save package metadata.
956 956
957- ```PKGDEST`` <&YOCTO_DOCS_REF_URL;#var-PKGDEST>`__: The parent 957- :term:`PKGDEST`: The parent
958 directory (i.e. ``packages-split``) for packages after they have been 958 directory (i.e. ``packages-split``) for packages after they have been
959 split. 959 split.
960 960
961- ```PKGDATA_DIR`` <&YOCTO_DOCS_REF_URL;#var-PKGDATA_DIR>`__: A shared, 961- :term:`PKGDATA_DIR`: A shared,
962 global-state directory that holds packaging metadata generated during 962 global-state directory that holds packaging metadata generated during
963 the packaging process. The packaging process copies metadata from 963 the packaging process. The packaging process copies metadata from
964 ``PKGDESTWORK`` to the ``PKGDATA_DIR`` area where it becomes globally 964 ``PKGDESTWORK`` to the ``PKGDATA_DIR`` area where it becomes globally
965 available. 965 available.
966 966
967- ```STAGING_DIR_HOST`` <&YOCTO_DOCS_REF_URL;#var-STAGING_DIR_HOST>`__: 967- :term:`STAGING_DIR_HOST`:
968 The path for the sysroot for the system on which a component is built 968 The path for the sysroot for the system on which a component is built
969 to run (i.e. ``recipe-sysroot``). 969 to run (i.e. ``recipe-sysroot``).
970 970
971- ```STAGING_DIR_NATIVE`` <&YOCTO_DOCS_REF_URL;#var-STAGING_DIR_NATIVE>`__: 971- :term:`STAGING_DIR_NATIVE`:
972 The path for the sysroot used when building components for the build 972 The path for the sysroot used when building components for the build
973 host (i.e. ``recipe-sysroot-native``). 973 host (i.e. ``recipe-sysroot-native``).
974 974
975- ```STAGING_DIR_TARGET`` <&YOCTO_DOCS_REF_URL;#var-STAGING_DIR_TARGET>`__: 975- :term:`STAGING_DIR_TARGET`:
976 The path for the sysroot used when a component that is built to 976 The path for the sysroot used when a component that is built to
977 execute on a system and it generates code for yet another machine 977 execute on a system and it generates code for yet another machine
978 (e.g. cross-canadian recipes). 978 (e.g. cross-canadian recipes).
979 979
980The ```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ variable defines the 980The :term:`FILES` variable defines the
981files that go into each package in 981files that go into each package in
982```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__. If you want 982:term:`PACKAGES`. If you want
983details on how this is accomplished, you can look at 983details on how this is accomplished, you can look at
984```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__. 984```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__.
985 985
@@ -1013,36 +1013,36 @@ system uses BitBake to generate the root filesystem image:
1013 1013
1014The image generation process consists of several stages and depends on 1014The image generation process consists of several stages and depends on
1015several tasks and variables. The 1015several tasks and variables. The
1016```do_rootfs`` <&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs>`__ task creates 1016:ref:`ref-tasks-rootfs` task creates
1017the root filesystem (file and directory structure) for an image. This 1017the root filesystem (file and directory structure) for an image. This
1018task uses several key variables to help create the list of packages to 1018task uses several key variables to help create the list of packages to
1019actually install: 1019actually install:
1020 1020
1021- ```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__: Lists 1021- :term:`IMAGE_INSTALL`: Lists
1022 out the base set of packages from which to install from the Package 1022 out the base set of packages from which to install from the Package
1023 Feeds area. 1023 Feeds area.
1024 1024
1025- ```PACKAGE_EXCLUDE`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_EXCLUDE>`__: 1025- :term:`PACKAGE_EXCLUDE`:
1026 Specifies packages that should not be installed into the image. 1026 Specifies packages that should not be installed into the image.
1027 1027
1028- ```IMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES>`__: 1028- :term:`IMAGE_FEATURES`:
1029 Specifies features to include in the image. Most of these features 1029 Specifies features to include in the image. Most of these features
1030 map to additional packages for installation. 1030 map to additional packages for installation.
1031 1031
1032- ```PACKAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES>`__: 1032- :term:`PACKAGE_CLASSES`:
1033 Specifies the package backend (e.g. RPM, DEB, or IPK) to use and 1033 Specifies the package backend (e.g. RPM, DEB, or IPK) to use and
1034 consequently helps determine where to locate packages within the 1034 consequently helps determine where to locate packages within the
1035 Package Feeds area. 1035 Package Feeds area.
1036 1036
1037- ```IMAGE_LINGUAS`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_LINGUAS>`__: 1037- :term:`IMAGE_LINGUAS`:
1038 Determines the language(s) for which additional language support 1038 Determines the language(s) for which additional language support
1039 packages are installed. 1039 packages are installed.
1040 1040
1041- ```PACKAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_INSTALL>`__: 1041- :term:`PACKAGE_INSTALL`:
1042 The final list of packages passed to the package manager for 1042 The final list of packages passed to the package manager for
1043 installation into the image. 1043 installation into the image.
1044 1044
1045With ```IMAGE_ROOTFS`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_ROOTFS>`__ 1045With :term:`IMAGE_ROOTFS`
1046pointing to the location of the filesystem under construction and the 1046pointing to the location of the filesystem under construction and the
1047``PACKAGE_INSTALL`` variable providing the final list of packages to 1047``PACKAGE_INSTALL`` variable providing the final list of packages to
1048install, the root file system is created. 1048install, the root file system is created.
@@ -1069,27 +1069,27 @@ root filesystem image. This file lists out, line-by-line, the installed
1069packages. The manifest file is useful for the 1069packages. The manifest file is useful for the
1070```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class, 1070```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class,
1071for example, to determine whether or not to run specific tests. See the 1071for example, to determine whether or not to run specific tests. See the
1072```IMAGE_MANIFEST`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_MANIFEST>`__ 1072:term:`IMAGE_MANIFEST`
1073variable for additional information. 1073variable for additional information.
1074 1074
1075Optimizing processes that are run across the image include ``mklibs``, 1075Optimizing processes that are run across the image include ``mklibs``,
1076``prelink``, and any other post-processing commands as defined by the 1076``prelink``, and any other post-processing commands as defined by the
1077```ROOTFS_POSTPROCESS_COMMAND`` <&YOCTO_DOCS_REF_URL;#var-ROOTFS_POSTPROCESS_COMMAND>`__ 1077:term:`ROOTFS_POSTPROCESS_COMMAND`
1078variable. The ``mklibs`` process optimizes the size of the libraries, 1078variable. The ``mklibs`` process optimizes the size of the libraries,
1079while the ``prelink`` process optimizes the dynamic linking of shared 1079while the ``prelink`` process optimizes the dynamic linking of shared
1080libraries to reduce start up time of executables. 1080libraries to reduce start up time of executables.
1081 1081
1082After the root filesystem is built, processing begins on the image 1082After the root filesystem is built, processing begins on the image
1083through the ```do_image`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__ 1083through the :ref:`ref-tasks-image`
1084task. The build system runs any pre-processing commands as defined by 1084task. The build system runs any pre-processing commands as defined by
1085the 1085the
1086```IMAGE_PREPROCESS_COMMAND`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_PREPROCESS_COMMAND>`__ 1086:term:`IMAGE_PREPROCESS_COMMAND`
1087variable. This variable specifies a list of functions to call before the 1087variable. This variable specifies a list of functions to call before the
1088build system creates the final image output files. 1088build system creates the final image output files.
1089 1089
1090The build system dynamically creates ``do_image_*`` tasks as needed, 1090The build system dynamically creates ``do_image_*`` tasks as needed,
1091based on the image types specified in the 1091based on the image types specified in the
1092```IMAGE_FSTYPES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES>`__ variable. 1092:term:`IMAGE_FSTYPES` variable.
1093The process turns everything into an image file or a set of image files 1093The process turns everything into an image file or a set of image files
1094and can compress the root filesystem image to reduce the overall size of 1094and can compress the root filesystem image to reduce the overall size of
1095the image. The formats used for the root filesystem depend on the 1095the image. The formats used for the root filesystem depend on the
@@ -1105,7 +1105,7 @@ The final task involved in image creation is the
1105```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__ 1105```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__
1106task. This task completes the image by applying any image post 1106task. This task completes the image by applying any image post
1107processing as defined through the 1107processing as defined through the
1108```IMAGE_POSTPROCESS_COMMAND`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_POSTPROCESS_COMMAND>`__ 1108:term:`IMAGE_POSTPROCESS_COMMAND`
1109variable. The variable specifies a list of functions to call once the 1109variable. The variable specifies a list of functions to call once the
1110build system has created the final image output files. 1110build system has created the final image output files.
1111 1111
@@ -1143,9 +1143,9 @@ the extensible SDK (eSDK):
1143 1143
1144Like image generation, the SDK script process consists of several stages 1144Like image generation, the SDK script process consists of several stages
1145and depends on many variables. The 1145and depends on many variables. The
1146```do_populate_sdk`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sdk>`__ 1146:ref:`ref-tasks-populate_sdk`
1147and 1147and
1148```do_populate_sdk_ext`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sdk_ext>`__ 1148:ref:`ref-tasks-populate_sdk_ext`
1149tasks use these key variables to help create the list of packages to 1149tasks use these key variables to help create the list of packages to
1150actually install. For information on the variables listed in the figure, 1150actually install. For information on the variables listed in the figure,
1151see the "`Application Development SDK <#sdk-dev-environment>`__" 1151see the "`Application Development SDK <#sdk-dev-environment>`__"
@@ -1155,7 +1155,7 @@ The ``do_populate_sdk`` task helps create the standard SDK and handles
1155two parts: a target part and a host part. The target part is the part 1155two parts: a target part and a host part. The target part is the part
1156built for the target hardware and includes libraries and headers. The 1156built for the target hardware and includes libraries and headers. The
1157host part is the part of the SDK that runs on the 1157host part is the part of the SDK that runs on the
1158```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__. 1158:term:`SDKMACHINE`.
1159 1159
1160The ``do_populate_sdk_ext`` task helps create the extensible SDK and 1160The ``do_populate_sdk_ext`` task helps create the extensible SDK and
1161handles host and target parts differently than its counter part does for 1161handles host and target parts differently than its counter part does for
@@ -1173,9 +1173,9 @@ Stamp Files and the Rerunning of Tasks
1173~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1173~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1174 1174
1175For each task that completes successfully, BitBake writes a stamp file 1175For each task that completes successfully, BitBake writes a stamp file
1176into the ```STAMPS_DIR`` <&YOCTO_DOCS_REF_URL;#var-STAMPS_DIR>`__ 1176into the :term:`STAMPS_DIR`
1177directory. The beginning of the stamp file's filename is determined by 1177directory. The beginning of the stamp file's filename is determined by
1178the ```STAMP`` <&YOCTO_DOCS_REF_URL;#var-STAMP>`__ variable, and the end 1178the :term:`STAMP` variable, and the end
1179of the name consists of the task's name and current `input 1179of the name consists of the task's name and current `input
1180checksum <#overview-checksums>`__. 1180checksum <#overview-checksums>`__.
1181 1181
@@ -1202,8 +1202,8 @@ file does not exist, the task is rerun.
1202 However, you should realize that stamp files only serve as a marker 1202 However, you should realize that stamp files only serve as a marker
1203 that some work has been done and that these files do not record task 1203 that some work has been done and that these files do not record task
1204 output. The actual task output would usually be somewhere in 1204 output. The actual task output would usually be somewhere in
1205 ```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__ (e.g. in some 1205 :term:`TMPDIR` (e.g. in some
1206 recipe's ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__.) What 1206 recipe's :term:`WORKDIR`.) What
1207 the sstate cache mechanism adds is a way to cache task output that 1207 the sstate cache mechanism adds is a way to cache task output that
1208 can then be shared between build machines. 1208 can then be shared between build machines.
1209 1209
@@ -1244,16 +1244,16 @@ locations as needed. In some cases, it makes sense to have a setscene
1244task variant (e.g. generating package files in the 1244task variant (e.g. generating package files in the
1245```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ 1245```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
1246task). In other cases, it does not make sense (e.g. a 1246task). In other cases, it does not make sense (e.g. a
1247```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task or a 1247:ref:`ref-tasks-patch` task or a
1248```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__ task) since 1248:ref:`ref-tasks-unpack` task) since
1249the work involved would be equal to or greater than the underlying task. 1249the work involved would be equal to or greater than the underlying task.
1250 1250
1251In the build system, the common tasks that have setscene variants are 1251In the build system, the common tasks that have setscene variants are
1252```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__, 1252:ref:`ref-tasks-package`,
1253``do_package_write_*``, 1253``do_package_write_*``,
1254```do_deploy`` <&YOCTO_DOCS_REF_URL;#ref-tasks-deploy>`__, 1254:ref:`ref-tasks-deploy`,
1255```do_packagedata`` <&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata>`__, and 1255:ref:`ref-tasks-packagedata`, and
1256```do_populate_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot>`__. 1256:ref:`ref-tasks-populate_sysroot`.
1257Notice that these tasks represent most of the tasks whose output is an 1257Notice that these tasks represent most of the tasks whose output is an
1258end result. 1258end result.
1259 1259
@@ -1321,14 +1321,14 @@ The build process writes images out to the `Build
1321Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the 1321Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the
1322``tmp/deploy/images/machine/`` folder as shown in the figure. This 1322``tmp/deploy/images/machine/`` folder as shown in the figure. This
1323folder contains any files expected to be loaded on the target device. 1323folder contains any files expected to be loaded on the target device.
1324The ```DEPLOY_DIR`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR>`__ variable 1324The :term:`DEPLOY_DIR` variable
1325points to the ``deploy`` directory, while the 1325points to the ``deploy`` directory, while the
1326```DEPLOY_DIR_IMAGE`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_IMAGE>`__ 1326:term:`DEPLOY_DIR_IMAGE`
1327variable points to the appropriate directory containing images for the 1327variable points to the appropriate directory containing images for the
1328current configuration. 1328current configuration.
1329 1329
1330- kernel-image: A kernel binary file. The 1330- kernel-image: A kernel binary file. The
1331 ```KERNEL_IMAGETYPE`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE>`__ 1331 :term:`KERNEL_IMAGETYPE`
1332 variable determines the naming scheme for the kernel image file. 1332 variable determines the naming scheme for the kernel image file.
1333 Depending on this variable, the file could begin with a variety of 1333 Depending on this variable, the file could begin with a variety of
1334 naming strings. The ``deploy/images/``\ machine directory can contain 1334 naming strings. The ``deploy/images/``\ machine directory can contain
@@ -1336,7 +1336,7 @@ current configuration.
1336 1336
1337- root-filesystem-image: Root filesystems for the target device (e.g. 1337- root-filesystem-image: Root filesystems for the target device (e.g.
1338 ``*.ext3`` or ``*.bz2`` files). The 1338 ``*.ext3`` or ``*.bz2`` files). The
1339 ```IMAGE_FSTYPES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES>`__ 1339 :term:`IMAGE_FSTYPES`
1340 variable determines the root filesystem image type. The 1340 variable determines the root filesystem image type. The
1341 ``deploy/images/``\ machine directory can contain multiple root 1341 ``deploy/images/``\ machine directory can contain multiple root
1342 filesystems for the machine. 1342 filesystems for the machine.
@@ -1344,7 +1344,7 @@ current configuration.
1344- kernel-modules: Tarballs that contain all the modules built for the 1344- kernel-modules: Tarballs that contain all the modules built for the
1345 kernel. Kernel module tarballs exist for legacy purposes and can be 1345 kernel. Kernel module tarballs exist for legacy purposes and can be
1346 suppressed by setting the 1346 suppressed by setting the
1347 ```MODULE_TARBALL_DEPLOY`` <&YOCTO_DOCS_REF_URL;#var-MODULE_TARBALL_DEPLOY>`__ 1347 :term:`MODULE_TARBALL_DEPLOY`
1348 variable to "0". The ``deploy/images/``\ machine directory can 1348 variable to "0". The ``deploy/images/``\ machine directory can
1349 contain multiple kernel module tarballs for the machine. 1349 contain multiple kernel module tarballs for the machine.
1350 1350
@@ -1401,72 +1401,72 @@ can initialize the environment before using the tools.
1401 Software Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. 1401 Software Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
1402 1402
1403All the output files for an SDK are written to the ``deploy/sdk`` folder 1403All the output files for an SDK are written to the ``deploy/sdk`` folder
1404inside the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ as 1404inside the :term:`Build Directory` as
1405shown in the previous figure. Depending on the type of SDK, several 1405shown in the previous figure. Depending on the type of SDK, several
1406variables exist that help configure these files. The following list 1406variables exist that help configure these files. The following list
1407shows the variables associated with an extensible SDK: 1407shows the variables associated with an extensible SDK:
1408 1408
1409- ```DEPLOY_DIR`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR>`__: Points to 1409- :term:`DEPLOY_DIR`: Points to
1410 the ``deploy`` directory. 1410 the ``deploy`` directory.
1411 1411
1412- ```SDK_EXT_TYPE`` <&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE>`__: 1412- :term:`SDK_EXT_TYPE`:
1413 Controls whether or not shared state artifacts are copied into the 1413 Controls whether or not shared state artifacts are copied into the
1414 extensible SDK. By default, all required shared state artifacts are 1414 extensible SDK. By default, all required shared state artifacts are
1415 copied into the SDK. 1415 copied into the SDK.
1416 1416
1417- ```SDK_INCLUDE_PKGDATA`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_PKGDATA>`__: 1417- :term:`SDK_INCLUDE_PKGDATA`:
1418 Specifies whether or not packagedata is included in the extensible 1418 Specifies whether or not packagedata is included in the extensible
1419 SDK for all recipes in the "world" target. 1419 SDK for all recipes in the "world" target.
1420 1420
1421- ```SDK_INCLUDE_TOOLCHAIN`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN>`__: 1421- :term:`SDK_INCLUDE_TOOLCHAIN`:
1422 Specifies whether or not the toolchain is included when building the 1422 Specifies whether or not the toolchain is included when building the
1423 extensible SDK. 1423 extensible SDK.
1424 1424
1425- ```SDK_LOCAL_CONF_WHITELIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_WHITELIST>`__: 1425- :term:`SDK_LOCAL_CONF_WHITELIST`:
1426 A list of variables allowed through from the build system 1426 A list of variables allowed through from the build system
1427 configuration into the extensible SDK configuration. 1427 configuration into the extensible SDK configuration.
1428 1428
1429- ```SDK_LOCAL_CONF_BLACKLIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST>`__: 1429- :term:`SDK_LOCAL_CONF_BLACKLIST`:
1430 A list of variables not allowed through from the build system 1430 A list of variables not allowed through from the build system
1431 configuration into the extensible SDK configuration. 1431 configuration into the extensible SDK configuration.
1432 1432
1433- ```SDK_INHERIT_BLACKLIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST>`__: 1433- :term:`SDK_INHERIT_BLACKLIST`:
1434 A list of classes to remove from the 1434 A list of classes to remove from the
1435 ```INHERIT`` <&YOCTO_DOCS_REF_URL;#var-INHERIT>`__ value globally 1435 :term:`INHERIT` value globally
1436 within the extensible SDK configuration. 1436 within the extensible SDK configuration.
1437 1437
1438This next list, shows the variables associated with a standard SDK: 1438This next list, shows the variables associated with a standard SDK:
1439 1439
1440- ```DEPLOY_DIR`` <&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR>`__: Points to 1440- :term:`DEPLOY_DIR`: Points to
1441 the ``deploy`` directory. 1441 the ``deploy`` directory.
1442 1442
1443- ```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__: Specifies 1443- :term:`SDKMACHINE`: Specifies
1444 the architecture of the machine on which the cross-development tools 1444 the architecture of the machine on which the cross-development tools
1445 are run to create packages for the target hardware. 1445 are run to create packages for the target hardware.
1446 1446
1447- ```SDKIMAGE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-SDKIMAGE_FEATURES>`__: 1447- :term:`SDKIMAGE_FEATURES`:
1448 Lists the features to include in the "target" part of the SDK. 1448 Lists the features to include in the "target" part of the SDK.
1449 1449
1450- ```TOOLCHAIN_HOST_TASK`` <&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_HOST_TASK>`__: 1450- :term:`TOOLCHAIN_HOST_TASK`:
1451 Lists packages that make up the host part of the SDK (i.e. the part 1451 Lists packages that make up the host part of the SDK (i.e. the part
1452 that runs on the ``SDKMACHINE``). When you use 1452 that runs on the ``SDKMACHINE``). When you use
1453 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of 1453 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
1454 default packages apply. This variable allows you to add more 1454 default packages apply. This variable allows you to add more
1455 packages. 1455 packages.
1456 1456
1457- ```TOOLCHAIN_TARGET_TASK`` <&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK>`__: 1457- :term:`TOOLCHAIN_TARGET_TASK`:
1458 Lists packages that make up the target part of the SDK (i.e. the part 1458 Lists packages that make up the target part of the SDK (i.e. the part
1459 built for the target hardware). 1459 built for the target hardware).
1460 1460
1461- ```SDKPATH`` <&YOCTO_DOCS_REF_URL;#var-SDKPATH>`__: Defines the 1461- :term:`SDKPATH`: Defines the
1462 default SDK installation path offered by the installation script. 1462 default SDK installation path offered by the installation script.
1463 1463
1464- ```SDK_HOST_MANIFEST`` <&YOCTO_DOCS_REF_URL;#var-SDK_HOST_MANIFEST>`__: 1464- :term:`SDK_HOST_MANIFEST`:
1465 Lists all the installed packages that make up the host part of the 1465 Lists all the installed packages that make up the host part of the
1466 SDK. This variable also plays a minor role for extensible SDK 1466 SDK. This variable also plays a minor role for extensible SDK
1467 development as well. However, it is mainly used for the standard SDK. 1467 development as well. However, it is mainly used for the standard SDK.
1468 1468
1469- ```SDK_TARGET_MANIFEST`` <&YOCTO_DOCS_REF_URL;#var-SDK_TARGET_MANIFEST>`__: 1469- :term:`SDK_TARGET_MANIFEST`:
1470 Lists all the installed packages that make up the target part of the 1470 Lists all the installed packages that make up the target part of the
1471 SDK. This variable also plays a minor role for extensible SDK 1471 SDK. This variable also plays a minor role for extensible SDK
1472 development as well. However, it is mainly used for the standard SDK. 1472 development as well. However, it is mainly used for the standard SDK.
@@ -1497,7 +1497,7 @@ toolchain construction and use.
1497Most of the work occurs on the Build Host. This is the machine used to 1497Most of the work occurs on the Build Host. This is the machine used to
1498build images and generally work within the the Yocto Project 1498build images and generally work within the the Yocto Project
1499environment. When you run 1499environment. When you run
1500`BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ to create an image, the 1500:term:`BitBake` to create an image, the
1501OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a 1501OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a
1502cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what 1502cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what
1503BitBake uses to compile source files when creating the target image. You 1503BitBake uses to compile source files when creating the target image. You
@@ -1558,11 +1558,11 @@ relocatable SDK used to develop applications. When you run the
1558installer, it installs the toolchain, which contains the development 1558installer, it installs the toolchain, which contains the development
1559tools (e.g., ``gcc-cross-canadian``, ``binutils-cross-canadian``, and 1559tools (e.g., ``gcc-cross-canadian``, ``binutils-cross-canadian``, and
1560other ``nativesdk-*`` tools), which are tools native to the SDK (i.e. 1560other ``nativesdk-*`` tools), which are tools native to the SDK (i.e.
1561native to ```SDK_ARCH`` <&YOCTO_DOCS_REF_URL;#var-SDK_ARCH>`__), you 1561native to :term:`SDK_ARCH`), you
1562need to cross-compile and test your software. The figure shows the 1562need to cross-compile and test your software. The figure shows the
1563commands you use to easily build out this toolchain. This 1563commands you use to easily build out this toolchain. This
1564cross-development toolchain is built to execute on the 1564cross-development toolchain is built to execute on the
1565```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__, which might or 1565:term:`SDKMACHINE`, which might or
1566might not be the same machine as the Build Host. 1566might not be the same machine as the Build Host.
1567 1567
1568.. note:: 1568.. note::
@@ -1603,7 +1603,7 @@ glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian
1603 (i.e. it is designed to run on the build host). 1603 (i.e. it is designed to run on the build host).
1604 1604
1605- ``gcc-cross-canadian``: The final relocatable cross-compiler. When 1605- ``gcc-cross-canadian``: The final relocatable cross-compiler. When
1606 run on the ```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__, 1606 run on the :term:`SDKMACHINE`,
1607 this tool produces executable code that runs on the target device. 1607 this tool produces executable code that runs on the target device.
1608 Only one cross-canadian compiler is produced per architecture since 1608 Only one cross-canadian compiler is produced per architecture since
1609 they can be targeted at different processor optimizations using 1609 they can be targeted at different processor optimizations using
@@ -1623,7 +1623,7 @@ Shared State Cache
1623================== 1623==================
1624 1624
1625By design, the OpenEmbedded build system builds everything from scratch 1625By design, the OpenEmbedded build system builds everything from scratch
1626unless `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ can determine 1626unless :term:`BitBake` can determine
1627that parts do not need to be rebuilt. Fundamentally, building from 1627that parts do not need to be rebuilt. Fundamentally, building from
1628scratch is attractive as it means all parts are built fresh and no 1628scratch is attractive as it means all parts are built fresh and no
1629possibility of stale data exists that can cause problems. When 1629possibility of stale data exists that can cause problems. When
@@ -1664,7 +1664,7 @@ them if they are deemed to be valid.
1664.. note:: 1664.. note::
1665 1665
1666 - The build system does not maintain 1666 - The build system does not maintain
1667 ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__ information as part of 1667 :term:`PR` information as part of
1668 the shared state packages. Consequently, considerations exist that 1668 the shared state packages. Consequently, considerations exist that
1669 affect maintaining shared state feeds. For information on how the 1669 affect maintaining shared state feeds. For information on how the
1670 build system works with packages and can track incrementing ``PR`` 1670 build system works with packages and can track incrementing ``PR``
@@ -1695,8 +1695,8 @@ works on a per-task basis rather than a per-recipe basis. You might
1695wonder why using a per-task basis is preferred over a per-recipe basis. 1695wonder why using a per-task basis is preferred over a per-recipe basis.
1696To help explain, consider having the IPK packaging backend enabled and 1696To help explain, consider having the IPK packaging backend enabled and
1697then switching to DEB. In this case, the 1697then switching to DEB. In this case, the
1698```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ and 1698:ref:`ref-tasks-install` and
1699```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ task outputs 1699:ref:`ref-tasks-package` task outputs
1700are still valid. However, with a per-recipe approach, the build would 1700are still valid. However, with a per-recipe approach, the build would
1701not include the ``.deb`` files. Consequently, you would have to 1701not include the ``.deb`` files. Consequently, you would have to
1702invalidate the whole build and rerun it. Rerunning everything is not the 1702invalidate the whole build and rerun it. Rerunning everything is not the
@@ -1720,7 +1720,7 @@ you a good idea of when the task's data changes.
1720 1720
1721To complicate the problem, there are things that should not be included 1721To complicate the problem, there are things that should not be included
1722in the checksum. First, there is the actual specific build path of a 1722in the checksum. First, there is the actual specific build path of a
1723given task - the ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__. It 1723given task - the :term:`WORKDIR`. It
1724does not matter if the work directory changes because it should not 1724does not matter if the work directory changes because it should not
1725affect the output for target packages. Also, the build process has the 1725affect the output for target packages. Also, the build process has the
1726objective of making native or cross packages relocatable. 1726objective of making native or cross packages relocatable.
@@ -1755,9 +1755,9 @@ Like the ``WORKDIR`` case, situations exist where dependencies should be
1755ignored. For these situations, you can instruct the build process to 1755ignored. For these situations, you can instruct the build process to
1756ignore a dependency by using a line like the following: 1756ignore a dependency by using a line like the following:
1757PACKAGE_ARCHS[vardepsexclude] = "MACHINE" This example ensures that the 1757PACKAGE_ARCHS[vardepsexclude] = "MACHINE" This example ensures that the
1758```PACKAGE_ARCHS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCHS>`__ variable 1758:term:`PACKAGE_ARCHS` variable
1759does not depend on the value of 1759does not depend on the value of
1760```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__, even if it does 1760:term:`MACHINE`, even if it does
1761reference it. 1761reference it.
1762 1762
1763Equally, there are cases where you need to add dependencies BitBake is 1763Equally, there are cases where you need to add dependencies BitBake is
@@ -1795,9 +1795,9 @@ STAGING_DIR_TARGET COREBASE PRSERV_HOST \\ PRSERV_DUMPDIR
1795PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ CCACHE_DIR 1795PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ CCACHE_DIR
1796EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" The 1796EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" The
1797previous example excludes 1797previous example excludes
1798```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__ since that variable 1798:term:`WORKDIR` since that variable
1799is actually constructed as a path within 1799is actually constructed as a path within
1800```TMPDIR`` <&YOCTO_DOCS_REF_URL;#var-TMPDIR>`__, which is on the 1800:term:`TMPDIR`, which is on the
1801whitelist. 1801whitelist.
1802 1802
1803The rules for deciding which hashes of dependent tasks to include 1803The rules for deciding which hashes of dependent tasks to include
@@ -1806,7 +1806,7 @@ accomplished with a Python function. The code in
1806``meta/lib/oe/sstatesig.py`` shows two examples of this and also 1806``meta/lib/oe/sstatesig.py`` shows two examples of this and also
1807illustrates how you can insert your own policy into the system if so 1807illustrates how you can insert your own policy into the system if so
1808desired. This file defines the two basic signature generators 1808desired. This file defines the two basic signature generators
1809`OE-Core <&YOCTO_DOCS_REF_URL;#oe-core>`__ uses: "OEBasic" and 1809:term:`OpenEmbedded-Core (OE-Core)` uses: "OEBasic" and
1810"OEBasicHash". By default, a dummy "noop" signature handler is enabled 1810"OEBasicHash". By default, a dummy "noop" signature handler is enabled
1811in BitBake. This means that behavior is unchanged from previous 1811in BitBake. This means that behavior is unchanged from previous
1812versions. OE-Core uses the "OEBasicHash" signature handler by default 1812versions. OE-Core uses the "OEBasicHash" signature handler by default
@@ -1816,7 +1816,7 @@ as the "OEBasic" version but adds the task hash to the `stamp
1816files <#stamp-files-and-the-rerunning-of-tasks>`__. This results in any 1816files <#stamp-files-and-the-rerunning-of-tasks>`__. This results in any
1817metadata change that changes the task hash, automatically causing the 1817metadata change that changes the task hash, automatically causing the
1818task to be run again. This removes the need to bump 1818task to be run again. This removes the need to bump
1819```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__ values, and changes to metadata 1819:term:`PR` values, and changes to metadata
1820automatically ripple across the build. 1820automatically ripple across the build.
1821 1821
1822It is also worth noting that the end result of these signature 1822It is also worth noting that the end result of these signature
@@ -1842,7 +1842,7 @@ half the problem of supporting a shared state. The other half of the
1842problem is being able to use checksum information during the build and 1842problem is being able to use checksum information during the build and
1843being able to reuse or rebuild specific components. 1843being able to reuse or rebuild specific components.
1844 1844
1845The ```sstate`` <&YOCTO_DOCS_REF_URL;#ref-classes-sstate>`__ class is a 1845The :ref:`sstate <ref-classes-sstate>` class is a
1846relatively generic implementation of how to "capture" a snapshot of a 1846relatively generic implementation of how to "capture" a snapshot of a
1847given task. The idea is that the build process does not care about the 1847given task. The idea is that the build process does not care about the
1848source of a task's output. Output could be freshly built or it could be 1848source of a task's output. Output could be freshly built or it could be
@@ -1850,18 +1850,18 @@ downloaded and unpacked from somewhere. In other words, the build
1850process does not need to worry about its origin. 1850process does not need to worry about its origin.
1851 1851
1852Two types of output exist. One type is just about creating a directory 1852Two types of output exist. One type is just about creating a directory
1853in ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__. A good example is 1853in :term:`WORKDIR`. A good example is
1854the output of either 1854the output of either
1855```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ or 1855:ref:`ref-tasks-install` or
1856```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__. The other 1856:ref:`ref-tasks-package`. The other
1857type of output occurs when a set of data is merged into a shared 1857type of output occurs when a set of data is merged into a shared
1858directory tree such as the sysroot. 1858directory tree such as the sysroot.
1859 1859
1860The Yocto Project team has tried to keep the details of the 1860The Yocto Project team has tried to keep the details of the
1861implementation hidden in ``sstate`` class. From a user's perspective, 1861implementation hidden in ``sstate`` class. From a user's perspective,
1862adding shared state wrapping to a task is as simple as this 1862adding shared state wrapping to a task is as simple as this
1863```do_deploy`` <&YOCTO_DOCS_REF_URL;#ref-tasks-deploy>`__ example taken 1863:ref:`ref-tasks-deploy` example taken
1864from the ```deploy`` <&YOCTO_DOCS_REF_URL;#ref-classes-deploy>`__ class: 1864from the :ref:`deploy <ref-classes-deploy>` class:
1865DEPLOYDIR = "${WORKDIR}/deploy-${PN}" SSTATETASKS += "do_deploy" 1865DEPLOYDIR = "${WORKDIR}/deploy-${PN}" SSTATETASKS += "do_deploy"
1866do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" 1866do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
1867do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" python 1867do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" python
@@ -1871,9 +1871,9 @@ do_deploy[dirs] = "${DEPLOYDIR} ${B}" do_deploy[stamp-extra-info] =
1871 1871
1872- Adding "do_deploy" to ``SSTATETASKS`` adds some required 1872- Adding "do_deploy" to ``SSTATETASKS`` adds some required
1873 sstate-related processing, which is implemented in the 1873 sstate-related processing, which is implemented in the
1874 ```sstate`` <&YOCTO_DOCS_REF_URL;#ref-classes-sstate>`__ class, to 1874 :ref:`sstate <ref-classes-sstate>` class, to
1875 before and after the 1875 before and after the
1876 ```do_deploy`` <&YOCTO_DOCS_REF_URL;#ref-tasks-deploy>`__ task. 1876 :ref:`ref-tasks-deploy` task.
1877 1877
1878- The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that 1878- The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
1879 ``do_deploy`` places its output in ``${DEPLOYDIR}`` when run normally 1879 ``do_deploy`` places its output in ``${DEPLOYDIR}`` when run normally
@@ -1965,8 +1965,8 @@ do_deploy[dirs] = "${DEPLOYDIR} ${B}" do_deploy[stamp-extra-info] =
1965 "${PACKAGELOCK}" 1965 "${PACKAGELOCK}"
1966 1966
1967Behind the scenes, the shared state code works by looking in 1967Behind the scenes, the shared state code works by looking in
1968```SSTATE_DIR`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR>`__ and 1968:term:`SSTATE_DIR` and
1969```SSTATE_MIRRORS`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS>`__ for 1969:term:`SSTATE_MIRRORS` for
1970shared state files. Here is an example: SSTATE_MIRRORS ?= "\\ file://.\* 1970shared state files. Here is an example: SSTATE_MIRRORS ?= "\\ file://.\*
1971http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \\n \\ 1971http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \\n \\
1972file://.\* file:///some/local/dir/sstate/PATH" 1972file://.\* file:///some/local/dir/sstate/PATH"
@@ -1998,7 +1998,7 @@ tasks on which it is dependent are not executed.
1998 1998
1999As a real world example, the aim is when building an IPK-based image, 1999As a real world example, the aim is when building an IPK-based image,
2000only the 2000only the
2001```do_package_write_ipk`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_ipk>`__ 2001:ref:`ref-tasks-package_write_ipk`
2002tasks would have their shared state packages fetched and extracted. 2002tasks would have their shared state packages fetched and extracted.
2003Since the sysroot is not used, it would never get extracted. This is 2003Since the sysroot is not used, it would never get extracted. This is
2004another reason why a task-based approach is preferred over a 2004another reason why a task-based approach is preferred over a
@@ -2011,22 +2011,22 @@ Automatically Added Runtime Dependencies
2011The OpenEmbedded build system automatically adds common types of runtime 2011The OpenEmbedded build system automatically adds common types of runtime
2012dependencies between packages, which means that you do not need to 2012dependencies between packages, which means that you do not need to
2013explicitly declare the packages using 2013explicitly declare the packages using
2014```RDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-RDEPENDS>`__. Three automatic 2014:term:`RDEPENDS`. Three automatic
2015mechanisms exist (``shlibdeps``, ``pcdeps``, and ``depchains``) that 2015mechanisms exist (``shlibdeps``, ``pcdeps``, and ``depchains``) that
2016handle shared libraries, package configuration (pkg-config) modules, and 2016handle shared libraries, package configuration (pkg-config) modules, and
2017``-dev`` and ``-dbg`` packages, respectively. For other types of runtime 2017``-dev`` and ``-dbg`` packages, respectively. For other types of runtime
2018dependencies, you must manually declare the dependencies. 2018dependencies, you must manually declare the dependencies.
2019 2019
2020- ``shlibdeps``: During the 2020- ``shlibdeps``: During the
2021 ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ task of 2021 :ref:`ref-tasks-package` task of
2022 each recipe, all shared libraries installed by the recipe are 2022 each recipe, all shared libraries installed by the recipe are
2023 located. For each shared library, the package that contains the 2023 located. For each shared library, the package that contains the
2024 shared library is registered as providing the shared library. More 2024 shared library is registered as providing the shared library. More
2025 specifically, the package is registered as providing the 2025 specifically, the package is registered as providing the
2026 `soname <https://en.wikipedia.org/wiki/Soname>`__ of the library. The 2026 `soname <https://en.wikipedia.org/wiki/Soname>`__ of the library. The
2027 resulting shared-library-to-package mapping is saved globally in 2027 resulting shared-library-to-package mapping is saved globally in
2028 ```PKGDATA_DIR`` <&YOCTO_DOCS_REF_URL;#var-PKGDATA_DIR>`__ by the 2028 :term:`PKGDATA_DIR` by the
2029 ```do_packagedata`` <&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata>`__ 2029 :ref:`ref-tasks-packagedata`
2030 task. 2030 task.
2031 2031
2032 Simultaneously, all executables and shared libraries installed by the 2032 Simultaneously, all executables and shared libraries installed by the
@@ -2047,7 +2047,7 @@ dependencies, you must manually declare the dependencies.
2047 If you want to avoid a package being registered as providing a 2047 If you want to avoid a package being registered as providing a
2048 particular shared library (e.g. because the library is for internal 2048 particular shared library (e.g. because the library is for internal
2049 use only), then add the library to 2049 use only), then add the library to
2050 ```PRIVATE_LIBS`` <&YOCTO_DOCS_REF_URL;#var-PRIVATE_LIBS>`__ inside 2050 :term:`PRIVATE_LIBS` inside
2051 the package's recipe. 2051 the package's recipe.
2052 2052
2053- ``pcdeps``: During the ``do_package`` task of each recipe, all 2053- ``pcdeps``: During the ``do_package`` task of each recipe, all
@@ -2082,7 +2082,7 @@ dependencies, you must manually declare the dependencies.
2082 need for a dependency between the packages. 2082 need for a dependency between the packages.
2083 2083
2084 The dependencies added by ``depchains`` are in the form of 2084 The dependencies added by ``depchains`` are in the form of
2085 ```RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS>`__. 2085 :term:`RRECOMMENDS`.
2086 2086
2087 .. note:: 2087 .. note::
2088 2088
@@ -2101,11 +2101,11 @@ dependencies, you must manually declare the dependencies.
2101 To ensure that the dependency chain is never broken, ``-dev`` and 2101 To ensure that the dependency chain is never broken, ``-dev`` and
2102 ``-dbg`` packages are always generated by default, even if the 2102 ``-dbg`` packages are always generated by default, even if the
2103 packages turn out to be empty. See the 2103 packages turn out to be empty. See the
2104 ```ALLOW_EMPTY`` <&YOCTO_DOCS_REF_URL;#var-ALLOW_EMPTY>`__ variable 2104 :term:`ALLOW_EMPTY` variable
2105 for more information. 2105 for more information.
2106 2106
2107The ``do_package`` task depends on the ``do_packagedata`` task of each 2107The ``do_package`` task depends on the ``do_packagedata`` task of each
2108recipe in ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ through use 2108recipe in :term:`DEPENDS` through use
2109of a ``[``\ ```deptask`` <&YOCTO_DOCS_BB_URL;#variable-flags>`__\ ``]`` 2109of a ``[``\ ```deptask`` <&YOCTO_DOCS_BB_URL;#variable-flags>`__\ ``]``
2110declaration, which guarantees that the required 2110declaration, which guarantees that the required
2111shared-library/module-to-package mapping information will be available 2111shared-library/module-to-package mapping information will be available
@@ -2116,15 +2116,15 @@ Fakeroot and Pseudo
2116 2116
2117Some tasks are easier to implement when allowed to perform certain 2117Some tasks are easier to implement when allowed to perform certain
2118operations that are normally reserved for the root user (e.g. 2118operations that are normally reserved for the root user (e.g.
2119```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__, 2119:ref:`ref-tasks-install`,
2120```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__, 2120```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__,
2121```do_rootfs`` <&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs>`__, and 2121:ref:`ref-tasks-rootfs`, and
2122```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example, 2122```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example,
2123the ``do_install`` task benefits from being able to set the UID and GID 2123the ``do_install`` task benefits from being able to set the UID and GID
2124of installed files to arbitrary values. 2124of installed files to arbitrary values.
2125 2125
2126One approach to allowing tasks to perform root-only operations would be 2126One approach to allowing tasks to perform root-only operations would be
2127to require `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ to run as 2127to require :term:`BitBake` to run as
2128root. However, this method is cumbersome and has security issues. The 2128root. However, this method is cumbersome and has security issues. The
2129approach that is actually used is to run tasks that benefit from root 2129approach that is actually used is to run tasks that benefit from root
2130privileges in a "fake" root environment. Within this environment, the 2130privileges in a "fake" root environment. Within this environment, the
@@ -2148,7 +2148,7 @@ which results in the illusion of running as root. To keep track of
2148"fake" file ownership and permissions resulting from operations that 2148"fake" file ownership and permissions resulting from operations that
2149require root permissions, Pseudo uses an SQLite 3 database. This 2149require root permissions, Pseudo uses an SQLite 3 database. This
2150database is stored in 2150database is stored in
2151``${``\ ```WORKDIR`` <&YOCTO_DOCS_REF_URL;#var-WORKDIR>`__\ ``}/pseudo/files.db`` 2151``${``\ :term:`WORKDIR`\ ``}/pseudo/files.db``
2152for individual recipes. Storing the database in a file as opposed to in 2152for individual recipes. Storing the database in a file as opposed to in
2153memory gives persistence between tasks and builds, which is not 2153memory gives persistence between tasks and builds, which is not
2154accomplished using fakeroot. 2154accomplished using fakeroot.
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index d59e52c488..745d2ecf91 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -149,7 +149,7 @@ Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the
149interface, you can click on any particular item in the "Name" column and 149interface, you can click on any particular item in the "Name" column and
150see the URL at the bottom of the page that you need to clone a Git 150see the URL at the bottom of the page that you need to clone a Git
151repository for that particular item. Having a local Git repository of 151repository for that particular item. Having a local Git repository of
152the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which 152the :term:`Source Directory`, which
153is usually named "poky", allows you to make changes, contribute to the 153is usually named "poky", allows you to make changes, contribute to the
154history, and ultimately enhance the Yocto Project's tools, Board Support 154history, and ultimately enhance the Yocto Project's tools, Board Support
155Packages, and so forth. 155Packages, and so forth.
@@ -636,7 +636,7 @@ find information on the GNU GPL
636 636
637When you build an image using the Yocto Project, the build process uses 637When you build an image using the Yocto Project, the build process uses
638a known list of licenses to ensure compliance. You can find this list in 638a known list of licenses to ensure compliance. You can find this list in
639the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at 639the :term:`Source Directory` at
640``meta/files/common-licenses``. Once the build completes, the list of 640``meta/files/common-licenses``. Once the build completes, the list of
641all licenses found and used during that build are kept in the `Build 641all licenses found and used during that build are kept in the `Build
642Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at 642Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at
@@ -660,7 +660,7 @@ that conform to the Open Source Definition (OSD).
660 660
661You can find a list of the combined SPDX and OSI licenses that the Yocto 661You can find a list of the combined SPDX and OSI licenses that the Yocto
662Project uses in the ``meta/files/common-licenses`` directory in your 662Project uses in the ``meta/files/common-licenses`` directory in your
663`Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. 663:term:`Source Directory`.
664 664
665For information that can help you maintain compliance with various open 665For information that can help you maintain compliance with various open
666source licensing during the lifecycle of a product created using the 666source licensing during the lifecycle of a product created using the
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index 3f845731a0..b27412cb25 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -260,7 +260,7 @@ accomplish this through a recipe that is a BitBake append
260 Yocto Project Board Support Packages (BSP) Developer's Guide 260 Yocto Project Board Support Packages (BSP) Developer's Guide
261 . 261 .
262 262
263The `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ 263The :term:`Source Directory`
264contains both general layers and BSP layers right out of the box. You 264contains both general layers and BSP layers right out of the box. You
265can easily identify layers that ship with a Yocto Project release in the 265can easily identify layers that ship with a Yocto Project release in the
266Source Directory by their names. Layers typically have names that begin 266Source Directory by their names. Layers typically have names that begin
@@ -461,7 +461,7 @@ Open-Embedded Build System Components
461------------------------------------- 461-------------------------------------
462 462
463The following list consists of components associated with the 463The following list consists of components associated with the
464`OpenEmbedded build system <&YOCTO_DOCS_REF_URL;#build-system-term>`__: 464:term:`OpenEmbedded Build System`:
465 465
466- *BitBake:* BitBake is a core component of the Yocto Project and is 466- *BitBake:* BitBake is a core component of the Yocto Project and is
467 used by the OpenEmbedded build system to build images. While BitBake 467 used by the OpenEmbedded build system to build images. While BitBake
@@ -508,7 +508,7 @@ Reference Distribution (Poky)
508----------------------------- 508-----------------------------
509 509
510Poky is the Yocto Project reference distribution. It contains the 510Poky is the Yocto Project reference distribution. It contains the
511`Open-Embedded build system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ 511:term:`OpenEmbedded Build System`
512(BitBake and OE-Core) as well as a set of metadata to get you started 512(BitBake and OE-Core) as well as a set of metadata to get you started
513building your own distribution. See the 513building your own distribution. See the
514`figure <#what-is-the-yocto-project>`__ in "What is the Yocto Project?" 514`figure <#what-is-the-yocto-project>`__ in "What is the Yocto Project?"
@@ -618,7 +618,7 @@ Project.
618- *Native Linux Host:* By far the best option for a Build Host. A 618- *Native Linux Host:* By far the best option for a Build Host. A
619 system running Linux as its native operating system allows you to 619 system running Linux as its native operating system allows you to
620 develop software by directly using the 620 develop software by directly using the
621 `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ tool. You can 621 :term:`BitBake` tool. You can
622 accomplish all aspects of development from a familiar shell of a 622 accomplish all aspects of development from a familiar shell of a
623 supported Linux distribution. 623 supported Linux distribution.
624 624
@@ -684,9 +684,9 @@ Reference Embedded Distribution (Poky)
684 684
685"Poky", which is pronounced *Pock*-ee, is the name of the Yocto 685"Poky", which is pronounced *Pock*-ee, is the name of the Yocto
686Project's reference distribution or Reference OS Kit. Poky contains the 686Project's reference distribution or Reference OS Kit. Poky contains the
687`OpenEmbedded Build System <&YOCTO_DOCS_REF_URL;#build-system-term>`__ 687:term:`OpenEmbedded Build System`
688(`BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ and 688(:term:`BitBake` and
689`OpenEmbedded-Core <&YOCTO_DOCS_REF_URL;#oe-core>`__) as well as a set 689:term:`OpenEmbedded-Core (OE-Core)`) as well as a set
690of `metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ to get you started 690of `metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ to get you started
691building your own distro. In other words, Poky is a base specification 691building your own distro. In other words, Poky is a base specification
692of the functionality needed for a typical embedded system as well as the 692of the functionality needed for a typical embedded system as well as the
@@ -923,9 +923,9 @@ helpful for getting started:
923 Another point worth noting is that historically within the Yocto 923 Another point worth noting is that historically within the Yocto
924 Project, recipes were referred to as packages - thus, the existence 924 Project, recipes were referred to as packages - thus, the existence
925 of several BitBake variables that are seemingly mis-named, (e.g. 925 of several BitBake variables that are seemingly mis-named, (e.g.
926 ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__, 926 :term:`PR`,
927 ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__, and 927 :term:`PV`, and
928 ```PE`` <&YOCTO_DOCS_REF_URL;#var-PE>`__). 928 :term:`PE`).
929 929
930- *Poky:* Poky is a reference embedded distribution and a reference 930- *Poky:* Poky is a reference embedded distribution and a reference
931 test configuration. Poky provides the following: 931 test configuration. Poky provides the following:
diff --git a/documentation/profile-manual/profile-manual-intro.rst b/documentation/profile-manual/profile-manual-intro.rst
index d4d0ba4dc8..5d51df74dc 100644
--- a/documentation/profile-manual/profile-manual-intro.rst
+++ b/documentation/profile-manual/profile-manual-intro.rst
@@ -51,7 +51,7 @@ well e.g.: $ bitbake core-image-sato
51 it packages, which makes it difficult to use some of the tools. 51 it packages, which makes it difficult to use some of the tools.
52 52
53 You can prevent that by setting the 53 You can prevent that by setting the
54 ```INHIBIT_PACKAGE_STRIP`` <&YOCTO_DOCS_REF_URL;#var-INHIBIT_PACKAGE_STRIP>`__ 54 :term:`INHIBIT_PACKAGE_STRIP`
55 variable to "1" in your ``local.conf`` when you build the image: 55 variable to "1" in your ``local.conf`` when you build the image:
56 56
57INHIBIT_PACKAGE_STRIP = "1" The above setting will noticeably increase 57INHIBIT_PACKAGE_STRIP = "1" The above setting will noticeably increase
@@ -64,6 +64,6 @@ To generate debug info for packages, you can add dbg-pkgs to
64EXTRA_IMAGE_FEATURES in local.conf. For example: EXTRA_IMAGE_FEATURES = 64EXTRA_IMAGE_FEATURES in local.conf. For example: EXTRA_IMAGE_FEATURES =
65"debug-tweaks tools-profile dbg-pkgs" Additionally, in order to generate 65"debug-tweaks tools-profile dbg-pkgs" Additionally, in order to generate
66the right type of debuginfo, we also need to set 66the right type of debuginfo, we also need to set
67```PACKAGE_DEBUG_SPLIT_STYLE`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_DEBUG_SPLIT_STYLE>`__ 67:term:`PACKAGE_DEBUG_SPLIT_STYLE`
68in the ``local.conf`` file: PACKAGE_DEBUG_SPLIT_STYLE = 68in the ``local.conf`` file: PACKAGE_DEBUG_SPLIT_STYLE =
69'debug-file-directory' 69'debug-file-directory'
diff --git a/documentation/profile-manual/profile-manual-usage.rst b/documentation/profile-manual/profile-manual-usage.rst
index a2206cc829..b97a1c6e96 100644
--- a/documentation/profile-manual/profile-manual-usage.rst
+++ b/documentation/profile-manual/profile-manual-usage.rst
@@ -50,7 +50,7 @@ outlined in the General Setup section.
50 50
51In particular, you'll get the most mileage out of perf if you profile an 51In particular, you'll get the most mileage out of perf if you profile an
52image built with the following in your ``local.conf`` file: 52image built with the following in your ``local.conf`` file:
53`INHIBIT_PACKAGE_STRIP <&YOCTO_DOCS_REF_URL;#var-INHIBIT_PACKAGE_STRIP>`__ 53:term:`INHIBIT_PACKAGE_STRIP`
54= "1" 54= "1"
55 55
56perf runs on the target system for the most part. You can archive 56perf runs on the target system for the most part. You can archive
@@ -246,7 +246,7 @@ system.
246 246
247One way around that is to put the following in your ``local.conf`` file 247One way around that is to put the following in your ``local.conf`` file
248when you build the image: 248when you build the image:
249`INHIBIT_PACKAGE_STRIP <&YOCTO_DOCS_REF_URL;#var-INHIBIT_PACKAGE_STRIP>`__ 249:term:`INHIBIT_PACKAGE_STRIP`
250= "1" However, we already have an image with the binaries stripped, so 250= "1" However, we already have an image with the binaries stripped, so
251what can we do to get perf to resolve the symbols? Basically we need to 251what can we do to get perf to resolve the symbols? Basically we need to
252install the debuginfo for the busybox package. 252install the debuginfo for the busybox package.
@@ -256,7 +256,7 @@ dbg-pkgs to EXTRA_IMAGE_FEATURES in local.conf. For example:
256EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs" 256EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
257Additionally, in order to generate the type of debuginfo that perf 257Additionally, in order to generate the type of debuginfo that perf
258understands, we also need to set 258understands, we also need to set
259```PACKAGE_DEBUG_SPLIT_STYLE`` <&YOCTO_DOCS_REF_URL;#var-PACKAGE_DEBUG_SPLIT_STYLE>`__ 259:term:`PACKAGE_DEBUG_SPLIT_STYLE`
260in the ``local.conf`` file: PACKAGE_DEBUG_SPLIT_STYLE = 260in the ``local.conf`` file: PACKAGE_DEBUG_SPLIT_STYLE =
261'debug-file-directory' Once we've done that, we can install the 261'debug-file-directory' Once we've done that, we can install the
262debuginfo for busybox. The debug packages once built can be found in 262debuginfo for busybox. The debug packages once built can be found in
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index d3dac28b0f..07244a0311 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -8,7 +8,7 @@ FAQ
8 8
9**A:** The term "`Poky <#>`__" refers to the specific reference build 9**A:** The term "`Poky <#>`__" refers to the specific reference build
10system that the Yocto Project provides. Poky is based on 10system that the Yocto Project provides. Poky is based on
11`OE-Core <#oe-core>`__ and `BitBake <#bitbake-term>`__. Thus, the 11:term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the
12generic term used here for the build system is the "OpenEmbedded build 12generic term used here for the build system is the "OpenEmbedded build
13system." Development in the Yocto Project using Poky is closely tied to 13system." Development in the Yocto Project using Poky is closely tied to
14OpenEmbedded, with changes always being merged to OE-Core or BitBake 14OpenEmbedded, with changes always being merged to OE-Core or BitBake
@@ -29,7 +29,7 @@ steps on how to update your build tools.
29 29
30**A:** There are three areas that help with stability; 30**A:** There are three areas that help with stability;
31 31
32- The Yocto Project team keeps `OE-Core <#oe-core>`__ small and 32- The Yocto Project team keeps :term:`OpenEmbedded-Core (OE-Core)` small and
33 focused, containing around 830 recipes as opposed to the thousands 33 focused, containing around 830 recipes as opposed to the thousands
34 available in other OpenEmbedded community layers. Keeping it small 34 available in other OpenEmbedded community layers. Keeping it small
35 makes it easy to test and maintain. 35 makes it easy to test and maintain.
@@ -227,19 +227,19 @@ meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
227size, you need to set various configurations: 227size, you need to set various configurations:
228 228
229- *Image Size:* The OpenEmbedded build system uses the 229- *Image Size:* The OpenEmbedded build system uses the
230 ```IMAGE_ROOTFS_SIZE`` <#var-IMAGE_ROOTFS_SIZE>`__ variable to define 230 :term:`IMAGE_ROOTFS_SIZE` variable to define
231 the size of the image in Kbytes. The build system determines the size 231 the size of the image in Kbytes. The build system determines the size
232 by taking into account the initial root filesystem size before any 232 by taking into account the initial root filesystem size before any
233 modifications such as requested size for the image and any requested 233 modifications such as requested size for the image and any requested
234 additional free disk space to be added to the image. 234 additional free disk space to be added to the image.
235 235
236- *Overhead:* Use the 236- *Overhead:* Use the
237 ```IMAGE_OVERHEAD_FACTOR`` <#var-IMAGE_OVERHEAD_FACTOR>`__ variable 237 :term:`IMAGE_OVERHEAD_FACTOR` variable
238 to define the multiplier that the build system applies to the initial 238 to define the multiplier that the build system applies to the initial
239 image size, which is 1.3 by default. 239 image size, which is 1.3 by default.
240 240
241- *Additional Free Space:* Use the 241- *Additional Free Space:* Use the
242 ```IMAGE_ROOTFS_EXTRA_SPACE`` <#var-IMAGE_ROOTFS_EXTRA_SPACE>`__ 242 :term:`IMAGE_ROOTFS_EXTRA_SPACE`
243 variable to add additional free space to the image. The build system 243 variable to add additional free space to the image. The build system
244 adds this space to the image after it determines its 244 adds this space to the image after it determines its
245 ``IMAGE_ROOTFS_SIZE``. 245 ``IMAGE_ROOTFS_SIZE``.
@@ -281,8 +281,8 @@ environments if HTTP transport is available.
281 281
282When the build system searches for source code, it first tries the local 282When the build system searches for source code, it first tries the local
283download directory. If that location fails, Poky tries 283download directory. If that location fails, Poky tries
284```PREMIRRORS`` <#var-PREMIRRORS>`__, the upstream source, and then 284:term:`PREMIRRORS`, the upstream source, and then
285```MIRRORS`` <#var-MIRRORS>`__ in that order. 285:term:`MIRRORS` in that order.
286 286
287Assuming your distribution is "poky", the OpenEmbedded build system uses 287Assuming your distribution is "poky", the OpenEmbedded build system uses
288the Yocto Project source ``PREMIRRORS`` by default for SCM-based 288the Yocto Project source ``PREMIRRORS`` by default for SCM-based
@@ -409,7 +409,7 @@ my recipe is installing to the wrong place, or I am getting permissions
409errors during the do_install task in my recipe! What is wrong? 409errors during the do_install task in my recipe! What is wrong?
410 410
411**A:** This situation results when a build system does not recognize the 411**A:** This situation results when a build system does not recognize the
412environment variables supplied to it by `BitBake <#bitbake-term>`__. The 412environment variables supplied to it by :term:`BitBake`. The
413incident that prompted this FAQ entry involved a Makefile that used an 413incident that prompted this FAQ entry involved a Makefile that used an
414environment variable named ``BINDIR`` instead of the more standard 414environment variable named ``BINDIR`` instead of the more standard
415variable ``bindir``. The makefile's hardcoded default value of 415variable ``bindir``. The makefile's hardcoded default value of
diff --git a/documentation/ref-manual/migration.rst b/documentation/ref-manual/migration.rst
index 8a309d003b..b8d27f3325 100644
--- a/documentation/ref-manual/migration.rst
+++ b/documentation/ref-manual/migration.rst
@@ -68,7 +68,7 @@ Local Configuration
68------------------- 68-------------------
69 69
70Differences include changes for 70Differences include changes for
71```SSTATE_MIRRORS`` <#var-SSTATE_MIRRORS>`__ and ``bblayers.conf``. 71:term:`SSTATE_MIRRORS` and ``bblayers.conf``.
72 72
73.. _migration-1.3-sstate-mirrors: 73.. _migration-1.3-sstate-mirrors:
74 74
@@ -76,13 +76,13 @@ SSTATE_MIRRORS
76~~~~~~~~~~~~~~ 76~~~~~~~~~~~~~~
77 77
78The shared state cache (sstate-cache), as pointed to by 78The shared state cache (sstate-cache), as pointed to by
79```SSTATE_DIR`` <#var-SSTATE_DIR>`__, by default now has two-character 79:term:`SSTATE_DIR`, by default now has two-character
80subdirectories to prevent issues arising from too many files in the same 80subdirectories to prevent issues arising from too many files in the same
81directory. Also, native sstate-cache packages, which are built to run on 81directory. Also, native sstate-cache packages, which are built to run on
82the host system, will go into a subdirectory named using the distro ID 82the host system, will go into a subdirectory named using the distro ID
83string. If you copy the newly structured sstate-cache to a mirror 83string. If you copy the newly structured sstate-cache to a mirror
84location (either local or remote) and then point to it in 84location (either local or remote) and then point to it in
85```SSTATE_MIRRORS`` <#var-SSTATE_MIRRORS>`__, you need to append "PATH" 85:term:`SSTATE_MIRRORS`, you need to append "PATH"
86to the end of the mirror URL so that the path used by BitBake before the 86to the end of the mirror URL so that the path used by BitBake before the
87mirror substitution is appended to the path used to access the mirror. 87mirror substitution is appended to the path used to access the mirror.
88Here is an example: SSTATE_MIRRORS = "file://.\* 88Here is an example: SSTATE_MIRRORS = "file://.\*
@@ -138,7 +138,7 @@ four-space indentation.
138proto= in SRC_URI 138proto= in SRC_URI
139~~~~~~~~~~~~~~~~~ 139~~~~~~~~~~~~~~~~~
140 140
141Any use of ``proto=`` in ```SRC_URI`` <#var-SRC_URI>`__ needs to be 141Any use of ``proto=`` in :term:`SRC_URI` needs to be
142changed to ``protocol=``. In particular, this applies to the following 142changed to ``protocol=``. In particular, this applies to the following
143URIs: 143URIs:
144 144
@@ -161,7 +161,7 @@ nativesdk
161The suffix ``nativesdk`` is now implemented as a prefix, which 161The suffix ``nativesdk`` is now implemented as a prefix, which
162simplifies a lot of the packaging code for ``nativesdk`` recipes. All 162simplifies a lot of the packaging code for ``nativesdk`` recipes. All
163custom ``nativesdk`` recipes, which are relocatable packages that are 163custom ``nativesdk`` recipes, which are relocatable packages that are
164native to ```SDK_ARCH`` <#var-SDK_ARCH>`__, and any references need to 164native to :term:`SDK_ARCH`, and any references need to
165be updated to use ``nativesdk-*`` instead of ``*-nativesdk``. 165be updated to use ``nativesdk-*`` instead of ``*-nativesdk``.
166 166
167.. _migration-1.3-task-recipes: 167.. _migration-1.3-task-recipes:
@@ -179,8 +179,8 @@ recipes to ``packagegroup-*``, and change them to inherit
179``packagegroup`` instead of ``task``, as well as taking the opportunity 179``packagegroup`` instead of ``task``, as well as taking the opportunity
180to remove anything now handled by ``packagegroup.bbclass``, such as 180to remove anything now handled by ``packagegroup.bbclass``, such as
181providing ``-dev`` and ``-dbg`` packages, setting 181providing ``-dev`` and ``-dbg`` packages, setting
182```LIC_FILES_CHKSUM`` <#var-LIC_FILES_CHKSUM>`__, and so forth. See the 182:term:`LIC_FILES_CHKSUM`, and so forth. See the
183"```packagegroup.bbclass`` <#ref-classes-packagegroup>`__" section for 183":ref:`packagegroup.bbclass <ref-classes-packagegroup>`" section for
184further details. 184further details.
185 185
186.. _migration-1.3-image-features: 186.. _migration-1.3-image-features:
@@ -189,7 +189,7 @@ IMAGE_FEATURES
189~~~~~~~~~~~~~~ 189~~~~~~~~~~~~~~
190 190
191Image recipes that previously included "apps-console-core" in 191Image recipes that previously included "apps-console-core" in
192```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ should now include "splash" 192:term:`IMAGE_FEATURES` should now include "splash"
193instead to enable the boot-up splash screen. Retaining 193instead to enable the boot-up splash screen. Retaining
194"apps-console-core" will still include the splash screen but generates a 194"apps-console-core" will still include the splash screen but generates a
195warning. The "apps-x11-core" and "apps-x11-games" ``IMAGE_FEATURES`` 195warning. The "apps-x11-core" and "apps-x11-games" ``IMAGE_FEATURES``
@@ -202,7 +202,7 @@ Removed Recipes
202 202
203The following recipes have been removed. For most of them, it is 203The following recipes have been removed. For most of them, it is
204unlikely that you would have any references to them in your own 204unlikely that you would have any references to them in your own
205`Metadata <#metadata>`__. However, you should check your metadata 205:term:`Metadata`. However, you should check your metadata
206against this list to be sure: 206against this list to be sure:
207 207
208- *``libx11-trim``*: Replaced by ``libx11``, which has a negligible 208- *``libx11-trim``*: Replaced by ``libx11``, which has a negligible
@@ -247,7 +247,7 @@ Linux Kernel Naming
247------------------- 247-------------------
248 248
249The naming scheme for kernel output binaries has been changed to now 249The naming scheme for kernel output binaries has been changed to now
250include ```PE`` <#var-PE>`__ as part of the filename: 250include :term:`PE` as part of the filename:
251KERNEL_IMAGE_BASE_NAME ?= 251KERNEL_IMAGE_BASE_NAME ?=
252"${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}" 252"${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
253 253
@@ -276,13 +276,13 @@ Differences include the following:
276 a comment. 276 a comment.
277 277
278- *Package Name Overrides:* The runtime package specific variables 278- *Package Name Overrides:* The runtime package specific variables
279 ```RDEPENDS`` <#var-RDEPENDS>`__, 279 :term:`RDEPENDS`,
280 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, 280 :term:`RRECOMMENDS`,
281 ```RSUGGESTS`` <#var-RSUGGESTS>`__, 281 :term:`RSUGGESTS`,
282 ```RPROVIDES`` <#var-RPROVIDES>`__, 282 :term:`RPROVIDES`,
283 ```RCONFLICTS`` <#var-RCONFLICTS>`__, 283 :term:`RCONFLICTS`,
284 ```RREPLACES`` <#var-RREPLACES>`__, ```FILES`` <#var-FILES>`__, 284 :term:`RREPLACES`, :term:`FILES`,
285 ```ALLOW_EMPTY`` <#var-ALLOW_EMPTY>`__, and the pre, post, install, 285 :term:`ALLOW_EMPTY`, and the pre, post, install,
286 and uninstall script functions ``pkg_preinst``, ``pkg_postinst``, 286 and uninstall script functions ``pkg_preinst``, ``pkg_postinst``,
287 ``pkg_prerm``, and ``pkg_postrm`` should always have a package name 287 ``pkg_prerm``, and ``pkg_postrm`` should always have a package name
288 override. For example, use ``RDEPENDS_${PN}`` for the main package 288 override. For example, use ``RDEPENDS_${PN}`` for the main package
@@ -305,15 +305,15 @@ Differences include the following:
305 you have missing declared dependencies. 305 you have missing declared dependencies.
306 306
307- *Scanning Directory Names:* When scanning for files in 307- *Scanning Directory Names:* When scanning for files in
308 ```SRC_URI`` <#var-SRC_URI>`__, the build system now uses 308 :term:`SRC_URI`, the build system now uses
309 ```FILESOVERRIDES`` <#var-FILESOVERRIDES>`__ instead of 309 :term:`FILESOVERRIDES` instead of
310 ```OVERRIDES`` <#var-OVERRIDES>`__ for the directory names. In 310 :term:`OVERRIDES` for the directory names. In
311 general, the values previously in ``OVERRIDES`` are now in 311 general, the values previously in ``OVERRIDES`` are now in
312 ``FILESOVERRIDES`` as well. However, if you relied upon an additional 312 ``FILESOVERRIDES`` as well. However, if you relied upon an additional
313 value you previously added to ``OVERRIDES``, you might now need to 313 value you previously added to ``OVERRIDES``, you might now need to
314 add it to ``FILESOVERRIDES`` unless you are already adding it through 314 add it to ``FILESOVERRIDES`` unless you are already adding it through
315 the ```MACHINEOVERRIDES`` <#var-MACHINEOVERRIDES>`__ or 315 the :term:`MACHINEOVERRIDES` or
316 ```DISTROOVERRIDES`` <#var-DISTROOVERRIDES>`__ variables, as 316 :term:`DISTROOVERRIDES` variables, as
317 appropriate. For more related changes, see the 317 appropriate. For more related changes, see the
318 "`Variables <#migration-1.4-variables>`__" section. 318 "`Variables <#migration-1.4-variables>`__" section.
319 319
@@ -335,7 +335,7 @@ Custom Interfaces File (netbase change)
335If you have created your own custom ``etc/network/interfaces`` file by 335If you have created your own custom ``etc/network/interfaces`` file by
336creating an append file for the ``netbase`` recipe, you now need to 336creating an append file for the ``netbase`` recipe, you now need to
337create an append file for the ``init-ifupdown`` recipe instead, which 337create an append file for the ``init-ifupdown`` recipe instead, which
338you can find in the `Source Directory <#source-directory>`__ at 338you can find in the :term:`Source Directory` at
339``meta/recipes-core/init-ifupdown``. For information on how to use 339``meta/recipes-core/init-ifupdown``. For information on how to use
340append files, see the "`Using .bbappend 340append files, see the "`Using .bbappend
341Files <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the 341Files <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the
@@ -363,24 +363,24 @@ The following variables have changed:
363- *``SANITY_TESTED_DISTROS``:* This variable now uses a distribution 363- *``SANITY_TESTED_DISTROS``:* This variable now uses a distribution
364 ID, which is composed of the host distributor ID followed by the 364 ID, which is composed of the host distributor ID followed by the
365 release. Previously, 365 release. Previously,
366 ```SANITY_TESTED_DISTROS`` <#var-SANITY_TESTED_DISTROS>`__ was 366 :term:`SANITY_TESTED_DISTROS` was
367 composed of the description field. For example, "Ubuntu 12.10" 367 composed of the description field. For example, "Ubuntu 12.10"
368 becomes "Ubuntu-12.10". You do not need to worry about this change if 368 becomes "Ubuntu-12.10". You do not need to worry about this change if
369 you are not specifically setting this variable, or if you are 369 you are not specifically setting this variable, or if you are
370 specifically setting it to "". 370 specifically setting it to "".
371 371
372- *``SRC_URI``:* The ``${``\ ```PN`` <#var-PN>`__\ ``}``, 372- *``SRC_URI``:* The ``${``\ :term:`PN`\ ``}``,
373 ``${``\ ```PF`` <#var-PF>`__\ ``}``, 373 ``${``\ :term:`PF`\ ``}``,
374 ``${``\ ```P`` <#var-P>`__\ ``}``, and ``FILE_DIRNAME`` directories 374 ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories
375 have been dropped from the default value of the 375 have been dropped from the default value of the
376 ```FILESPATH`` <#var-FILESPATH>`__ variable, which is used as the 376 :term:`FILESPATH` variable, which is used as the
377 search path for finding files referred to in 377 search path for finding files referred to in
378 ```SRC_URI`` <#var-SRC_URI>`__. If you have a recipe that relied upon 378 :term:`SRC_URI`. If you have a recipe that relied upon
379 these directories, which would be unusual, then you will need to add 379 these directories, which would be unusual, then you will need to add
380 the appropriate paths within the recipe or, alternatively, rearrange 380 the appropriate paths within the recipe or, alternatively, rearrange
381 the files. The most common locations are still covered by ``${BP}``, 381 the files. The most common locations are still covered by ``${BP}``,
382 ``${BPN}``, and "files", which all remain in the default value of 382 ``${BPN}``, and "files", which all remain in the default value of
383 ```FILESPATH`` <#var-FILESPATH>`__. 383 :term:`FILESPATH`.
384 384
385.. _migration-target-package-management-with-rpm: 385.. _migration-target-package-management-with-rpm:
386 386
@@ -554,9 +554,9 @@ The following changes have been made that relate to BitBake:
554 554
555- The ``bitbake-runtask`` script has been removed. 555- The ``bitbake-runtask`` script has been removed.
556 556
557- ``${``\ ```P`` <#var-P>`__\ ``}`` and 557- ``${``\ :term:`P`\ ``}`` and
558 ``${``\ ```PF`` <#var-PF>`__\ ``}`` are no longer added to 558 ``${``\ :term:`PF`\ ``}`` are no longer added to
559 ```PROVIDES`` <#var-PROVIDES>`__ by default in ``bitbake.conf``. 559 :term:`PROVIDES` by default in ``bitbake.conf``.
560 These version-specific ``PROVIDES`` items were seldom used. 560 These version-specific ``PROVIDES`` items were seldom used.
561 Attempting to use them could result in two versions being built 561 Attempting to use them could result in two versions being built
562 simultaneously rather than just one version due to the way BitBake 562 simultaneously rather than just one version due to the way BitBake
@@ -569,19 +569,19 @@ QA Warnings
569 569
570The following changes have been made to the package QA checks: 570The following changes have been made to the package QA checks:
571 571
572- If you have customized ```ERROR_QA`` <#var-ERROR_QA>`__ or 572- If you have customized :term:`ERROR_QA` or
573 ```WARN_QA`` <#var-WARN_QA>`__ values in your configuration, check 573 :term:`WARN_QA` values in your configuration, check
574 that they contain all of the issues that you wish to be reported. 574 that they contain all of the issues that you wish to be reported.
575 Previous Yocto Project versions contained a bug that meant that any 575 Previous Yocto Project versions contained a bug that meant that any
576 item not mentioned in ``ERROR_QA`` or ``WARN_QA`` would be treated as 576 item not mentioned in ``ERROR_QA`` or ``WARN_QA`` would be treated as
577 a warning. Consequently, several important items were not already in 577 a warning. Consequently, several important items were not already in
578 the default value of ``WARN_QA``. All of the possible QA checks are 578 the default value of ``WARN_QA``. All of the possible QA checks are
579 now documented in the "```insane.bbclass`` <#ref-classes-insane>`__" 579 now documented in the ":ref:`insane.bbclass <ref-classes-insane>`"
580 section. 580 section.
581 581
582- An additional QA check has been added to check if 582- An additional QA check has been added to check if
583 ``/usr/share/info/dir`` is being installed. Your recipe should delete 583 ``/usr/share/info/dir`` is being installed. Your recipe should delete
584 this file within ```do_install`` <#ref-tasks-install>`__ if "make 584 this file within :ref:`ref-tasks-install` if "make
585 install" is installing it. 585 install" is installing it.
586 586
587- If you are using the buildhistory class, the check for the package 587- If you are using the buildhistory class, the check for the package
@@ -591,7 +591,7 @@ The following changes have been made to the package QA checks:
591 "version-going-backwards" to your value for one or the other 591 "version-going-backwards" to your value for one or the other
592 variables depending on how you wish it to be handled. See the 592 variables depending on how you wish it to be handled. See the
593 documented QA checks in the 593 documented QA checks in the
594 "```insane.bbclass`` <#ref-classes-insane>`__" section. 594 ":ref:`insane.bbclass <ref-classes-insane>`" section.
595 595
596.. _migration-1.5-directory-layout-changes: 596.. _migration-1.5-directory-layout-changes:
597 597
@@ -601,25 +601,25 @@ Directory Layout Changes
601The following directory changes exist: 601The following directory changes exist:
602 602
603- Output SDK installer files are now named to include the image name 603- Output SDK installer files are now named to include the image name
604 and tuning architecture through the ```SDK_NAME`` <#var-SDK_NAME>`__ 604 and tuning architecture through the :term:`SDK_NAME`
605 variable. 605 variable.
606 606
607- Images and related files are now installed into a directory that is 607- Images and related files are now installed into a directory that is
608 specific to the machine, instead of a parent directory containing 608 specific to the machine, instead of a parent directory containing
609 output files for multiple machines. The 609 output files for multiple machines. The
610 ```DEPLOY_DIR_IMAGE`` <#var-DEPLOY_DIR_IMAGE>`__ variable continues 610 :term:`DEPLOY_DIR_IMAGE` variable continues
611 to point to the directory containing images for the current 611 to point to the directory containing images for the current
612 ```MACHINE`` <#var-MACHINE>`__ and should be used anywhere there is a 612 :term:`MACHINE` and should be used anywhere there is a
613 need to refer to this directory. The ``runqemu`` script now uses this 613 need to refer to this directory. The ``runqemu`` script now uses this
614 variable to find images and kernel binaries and will use BitBake to 614 variable to find images and kernel binaries and will use BitBake to
615 determine the directory. Alternatively, you can set the 615 determine the directory. Alternatively, you can set the
616 ``DEPLOY_DIR_IMAGE`` variable in the external environment. 616 ``DEPLOY_DIR_IMAGE`` variable in the external environment.
617 617
618- When buildhistory is enabled, its output is now written under the 618- When buildhistory is enabled, its output is now written under the
619 `Build Directory <#build-directory>`__ rather than 619 :term:`Build Directory` rather than
620 ```TMPDIR`` <#var-TMPDIR>`__. Doing so makes it easier to delete 620 :term:`TMPDIR`. Doing so makes it easier to delete
621 ``TMPDIR`` and preserve the build history. Additionally, data for 621 ``TMPDIR`` and preserve the build history. Additionally, data for
622 produced SDKs is now split by ```IMAGE_NAME`` <#var-IMAGE_NAME>`__. 622 produced SDKs is now split by :term:`IMAGE_NAME`.
623 623
624- The ``pkgdata`` directory produced as part of the packaging process 624- The ``pkgdata`` directory produced as part of the packaging process
625 has been collapsed into a single machine-specific directory. This 625 has been collapsed into a single machine-specific directory. This
@@ -632,7 +632,7 @@ Shortened Git ``SRCREV`` Values
632------------------------------- 632-------------------------------
633 633
634BitBake will now shorten revisions from Git repositories from the normal 634BitBake will now shorten revisions from Git repositories from the normal
63540 characters down to 10 characters within ```SRCPV`` <#var-SRCPV>`__ 63540 characters down to 10 characters within :term:`SRCPV`
636for improved usability in path and file names. This change should be 636for improved usability in path and file names. This change should be
637safe within contexts where these revisions are used because the chances 637safe within contexts where these revisions are used because the chances
638of spatially close collisions is very low. Distant collisions are not a 638of spatially close collisions is very low. Distant collisions are not a
@@ -644,16 +644,16 @@ major issue in the way the values are used.
644------------------ 644------------------
645 645
646The following changes have been made that relate to 646The following changes have been made that relate to
647```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__: 647:term:`IMAGE_FEATURES`:
648 648
649- The value of ``IMAGE_FEATURES`` is now validated to ensure invalid 649- The value of ``IMAGE_FEATURES`` is now validated to ensure invalid
650 feature items are not added. Some users mistakenly add package names 650 feature items are not added. Some users mistakenly add package names
651 to this variable instead of using 651 to this variable instead of using
652 ```IMAGE_INSTALL`` <#var-IMAGE_INSTALL>`__ in order to have the 652 :term:`IMAGE_INSTALL` in order to have the
653 package added to the image, which does not work. This change is 653 package added to the image, which does not work. This change is
654 intended to catch those kinds of situations. Valid ``IMAGE_FEATURES`` 654 intended to catch those kinds of situations. Valid ``IMAGE_FEATURES``
655 are drawn from ``PACKAGE_GROUP`` definitions, 655 are drawn from ``PACKAGE_GROUP`` definitions,
656 ```COMPLEMENTARY_GLOB`` <#var-COMPLEMENTARY_GLOB>`__ and a new 656 :term:`COMPLEMENTARY_GLOB` and a new
657 "validitems" varflag on ``IMAGE_FEATURES``. The "validitems" varflag 657 "validitems" varflag on ``IMAGE_FEATURES``. The "validitems" varflag
658 change allows additional features to be added if they are not 658 change allows additional features to be added if they are not
659 provided using the previous two mechanisms. 659 provided using the previous two mechanisms.
@@ -682,9 +682,9 @@ Removal of Package Manager Database Within Image Recipes
682 682
683The image ``core-image-minimal`` no longer adds 683The image ``core-image-minimal`` no longer adds
684``remove_packaging_data_files`` to 684``remove_packaging_data_files`` to
685```ROOTFS_POSTPROCESS_COMMAND`` <#var-ROOTFS_POSTPROCESS_COMMAND>`__. 685:term:`ROOTFS_POSTPROCESS_COMMAND`.
686This addition is now handled automatically when "package-management" is 686This addition is now handled automatically when "package-management" is
687not in ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__. If you have custom 687not in :term:`IMAGE_FEATURES`. If you have custom
688image recipes that make this addition, you should remove the lines, as 688image recipes that make this addition, you should remove the lines, as
689they are not needed and might interfere with correct operation of 689they are not needed and might interfere with correct operation of
690postinstall scripts. 690postinstall scripts.
@@ -694,7 +694,7 @@ postinstall scripts.
694Images Now Rebuild Only on Changes Instead of Every Time 694Images Now Rebuild Only on Changes Instead of Every Time
695-------------------------------------------------------- 695--------------------------------------------------------
696 696
697The ```do_rootfs`` <#ref-tasks-rootfs>`__ and other related image 697The :ref:`ref-tasks-rootfs` and other related image
698construction tasks are no longer marked as "nostamp". Consequently, they 698construction tasks are no longer marked as "nostamp". Consequently, they
699will only be re-executed when their inputs have changed. Previous 699will only be re-executed when their inputs have changed. Previous
700versions of the OpenEmbedded build system always rebuilt the image when 700versions of the OpenEmbedded build system always rebuilt the image when
@@ -711,7 +711,7 @@ them from ``task-*`` to ``packagegroup-*`` and inherit packagegroup
711instead. 711instead.
712 712
713For more information, see the 713For more information, see the
714"```packagegroup.bbclass`` <#ref-classes-packagegroup>`__" section. 714":ref:`packagegroup.bbclass <ref-classes-packagegroup>`" section.
715 715
716.. _migration-1.5-busybox: 716.. _migration-1.5-busybox:
717 717
@@ -723,7 +723,7 @@ root for those components that need it, and another for the rest of the
723components. Splitting BusyBox allows for optimization that eliminates 723components. Splitting BusyBox allows for optimization that eliminates
724the ``tinylogin`` recipe as recommended by upstream. You can disable 724the ``tinylogin`` recipe as recommended by upstream. You can disable
725this split by setting 725this split by setting
726```BUSYBOX_SPLIT_SUID`` <#var-BUSYBOX_SPLIT_SUID>`__ to "0". 726:term:`BUSYBOX_SPLIT_SUID` to "0".
727 727
728.. _migration-1.5-automated-image-testing: 728.. _migration-1.5-automated-image-testing:
729 729
@@ -771,7 +771,7 @@ section in the Yocto Project Development Tasks Manual.
771Following are changes to ``udev``: 771Following are changes to ``udev``:
772 772
773- ``udev`` no longer brings in ``udev-extraconf`` automatically through 773- ``udev`` no longer brings in ``udev-extraconf`` automatically through
774 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, since this was originally 774 :term:`RRECOMMENDS`, since this was originally
775 intended to be optional. If you need the extra rules, then add 775 intended to be optional. If you need the extra rules, then add
776 ``udev-extraconf`` to your image. 776 ``udev-extraconf`` to your image.
777 777
@@ -821,13 +821,13 @@ Following is a list of short entries describing other changes:
821- ``alsa-state``: Provide an empty ``asound.conf`` by default. 821- ``alsa-state``: Provide an empty ``asound.conf`` by default.
822 822
823- ``classes/image``: Ensure 823- ``classes/image``: Ensure
824 ```BAD_RECOMMENDATIONS`` <#var-BAD_RECOMMENDATIONS>`__ supports 824 :term:`BAD_RECOMMENDATIONS` supports
825 pre-renamed package names. 825 pre-renamed package names.
826 826
827- ``classes/rootfs_rpm``: Implement ``BAD_RECOMMENDATIONS`` for RPM. 827- ``classes/rootfs_rpm``: Implement ``BAD_RECOMMENDATIONS`` for RPM.
828 828
829- ``systemd``: Remove ``systemd_unitdir`` if ``systemd`` is not in 829- ``systemd``: Remove ``systemd_unitdir`` if ``systemd`` is not in
830 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. 830 :term:`DISTRO_FEATURES`.
831 831
832- ``systemd``: Remove ``init.d`` dir if ``systemd`` unit file is 832- ``systemd``: Remove ``init.d`` dir if ``systemd`` unit file is
833 present and ``sysvinit`` is not a distro feature. 833 present and ``sysvinit`` is not a distro feature.
@@ -854,7 +854,7 @@ Project 1.6 Release from the prior release.
854``archiver`` Class 854``archiver`` Class
855------------------ 855------------------
856 856
857The ```archiver`` <#ref-classes-archiver>`__ class has been rewritten 857The :ref:`archiver <ref-classes-archiver>` class has been rewritten
858and its configuration has been simplified. For more details on the 858and its configuration has been simplified. For more details on the
859source archiver, see the "`Maintaining Open Source License Compliance 859source archiver, see the "`Maintaining Open Source License Compliance
860During Your Product's 860During Your Product's
@@ -889,7 +889,7 @@ The following packaging changes have been made:
889BitBake 889BitBake
890------- 890-------
891 891
892The following changes have been made to `BitBake <#bitbake-term>`__. 892The following changes have been made to :term:`BitBake`.
893 893
894.. _migration-1.6-matching-branch-requirement-for-git-fetching: 894.. _migration-1.6-matching-branch-requirement-for-git-fetching:
895 895
@@ -897,8 +897,8 @@ Matching Branch Requirement for Git Fetching
897~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 897~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
898 898
899When fetching source from a Git repository using 899When fetching source from a Git repository using
900```SRC_URI`` <#var-SRC_URI>`__, BitBake will now validate the 900:term:`SRC_URI`, BitBake will now validate the
901```SRCREV`` <#var-SRCREV>`__ value against the branch. You can specify 901:term:`SRCREV` value against the branch. You can specify
902the branch using the following form: SRC_URI = 902the branch using the following form: SRC_URI =
903"git://server.name/repository;branch=branchname" If you do not specify a 903"git://server.name/repository;branch=branchname" If you do not specify a
904branch, BitBake looks in the default "master" branch. 904branch, BitBake looks in the default "master" branch.
@@ -960,7 +960,7 @@ will need to add ``2>&1`` (or something similar) to the end of your
960``task-``\ taskname overrides have been adjusted so that tasks whose 960``task-``\ taskname overrides have been adjusted so that tasks whose
961names contain underscores have the underscores replaced by hyphens for 961names contain underscores have the underscores replaced by hyphens for
962the override so that they now function properly. For example, the task 962the override so that they now function properly. For example, the task
963override for ```do_populate_sdk`` <#ref-tasks-populate_sdk>`__ is 963override for :ref:`ref-tasks-populate_sdk` is
964``task-populate-sdk``. 964``task-populate-sdk``.
965 965
966.. _migration-1.6-variable-changes: 966.. _migration-1.6-variable-changes:
@@ -977,7 +977,7 @@ Glossary <#ref-variables-glos>`__" Chapter.
977``TMPDIR`` 977``TMPDIR``
978~~~~~~~~~~ 978~~~~~~~~~~
979 979
980```TMPDIR`` <#var-TMPDIR>`__ can no longer be on an NFS mount. NFS does 980:term:`TMPDIR` can no longer be on an NFS mount. NFS does
981not offer full POSIX locking and inode consistency and can cause 981not offer full POSIX locking and inode consistency and can cause
982unexpected issues if used to store ``TMPDIR``. 982unexpected issues if used to store ``TMPDIR``.
983 983
@@ -990,7 +990,7 @@ NFS mount, an error occurs.
990~~~~~~~~~ 990~~~~~~~~~
991 991
992The ``PRINC`` variable has been deprecated and triggers a warning if 992The ``PRINC`` variable has been deprecated and triggers a warning if
993detected during a build. For ```PR`` <#var-PR>`__ increments on changes, 993detected during a build. For :term:`PR` increments on changes,
994use the PR service instead. You can find out more about this service in 994use the PR service instead. You can find out more about this service in
995the "`Working With a PR 995the "`Working With a PR
996Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section in 996Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section in
@@ -1001,7 +1001,7 @@ the Yocto Project Development Tasks Manual.
1001``IMAGE_TYPES`` 1001``IMAGE_TYPES``
1002~~~~~~~~~~~~~~~ 1002~~~~~~~~~~~~~~~
1003 1003
1004The "sum.jffs2" option for ```IMAGE_TYPES`` <#var-IMAGE_TYPES>`__ has 1004The "sum.jffs2" option for :term:`IMAGE_TYPES` has
1005been replaced by the "jffs2.sum" option, which fits the processing 1005been replaced by the "jffs2.sum" option, which fits the processing
1006order. 1006order.
1007 1007
@@ -1010,7 +1010,7 @@ order.
1010``COPY_LIC_MANIFEST`` 1010``COPY_LIC_MANIFEST``
1011~~~~~~~~~~~~~~~~~~~~~ 1011~~~~~~~~~~~~~~~~~~~~~
1012 1012
1013The ```COPY_LIC_MANIFEST`` <#var-COPY_LIC_MANIFEST>`__ variable must now 1013The :term:`COPY_LIC_MANIFEST` variable must now
1014be set to "1" rather than any value in order to enable it. 1014be set to "1" rather than any value in order to enable it.
1015 1015
1016.. _migration-1.6-variable-changes-COPY_LIC_DIRS: 1016.. _migration-1.6-variable-changes-COPY_LIC_DIRS:
@@ -1018,7 +1018,7 @@ be set to "1" rather than any value in order to enable it.
1018``COPY_LIC_DIRS`` 1018``COPY_LIC_DIRS``
1019~~~~~~~~~~~~~~~~~ 1019~~~~~~~~~~~~~~~~~
1020 1020
1021The ```COPY_LIC_DIRS`` <#var-COPY_LIC_DIRS>`__ variable must now be set 1021The :term:`COPY_LIC_DIRS` variable must now be set
1022to "1" rather than any value in order to enable it. 1022to "1" rather than any value in order to enable it.
1023 1023
1024.. _migration-1.6-variable-changes-PACKAGE_GROUP: 1024.. _migration-1.6-variable-changes-PACKAGE_GROUP:
@@ -1027,7 +1027,7 @@ to "1" rather than any value in order to enable it.
1027~~~~~~~~~~~~~~~~~ 1027~~~~~~~~~~~~~~~~~
1028 1028
1029The ``PACKAGE_GROUP`` variable has been renamed to 1029The ``PACKAGE_GROUP`` variable has been renamed to
1030```FEATURE_PACKAGES`` <#var-FEATURE_PACKAGES>`__ to more accurately 1030:term:`FEATURE_PACKAGES` to more accurately
1031reflect its purpose. You can still use ``PACKAGE_GROUP`` but the 1031reflect its purpose. You can still use ``PACKAGE_GROUP`` but the
1032OpenEmbedded build system produces a warning message when it encounters 1032OpenEmbedded build system produces a warning message when it encounters
1033the variable. 1033the variable.
@@ -1039,15 +1039,15 @@ Preprocess and Post Process Command Variable Behavior
1039 1039
1040The following variables now expect a semicolon separated list of 1040The following variables now expect a semicolon separated list of
1041functions to call and not arbitrary shell commands: 1041functions to call and not arbitrary shell commands:
1042`ROOTFS_PREPROCESS_COMMAND <#var-ROOTFS_PREPROCESS_COMMAND>`__ 1042:term:`ROOTFS_PREPROCESS_COMMAND`
1043`ROOTFS_POSTPROCESS_COMMAND <#var-ROOTFS_POSTPROCESS_COMMAND>`__ 1043:term:`ROOTFS_POSTPROCESS_COMMAND`
1044`SDK_POSTPROCESS_COMMAND <#var-SDK_POSTPROCESS_COMMAND>`__ 1044:term:`SDK_POSTPROCESS_COMMAND`
1045`POPULATE_SDK_POST_TARGET_COMMAND <#var-POPULATE_SDK_POST_TARGET_COMMAND>`__ 1045:term:`POPULATE_SDK_POST_TARGET_COMMAND`
1046`POPULATE_SDK_POST_HOST_COMMAND <#var-POPULATE_SDK_POST_HOST_COMMAND>`__ 1046:term:`POPULATE_SDK_POST_HOST_COMMAND`
1047`IMAGE_POSTPROCESS_COMMAND <#var-IMAGE_POSTPROCESS_COMMAND>`__ 1047:term:`IMAGE_POSTPROCESS_COMMAND`
1048`IMAGE_PREPROCESS_COMMAND <#var-IMAGE_PREPROCESS_COMMAND>`__ 1048:term:`IMAGE_PREPROCESS_COMMAND`
1049`ROOTFS_POSTUNINSTALL_COMMAND <#var-ROOTFS_POSTUNINSTALL_COMMAND>`__ 1049:term:`ROOTFS_POSTUNINSTALL_COMMAND`
1050`ROOTFS_POSTINSTALL_COMMAND <#var-ROOTFS_POSTINSTALL_COMMAND>`__ For 1050:term:`ROOTFS_POSTINSTALL_COMMAND` For
1051migration purposes, you can simply wrap shell commands in a shell 1051migration purposes, you can simply wrap shell commands in a shell
1052function and then call the function. Here is an example: 1052function and then call the function. Here is an example:
1053my_postprocess_function() { echo "hello" > ${IMAGE_ROOTFS}/hello.txt } 1053my_postprocess_function() { echo "hello" > ${IMAGE_ROOTFS}/hello.txt }
@@ -1062,7 +1062,7 @@ Package Tests (ptest) are built but not installed by default. For
1062information on using Package Tests, see the "`Testing Packages with 1062information on using Package Tests, see the "`Testing Packages with
1063ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in 1063ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in
1064the Yocto Project Development Tasks Manual. For information on the 1064the Yocto Project Development Tasks Manual. For information on the
1065``ptest`` class, see the "```ptest.bbclass`` <#ref-classes-ptest>`__" 1065``ptest`` class, see the ":ref:`ptest.bbclass <ref-classes-ptest>`"
1066section. 1066section.
1067 1067
1068.. _migration-1.6-build-changes: 1068.. _migration-1.6-build-changes:
@@ -1072,8 +1072,8 @@ Build Changes
1072 1072
1073Separate build and source directories have been enabled by default for 1073Separate build and source directories have been enabled by default for
1074selected recipes where it is known to work (a whitelist) and for all 1074selected recipes where it is known to work (a whitelist) and for all
1075recipes that inherit the ```cmake`` <#ref-classes-cmake>`__ class. In 1075recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In
1076future releases the ```autotools`` <#ref-classes-autotools>`__ class 1076future releases the :ref:`autotools <ref-classes-autotools>` class
1077will enable a separate build directory by default as well. Recipes 1077will enable a separate build directory by default as well. Recipes
1078building Autotools-based software that fails to build with a separate 1078building Autotools-based software that fails to build with a separate
1079build directory should be changed to inherit from the 1079build directory should be changed to inherit from the
@@ -1116,12 +1116,12 @@ Licensing
1116--------- 1116---------
1117 1117
1118The top-level ``LICENSE`` file has been changed to better describe the 1118The top-level ``LICENSE`` file has been changed to better describe the
1119license of the various components of `OE-Core <#oe-core>`__. However, 1119license of the various components of :term:`OpenEmbedded-Core (OE-Core)`. However,
1120the licensing itself remains unchanged. 1120the licensing itself remains unchanged.
1121 1121
1122Normally, this change would not cause any side-effects. However, some 1122Normally, this change would not cause any side-effects. However, some
1123recipes point to this file within 1123recipes point to this file within
1124```LIC_FILES_CHKSUM`` <#var-LIC_FILES_CHKSUM>`__ (as 1124:term:`LIC_FILES_CHKSUM` (as
1125``${COREBASE}/LICENSE``) and thus the accompanying checksum must be 1125``${COREBASE}/LICENSE``) and thus the accompanying checksum must be
1126changed from 3f40d7994397109285ec7b81fdeb3b58 to 1126changed from 3f40d7994397109285ec7b81fdeb3b58 to
11274d92cd373abda3937c2bc47fbc49d690. A better alternative is to have 11274d92cd373abda3937c2bc47fbc49d690. A better alternative is to have
@@ -1135,7 +1135,7 @@ rather than pointing to ``${COREBASE}/LICENSE``.
1135------------------ 1135------------------
1136 1136
1137The "-fpermissive" option has been removed from the default 1137The "-fpermissive" option has been removed from the default
1138```CFLAGS`` <#var-CFLAGS>`__ value. You need to take action on 1138:term:`CFLAGS` value. You need to take action on
1139individual recipes that fail when building with this option. You need to 1139individual recipes that fail when building with this option. You need to
1140either patch the recipes to fix the issues reported by the compiler, or 1140either patch the recipes to fix the issues reported by the compiler, or
1141you need to add "-fpermissive" to ``CFLAGS`` in the recipes. 1141you need to add "-fpermissive" to ``CFLAGS`` in the recipes.
@@ -1146,9 +1146,9 @@ Custom Image Output Types
1146------------------------- 1146-------------------------
1147 1147
1148Custom image output types, as selected using 1148Custom image output types, as selected using
1149```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__, must declare their 1149:term:`IMAGE_FSTYPES`, must declare their
1150dependencies on other image types (if any) using a new 1150dependencies on other image types (if any) using a new
1151```IMAGE_TYPEDEP`` <#var-IMAGE_TYPEDEP>`__ variable. 1151:term:`IMAGE_TYPEDEP` variable.
1152 1152
1153.. _migration-1.6-do-package-write-task: 1153.. _migration-1.6-do-package-write-task:
1154 1154
@@ -1264,7 +1264,7 @@ Changes to Setting QEMU ``PACKAGECONFIG`` Options in ``local.conf``
1264------------------------------------------------------------------- 1264-------------------------------------------------------------------
1265 1265
1266The QEMU recipe now uses a number of 1266The QEMU recipe now uses a number of
1267```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__ options to enable various 1267:term:`PACKAGECONFIG` options to enable various
1268optional features. The method used to set defaults for these options 1268optional features. The method used to set defaults for these options
1269means that existing ``local.conf`` files will need to be be modified to 1269means that existing ``local.conf`` files will need to be be modified to
1270append to ``PACKAGECONFIG`` for ``qemu-native`` and ``nativesdk-qemu`` 1270append to ``PACKAGECONFIG`` for ``qemu-native`` and ``nativesdk-qemu``
@@ -1291,13 +1291,13 @@ for more information.
1291Autotools Class Changes 1291Autotools Class Changes
1292----------------------- 1292-----------------------
1293 1293
1294The following ```autotools`` <#ref-classes-autotools>`__ class changes 1294The following :ref:`autotools <ref-classes-autotools>` class changes
1295occurred: 1295occurred:
1296 1296
1297- *A separate build directory is now used by default:* The 1297- *A separate build directory is now used by default:* The
1298 ``autotools`` class has been changed to use a directory for building 1298 ``autotools`` class has been changed to use a directory for building
1299 (```B`` <#var-B>`__), which is separate from the source directory 1299 (:term:`B`), which is separate from the source directory
1300 (```S`` <#var-S>`__). This is commonly referred to as ``B != S``, or 1300 (:term:`S`). This is commonly referred to as ``B != S``, or
1301 an out-of-tree build. 1301 an out-of-tree build.
1302 1302
1303 If the software being built is already capable of building in a 1303 If the software being built is already capable of building in a
@@ -1368,10 +1368,10 @@ Kernel Module Autoloading
1368 1368
1369The ```module_autoload_*`` <#var-module_autoload>`__ variable is now 1369The ```module_autoload_*`` <#var-module_autoload>`__ variable is now
1370deprecated and a new 1370deprecated and a new
1371```KERNEL_MODULE_AUTOLOAD`` <#var-KERNEL_MODULE_AUTOLOAD>`__ variable 1371:term:`KERNEL_MODULE_AUTOLOAD` variable
1372should be used instead. Also, ```module_conf_*`` <#var-module_conf>`__ 1372should be used instead. Also, ```module_conf_*`` <#var-module_conf>`__
1373must now be used in conjunction with a new 1373must now be used in conjunction with a new
1374```KERNEL_MODULE_PROBECONF`` <#var-KERNEL_MODULE_PROBECONF>`__ variable. 1374:term:`KERNEL_MODULE_PROBECONF` variable.
1375The new variables no longer require you to specify the module name as 1375The new variables no longer require you to specify the module name as
1376part of the variable name. This change not only simplifies usage but 1376part of the variable name. This change not only simplifies usage but
1377also allows the values of these variables to be appropriately 1377also allows the values of these variables to be appropriately
@@ -1395,15 +1395,15 @@ The following changes have occurred to the QA check process:
1395 see the "`QA Error and Warning Messages <#ref-qa-checks>`__" chapter. 1395 see the "`QA Error and Warning Messages <#ref-qa-checks>`__" chapter.
1396 1396
1397- Package QA checks are now performed during a new 1397- Package QA checks are now performed during a new
1398 ```do_package_qa`` <#ref-tasks-package_qa>`__ task rather than being 1398 :ref:`ref-tasks-package_qa` task rather than being
1399 part of the ```do_package`` <#ref-tasks-package>`__ task. This allows 1399 part of the :ref:`ref-tasks-package` task. This allows
1400 more parallel execution. This change is unlikely to be an issue 1400 more parallel execution. This change is unlikely to be an issue
1401 except for highly customized recipes that disable packaging tasks 1401 except for highly customized recipes that disable packaging tasks
1402 themselves by marking them as ``noexec``. For those packages, you 1402 themselves by marking them as ``noexec``. For those packages, you
1403 will need to disable the ``do_package_qa`` task as well. 1403 will need to disable the ``do_package_qa`` task as well.
1404 1404
1405- Files being overwritten during the 1405- Files being overwritten during the
1406 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task now 1406 :ref:`ref-tasks-populate_sysroot` task now
1407 trigger an error instead of a warning. Recipes should not be 1407 trigger an error instead of a warning. Recipes should not be
1408 overwriting files written to the sysroot by other recipes. If you 1408 overwriting files written to the sysroot by other recipes. If you
1409 have these types of recipes, you need to alter them so that they do 1409 have these types of recipes, you need to alter them so that they do
@@ -1412,7 +1412,7 @@ The following changes have occurred to the QA check process:
1412 You might now receive this error after changes in configuration or 1412 You might now receive this error after changes in configuration or
1413 metadata resulting in orphaned files being left in the sysroot. If 1413 metadata resulting in orphaned files being left in the sysroot. If
1414 you do receive this error, the way to resolve the issue is to delete 1414 you do receive this error, the way to resolve the issue is to delete
1415 your ```TMPDIR`` <#var-TMPDIR>`__ or to move it out of the way and 1415 your :term:`TMPDIR` or to move it out of the way and
1416 then re-start the build. Anything that has been fully built up to 1416 then re-start the build. Anything that has been fully built up to
1417 that point and does not need rebuilding will be restored from the 1417 that point and does not need rebuilding will be restored from the
1418 shared state cache and the rest of the build will be able to proceed 1418 shared state cache and the rest of the build will be able to proceed
@@ -1508,7 +1508,7 @@ BlueZ 4.x / 5.x Selection
1508 1508
1509Proper built-in support for selecting BlueZ 5.x in preference to the 1509Proper built-in support for selecting BlueZ 5.x in preference to the
1510default of 4.x now exists. To use BlueZ 5.x, simply add "bluez5" to your 1510default of 4.x now exists. To use BlueZ 5.x, simply add "bluez5" to your
1511```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ value. If you had 1511:term:`DISTRO_FEATURES` value. If you had
1512previously added append files (``*.bbappend``) to make this selection, 1512previously added append files (``*.bbappend``) to make this selection,
1513you can now remove them. 1513you can now remove them.
1514 1514
@@ -1532,8 +1532,8 @@ code tree. In theory, migration paths have been provided for most common
1532usages in kernel recipes but this might not work in all cases. In 1532usages in kernel recipes but this might not work in all cases. In
1533particular, users need to ensure that ``${S}`` (source files) and 1533particular, users need to ensure that ``${S}`` (source files) and
1534``${B}`` (build artifacts) are used correctly in functions such as 1534``${B}`` (build artifacts) are used correctly in functions such as
1535```do_configure`` <#ref-tasks-configure>`__ and 1535:ref:`ref-tasks-configure` and
1536```do_install`` <#ref-tasks-install>`__. For kernel recipes that do not 1536:ref:`ref-tasks-install`. For kernel recipes that do not
1537inherit from ``kernel-yocto`` or include ``linux-yocto.inc``, you might 1537inherit from ``kernel-yocto`` or include ``linux-yocto.inc``, you might
1538wish to refer to the ``linux.inc`` file in the ``meta-oe`` layer for the 1538wish to refer to the ``linux.inc`` file in the ``meta-oe`` layer for the
1539kinds of changes you need to make. For reference, here is the 1539kinds of changes you need to make. For reference, here is the
@@ -1554,7 +1554,7 @@ SSL 3.0 is now disabled when building OpenSSL. Disabling SSL 3.0 avoids
1554any lingering instances of the POODLE vulnerability. If you feel you 1554any lingering instances of the POODLE vulnerability. If you feel you
1555must re-enable SSL 3.0, then you can add an append file (``*.bbappend``) 1555must re-enable SSL 3.0, then you can add an append file (``*.bbappend``)
1556for the ``openssl`` recipe to remove "-no-ssl3" from 1556for the ``openssl`` recipe to remove "-no-ssl3" from
1557```EXTRA_OECONF`` <#var-EXTRA_OECONF>`__. 1557:term:`EXTRA_OECONF`.
1558 1558
1559.. _migration-1.8-default-sysroot-poisoning: 1559.. _migration-1.8-default-sysroot-poisoning:
1560 1560
@@ -1578,17 +1578,17 @@ need to take corrective steps.
1578Rebuild Improvements 1578Rebuild Improvements
1579-------------------- 1579--------------------
1580 1580
1581Changes have been made to the ```base`` <#ref-classes-base>`__, 1581Changes have been made to the :ref:`base <ref-classes-base>`,
1582```autotools`` <#ref-classes-autotools>`__, and 1582:ref:`autotools <ref-classes-autotools>`, and
1583```cmake`` <#ref-classes-cmake>`__ classes to clean out generated files 1583:ref:`cmake <ref-classes-cmake>` classes to clean out generated files
1584when the ```do_configure`` <#ref-tasks-configure>`__ task needs to be 1584when the :ref:`ref-tasks-configure` task needs to be
1585re-executed. 1585re-executed.
1586 1586
1587One of the improvements is to attempt to run "make clean" during the 1587One of the improvements is to attempt to run "make clean" during the
1588``do_configure`` task if a ``Makefile`` exists. Some software packages 1588``do_configure`` task if a ``Makefile`` exists. Some software packages
1589do not provide a working clean target within their make files. If you 1589do not provide a working clean target within their make files. If you
1590have such recipes, you need to set 1590have such recipes, you need to set
1591```CLEANBROKEN`` <#var-CLEANBROKEN>`__ to "1" within the recipe, for 1591:term:`CLEANBROKEN` to "1" within the recipe, for
1592example: CLEANBROKEN = "1" 1592example: CLEANBROKEN = "1"
1593 1593
1594.. _migration-1.8-qa-check-and-validation-changes: 1594.. _migration-1.8-qa-check-and-validation-changes:
@@ -1603,18 +1603,18 @@ The following QA Check and Validation Changes have occurred:
1603 recipe or append file. 1603 recipe or append file.
1604 1604
1605- An additional QA check has been added to detect usage of ``${D}`` in 1605- An additional QA check has been added to detect usage of ``${D}`` in
1606 ```FILES`` <#var-FILES>`__ values where ```D`` <#var-D>`__ values 1606 :term:`FILES` values where :term:`D` values
1607 should not be used at all. The same check ensures that ``$D`` is used 1607 should not be used at all. The same check ensures that ``$D`` is used
1608 in ``pkg_preinst/pkg_postinst/pkg_prerm/pkg_postrm`` functions 1608 in ``pkg_preinst/pkg_postinst/pkg_prerm/pkg_postrm`` functions
1609 instead of ``${D}``. 1609 instead of ``${D}``.
1610 1610
1611- ```S`` <#var-S>`__ now needs to be set to a valid value within a 1611- :term:`S` now needs to be set to a valid value within a
1612 recipe. If ``S`` is not set in the recipe, the directory is not 1612 recipe. If ``S`` is not set in the recipe, the directory is not
1613 automatically created. If ``S`` does not point to a directory that 1613 automatically created. If ``S`` does not point to a directory that
1614 exists at the time the ```do_unpack`` <#ref-tasks-unpack>`__ task 1614 exists at the time the :ref:`ref-tasks-unpack` task
1615 finishes, a warning will be shown. 1615 finishes, a warning will be shown.
1616 1616
1617- ```LICENSE`` <#var-LICENSE>`__ is now validated for correct 1617- :term:`LICENSE` is now validated for correct
1618 formatting of multiple licenses. If the format is invalid (e.g. 1618 formatting of multiple licenses. If the format is invalid (e.g.
1619 multiple licenses are specified with no operators to specify how the 1619 multiple licenses are specified with no operators to specify how the
1620 multiple licenses interact), then a warning will be shown. 1620 multiple licenses interact), then a warning will be shown.
@@ -1633,7 +1633,7 @@ The following miscellaneous changes have occurred:
1633- The ``oe-pkgdata-util`` script now expects a "-p" option to be 1633- The ``oe-pkgdata-util`` script now expects a "-p" option to be
1634 specified before the ``pkgdata`` directory, which is now optional. If 1634 specified before the ``pkgdata`` directory, which is now optional. If
1635 the ``pkgdata`` directory is not specified, the script will run 1635 the ``pkgdata`` directory is not specified, the script will run
1636 BitBake to query ```PKGDATA_DIR`` <#var-PKGDATA_DIR>`__ from the 1636 BitBake to query :term:`PKGDATA_DIR` from the
1637 build environment. 1637 build environment.
1638 1638
1639Moving to the Yocto Project 2.0 Release 1639Moving to the Yocto Project 2.0 Release
@@ -1811,7 +1811,7 @@ Recipe Maintenance Tracking Data Moved to OE-Core
1811------------------------------------------------- 1811-------------------------------------------------
1812 1812
1813Maintenance tracking data for recipes that was previously part of 1813Maintenance tracking data for recipes that was previously part of
1814``meta-yocto`` has been moved to `OE-Core <#oe-core>`__. The change 1814``meta-yocto`` has been moved to :term:`OpenEmbedded-Core (OE-Core)`. The change
1815includes ``package_regex.inc`` and ``distro_alias.inc``, which are 1815includes ``package_regex.inc`` and ``distro_alias.inc``, which are
1816typically enabled when using the ``distrodata`` class. Additionally, the 1816typically enabled when using the ``distrodata`` class. Additionally, the
1817contents of ``upstream_tracking.inc`` has now been split out to the 1817contents of ``upstream_tracking.inc`` has now been split out to the
@@ -1827,7 +1827,7 @@ configuration are now automatically removed from sysroot as well as
1827removed from any other place managed by shared state. This automatic 1827removed from any other place managed by shared state. This automatic
1828cleanup means that the build system now properly handles situations such 1828cleanup means that the build system now properly handles situations such
1829as renaming the build system side of recipes, removal of layers from 1829as renaming the build system side of recipes, removal of layers from
1830``bblayers.conf``, and ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ 1830``bblayers.conf``, and :term:`DISTRO_FEATURES`
1831changes. 1831changes.
1832 1832
1833Additionally, work directories for old versions of recipes are now 1833Additionally, work directories for old versions of recipes are now
@@ -1847,7 +1847,7 @@ modifications synchronized, it is not always obvious to developers how
1847to manipulate the Metadata as compared to the source. 1847to manipulate the Metadata as compared to the source.
1848 1848
1849Metadata processing has now been removed from the 1849Metadata processing has now been removed from the
1850```kernel-yocto`` <#ref-classes-kernel-yocto>`__ class and the external 1850:ref:`kernel-yocto <ref-classes-kernel-yocto>` class and the external
1851Metadata repository ``yocto-kernel-cache``, which has always been used 1851Metadata repository ``yocto-kernel-cache``, which has always been used
1852to seed the ``linux-yocto`` "meta" branch. This separate ``linux-yocto`` 1852to seed the ``linux-yocto`` "meta" branch. This separate ``linux-yocto``
1853cache repository is now the primary location for this data. Due to this 1853cache repository is now the primary location for this data. Due to this
@@ -1870,13 +1870,13 @@ The following QA checks have been added:
1870 1870
1871- Added an "invalid-chars" check for invalid (non-UTF8) characters in 1871- Added an "invalid-chars" check for invalid (non-UTF8) characters in
1872 recipe metadata variable values (i.e. 1872 recipe metadata variable values (i.e.
1873 ```DESCRIPTION`` <#var-DESCRIPTION>`__, 1873 :term:`DESCRIPTION`,
1874 ```SUMMARY`` <#var-SUMMARY>`__, ```LICENSE`` <#var-LICENSE>`__, and 1874 :term:`SUMMARY`, :term:`LICENSE`, and
1875 ```SECTION`` <#var-SECTION>`__). Some package managers do not support 1875 :term:`SECTION`). Some package managers do not support
1876 these characters. 1876 these characters.
1877 1877
1878- Added an "invalid-packageconfig" check for any options specified in 1878- Added an "invalid-packageconfig" check for any options specified in
1879 ```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__ that do not match any 1879 :term:`PACKAGECONFIG` that do not match any
1880 ``PACKAGECONFIG`` option defined for the recipe. 1880 ``PACKAGECONFIG`` option defined for the recipe.
1881 1881
1882.. _migration-2.0-miscellaneous: 1882.. _migration-2.0-miscellaneous:
@@ -1888,7 +1888,7 @@ These additional changes exist:
1888 1888
1889- ``gtk-update-icon-cache`` has been renamed to ``gtk-icon-utils``. 1889- ``gtk-update-icon-cache`` has been renamed to ``gtk-icon-utils``.
1890 1890
1891- The ``tools-profile`` ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ 1891- The ``tools-profile`` :term:`IMAGE_FEATURES`
1892 item as well as its corresponding packagegroup and 1892 item as well as its corresponding packagegroup and
1893 ``packagegroup-core-tools-profile`` no longer bring in ``oprofile``. 1893 ``packagegroup-core-tools-profile`` no longer bring in ``oprofile``.
1894 Bringing in ``oprofile`` was originally added to aid compilation on 1894 Bringing in ``oprofile`` was originally added to aid compilation on
@@ -1897,7 +1897,7 @@ These additional changes exist:
1897 powerful target platforms and the existence of better 1897 powerful target platforms and the existence of better
1898 cross-compilation tools. 1898 cross-compilation tools.
1899 1899
1900- The ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ variable's default 1900- The :term:`IMAGE_FSTYPES` variable's default
1901 value now specifies ``ext4`` instead of ``ext3``. 1901 value now specifies ``ext4`` instead of ``ext3``.
1902 1902
1903- All support for the ``PRINC`` variable has been removed. 1903- All support for the ``PRINC`` variable has been removed.
@@ -1937,7 +1937,7 @@ The convention for overrides has always been for them to be lower-case
1937characters. This practice is now a requirement as BitBake's datastore 1937characters. This practice is now a requirement as BitBake's datastore
1938now assumes lower-case characters in order to give a slight performance 1938now assumes lower-case characters in order to give a slight performance
1939boost during parsing. In practical terms, this requirement means that 1939boost during parsing. In practical terms, this requirement means that
1940anything that ends up in ```OVERRIDES`` <#var-OVERRIDES>`__ must now 1940anything that ends up in :term:`OVERRIDES` must now
1941appear in lower-case characters (e.g. values for ``MACHINE``, 1941appear in lower-case characters (e.g. values for ``MACHINE``,
1942``TARGET_ARCH``, ``DISTRO``, and also recipe names if 1942``TARGET_ARCH``, ``DISTRO``, and also recipe names if
1943``_pn-``\ recipename overrides are to be effective). 1943``_pn-``\ recipename overrides are to be effective).
@@ -1970,7 +1970,7 @@ layer to make this change: sed -e 's:\(\.getVar([^,()]*\)):\1, False):g'
1970Makefile Environment Changes 1970Makefile Environment Changes
1971---------------------------- 1971----------------------------
1972 1972
1973```EXTRA_OEMAKE`` <#var-EXTRA_OEMAKE>`__ now defaults to "" instead of 1973:term:`EXTRA_OEMAKE` now defaults to "" instead of
1974"-e MAKEFLAGS=". Setting ``EXTRA_OEMAKE`` to "-e MAKEFLAGS=" by default 1974"-e MAKEFLAGS=". Setting ``EXTRA_OEMAKE`` to "-e MAKEFLAGS=" by default
1975was a historical accident that has required many classes (e.g. 1975was a historical accident that has required many classes (e.g.
1976``autotools``, ``module``) and recipes to override this default in order 1976``autotools``, ``module``) and recipes to override this default in order
@@ -2007,14 +2007,14 @@ breaking FHS.
2007``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files 2007``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files
2008-------------------------------------------------------- 2008--------------------------------------------------------
2009 2009
2010For recipes inheriting the ```autotools`` <#ref-classes-autotools>`__ 2010For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
2011class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for 2011class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for
2012``autoconf``. The reason for this change is because the 2012``autoconf``. The reason for this change is because the
2013``ac_cv_sizeof_off_t`` value is not necessarily static per architecture 2013``ac_cv_sizeof_off_t`` value is not necessarily static per architecture
2014as was previously assumed. Rather, the value changes based on whether 2014as was previously assumed. Rather, the value changes based on whether
2015large file support is enabled. For most software that uses ``autoconf``, 2015large file support is enabled. For most software that uses ``autoconf``,
2016this change should not be a problem. However, if you have a recipe that 2016this change should not be a problem. However, if you have a recipe that
2017bypasses the standard ```do_configure`` <#ref-tasks-configure>`__ task 2017bypasses the standard :ref:`ref-tasks-configure` task
2018from the ``autotools`` class and the software the recipe is building 2018from the ``autotools`` class and the software the recipe is building
2019uses a very old version of ``autoconf``, the recipe might be incapable 2019uses a very old version of ``autoconf``, the recipe might be incapable
2020of determining the correct size of ``off_t`` during ``do_configure``. 2020of determining the correct size of ``off_t`` during ``do_configure``.
@@ -2030,7 +2030,7 @@ implementation does get used.
2030Image Generation is Now Split Out from Filesystem Generation 2030Image Generation is Now Split Out from Filesystem Generation
2031------------------------------------------------------------ 2031------------------------------------------------------------
2032 2032
2033Previously, for image recipes the ```do_rootfs`` <#ref-tasks-rootfs>`__ 2033Previously, for image recipes the :ref:`ref-tasks-rootfs`
2034task assembled the filesystem and then from that filesystem generated 2034task assembled the filesystem and then from that filesystem generated
2035images. With this Yocto Project release, image generation is split into 2035images. With this Yocto Project release, image generation is split into
2036separate ```do_image_*`` <#ref-tasks-image>`__ tasks for clarity both in 2036separate ```do_image_*`` <#ref-tasks-image>`__ tasks for clarity both in
@@ -2047,7 +2047,7 @@ time.
2047 2047
2048A minor part of this restructuring is that the post-processing 2048A minor part of this restructuring is that the post-processing
2049definitions and functions have been moved from the 2049definitions and functions have been moved from the
2050```image`` <#ref-classes-image>`__ class to the 2050:ref:`image <ref-classes-image>` class to the
2051```rootfs-postcommands`` <#ref-classes-rootfs*>`__ class. Functionally, 2051```rootfs-postcommands`` <#ref-classes-rootfs*>`__ class. Functionally,
2052however, they remain unchanged. 2052however, they remain unchanged.
2053 2053
@@ -2099,7 +2099,7 @@ Class Changes
2099The following classes have changed: 2099The following classes have changed:
2100 2100
2101- ``autotools_stage``: Removed because the 2101- ``autotools_stage``: Removed because the
2102 ```autotools`` <#ref-classes-autotools>`__ class now provides its 2102 :ref:`autotools <ref-classes-autotools>` class now provides its
2103 functionality. Recipes that inherited from ``autotools_stage`` should 2103 functionality. Recipes that inherited from ``autotools_stage`` should
2104 now inherit from ``autotools`` instead. 2104 now inherit from ``autotools`` instead.
2105 2105
@@ -2108,7 +2108,7 @@ The following classes have changed:
2108 this change should not cause any issues. 2108 this change should not cause any issues.
2109 2109
2110- ``bootimg``: Merged into the 2110- ``bootimg``: Merged into the
2111 ```image-live`` <#ref-classes-image-live>`__ class. The ``bootimg`` 2111 :ref:`image-live <ref-classes-image-live>` class. The ``bootimg``
2112 class was rarely directly used. Consequently, this change should not 2112 class was rarely directly used. Consequently, this change should not
2113 cause any issues. 2113 cause any issues.
2114 2114
@@ -2166,7 +2166,7 @@ The following changes have been made for the Poky distribution:
2166 not need to change anything unless you are relying on this naming 2166 not need to change anything unless you are relying on this naming
2167 elsewhere. 2167 elsewhere.
2168 2168
2169- The ```uninative`` <#ref-classes-uninative>`__ class is now enabled 2169- The :ref:`uninative <ref-classes-uninative>` class is now enabled
2170 by default in Poky. This class attempts to isolate the build system 2170 by default in Poky. This class attempts to isolate the build system
2171 from the host distribution's C library and makes re-use of native 2171 from the host distribution's C library and makes re-use of native
2172 shared state artifacts across different host distributions practical. 2172 shared state artifacts across different host distributions practical.
@@ -2278,7 +2278,7 @@ These additional changes exist:
2278 2278
2279- Previously, the following list of packages were removed if 2279- Previously, the following list of packages were removed if
2280 package-management was not in 2280 package-management was not in
2281 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__, regardless of any 2281 :term:`IMAGE_FEATURES`, regardless of any
2282 dependencies: update-rc.d base-passwd shadow update-alternatives 2282 dependencies: update-rc.d base-passwd shadow update-alternatives
2283 run-postinsts With the Yocto Project 2.1 release, these packages are 2283 run-postinsts With the Yocto Project 2.1 release, these packages are
2284 only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since 2284 only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since
@@ -2362,9 +2362,9 @@ Staging Directories in Sysroot Has Been Simplified
2362-------------------------------------------------- 2362--------------------------------------------------
2363 2363
2364The way directories are staged in sysroot has been simplified and 2364The way directories are staged in sysroot has been simplified and
2365introduces the new ```SYSROOT_DIRS`` <#var-SYSROOT_DIRS>`__, 2365introduces the new :term:`SYSROOT_DIRS`,
2366```SYSROOT_DIRS_NATIVE`` <#var-SYSROOT_DIRS_NATIVE>`__, and 2366:term:`SYSROOT_DIRS_NATIVE`, and
2367```SYSROOT_DIRS_BLACKLIST`` <#var-SYSROOT_DIRS_BLACKLIST>`__. See the 2367:term:`SYSROOT_DIRS_BLACKLIST`. See the
2368`v2 patch series on the OE-Core Mailing 2368`v2 patch series on the OE-Core Mailing
2369List <http://lists.openembedded.org/pipermail/openembedded-core/2016-May/121365.html>`__ 2369List <http://lists.openembedded.org/pipermail/openembedded-core/2016-May/121365.html>`__
2370for additional information. 2370for additional information.
@@ -2408,7 +2408,7 @@ Metadata Must Now Use Python 3 Syntax
2408The metadata is now required to use Python 3 syntax. For help preparing 2408The metadata is now required to use Python 3 syntax. For help preparing
2409metadata, see any of the many Python 3 porting guides available. 2409metadata, see any of the many Python 3 porting guides available.
2410Alternatively, you can reference the conversion commits for Bitbake and 2410Alternatively, you can reference the conversion commits for Bitbake and
2411you can use `OE-Core <#oe-core>`__ as a guide for changes. Following are 2411you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are
2412particular areas of interest: \* subprocess command-line pipes needing 2412particular areas of interest: \* subprocess command-line pipes needing
2413locale decoding \* the syntax for octal values changed \* the 2413locale decoding \* the syntax for octal values changed \* the
2414``iter*()`` functions changed name \* iterators now return views, not 2414``iter*()`` functions changed name \* iterators now return views, not
@@ -2449,7 +2449,7 @@ compared to uClibc.
2449``${B}`` No Longer Default Working Directory for Tasks 2449``${B}`` No Longer Default Working Directory for Tasks
2450------------------------------------------------------ 2450------------------------------------------------------
2451 2451
2452``${``\ ```B`` <#var-B>`__\ ``}`` is no longer the default working 2452``${``\ :term:`B`\ ``}`` is no longer the default working
2453directory for tasks. Consequently, any custom tasks you define now need 2453directory for tasks. Consequently, any custom tasks you define now need
2454to either have the 2454to either have the
2455``[``\ ```dirs`` <&YOCTO_DOCS_BB_URL;#variable-flags>`__\ ``]`` flag 2455``[``\ ```dirs`` <&YOCTO_DOCS_BB_URL;#variable-flags>`__\ ``]`` flag
@@ -2479,7 +2479,7 @@ enables fine-grained tuning of options passed to QEMU without the
2479``runqemu`` script hard-coding any knowledge about different machines. 2479``runqemu`` script hard-coding any knowledge about different machines.
2480Using a configuration file is particularly convenient when trying to use 2480Using a configuration file is particularly convenient when trying to use
2481QEMU with machines other than the ``qemu*`` machines in 2481QEMU with machines other than the ``qemu*`` machines in
2482`OE-Core <#oe-core>`__. The ``qemuboot.conf`` file is generated by the 2482:term:`OpenEmbedded-Core (OE-Core)`. The ``qemuboot.conf`` file is generated by the
2483``qemuboot`` class when the root filesystem is being build (i.e. build 2483``qemuboot`` class when the root filesystem is being build (i.e. build
2484rootfs). QEMU boot arguments can be set in BSP's configuration file and 2484rootfs). QEMU boot arguments can be set in BSP's configuration file and
2485the ``qemuboot`` class will save them to ``qemuboot.conf``. 2485the ``qemuboot`` class will save them to ``qemuboot.conf``.
@@ -2527,7 +2527,7 @@ socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device
2527virtconsole,chardev=virtcon" runqemu will replace "@PORT@" with the port 2527virtconsole,chardev=virtcon" runqemu will replace "@PORT@" with the port
2528number which is used. 2528number which is used.
2529 2529
2530To use ``runqemu``, set ```IMAGE_CLASSES`` <#var-IMAGE_CLASSES>`__ as 2530To use ``runqemu``, set :term:`IMAGE_CLASSES` as
2531follows and run ``runqemu``: 2531follows and run ``runqemu``:
2532 2532
2533.. note:: 2533.. note::
@@ -2545,7 +2545,7 @@ Default Linker Hash Style Changed
2545 2545
2546The default linker hash style for ``gcc-cross`` is now "sysv" in order 2546The default linker hash style for ``gcc-cross`` is now "sysv" in order
2547to catch recipes that are building software without using the 2547to catch recipes that are building software without using the
2548OpenEmbedded ```LDFLAGS`` <#var-LDFLAGS>`__. This change could result in 2548OpenEmbedded :term:`LDFLAGS`. This change could result in
2549seeing some "No GNU_HASH in the elf binary" QA issues when building such 2549seeing some "No GNU_HASH in the elf binary" QA issues when building such
2550recipes. You need to fix these recipes so that they use the expected 2550recipes. You need to fix these recipes so that they use the expected
2551``LDFLAGS``. Depending on how the software is built, the build system 2551``LDFLAGS``. Depending on how the software is built, the build system
@@ -2559,7 +2559,7 @@ to the recipe: TARGET_CC_ARCH += "${LDFLAGS}"
2559-------------------------------------------------------------- 2559--------------------------------------------------------------
2560 2560
2561The ``KERNEL_IMAGE_BASE_NAME`` variable no longer uses the 2561The ``KERNEL_IMAGE_BASE_NAME`` variable no longer uses the
2562```KERNEL_IMAGETYPE`` <#var-KERNEL_IMAGETYPE>`__ variable to create the 2562:term:`KERNEL_IMAGETYPE` variable to create the
2563image's base name. Because the OpenEmbedded build system can now build 2563image's base name. Because the OpenEmbedded build system can now build
2564multiple kernel image types, this part of the kernel image base name as 2564multiple kernel image types, this part of the kernel image base name as
2565been removed leaving only the following: KERNEL_IMAGE_BASE_NAME ?= 2565been removed leaving only the following: KERNEL_IMAGE_BASE_NAME ?=
@@ -2577,11 +2577,11 @@ The following changes took place for BitBake:
2577- The "goggle" UI and standalone image-writer tool have been removed as 2577- The "goggle" UI and standalone image-writer tool have been removed as
2578 they both require GTK+ 2.0 and were not being maintained. 2578 they both require GTK+ 2.0 and were not being maintained.
2579 2579
2580- The Perforce fetcher now supports ```SRCREV`` <#var-SRCREV>`__ for 2580- The Perforce fetcher now supports :term:`SRCREV` for
2581 specifying the source revision to use, be it 2581 specifying the source revision to use, be it
2582 ``${``\ ```AUTOREV`` <#var-AUTOREV>`__\ ``}``, changelist number, 2582 ``${``\ :term:`AUTOREV`\ ``}``, changelist number,
2583 p4date, or label, in preference to separate 2583 p4date, or label, in preference to separate
2584 ```SRC_URI`` <#var-SRC_URI>`__ parameters to specify these. This 2584 :term:`SRC_URI` parameters to specify these. This
2585 change is more in-line with how the other fetchers work for source 2585 change is more in-line with how the other fetchers work for source
2586 control systems. Recipes that fetch from Perforce will need to be 2586 control systems. Recipes that fetch from Perforce will need to be
2587 updated to use ``SRCREV`` in place of specifying the source revision 2587 updated to use ``SRCREV`` in place of specifying the source revision
@@ -2687,8 +2687,8 @@ The following classes have been removed:
2687 2687
2688- ``distutils3-native-base``: No longer needed. 2688- ``distutils3-native-base``: No longer needed.
2689 2689
2690- ``sdl``: Only set ```DEPENDS`` <#var-DEPENDS>`__ and 2690- ``sdl``: Only set :term:`DEPENDS` and
2691 ```SECTION`` <#var-SECTION>`__, which are better set within the 2691 :term:`SECTION`, which are better set within the
2692 recipe instead. 2692 recipe instead.
2693 2693
2694- ``sip``: Mostly unused. 2694- ``sip``: Mostly unused.
@@ -2723,9 +2723,9 @@ The following miscellaneous changes have occurred:
2723 respective recipes. 2723 respective recipes.
2724 2724
2725- Both ``devtool add`` and ``recipetool create`` now use a fixed 2725- Both ``devtool add`` and ``recipetool create`` now use a fixed
2726 ```SRCREV`` <#var-SRCREV>`__ by default when fetching from a Git 2726 :term:`SRCREV` by default when fetching from a Git
2727 repository. You can override this in either case to use 2727 repository. You can override this in either case to use
2728 ``${``\ ```AUTOREV`` <#var-AUTOREV>`__\ ``}`` instead by using the 2728 ``${``\ :term:`AUTOREV`\ ``}`` instead by using the
2729 ``-a`` or ``DASHDASHautorev`` command-line option 2729 ``-a`` or ``DASHDASHautorev`` command-line option
2730 2730
2731- ``distcc``: GTK+ UI is now disabled by default. 2731- ``distcc``: GTK+ UI is now disabled by default.
@@ -2776,14 +2776,14 @@ Consider the following:
2776- *Specify Pre-Installation and Post-Installation Native Tool 2776- *Specify Pre-Installation and Post-Installation Native Tool
2777 Dependencies:* You must specifically specify any special native tool 2777 Dependencies:* You must specifically specify any special native tool
2778 dependencies of ``pkg_preinst`` and ``pkg_postinst`` scripts by using 2778 dependencies of ``pkg_preinst`` and ``pkg_postinst`` scripts by using
2779 the ```PACKAGE_WRITE_DEPS`` <#var-PACKAGE_WRITE_DEPS>`__ variable. 2779 the :term:`PACKAGE_WRITE_DEPS` variable.
2780 Specifying these dependencies ensures that these tools are available 2780 Specifying these dependencies ensures that these tools are available
2781 if these scripts need to be run on the build host during the 2781 if these scripts need to be run on the build host during the
2782 ```do_rootfs`` <#ref-tasks-rootfs>`__ task. 2782 :ref:`ref-tasks-rootfs` task.
2783 2783
2784 As an example, see the ``dbus`` recipe. You will see that this recipe 2784 As an example, see the ``dbus`` recipe. You will see that this recipe
2785 has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in 2785 has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in
2786 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. In the example, 2786 :term:`DISTRO_FEATURES`. In the example,
2787 ``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``, 2787 ``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``,
2788 which is also conditional on "systemd" being in ``DISTRO_FEATURES``. 2788 which is also conditional on "systemd" being in ``DISTRO_FEATURES``.
2789 2789
@@ -2797,7 +2797,7 @@ Consider the following:
2797 functions being called through ``SSTATEPOSTINSTFUNCS`` are doing 2797 functions being called through ``SSTATEPOSTINSTFUNCS`` are doing
2798 relocation, then you will need to change these to use a 2798 relocation, then you will need to change these to use a
2799 post-installation script that is installed by a function added to 2799 post-installation script that is installed by a function added to
2800 ```SYSROOT_PREPROCESS_FUNCS`` <#var-SYSROOT_PREPROCESS_FUNCS>`__. 2800 :term:`SYSROOT_PREPROCESS_FUNCS`.
2801 2801
2802 For an example, see the ``pixbufcache`` class in ``meta/classes/`` in 2802 For an example, see the ``pixbufcache`` class in ``meta/classes/`` in
2803 the Yocto Project `Source 2803 the Yocto Project `Source
@@ -2821,7 +2821,7 @@ Consider the following:
2821 the shared sysroot is now gone, the scripts 2821 the shared sysroot is now gone, the scripts
2822 ``oe-find-native-sysroot`` and ``oe-run-native`` have been changed 2822 ``oe-find-native-sysroot`` and ``oe-run-native`` have been changed
2823 such that you need to specify which recipe's 2823 such that you need to specify which recipe's
2824 ```STAGING_DIR_NATIVE`` <#var-STAGING_DIR_NATIVE>`__ is used. 2824 :term:`STAGING_DIR_NATIVE` is used.
2825 2825
2826.. note:: 2826.. note::
2827 2827
@@ -2839,8 +2839,8 @@ Within the environment used to run build tasks, the environment variable
2839``PATH`` is now sanitized such that the normal native binary paths 2839``PATH`` is now sanitized such that the normal native binary paths
2840(``/bin``, ``/sbin``, ``/usr/bin`` and so forth) are removed and a 2840(``/bin``, ``/sbin``, ``/usr/bin`` and so forth) are removed and a
2841directory containing symbolic links linking only to the binaries from 2841directory containing symbolic links linking only to the binaries from
2842the host mentioned in the ```HOSTTOOLS`` <#var-HOSTTOOLS>`__ and 2842the host mentioned in the :term:`HOSTTOOLS` and
2843```HOSTTOOLS_NONFATAL`` <#var-HOSTTOOLS_NONFATAL>`__ variables is added 2843:term:`HOSTTOOLS_NONFATAL` variables is added
2844to ``PATH``. 2844to ``PATH``.
2845 2845
2846Consequently, any native binaries provided by the host that you need to 2846Consequently, any native binaries provided by the host that you need to
@@ -2848,7 +2848,7 @@ call needs to be in one of these two variables at the configuration
2848level. 2848level.
2849 2849
2850Alternatively, you can add a native recipe (i.e. ``-native``) that 2850Alternatively, you can add a native recipe (i.e. ``-native``) that
2851provides the binary to the recipe's ```DEPENDS`` <#var-DEPENDS>`__ 2851provides the binary to the recipe's :term:`DEPENDS`
2852value. 2852value.
2853 2853
2854.. note:: 2854.. note::
@@ -2881,7 +2881,7 @@ The following changes to scripts took place:
2881- *``cleanup-workdir``:* The ``cleanup-workdir`` script has been 2881- *``cleanup-workdir``:* The ``cleanup-workdir`` script has been
2882 removed because the script was found to be deleting files it should 2882 removed because the script was found to be deleting files it should
2883 not have, which lead to broken build trees. Rather than trying to 2883 not have, which lead to broken build trees. Rather than trying to
2884 delete portions of ```TMPDIR`` <#var-TMPDIR>`__ and getting it wrong, 2884 delete portions of :term:`TMPDIR` and getting it wrong,
2885 it is recommended that you delete ``TMPDIR`` and have it restored 2885 it is recommended that you delete ``TMPDIR`` and have it restored
2886 from shared state (sstate) on subsequent builds. 2886 from shared state (sstate) on subsequent builds.
2887 2887
@@ -2927,8 +2927,8 @@ The following changes took place for BitBake:
2927 between recipes, which could be misleading. 2927 between recipes, which could be misleading.
2928 2928
2929- *Mirror Variable Splitting Changes:* Mirror variables including 2929- *Mirror Variable Splitting Changes:* Mirror variables including
2930 ```MIRRORS`` <#var-MIRRORS>`__, ```PREMIRRORS`` <#var-PREMIRRORS>`__, 2930 :term:`MIRRORS`, :term:`PREMIRRORS`,
2931 and ```SSTATE_MIRRORS`` <#var-SSTATE_MIRRORS>`__ can now separate 2931 and :term:`SSTATE_MIRRORS` can now separate
2932 values entirely with spaces. Consequently, you no longer need "\\n". 2932 values entirely with spaces. Consequently, you no longer need "\\n".
2933 BitBake looks for pairs of values, which simplifies usage. There 2933 BitBake looks for pairs of values, which simplifies usage. There
2934 should be no change required to existing mirror variable values 2934 should be no change required to existing mirror variable values
@@ -2940,7 +2940,7 @@ The following changes took place for BitBake:
2940 when the "protocol" parameter is set to "svn+ssh". You can only use 2940 when the "protocol" parameter is set to "svn+ssh". You can only use
2941 the new parameter to specify the ``ssh`` program used by SVN. The SVN 2941 the new parameter to specify the ``ssh`` program used by SVN. The SVN
2942 fetcher passes the new parameter through the ``SVN_SSH`` environment 2942 fetcher passes the new parameter through the ``SVN_SSH`` environment
2943 variable during the ```do_fetch`` <#ref-tasks-fetch>`__ task. 2943 variable during the :ref:`ref-tasks-fetch` task.
2944 2944
2945 See the "`Subversion (SVN) Fetcher 2945 See the "`Subversion (SVN) Fetcher
2946 (svn://) <&YOCTO_DOCS_BB_URL;#svn-fetcher>`__" section in the BitBake 2946 (svn://) <&YOCTO_DOCS_BB_URL;#svn-fetcher>`__" section in the BitBake
@@ -2974,8 +2974,8 @@ GPLv2 Versions of GPLv3 Recipes Moved
2974Older GPLv2 versions of GPLv3 recipes have moved to a separate 2974Older GPLv2 versions of GPLv3 recipes have moved to a separate
2975``meta-gplv2`` layer. 2975``meta-gplv2`` layer.
2976 2976
2977If you use ```INCOMPATIBLE_LICENSE`` <#var-INCOMPATIBLE_LICENSE>`__ to 2977If you use :term:`INCOMPATIBLE_LICENSE` to
2978exclude GPLv3 or set ```PREFERRED_VERSION`` <#var-PREFERRED_VERSION>`__ 2978exclude GPLv3 or set :term:`PREFERRED_VERSION`
2979to substitute a GPLv2 version of a GPLv3 recipe, then you must add the 2979to substitute a GPLv2 version of a GPLv3 recipe, then you must add the
2980``meta-gplv2`` layer to your configuration. 2980``meta-gplv2`` layer to your configuration.
2981 2981
@@ -3052,7 +3052,7 @@ The following package management changes took place:
3052 This change was made because too many places in DNF/RPM4 stack 3052 This change was made because too many places in DNF/RPM4 stack
3053 already make that assumption. Only the filenames and the architecture 3053 already make that assumption. Only the filenames and the architecture
3054 tag has changed. Nothing else has changed in OE-core system, 3054 tag has changed. Nothing else has changed in OE-core system,
3055 particularly in the ```allarch.bbclass`` <#ref-classes-allarch>`__ 3055 particularly in the :ref:`allarch.bbclass <ref-classes-allarch>`
3056 class. 3056 class.
3057 3057
3058- Signing of remote package feeds using ``PACKAGE_FEED_SIGN`` is not 3058- Signing of remote package feeds using ``PACKAGE_FEED_SIGN`` is not
@@ -3100,7 +3100,7 @@ The following recipes have been removed:
3100- *``tremor:``* Moved to ``meta-multimedia``. Fixed-integer Vorbis 3100- *``tremor:``* Moved to ``meta-multimedia``. Fixed-integer Vorbis
3101 decoding is not needed by current hardware. Thus, GStreamer's ivorbis 3101 decoding is not needed by current hardware. Thus, GStreamer's ivorbis
3102 plugin has been disabled by default eliminating the need for the 3102 plugin has been disabled by default eliminating the need for the
3103 ``tremor`` recipe in `OE-Core <#oe-core>`__. 3103 ``tremor`` recipe in :term:`OpenEmbedded-Core (OE-Core)`.
3104 3104
3105- *``gummiboot:``* Replaced by ``systemd-boot``. 3105- *``gummiboot:``* Replaced by ``systemd-boot``.
3106 3106
@@ -3151,7 +3151,7 @@ The following QA checks have changed:
3151 warning, you need to address missing runtime dependencies. 3151 warning, you need to address missing runtime dependencies.
3152 3152
3153 For additional information, see the 3153 For additional information, see the
3154 ```insane`` <#ref-classes-insane>`__ class and the "`Errors and 3154 :ref:`insane <ref-classes-insane>` class and the "`Errors and
3155 Warnings <#qa-errors-and-warnings>`__" section. 3155 Warnings <#qa-errors-and-warnings>`__" section.
3156 3156
3157.. _migration-2.3-miscellaneous-changes: 3157.. _migration-2.3-miscellaneous-changes:
@@ -3162,7 +3162,7 @@ Miscellaneous Changes
3162The following miscellaneous changes have occurred: 3162The following miscellaneous changes have occurred:
3163 3163
3164- In this release, a number of recipes have been changed to ignore the 3164- In this release, a number of recipes have been changed to ignore the
3165 ``largefile`` ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ item, 3165 ``largefile`` :term:`DISTRO_FEATURES` item,
3166 enabling large file support unconditionally. This feature has always 3166 enabling large file support unconditionally. This feature has always
3167 been enabled by default. Disabling the feature has not been widely 3167 been enabled by default. Disabling the feature has not been widely
3168 tested. 3168 tested.
@@ -3174,8 +3174,8 @@ The following miscellaneous changes have occurred:
3174 largefile 3174 largefile
3175 feature, which would make it unconditionally enabled everywhere. 3175 feature, which would make it unconditionally enabled everywhere.
3176 3176
3177- If the ```DISTRO_VERSION`` <#var-DISTRO_VERSION>`__ value contains 3177- If the :term:`DISTRO_VERSION` value contains
3178 the value of the ```DATE`` <#var-DATE>`__ variable, which is the 3178 the value of the :term:`DATE` variable, which is the
3179 default between Poky releases, the ``DATE`` value is explicitly 3179 default between Poky releases, the ``DATE`` value is explicitly
3180 excluded from ``/etc/issue`` and ``/etc/issue.net``, which is 3180 excluded from ``/etc/issue`` and ``/etc/issue.net``, which is
3181 displayed at the login prompt, in order to avoid conflicts with 3181 displayed at the login prompt, in order to avoid conflicts with
@@ -3186,7 +3186,7 @@ The following miscellaneous changes have occurred:
3186 If you need the build date recorded in ``/etc/issue*`` or anywhere 3186 If you need the build date recorded in ``/etc/issue*`` or anywhere
3187 else in your image, a better method is to define a post-processing 3187 else in your image, a better method is to define a post-processing
3188 function to do it and have the function called from 3188 function to do it and have the function called from
3189 ```ROOTFS_POSTPROCESS_COMMAND`` <#var-ROOTFS_POSTPROCESS_COMMAND>`__. 3189 :term:`ROOTFS_POSTPROCESS_COMMAND`.
3190 Doing so ensures the value is always up-to-date with the created 3190 Doing so ensures the value is always up-to-date with the created
3191 image. 3191 image.
3192 3192
@@ -3195,7 +3195,7 @@ The following miscellaneous changes have occurred:
3195 RSA keys only, and with recent versions of OpenSSH, which deprecates 3195 RSA keys only, and with recent versions of OpenSSH, which deprecates
3196 DSA host keys. 3196 DSA host keys.
3197 3197
3198- The ```buildhistory`` <#ref-classes-buildhistory>`__ class now 3198- The :ref:`buildhistory <ref-classes-buildhistory>` class now
3199 correctly uses tabs as separators between all columns in 3199 correctly uses tabs as separators between all columns in
3200 ``installed-package-sizes.txt`` in order to aid import into other 3200 ``installed-package-sizes.txt`` in order to aid import into other
3201 tools. 3201 tools.
@@ -3206,7 +3206,7 @@ The following miscellaneous changes have occurred:
3206 DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig" 3206 DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig"
3207 3207
3208- The default value of 3208- The default value of
3209 ```COPYLEFT_LICENSE_INCLUDE`` <#var-COPYLEFT_LICENSE_INCLUDE>`__ now 3209 :term:`COPYLEFT_LICENSE_INCLUDE` now
3210 includes all versions of AGPL licenses in addition to GPL and LGPL. 3210 includes all versions of AGPL licenses in addition to GPL and LGPL.
3211 3211
3212 .. note:: 3212 .. note::
@@ -3227,14 +3227,14 @@ The following miscellaneous changes have occurred:
3227 3227
3228 If you need to preserve these ``.la`` files (e.g. in a custom 3228 If you need to preserve these ``.la`` files (e.g. in a custom
3229 distribution), you must change 3229 distribution), you must change
3230 ```INHERIT_DISTRO`` <#var-INHERIT_DISTRO>`__ such that 3230 :term:`INHERIT_DISTRO` such that
3231 "remove-libtool" is not included in the value. 3231 "remove-libtool" is not included in the value.
3232 3232
3233- Extensible SDKs built for GCC 5+ now refuse to install on a 3233- Extensible SDKs built for GCC 5+ now refuse to install on a
3234 distribution where the host GCC version is 4.8 or 4.9. This change 3234 distribution where the host GCC version is 4.8 or 4.9. This change
3235 resulted from the fact that the installation is known to fail due to 3235 resulted from the fact that the installation is known to fail due to
3236 the way the ``uninative`` shared state (sstate) package is built. See 3236 the way the ``uninative`` shared state (sstate) package is built. See
3237 the ```uninative`` <#ref-classes-uninative>`__ class for additional 3237 the :ref:`uninative <ref-classes-uninative>` class for additional
3238 information. 3238 information.
3239 3239
3240- All native and nativesdk recipes now use a separate 3240- All native and nativesdk recipes now use a separate
@@ -3242,18 +3242,18 @@ The following miscellaneous changes have occurred:
3242 recipes for the target, in order to avoid unnecessary rebuilds. 3242 recipes for the target, in order to avoid unnecessary rebuilds.
3243 3243
3244 The ``DISTRO_FEATURES`` for ``native`` recipes is 3244 The ``DISTRO_FEATURES`` for ``native`` recipes is
3245 ```DISTRO_FEATURES_NATIVE`` <#var-DISTRO_FEATURES_NATIVE>`__ added to 3245 :term:`DISTRO_FEATURES_NATIVE` added to
3246 an intersection of ``DISTRO_FEATURES`` and 3246 an intersection of ``DISTRO_FEATURES`` and
3247 ```DISTRO_FEATURES_FILTER_NATIVE`` <#var-DISTRO_FEATURES_FILTER_NATIVE>`__. 3247 :term:`DISTRO_FEATURES_FILTER_NATIVE`.
3248 3248
3249 For nativesdk recipes, the corresponding variables are 3249 For nativesdk recipes, the corresponding variables are
3250 ```DISTRO_FEATURES_NATIVESDK`` <#var-DISTRO_FEATURES_NATIVESDK>`__ 3250 :term:`DISTRO_FEATURES_NATIVESDK`
3251 and 3251 and
3252 ```DISTRO_FEATURES_FILTER_NATIVESDK`` <#var-DISTRO_FEATURES_FILTER_NATIVESDK>`__. 3252 :term:`DISTRO_FEATURES_FILTER_NATIVESDK`.
3253 3253
3254- The ``FILESDIR`` variable, which was previously deprecated and rarely 3254- The ``FILESDIR`` variable, which was previously deprecated and rarely
3255 used, has now been removed. You should change any recipes that set 3255 used, has now been removed. You should change any recipes that set
3256 ``FILESDIR`` to set ```FILESPATH`` <#var-FILESPATH>`__ instead. 3256 ``FILESDIR`` to set :term:`FILESPATH` instead.
3257 3257
3258- The ``MULTIMACH_HOST_SYS`` variable has been removed as it is no 3258- The ``MULTIMACH_HOST_SYS`` variable has been removed as it is no
3259 longer needed with recipe-specific sysroots. 3259 longer needed with recipe-specific sysroots.
@@ -3272,7 +3272,7 @@ Memory Resident Mode
3272A persistent mode is now available in BitBake's default operation, 3272A persistent mode is now available in BitBake's default operation,
3273replacing its previous "memory resident mode" (i.e. 3273replacing its previous "memory resident mode" (i.e.
3274``oe-init-build-env-memres``). Now you only need to set 3274``oe-init-build-env-memres``). Now you only need to set
3275```BB_SERVER_TIMEOUT`` <#var-BB_SERVER_TIMEOUT>`__ to a timeout (in 3275:term:`BB_SERVER_TIMEOUT` to a timeout (in
3276seconds) and BitBake's server stays resident for that amount of time 3276seconds) and BitBake's server stays resident for that amount of time
3277between invocations. The ``oe-init-build-env-memres`` script has been 3277between invocations. The ``oe-init-build-env-memres`` script has been
3278removed since a separate environment setup script is no longer needed. 3278removed since a separate environment setup script is no longer needed.
@@ -3306,11 +3306,11 @@ occurred:
3306 3306
3307 - The ``su`` program is now packaged in a separate "util-linux-su" 3307 - The ``su`` program is now packaged in a separate "util-linux-su"
3308 package, which is only built when "pam" is listed in the 3308 package, which is only built when "pam" is listed in the
3309 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ variable. 3309 :term:`DISTRO_FEATURES` variable.
3310 ``util-linux`` should not be installed unless it is needed because 3310 ``util-linux`` should not be installed unless it is needed because
3311 ``su`` is normally provided through the shadow file format. The 3311 ``su`` is normally provided through the shadow file format. The
3312 main ``util-linux`` package has runtime dependencies (i.e. 3312 main ``util-linux`` package has runtime dependencies (i.e.
3313 ```RDEPENDS`` <#var-RDEPENDS>`__) on the ``util-linux-su`` package 3313 :term:`RDEPENDS`) on the ``util-linux-su`` package
3314 when "pam" is in ``DISTRO_FEATURES``. 3314 when "pam" is in ``DISTRO_FEATURES``.
3315 3315
3316 - The ``switch_root`` program is now packaged in a separate 3316 - The ``switch_root`` program is now packaged in a separate
@@ -3318,7 +3318,7 @@ occurred:
3318 do not need the whole ``util-linux`` package or the busybox 3318 do not need the whole ``util-linux`` package or the busybox
3319 binary, which are both much larger than ``switch_root``. The main 3319 binary, which are both much larger than ``switch_root``. The main
3320 ``util-linux`` package has a recommended runtime dependency (i.e. 3320 ``util-linux`` package has a recommended runtime dependency (i.e.
3321 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__) on the 3321 :term:`RRECOMMENDS`) on the
3322 ``util-linux-switch-root`` package. 3322 ``util-linux-switch-root`` package.
3323 3323
3324 - The ``ionice`` program is now packaged in a separate 3324 - The ``ionice`` program is now packaged in a separate
@@ -3338,7 +3338,7 @@ occurred:
3338 runtime dependency (i.e. ``RRECOMMENDS``) on the ``shared-mime-info`` 3338 runtime dependency (i.e. ``RRECOMMENDS``) on the ``shared-mime-info``
3339 package, since large portions of GIO are not useful without the MIME 3339 package, since large portions of GIO are not useful without the MIME
3340 database. You can remove the dependency by using the 3340 database. You can remove the dependency by using the
3341 ```BAD_RECOMMENDATIONS`` <#var-BAD_RECOMMENDATIONS>`__ variable if 3341 :term:`BAD_RECOMMENDATIONS` variable if
3342 ``shared-mime-info`` is too large and is not required. 3342 ``shared-mime-info`` is too large and is not required.
3343 3343
3344- *Go Standard Runtime:* The Go standard runtime has been split out 3344- *Go Standard Runtime:* The Go standard runtime has been split out
@@ -3456,10 +3456,10 @@ Kernel Device Tree Move
3456 3456
3457Kernel Device Tree support is now easier to enable in a kernel recipe. 3457Kernel Device Tree support is now easier to enable in a kernel recipe.
3458The Device Tree code has moved to a 3458The Device Tree code has moved to a
3459```kernel-devicetree`` <#ref-classes-kernel-devicetree>`__ class. 3459:ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class.
3460Functionality is automatically enabled for any recipe that inherits the 3460Functionality is automatically enabled for any recipe that inherits the
3461```kernel`` <#ref-classes-kernel>`__ class and sets the 3461:ref:`kernel <ref-classes-kernel>` class and sets the
3462```KERNEL_DEVICETREE`` <#var-KERNEL_DEVICETREE>`__ variable. The 3462:term:`KERNEL_DEVICETREE` variable. The
3463previous mechanism for doing this, 3463previous mechanism for doing this,
3464``meta/recipes-kernel/linux/linux-dtb.inc``, is still available to avoid 3464``meta/recipes-kernel/linux/linux-dtb.inc``, is still available to avoid
3465breakage, but triggers a deprecation warning. Future releases of the 3465breakage, but triggers a deprecation warning. Future releases of the
@@ -3478,7 +3478,7 @@ The following package QA changes took place:
3478- The "unsafe-references-in-scripts" QA check has been removed. 3478- The "unsafe-references-in-scripts" QA check has been removed.
3479 3479
3480- If you refer to ``${COREBASE}/LICENSE`` within 3480- If you refer to ``${COREBASE}/LICENSE`` within
3481 ```LIC_FILES_CHKSUM`` <#var-LIC_FILES_CHKSUM>`__ you receive a 3481 :term:`LIC_FILES_CHKSUM` you receive a
3482 warning because this file is a description of the license for 3482 warning because this file is a description of the license for
3483 OE-Core. Use ``${COMMON_LICENSE_DIR}/MIT`` if your recipe is 3483 OE-Core. Use ``${COMMON_LICENSE_DIR}/MIT`` if your recipe is
3484 MIT-licensed and you cannot use the preferred method of referring to 3484 MIT-licensed and you cannot use the preferred method of referring to
@@ -3529,10 +3529,10 @@ The following are additional changes:
3529 from ``meta-poky`` to OE-Core (i.e. from 3529 from ``meta-poky`` to OE-Core (i.e. from
3530 ``meta-poky/conf/distro/include`` to ``meta/conf/distro/include``). 3530 ``meta-poky/conf/distro/include`` to ``meta/conf/distro/include``).
3531 3531
3532- The ```buildhistory`` <#ref-classes-buildhistory>`__ class now makes 3532- The :ref:`buildhistory <ref-classes-buildhistory>` class now makes
3533 a single commit per build rather than one commit per subdirectory in 3533 a single commit per build rather than one commit per subdirectory in
3534 the repository. This behavior assumes the commits are enabled with 3534 the repository. This behavior assumes the commits are enabled with
3535 ```BUILDHISTORY_COMMIT`` <#var-BUILDHISTORY_COMMIT>`__ = "1", which 3535 :term:`BUILDHISTORY_COMMIT` = "1", which
3536 is typical. Previously, the ``buildhistory`` class made one commit 3536 is typical. Previously, the ``buildhistory`` class made one commit
3537 per subdirectory in the repository in order to make it easier to see 3537 per subdirectory in the repository in order to make it easier to see
3538 the changes for a particular subdirectory. To view a particular 3538 the changes for a particular subdirectory. To view a particular
@@ -3540,7 +3540,7 @@ The following are additional changes:
3540 ``git show`` or ``git diff`` commands. 3540 ``git show`` or ``git diff`` commands.
3541 3541
3542- The ``x86-base.inc`` file, which is included by all x86-based machine 3542- The ``x86-base.inc`` file, which is included by all x86-based machine
3543 configurations, now sets ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ 3543 configurations, now sets :term:`IMAGE_FSTYPES`
3544 using ``?=`` to "live" rather than appending with ``+=``. This change 3544 using ``?=`` to "live" rather than appending with ``+=``. This change
3545 makes the default easier to override. 3545 makes the default easier to override.
3546 3546
@@ -3550,7 +3550,7 @@ The following are additional changes:
3550 Manual. 3550 Manual.
3551 3551
3552- By default, the ``security_flags.inc`` file sets a 3552- By default, the ``security_flags.inc`` file sets a
3553 ```GCCPIE`` <#var-GCCPIE>`__ variable with an option to enable 3553 :term:`GCCPIE` variable with an option to enable
3554 Position Independent Executables (PIE) within ``gcc``. Enabling PIE 3554 Position Independent Executables (PIE) within ``gcc``. Enabling PIE
3555 in the GNU C Compiler (GCC), makes Return Oriented Programming (ROP) 3555 in the GNU C Compiler (GCC), makes Return Oriented Programming (ROP)
3556 attacks much more difficult to execute. 3556 attacks much more difficult to execute.
@@ -3570,12 +3570,12 @@ The following are additional changes:
3570 you need to update them. 3570 you need to update them.
3571 3571
3572- OpenSSL 1.1 has been introduced. However, the default is still 1.0.x 3572- OpenSSL 1.1 has been introduced. However, the default is still 1.0.x
3573 through the ```PREFERRED_VERSION`` <#var-PREFERRED_VERSION>`__ 3573 through the :term:`PREFERRED_VERSION`
3574 variable. This preference is set is due to the remaining 3574 variable. This preference is set is due to the remaining
3575 compatibility issues with other software. The 3575 compatibility issues with other software. The
3576 ```PROVIDES`` <#var-PROVIDES>`__ variable in the openssl 1.0 recipe 3576 :term:`PROVIDES` variable in the openssl 1.0 recipe
3577 now includes "openssl10" as a marker that can be used in 3577 now includes "openssl10" as a marker that can be used in
3578 ```DEPENDS`` <#var-DEPENDS>`__ within recipes that build software 3578 :term:`DEPENDS` within recipes that build software
3579 that still depend on OpenSSL 1.0. 3579 that still depend on OpenSSL 1.0.
3580 3580
3581- To ensure consistent behavior, BitBake's "-r" and "-R" options (i.e. 3581- To ensure consistent behavior, BitBake's "-r" and "-R" options (i.e.
@@ -3747,7 +3747,7 @@ One particular change to note is that the Python recipes no longer have
3747build-time provides for their packages. This assumes ``python-foo`` is 3747build-time provides for their packages. This assumes ``python-foo`` is
3748one of the packages provided by the Python recipe. You can no longer run 3748one of the packages provided by the Python recipe. You can no longer run
3749``bitbake python-foo`` or have a 3749``bitbake python-foo`` or have a
3750```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ on ``python-foo``, 3750:term:`DEPENDS` on ``python-foo``,
3751but doing either of the following causes the package to work as 3751but doing either of the following causes the package to work as
3752expected: IMAGE_INSTALL_append = " python-foo" or RDEPENDS_${PN} = 3752expected: IMAGE_INSTALL_append = " python-foo" or RDEPENDS_${PN} =
3753"python-foo" The earlier build-time provides behavior was a quirk of the 3753"python-foo" The earlier build-time provides behavior was a quirk of the
@@ -3787,7 +3787,7 @@ The following are additional changes:
3787 ``sysklogd`` recipe no longer uses ``update-alternatives`` because it 3787 ``sysklogd`` recipe no longer uses ``update-alternatives`` because it
3788 is incompatible with other implementations. 3788 is incompatible with other implementations.
3789 3789
3790- By default, the ```cmake`` <#ref-classes-cmake>`__ class uses 3790- By default, the :ref:`cmake <ref-classes-cmake>` class uses
3791 ``ninja`` instead of ``make`` for building. This improves build 3791 ``ninja`` instead of ``make`` for building. This improves build
3792 performance. If a recipe is broken with ``ninja``, then the recipe 3792 performance. If a recipe is broken with ``ninja``, then the recipe
3793 can set ``OECMAKE_GENERATOR = "Unix Makefiles"`` to change back to 3793 can set ``OECMAKE_GENERATOR = "Unix Makefiles"`` to change back to
@@ -3878,7 +3878,7 @@ release, see ` <https://gcc.gnu.org/gcc-8/changes.html>`__.
3878 3878
3879If you still need to compile with version 7.x, GCC 7.3 is also provided. 3879If you still need to compile with version 7.x, GCC 7.3 is also provided.
3880You can select this version by setting the and can be selected by 3880You can select this version by setting the and can be selected by
3881setting the ```GCCVERSION`` <#var-GCCVERSION>`__ variable to "7.%" in 3881setting the :term:`GCCVERSION` variable to "7.%" in
3882your configuration. 3882your configuration.
3883 3883
3884.. _migration-2.6-removed-recipes: 3884.. _migration-2.6-removed-recipes:
@@ -3972,12 +3972,12 @@ For names of recipes removed because of this repository change, see the
3972--------------------------------------------------------------------------------------------------- 3972---------------------------------------------------------------------------------------------------
3973 3973
3974Previously, it was possible for Python recipes that inherited the 3974Previously, it was possible for Python recipes that inherited the
3975```distutils`` <#ref-classes-distutils>`__ and 3975:ref:`distutils <ref-classes-distutils>` and
3976```distutils3`` <#ref-classes-distutils3>`__ classes to fetch code 3976```distutils3`` <#ref-classes-distutils3>`__ classes to fetch code
3977during the ```do_configure`` <#ref-tasks-configure>`__ task to satisfy 3977during the :ref:`ref-tasks-configure` task to satisfy
3978dependencies mentioned in ``setup.py`` if those dependencies were not 3978dependencies mentioned in ``setup.py`` if those dependencies were not
3979provided in the sysroot (i.e. recipes providing the dependencies were 3979provided in the sysroot (i.e. recipes providing the dependencies were
3980missing from ```DEPENDS`` <#var-DEPENDS>`__). 3980missing from :term:`DEPENDS`).
3981 3981
3982.. note:: 3982.. note::
3983 3983
@@ -4018,9 +4018,9 @@ Image/Kernel Artifact Naming Changes
4018 4018
4019The following changes have been made: 4019The following changes have been made:
4020 4020
4021- Name variables (e.g. ```IMAGE_NAME`` <#var-IMAGE_NAME>`__) use a new 4021- Name variables (e.g. :term:`IMAGE_NAME`) use a new
4022 ``IMAGE_VERSION_SUFFIX`` variable instead of 4022 ``IMAGE_VERSION_SUFFIX`` variable instead of
4023 ```DATETIME`` <#var-DATETIME>`__. Using ``IMAGE_VERSION_SUFFIX`` 4023 :term:`DATETIME`. Using ``IMAGE_VERSION_SUFFIX``
4024 allows easier and more direct changes. 4024 allows easier and more direct changes.
4025 4025
4026 The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf`` 4026 The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf``
@@ -4029,40 +4029,40 @@ The following changes have been made:
4029- Several variables have changed names for consistency: Old Variable 4029- Several variables have changed names for consistency: Old Variable
4030 Name New Variable Name 4030 Name New Variable Name
4031 ======================================================== 4031 ========================================================
4032 KERNEL_IMAGE_BASE_NAME `KERNEL_IMAGE_NAME <#var-KERNEL_IMAGE_NAME>`__ 4032 KERNEL_IMAGE_BASE_NAME :term:`KERNEL_IMAGE_NAME`
4033 KERNEL_IMAGE_SYMLINK_NAME 4033 KERNEL_IMAGE_SYMLINK_NAME
4034 `KERNEL_IMAGE_LINK_NAME <#var-KERNEL_IMAGE_LINK_NAME>`__ 4034 :term:`KERNEL_IMAGE_LINK_NAME`
4035 MODULE_TARBALL_BASE_NAME 4035 MODULE_TARBALL_BASE_NAME
4036 `MODULE_TARBALL_NAME <#var-MODULE_TARBALL_NAME>`__ 4036 :term:`MODULE_TARBALL_NAME`
4037 MODULE_TARBALL_SYMLINK_NAME 4037 MODULE_TARBALL_SYMLINK_NAME
4038 `MODULE_TARBALL_LINK_NAME <#var-MODULE_TARBALL_LINK_NAME>`__ 4038 :term:`MODULE_TARBALL_LINK_NAME`
4039 INITRAMFS_BASE_NAME `INITRAMFS_NAME <#var-INITRAMFS_NAME>`__ 4039 INITRAMFS_BASE_NAME :term:`INITRAMFS_NAME`
4040 4040
4041- The ``MODULE_IMAGE_BASE_NAME`` variable has been removed. The module 4041- The ``MODULE_IMAGE_BASE_NAME`` variable has been removed. The module
4042 tarball name is now controlled directly with the 4042 tarball name is now controlled directly with the
4043 ```MODULE_TARBALL_NAME`` <#var-MODULE_TARBALL_NAME>`__ variable. 4043 :term:`MODULE_TARBALL_NAME` variable.
4044 4044
4045- The ```KERNEL_DTB_NAME`` <#var-KERNEL_DTB_NAME>`__ and 4045- The :term:`KERNEL_DTB_NAME` and
4046 ```KERNEL_DTB_LINK_NAME`` <#var-KERNEL_DTB_LINK_NAME>`__ variables 4046 :term:`KERNEL_DTB_LINK_NAME` variables
4047 have been introduced to control kernel Device Tree Binary (DTB) 4047 have been introduced to control kernel Device Tree Binary (DTB)
4048 artifact names instead of mangling ``KERNEL_IMAGE_*`` variables. 4048 artifact names instead of mangling ``KERNEL_IMAGE_*`` variables.
4049 4049
4050- The ```KERNEL_FIT_NAME`` <#var-KERNEL_FIT_NAME>`__ and 4050- The :term:`KERNEL_FIT_NAME` and
4051 ```KERNEL_FIT_LINK_NAME`` <#var-KERNEL_FIT_LINK_NAME>`__ variables 4051 :term:`KERNEL_FIT_LINK_NAME` variables
4052 have been introduced to specify the name of flattened image tree 4052 have been introduced to specify the name of flattened image tree
4053 (FIT) kernel images similar to other deployed artifacts. 4053 (FIT) kernel images similar to other deployed artifacts.
4054 4054
4055- The ```MODULE_TARBALL_NAME`` <#var-MODULE_TARBALL_NAME>`__ and 4055- The :term:`MODULE_TARBALL_NAME` and
4056 ```MODULE_TARBALL_LINK_NAME`` <#var-MODULE_TARBALL_LINK_NAME>`__ 4056 :term:`MODULE_TARBALL_LINK_NAME`
4057 variable values no longer include the "module-" prefix or ".tgz" 4057 variable values no longer include the "module-" prefix or ".tgz"
4058 suffix. These parts are now hardcoded so that the values are 4058 suffix. These parts are now hardcoded so that the values are
4059 consistent with other artifact naming variables. 4059 consistent with other artifact naming variables.
4060 4060
4061- Added the ```INITRAMFS_LINK_NAME`` <#var-INITRAMFS_LINK_NAME>`__ 4061- Added the :term:`INITRAMFS_LINK_NAME`
4062 variable so that the symlink can be controlled similarly to other 4062 variable so that the symlink can be controlled similarly to other
4063 artifact types. 4063 artifact types.
4064 4064
4065- ```INITRAMFS_NAME`` <#var-INITRAMFS_NAME>`__ now uses 4065- :term:`INITRAMFS_NAME` now uses
4066 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" instead 4066 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" instead
4067 of "${PV}-${PR}-${MACHINE}-${DATETIME}", which makes it consistent 4067 of "${PV}-${PR}-${MACHINE}-${DATETIME}", which makes it consistent
4068 with other variables. 4068 with other variables.
@@ -4072,9 +4072,9 @@ The following changes have been made:
4072``SERIAL_CONSOLE`` Deprecated 4072``SERIAL_CONSOLE`` Deprecated
4073----------------------------- 4073-----------------------------
4074 4074
4075The ```SERIAL_CONSOLE`` <#var-SERIAL_CONSOLE>`__ variable has been 4075The :term:`SERIAL_CONSOLE` variable has been
4076functionally replaced by the 4076functionally replaced by the
4077```SERIAL_CONSOLES`` <#var-SERIAL_CONSOLES>`__ variable for some time. 4077:term:`SERIAL_CONSOLES` variable for some time.
4078With the Yocto Project 2.6 release, ``SERIAL_CONSOLE`` has been 4078With the Yocto Project 2.6 release, ``SERIAL_CONSOLE`` has been
4079officially deprecated. 4079officially deprecated.
4080 4080
@@ -4122,7 +4122,7 @@ The following changes have occurred:
4122- *The ``forcevariable`` Override Now Has a Higher Priority Than 4122- *The ``forcevariable`` Override Now Has a Higher Priority Than
4123 ``libc`` Overrides:* The ``forcevariable`` override is documented to 4123 ``libc`` Overrides:* The ``forcevariable`` override is documented to
4124 be the highest priority override. However, due to a long-standing 4124 be the highest priority override. However, due to a long-standing
4125 quirk of how ```OVERRIDES`` <#var-OVERRIDES>`__ is set, the ``libc`` 4125 quirk of how :term:`OVERRIDES` is set, the ``libc``
4126 overrides (e.g. ``libc-glibc``, ``libc-musl``, and so forth) 4126 overrides (e.g. ``libc-glibc``, ``libc-musl``, and so forth)
4127 erroneously had a higher priority. This issue is now corrected. 4127 erroneously had a higher priority. This issue is now corrected.
4128 4128
@@ -4177,14 +4177,14 @@ This section provides information about automatic testing changes:
4177 ``TEST_IMAGE`` variable to "1" to enable automatic testing for 4177 ``TEST_IMAGE`` variable to "1" to enable automatic testing for
4178 successfully built images. The ``TEST_IMAGE`` variable no longer 4178 successfully built images. The ``TEST_IMAGE`` variable no longer
4179 exists and has been replaced by the 4179 exists and has been replaced by the
4180 ```TESTIMAGE_AUTO`` <#var-TESTIMAGE_AUTO>`__ variable. 4180 :term:`TESTIMAGE_AUTO` variable.
4181 4181
4182- *Inheriting the ``testimage`` and ``testsdk`` Classes:* Best 4182- *Inheriting the ``testimage`` and ``testsdk`` Classes:* Best
4183 practices now dictate that you use the 4183 practices now dictate that you use the
4184 ```IMAGE_CLASSES`` <#var-IMAGE_CLASSES>`__ variable rather than the 4184 :term:`IMAGE_CLASSES` variable rather than the
4185 ```INHERIT`` <#var-INHERIT>`__ variable when you inherit the 4185 :term:`INHERIT` variable when you inherit the
4186 ```testimage`` <#ref-classes-testimage*>`__ and 4186 ```testimage`` <#ref-classes-testimage*>`__ and
4187 ```testsdk`` <#ref-classes-testsdk>`__ classes used for automatic 4187 :ref:`testsdk <ref-classes-testsdk>` classes used for automatic
4188 testing. 4188 testing.
4189 4189
4190.. _migration-2.6-openssl-changes: 4190.. _migration-2.6-openssl-changes:
@@ -4207,7 +4207,7 @@ BitBake Changes
4207--------------- 4207---------------
4208 4208
4209The server logfile ``bitbake-cookerdaemon.log`` is now always placed in 4209The server logfile ``bitbake-cookerdaemon.log`` is now always placed in
4210the `Build Directory <#build-directory>`__ instead of the current 4210the :term:`Build Directory` instead of the current
4211directory. 4211directory.
4212 4212
4213.. _migration-2.6-security-changes: 4213.. _migration-2.6-security-changes:
@@ -4229,7 +4229,7 @@ want to explicitly defer a postinstall to first boot on the target
4229rather than at rootfs creation time, use ``pkg_postinst_ontarget()`` or 4229rather than at rootfs creation time, use ``pkg_postinst_ontarget()`` or
4230call ``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``. 4230call ``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``.
4231Any failure of a ``pkg_postinst()`` script (including exit 1) triggers 4231Any failure of a ``pkg_postinst()`` script (including exit 1) triggers
4232an error during the ```do_rootfs`` <#ref-tasks-rootfs>`__ task. 4232an error during the :ref:`ref-tasks-rootfs` task.
4233 4233
4234For more information on post-installation behavior, see the 4234For more information on post-installation behavior, see the
4235"`Post-Installation 4235"`Post-Installation
@@ -4245,14 +4245,14 @@ The ``python3`` recipe now enables profile-guided optimization. Using
4245this optimization requires a little extra build time in exchange for 4245this optimization requires a little extra build time in exchange for
4246improved performance on the target at runtime. Additionally, the 4246improved performance on the target at runtime. Additionally, the
4247optimization is only enabled if the current 4247optimization is only enabled if the current
4248```MACHINE`` <#var-MACHINE>`__ has support for user-mode emulation in 4248:term:`MACHINE` has support for user-mode emulation in
4249QEMU (i.e. "qemu-usermode" is in 4249QEMU (i.e. "qemu-usermode" is in
4250```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__, which it is by 4250:term:`MACHINE_FEATURES`, which it is by
4251default). 4251default).
4252 4252
4253If you wish to disable Python profile-guided optimization regardless of 4253If you wish to disable Python profile-guided optimization regardless of
4254the value of ``MACHINE_FEATURES``, then ensure that 4254the value of ``MACHINE_FEATURES``, then ensure that
4255```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__ for the ``python3`` recipe 4255:term:`PACKAGECONFIG` for the ``python3`` recipe
4256does not contain "pgo". You could accomplish the latter using the 4256does not contain "pgo". You could accomplish the latter using the
4257following at the configuration level: PACKAGECONFIG_remove_pn-python3 = 4257following at the configuration level: PACKAGECONFIG_remove_pn-python3 =
4258"pgo" Alternatively, you can set ``PACKAGECONFIG`` using an append file 4258"pgo" Alternatively, you can set ``PACKAGECONFIG`` using an append file
@@ -4276,13 +4276,13 @@ The following miscellaneous changes occurred:
4276 4276
4277- The ``NOISO`` and ``NOHDD`` variables are no longer used. You now 4277- The ``NOISO`` and ``NOHDD`` variables are no longer used. You now
4278 control building ``*.iso`` and ``*.hddimg`` image types directly by 4278 control building ``*.iso`` and ``*.hddimg`` image types directly by
4279 using the ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ variable. 4279 using the :term:`IMAGE_FSTYPES` variable.
4280 4280
4281- The ``scripts/contrib/mkefidisk.sh`` has been removed in favor of 4281- The ``scripts/contrib/mkefidisk.sh`` has been removed in favor of
4282 Wic. 4282 Wic.
4283 4283
4284- ``kernel-modules`` has been removed from 4284- ``kernel-modules`` has been removed from
4285 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__ for ``qemumips`` and 4285 :term:`RRECOMMENDS` for ``qemumips`` and
4286 ``qemumips64`` machines. Removal also impacts the ``x86-base.inc`` 4286 ``qemumips64`` machines. Removal also impacts the ``x86-base.inc``
4287 file. 4287 file.
4288 4288
@@ -4302,7 +4302,7 @@ The following miscellaneous changes occurred:
4302 the ``WHITELIST_GPL-3.0`` variable instead. 4302 the ``WHITELIST_GPL-3.0`` variable instead.
4303 4303
4304- ``${ASNEEDED}`` is now included in the 4304- ``${ASNEEDED}`` is now included in the
4305 ```TARGET_LDFLAGS`` <#var-TARGET_LDFLAGS>`__ variable directly. The 4305 :term:`TARGET_LDFLAGS` variable directly. The
4306 remaining definitions from ``meta/conf/distro/include/as-needed.inc`` 4306 remaining definitions from ``meta/conf/distro/include/as-needed.inc``
4307 have been moved to corresponding recipes. 4307 have been moved to corresponding recipes.
4308 4308
@@ -4332,7 +4332,7 @@ The following changes have been made to BitBake:
4332 indentation. If found, BitBake produces a warning. 4332 indentation. If found, BitBake produces a warning.
4333 4333
4334- Bitbake now checks 4334- Bitbake now checks
4335 ```BBFILE_COLLECTIONS`` <#var-BBFILE_COLLECTIONS>`__ for duplicate 4335 :term:`BBFILE_COLLECTIONS` for duplicate
4336 entries and triggers an error if any are found. 4336 entries and triggers an error if any are found.
4337 4337
4338.. _migration-2.7-eclipse-support-dropped: 4338.. _migration-2.7-eclipse-support-dropped:
@@ -4386,7 +4386,7 @@ License Value Corrections
4386------------------------- 4386-------------------------
4387 4387
4388The following corrections have been made to the 4388The following corrections have been made to the
4389```LICENSE`` <#var-LICENSE>`__ values set by recipes: *socat*: Corrected 4389:term:`LICENSE` values set by recipes: *socat*: Corrected
4390``LICENSE`` to be "GPLv2" rather than "GPLv2+". *libgfortran*: Set 4390``LICENSE`` to be "GPLv2" rather than "GPLv2+". *libgfortran*: Set
4391license to "GPL-3.0-with-GCC-exception". *elfutils*: Removed 4391license to "GPL-3.0-with-GCC-exception". *elfutils*: Removed
4392"Elfutils-Exception" and set to "GPLv2" for shared libraries 4392"Elfutils-Exception" and set to "GPLv2" for shared libraries
@@ -4404,11 +4404,11 @@ This section provides information about packaging changes.
4404- Debug split: The default debug split has been changed to create 4404- Debug split: The default debug split has been changed to create
4405 separate source packages (i.e. package_name\ ``-dbg`` and 4405 separate source packages (i.e. package_name\ ``-dbg`` and
4406 package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in 4406 package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in
4407 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ to bring in debug 4407 :term:`IMAGE_FEATURES` to bring in debug
4408 symbols and you still need the sources, you must now also add 4408 symbols and you still need the sources, you must now also add
4409 ``src-pkgs`` to ``IMAGE_FEATURES``. Source packages remain in the 4409 ``src-pkgs`` to ``IMAGE_FEATURES``. Source packages remain in the
4410 target portion of the SDK by default, unless you have set your own 4410 target portion of the SDK by default, unless you have set your own
4411 value for ```SDKIMAGE_FEATURES`` <#var-SDKIMAGE_FEATURES>`__ that 4411 value for :term:`SDKIMAGE_FEATURES` that
4412 does not include ``src-pkgs``. 4412 does not include ``src-pkgs``.
4413 4413
4414- Mount all using ``util-linux``: ``/etc/default/mountall`` has moved 4414- Mount all using ``util-linux``: ``/etc/default/mountall`` has moved
@@ -4417,10 +4417,10 @@ This section provides information about packaging changes.
4417- Splitting binaries using ``util-linux``: ``util-linux`` now splits 4417- Splitting binaries using ``util-linux``: ``util-linux`` now splits
4418 each binary into its own package for fine-grained control. The main 4418 each binary into its own package for fine-grained control. The main
4419 ``util-linux`` package pulls in the individual binary packages using 4419 ``util-linux`` package pulls in the individual binary packages using
4420 the ```RRECOMMENDS`` <#var-RRECOMMENDS>`__ and 4420 the :term:`RRECOMMENDS` and
4421 ```RDEPENDS`` <#var-RDEPENDS>`__ variables. As a result, existing 4421 :term:`RDEPENDS` variables. As a result, existing
4422 images should not see any changes assuming 4422 images should not see any changes assuming
4423 ```NO_RECOMMENDATIONS`` <#var-NO_RECOMMENDATIONS>`__ is not set. 4423 :term:`NO_RECOMMENDATIONS` is not set.
4424 4424
4425- ``netbase/base-files``: ``/etc/hosts`` has moved from ``netbase`` to 4425- ``netbase/base-files``: ``/etc/hosts`` has moved from ``netbase`` to
4426 ``base-files``. 4426 ``base-files``.
@@ -4480,13 +4480,13 @@ The following miscellaneous changes occurred:
4480- ``arm-tunes``: Removed the "-march" option if mcpu is already added. 4480- ``arm-tunes``: Removed the "-march" option if mcpu is already added.
4481 4481
4482- ``update-alternatives``: Convert file renames to 4482- ``update-alternatives``: Convert file renames to
4483 ```PACKAGE_PREPROCESS_FUNCS`` <#var-PACKAGE_PREPROCESS_FUNCS>`__ 4483 :term:`PACKAGE_PREPROCESS_FUNCS`
4484 4484
4485- ``base/pixbufcache``: Obsolete ``sstatecompletions`` code has been 4485- ``base/pixbufcache``: Obsolete ``sstatecompletions`` code has been
4486 removed. 4486 removed.
4487 4487
4488- ```native`` <#ref-classes-native>`__ class: 4488- :ref:`native <ref-classes-native>` class:
4489 ```RDEPENDS`` <#var-RDEPENDS>`__ handling has been enabled. 4489 :term:`RDEPENDS` handling has been enabled.
4490 4490
4491- ``inetutils``: This recipe has rsh disabled. 4491- ``inetutils``: This recipe has rsh disabled.
4492 4492
@@ -4707,7 +4707,7 @@ Sanity Checks
4707 4707
4708The following sanity check changes occurred. 4708The following sanity check changes occurred.
4709 4709
4710- ```SRC_URI`` <#var-SRC_URI>`__ is now checked for usage of two 4710- :term:`SRC_URI` is now checked for usage of two
4711 problematic items: 4711 problematic items:
4712 4712
4713 - "${PN}" prefix/suffix use - Warnings always appear if ${PN} is 4713 - "${PN}" prefix/suffix use - Warnings always appear if ${PN} is
@@ -4722,10 +4722,10 @@ The following sanity check changes occurred.
4722 4722
4723 Either one of these items now trigger a warning by default. If you 4723 Either one of these items now trigger a warning by default. If you
4724 wish to disable this check, remove ``src-uri-bad`` from 4724 wish to disable this check, remove ``src-uri-bad`` from
4725 ```WARN_QA`` <#var-WARN_QA>`__. 4725 :term:`WARN_QA`.
4726 4726
4727- The ``file-rdeps`` runtime dependency check no longer expands 4727- The ``file-rdeps`` runtime dependency check no longer expands
4728 ```RDEPENDS`` <#var-RDEPENDS>`__ recursively as there is no mechanism 4728 :term:`RDEPENDS` recursively as there is no mechanism
4729 to ensure they can be fully computed, and thus races sometimes result 4729 to ensure they can be fully computed, and thus races sometimes result
4730 in errors either showing up or not. Thus, you might now see errors 4730 in errors either showing up or not. Thus, you might now see errors
4731 for missing runtime dependencies that were previously satisfied 4731 for missing runtime dependencies that were previously satisfied
@@ -4736,7 +4736,7 @@ The following sanity check changes occurred.
4736 4736
4737- Setting ``DEPENDS_${PN}`` anywhere (i.e. typically in a recipe) now 4737- Setting ``DEPENDS_${PN}`` anywhere (i.e. typically in a recipe) now
4738 triggers an error. The error is triggered because 4738 triggers an error. The error is triggered because
4739 ```DEPENDS`` <#var-DEPENDS>`__ is not a package-specific variable 4739 :term:`DEPENDS` is not a package-specific variable
4740 unlike RDEPENDS. You should set ``DEPENDS`` instead. 4740 unlike RDEPENDS. You should set ``DEPENDS`` instead.
4741 4741
4742- systemd currently does not work well with the musl C library because 4742- systemd currently does not work well with the musl C library because
@@ -4757,14 +4757,14 @@ The following miscellaneous changes have occurred.
4757 4757
4758- The ``meta/recipes-kernel/linux/linux-dtb.inc`` file has been 4758- The ``meta/recipes-kernel/linux/linux-dtb.inc`` file has been
4759 removed. This file was previously deprecated in favor of setting 4759 removed. This file was previously deprecated in favor of setting
4760 ```KERNEL_DEVICETREE`` <#var-KERNEL_DEVICETREE>`__ in any kernel 4760 :term:`KERNEL_DEVICETREE` in any kernel
4761 recipe and only produced a warning. Remove any ``include`` or 4761 recipe and only produced a warning. Remove any ``include`` or
4762 ``require`` statements pointing to this file. 4762 ``require`` statements pointing to this file.
4763 4763
4764- ```TARGET_CFLAGS`` <#var-TARGET_CFLAGS>`__, 4764- :term:`TARGET_CFLAGS`,
4765 ```TARGET_CPPFLAGS`` <#var-TARGET_CPPFLAGS>`__, 4765 :term:`TARGET_CPPFLAGS`,
4766 ```TARGET_CXXFLAGS`` <#var-TARGET_CXXFLAGS>`__, and 4766 :term:`TARGET_CXXFLAGS`, and
4767 ```TARGET_LDFLAGS`` <#var-TARGET_LDFLAGS>`__ are no longer exported 4767 :term:`TARGET_LDFLAGS` are no longer exported
4768 to the external environment. This change did not require any changes 4768 to the external environment. This change did not require any changes
4769 to core recipes, which is a good indicator that no changes will be 4769 to core recipes, which is a good indicator that no changes will be
4770 required. However, if for some reason the software being built by one 4770 required. However, if for some reason the software being built by one
@@ -4774,14 +4774,14 @@ The following miscellaneous changes have occurred.
4774 exporting is not necessary. 4774 exporting is not necessary.
4775 4775
4776- You must change the host distro identifier used in 4776- You must change the host distro identifier used in
4777 ```NATIVELSBSTRING`` <#var-NATIVELSBSTRING>`__ to use all lowercase 4777 :term:`NATIVELSBSTRING` to use all lowercase
4778 characters even if it does not contain a version number. This change 4778 characters even if it does not contain a version number. This change
4779 is necessary only if you are not using ``uninative`` and 4779 is necessary only if you are not using ``uninative`` and
4780 ```SANITY_TESTED_DISTROS`` <#var-SANITY_TESTED_DISTROS>`__. 4780 :term:`SANITY_TESTED_DISTROS`.
4781 4781
4782- In the ``base-files`` recipe, writing the hostname into 4782- In the ``base-files`` recipe, writing the hostname into
4783 ``/etc/hosts`` and ``/etc/hostname`` is now done within the main 4783 ``/etc/hosts`` and ``/etc/hostname`` is now done within the main
4784 ```do_install`` <#ref-tasks-install>`__ function rather than in the 4784 :ref:`ref-tasks-install` function rather than in the
4785 ``do_install_basefilesissue`` function. The reason for the change is 4785 ``do_install_basefilesissue`` function. The reason for the change is
4786 because ``do_install_basefilesissue`` is more easily overridden 4786 because ``do_install_basefilesissue`` is more easily overridden
4787 without having to duplicate the hostname functionality. If you have 4787 without having to duplicate the hostname functionality. If you have
@@ -4882,7 +4882,7 @@ significant increase in the number of components that will be built just
4882when building a simple image such as core-image-minimal. If you do not 4882when building a simple image such as core-image-minimal. If you do not
4883need runtime tests enabled for core components, then it is recommended 4883need runtime tests enabled for core components, then it is recommended
4884that you remove "ptest" from 4884that you remove "ptest" from
4885```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ to save a significant 4885:term:`DISTRO_FEATURES` to save a significant
4886amount of build time e.g. by adding the following in your configuration: 4886amount of build time e.g. by adding the following in your configuration:
4887DISTRO_FEATURES_remove = "ptest" 4887DISTRO_FEATURES_remove = "ptest"
4888 4888
@@ -4966,7 +4966,7 @@ SRC_URI checksum behaviour
4966-------------------------- 4966--------------------------
4967 4967
4968Previously, recipes by tradition included both SHA256 and MD5 checksums 4968Previously, recipes by tradition included both SHA256 and MD5 checksums
4969for remotely fetched files in ```SRC_URI`` <#var-SRC_URI>`__, even 4969for remotely fetched files in :term:`SRC_URI`, even
4970though only one is actually mandated. However, the MD5 checksum does not 4970though only one is actually mandated. However, the MD5 checksum does not
4971add much given its inherent weakness; thus when a checksum fails only 4971add much given its inherent weakness; thus when a checksum fails only
4972the SHA256 sum will now be printed. The md5sum will still be verified if 4972the SHA256 sum will now be printed. The md5sum will still be verified if
@@ -4984,7 +4984,7 @@ fetches the shrinkwrap file and the dependencies. This removes the
4984slightly awkward ``NPM_LOCKDOWN`` and ``NPM_SHRINKWRAP`` variables which 4984slightly awkward ``NPM_LOCKDOWN`` and ``NPM_SHRINKWRAP`` variables which
4985pointed to local files; the lockdown file is no longer needed at all. 4985pointed to local files; the lockdown file is no longer needed at all.
4986Additionally, the package name in ``npm://`` entries in 4986Additionally, the package name in ``npm://`` entries in
4987```SRC_URI`` <#var-SRC_URI>`__ is now specified using a ``package`` 4987:term:`SRC_URI` is now specified using a ``package``
4988parameter instead of the earlier ``name`` which overlapped with the 4988parameter instead of the earlier ``name`` which overlapped with the
4989generic ``name`` parameter. All recipes using the npm fetcher will need 4989generic ``name`` parameter. All recipes using the npm fetcher will need
4990to be changed as a result. 4990to be changed as a result.
@@ -5019,9 +5019,9 @@ Packaging changes
5019 5019
5020- The ``ldconfig`` binary built as part of glibc has now been moved to 5020- The ``ldconfig`` binary built as part of glibc has now been moved to
5021 its own ``ldconfig`` package (note no ``glibc-`` prefix). This 5021 its own ``ldconfig`` package (note no ``glibc-`` prefix). This
5022 package is in the ```RRECOMMENDS`` <#var-RRECOMMENDS>`__ of the main 5022 package is in the :term:`RRECOMMENDS` of the main
5023 ``glibc`` package if ``ldconfig`` is present in 5023 ``glibc`` package if ``ldconfig`` is present in
5024 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. 5024 :term:`DISTRO_FEATURES`.
5025 5025
5026- ``libevent`` now splits each shared library into its own package (as 5026- ``libevent`` now splits each shared library into its own package (as
5027 Debian does). Since these are shared libraries and will be pulled in 5027 Debian does). Since these are shared libraries and will be pulled in
@@ -5058,7 +5058,7 @@ circumstances:
5058 5058
5059``conf/machine/include/x86-base.inc`` (inherited by most x86 machine 5059``conf/machine/include/x86-base.inc`` (inherited by most x86 machine
5060configurations) now specifies ``wic`` instead of ``live`` by default in 5060configurations) now specifies ``wic`` instead of ``live`` by default in
5061```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__. The ``live`` image type will 5061:term:`IMAGE_FSTYPES`. The ``live`` image type will
5062likely be removed in a future release so it is recommended that you use 5062likely be removed in a future release so it is recommended that you use
5063``wic`` instead. 5063``wic`` instead.
5064 5064
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index fdfd110ae7..1685483363 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -11,14 +11,14 @@ inherits a class it is enough to enable its features. There are cases,
11however, where in the recipe you might need to set variables or override 11however, where in the recipe you might need to set variables or override
12some default behavior. 12some default behavior.
13 13
14Any `Metadata <#metadata>`__ usually found in a recipe can also be 14Any :term:`Metadata` usually found in a recipe can also be
15placed in a class file. Class files are identified by the extension 15placed in a class file. Class files are identified by the extension
16``.bbclass`` and are usually placed in a ``classes/`` directory beneath 16``.bbclass`` and are usually placed in a ``classes/`` directory beneath
17the ``meta*/`` directory found in the `Source 17the ``meta*/`` directory found in the `Source
18Directory <#source-directory>`__. Class files can also be pointed to by 18Directory <#source-directory>`__. Class files can also be pointed to by
19```BUILDDIR`` <#var-BUILDDIR>`__ (e.g. ``build/``) in the same way as 19:term:`BUILDDIR` (e.g. ``build/``) in the same way as
20``.conf`` files in the ``conf`` directory. Class files are searched for 20``.conf`` files in the ``conf`` directory. Class files are searched for
21in ```BBPATH`` <#var-BBPATH>`__ using the same method by which ``.conf`` 21in :term:`BBPATH` using the same method by which ``.conf``
22files are searched. 22files are searched.
23 23
24This chapter discusses only the most useful and important classes. Other 24This chapter discusses only the most useful and important classes. Other
@@ -41,8 +41,8 @@ splitting out of debug symbols during packaging).
41 41
42 Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes that 42 Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes that
43 produce packages that depend on tunings through use of the 43 produce packages that depend on tunings through use of the
44 ```RDEPENDS`` <#var-RDEPENDS>`__ and 44 :term:`RDEPENDS` and
45 ```TUNE_PKGARCH`` <#var-TUNE_PKGARCH>`__ variables, should never be 45 :term:`TUNE_PKGARCH` variables, should never be
46 configured for all architectures using ``allarch``. This is the case 46 configured for all architectures using ``allarch``. This is the case
47 even if the recipes do not produce architecture-specific output. 47 even if the recipes do not produce architecture-specific output.
48 48
@@ -52,8 +52,8 @@ splitting out of debug symbols during packaging).
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 ``MACHINE`` is built even when the recipe never changes.
54 54
55By default, all recipes inherit the ```base`` <#ref-classes-base>`__ and 55By default, all recipes inherit the :ref:`base <ref-classes-base>` and
56```package`` <#ref-classes-package>`__ classes, which enable 56:ref:`package <ref-classes-package>` classes, which enable
57functionality needed for recipes that produce executable output. If your 57functionality needed for recipes that produce executable output. If your
58recipe, for example, only produces packages that contain configuration 58recipe, for example, only produces packages that contain configuration
59files, media files, or scripts (e.g. Python and Perl), then it should 59files, media files, or scripts (e.g. Python and Perl), then it should
@@ -71,7 +71,7 @@ For more details on the source archiver, see the "`Maintaining Open
71Source License Compliance During Your Product's 71Source License Compliance During Your Product's
72Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__" 72Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__"
73section in the Yocto Project Development Tasks Manual. You can also see 73section in the Yocto Project Development Tasks Manual. You can also see
74the ```ARCHIVER_MODE`` <#var-ARCHIVER_MODE>`__ variable for information 74the :term:`ARCHIVER_MODE` variable for information
75about the variable flags (varflags) that help control archive creation. 75about the variable flags (varflags) that help control archive creation.
76 76
77.. _ref-classes-autotools: 77.. _ref-classes-autotools:
@@ -96,8 +96,8 @@ By default, the ``autotools*`` classes use out-of-tree builds (i.e.
96If the software being built by a recipe does not support using 96If the software being built by a recipe does not support using
97out-of-tree builds, you should have the recipe inherit the 97out-of-tree builds, you should have the recipe inherit the
98``autotools-brokensep`` class. The ``autotools-brokensep`` class behaves 98``autotools-brokensep`` class. The ``autotools-brokensep`` class behaves
99the same as the ``autotools`` class but builds with ```B`` <#var-B>`__ 99the same as the ``autotools`` class but builds with :term:`B`
100== ```S`` <#var-S>`__. This method is useful when out-of-tree build 100== :term:`S`. This method is useful when out-of-tree build
101support is either not present or is broken. 101support is either not present or is broken.
102 102
103.. note:: 103.. note::
@@ -108,19 +108,19 @@ support is either not present or is broken.
108It's useful to have some idea of how the tasks defined by the 108It's useful to have some idea of how the tasks defined by the
109``autotools*`` classes work and what they do behind the scenes. 109``autotools*`` classes work and what they do behind the scenes.
110 110
111- ```do_configure`` <#ref-tasks-configure>`__ - Regenerates the 111- :ref:`ref-tasks-configure` - Regenerates the
112 configure script (using ``autoreconf``) and then launches it with a 112 configure script (using ``autoreconf``) and then launches it with a
113 standard set of arguments used during cross-compilation. You can pass 113 standard set of arguments used during cross-compilation. You can pass
114 additional parameters to ``configure`` through the ``EXTRA_OECONF`` 114 additional parameters to ``configure`` through the ``EXTRA_OECONF``
115 or ```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__ 115 or :term:`PACKAGECONFIG_CONFARGS`
116 variables. 116 variables.
117 117
118- ```do_compile`` <#ref-tasks-compile>`__ - Runs ``make`` with 118- :ref:`ref-tasks-compile` - Runs ``make`` with
119 arguments that specify the compiler and linker. You can pass 119 arguments that specify the compiler and linker. You can pass
120 additional arguments through the ``EXTRA_OEMAKE`` variable. 120 additional arguments through the ``EXTRA_OEMAKE`` variable.
121 121
122- ```do_install`` <#ref-tasks-install>`__ - Runs ``make install`` and 122- :ref:`ref-tasks-install` - Runs ``make install`` and
123 passes in ``${``\ ```D`` <#var-D>`__\ ``}`` as ``DESTDIR``. 123 passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``.
124 124
125.. _ref-classes-base: 125.. _ref-classes-base:
126 126
@@ -133,12 +133,12 @@ tasks such as fetching, unpacking, configuring (empty by default),
133compiling (runs any ``Makefile`` present), installing (empty by default) 133compiling (runs any ``Makefile`` present), installing (empty by default)
134and packaging (empty by default). These classes are often overridden or 134and packaging (empty by default). These classes are often overridden or
135extended by other classes such as the 135extended by other classes such as the
136```autotools`` <#ref-classes-autotools>`__ class or the 136:ref:`autotools <ref-classes-autotools>` class or the
137```package`` <#ref-classes-package>`__ class. 137:ref:`package <ref-classes-package>` class.
138 138
139The class also contains some commonly used functions such as 139The class also contains some commonly used functions such as
140``oe_runmake``, which runs ``make`` with the arguments specified in 140``oe_runmake``, which runs ``make`` with the arguments specified in
141```EXTRA_OEMAKE`` <#var-EXTRA_OEMAKE>`__ variable as well as the 141:term:`EXTRA_OEMAKE` variable as well as the
142arguments passed directly to ``oe_runmake``. 142arguments passed directly to ``oe_runmake``.
143 143
144.. _ref-classes-bash-completion: 144.. _ref-classes-bash-completion:
@@ -201,7 +201,7 @@ the ``sysroots/`` directory. Inheriting this class results in all paths
201in these scripts being changed to point into the ``sysroots/`` directory 201in these scripts being changed to point into the ``sysroots/`` directory
202so that all builds that use the script use the correct directories for 202so that all builds that use the script use the correct directories for
203the cross compiling layout. See the 203the cross compiling layout. See the
204```BINCONFIG_GLOB`` <#var-BINCONFIG_GLOB>`__ variable for more 204:term:`BINCONFIG_GLOB` variable for more
205information. 205information.
206 206
207.. _ref-classes-binconfig-disabled: 207.. _ref-classes-binconfig-disabled:
@@ -209,11 +209,11 @@ information.
209``binconfig-disabled.bbclass`` 209``binconfig-disabled.bbclass``
210============================== 210==============================
211 211
212An alternative version of the ```binconfig`` <#ref-classes-binconfig>`__ 212An alternative version of the :ref:`binconfig <ref-classes-binconfig>`
213class, which disables binary configuration scripts by making them return 213class, which disables binary configuration scripts by making them return
214an error in favor of using ``pkg-config`` to query the information. The 214an error in favor of using ``pkg-config`` to query the information. The
215scripts to be disabled should be specified using the 215scripts to be disabled should be specified using the
216```BINCONFIG`` <#var-BINCONFIG>`__ variable within the recipe inheriting 216:term:`BINCONFIG` variable within the recipe inheriting
217the class. 217the class.
218 218
219.. _ref-classes-blacklist: 219.. _ref-classes-blacklist:
@@ -223,8 +223,8 @@ the class.
223 223
224The ``blacklist`` class prevents the OpenEmbedded build system from 224The ``blacklist`` class prevents the OpenEmbedded build system from
225building specific recipes (blacklists them). To use this class, inherit 225building specific recipes (blacklists them). To use this class, inherit
226the class globally and set ```PNBLACKLIST`` <#var-PNBLACKLIST>`__ for 226the class globally and set :term:`PNBLACKLIST` for
227each recipe you wish to blacklist. Specify the ```PN`` <#var-PN>`__ 227each recipe you wish to blacklist. Specify the :term:`PN`
228value as a variable flag (varflag) and provide a reason, which is 228value as a variable flag (varflag) and provide a reason, which is
229reported, if the package is requested to be built as the value. For 229reported, if the package is requested to be built as the value. For
230example, if you want to blacklist a recipe called "exoticware", you add 230example, if you want to blacklist a recipe called "exoticware", you add
@@ -253,14 +253,14 @@ The ``buildstats`` class records performance statistics about each task
253executed during the build (e.g. elapsed time, CPU usage, and I/O usage). 253executed during the build (e.g. elapsed time, CPU usage, and I/O usage).
254 254
255When you use this class, the output goes into the 255When you use this class, the output goes into the
256```BUILDSTATS_BASE`` <#var-BUILDSTATS_BASE>`__ directory, which defaults 256:term:`BUILDSTATS_BASE` directory, which defaults
257to ``${TMPDIR}/buildstats/``. You can analyze the elapsed time using 257to ``${TMPDIR}/buildstats/``. You can analyze the elapsed time using
258``scripts/pybootchartgui/pybootchartgui.py``, which produces a cascading 258``scripts/pybootchartgui/pybootchartgui.py``, which produces a cascading
259chart of the entire build process and can be useful for highlighting 259chart of the entire build process and can be useful for highlighting
260bottlenecks. 260bottlenecks.
261 261
262Collecting build statistics is enabled by default through the 262Collecting build statistics is enabled by default through the
263```USER_CLASSES`` <#var-USER_CLASSES>`__ variable from your 263:term:`USER_CLASSES` variable from your
264``local.conf`` file. Consequently, you do not have to do anything to 264``local.conf`` file. Consequently, you do not have to do anything to
265enable the class. However, if you want to disable the class, simply 265enable the class. However, if you want to disable the class, simply
266remove "buildstats" from the ``USER_CLASSES`` list. 266remove "buildstats" from the ``USER_CLASSES`` list.
@@ -272,7 +272,7 @@ remove "buildstats" from the ``USER_CLASSES`` list.
272 272
273When inherited globally, prints statistics at the end of the build on 273When inherited globally, prints statistics at the end of the build on
274sstate re-use. In order to function, this class requires the 274sstate re-use. In order to function, this class requires the
275```buildstats`` <#ref-classes-buildstats>`__ class be enabled. 275:ref:`buildstats <ref-classes-buildstats>` class be enabled.
276 276
277.. _ref-classes-ccache: 277.. _ref-classes-ccache:
278 278
@@ -318,7 +318,7 @@ and other common items used by Clutter and related recipes.
318 318
319The ``cmake`` class allows for recipes that need to build software using 319The ``cmake`` class allows for recipes that need to build software using
320the `CMake <https://cmake.org/overview/>`__ build system. You can use 320the `CMake <https://cmake.org/overview/>`__ build system. You can use
321the ```EXTRA_OECMAKE`` <#var-EXTRA_OECMAKE>`__ variable to specify 321the :term:`EXTRA_OECMAKE` variable to specify
322additional configuration options to be passed using the ``cmake`` 322additional configuration options to be passed using the ``cmake``
323command line. 323command line.
324 324
@@ -326,7 +326,7 @@ On the occasion that you would be installing custom CMake toolchain
326files supplied by the application being built, you should install them 326files supplied by the application being built, you should install them
327to the preferred CMake Module directory: ``${D}${datadir}/cmake/`` 327to the preferred CMake Module directory: ``${D}${datadir}/cmake/``
328Modules during 328Modules during
329```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__. 329:ref:`ref-tasks-install`.
330 330
331.. _ref-classes-cml1: 331.. _ref-classes-cml1:
332 332
@@ -344,7 +344,7 @@ build configuration system.
344Enables compression for man pages and info pages. This class is intended 344Enables compression for man pages and info pages. This class is intended
345to be inherited globally. The default compression mechanism is gz (gzip) 345to be inherited globally. The default compression mechanism is gz (gzip)
346but you can select an alternative mechanism by setting the 346but you can select an alternative mechanism by setting the
347```DOC_COMPRESS`` <#var-DOC_COMPRESS>`__ variable. 347:term:`DOC_COMPRESS` variable.
348 348
349.. _ref-classes-copyleft_compliance: 349.. _ref-classes-copyleft_compliance:
350 350
@@ -354,15 +354,15 @@ but you can select an alternative mechanism by setting the
354The ``copyleft_compliance`` class preserves source code for the purposes 354The ``copyleft_compliance`` class preserves source code for the purposes
355of license compliance. This class is an alternative to the ``archiver`` 355of license compliance. This class is an alternative to the ``archiver``
356class and is still used by some users even though it has been deprecated 356class and is still used by some users even though it has been deprecated
357in favor of the ```archiver`` <#ref-classes-archiver>`__ class. 357in favor of the :ref:`archiver <ref-classes-archiver>` class.
358 358
359.. _ref-classes-copyleft_filter: 359.. _ref-classes-copyleft_filter:
360 360
361``copyleft_filter.bbclass`` 361``copyleft_filter.bbclass``
362=========================== 362===========================
363 363
364A class used by the ```archiver`` <#ref-classes-archiver>`__ and 364A class used by the :ref:`archiver <ref-classes-archiver>` and
365```copyleft_compliance`` <#ref-classes-copyleft_compliance>`__ classes 365:ref:`copyleft_compliance <ref-classes-copyleft_compliance>` classes
366for filtering licenses. The ``copyleft_filter`` class is an internal 366for filtering licenses. The ``copyleft_filter`` class is an internal
367class and is not intended to be used directly. 367class and is not intended to be used directly.
368 368
@@ -373,7 +373,7 @@ class and is not intended to be used directly.
373 373
374The ``core-image`` class provides common definitions for the 374The ``core-image`` class provides common definitions for the
375``core-image-*`` image recipes, such as support for additional 375``core-image-*`` image recipes, such as support for additional
376```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__. 376:term:`IMAGE_FEATURES`.
377 377
378.. _ref-classes-cpan: 378.. _ref-classes-cpan:
379 379
@@ -439,7 +439,7 @@ Debian naming policy (i.e. ``glibc`` becomes ``libc6`` and
439name and version as part of the package name. 439name and version as part of the package name.
440 440
441If a recipe creates packages for multiple libraries (shared object files 441If a recipe creates packages for multiple libraries (shared object files
442of ``.so`` type), use the ```LEAD_SONAME`` <#var-LEAD_SONAME>`__ 442of ``.so`` type), use the :term:`LEAD_SONAME`
443variable in the recipe to specify the library on which to apply the 443variable in the recipe to specify the library on which to apply the
444naming scheme. 444naming scheme.
445 445
@@ -449,14 +449,14 @@ naming scheme.
449================== 449==================
450 450
451The ``deploy`` class handles deploying files to the 451The ``deploy`` class handles deploying files to the
452```DEPLOY_DIR_IMAGE`` <#var-DEPLOY_DIR_IMAGE>`__ directory. The main 452:term:`DEPLOY_DIR_IMAGE` directory. The main
453function of this class is to allow the deploy step to be accelerated by 453function of this class is to allow the deploy step to be accelerated by
454shared state. Recipes that inherit this class should define their own 454shared state. Recipes that inherit this class should define their own
455```do_deploy`` <#ref-tasks-deploy>`__ function to copy the files to be 455:ref:`ref-tasks-deploy` function to copy the files to be
456deployed to ```DEPLOYDIR`` <#var-DEPLOYDIR>`__, and use ``addtask`` to 456deployed to :term:`DEPLOYDIR`, and use ``addtask`` to
457add the task at the appropriate place, which is usually after 457add the task at the appropriate place, which is usually after
458```do_compile`` <#ref-tasks-compile>`__ or 458:ref:`ref-tasks-compile` or
459```do_install`` <#ref-tasks-install>`__. The class then takes care of 459:ref:`ref-tasks-install`. The class then takes care of
460staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``. 460staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``.
461 461
462.. _ref-classes-devshell: 462.. _ref-classes-devshell:
@@ -476,13 +476,13 @@ information about using ``devshell``.
476======================= 476=======================
477 477
478The ``devupstream`` class uses 478The ``devupstream`` class uses
479```BBCLASSEXTEND`` <#var-BBCLASSEXTEND>`__ to add a variant of the 479:term:`BBCLASSEXTEND` to add a variant of the
480recipe that fetches from an alternative URI (e.g. Git) instead of a 480recipe that fetches from an alternative URI (e.g. Git) instead of a
481tarball. Following is an example: BBCLASSEXTEND = "devupstream:target" 481tarball. Following is an example: BBCLASSEXTEND = "devupstream:target"
482SRC_URI_class-devupstream = "git://git.example.com/example" 482SRC_URI_class-devupstream = "git://git.example.com/example"
483SRCREV_class-devupstream = "abcd1234" Adding the above statements to 483SRCREV_class-devupstream = "abcd1234" Adding the above statements to
484your recipe creates a variant that has 484your recipe creates a variant that has
485```DEFAULT_PREFERENCE`` <#var-DEFAULT_PREFERENCE>`__ set to "-1". 485:term:`DEFAULT_PREFERENCE` set to "-1".
486Consequently, you need to select the variant of the recipe to use it. 486Consequently, you need to select the variant of the recipe to use it.
487Any development-specific adjustments can be done by using the 487Any development-specific adjustments can be done by using the
488``class-devupstream`` override. Here is an example: 488``class-devupstream`` override. Here is an example:
@@ -506,11 +506,11 @@ due to BitBake's automatic fetch dependencies (e.g.
506 506
507The ``distro_features_check`` class allows individual recipes to check 507The ``distro_features_check`` class allows individual recipes to check
508for required and conflicting 508for required and conflicting
509```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. 509:term:`DISTRO_FEATURES`.
510 510
511This class provides support for the 511This class provides support for the
512```REQUIRED_DISTRO_FEATURES`` <#var-REQUIRED_DISTRO_FEATURES>`__ and 512:term:`REQUIRED_DISTRO_FEATURES` and
513```CONFLICT_DISTRO_FEATURES`` <#var-CONFLICT_DISTRO_FEATURES>`__ 513:term:`CONFLICT_DISTRO_FEATURES`
514variables. If any conditions specified in the recipe using the above 514variables. If any conditions specified in the recipe using the above
515variables are not met, the recipe will be skipped. 515variables are not met, the recipe will be skipped.
516 516
@@ -532,7 +532,7 @@ used.
532 ``distutils`` class in their recipes. 532 ``distutils`` class in their recipes.
533 533
534- Extensions that use build systems based on ``setuptools`` require the 534- Extensions that use build systems based on ``setuptools`` require the
535 ```setuptools`` <#ref-classes-setuptools>`__ class in their recipes. 535 :ref:`setuptools <ref-classes-setuptools>` class in their recipes.
536 536
537The ``distutils-common-base`` class is required by some of the 537The ``distutils-common-base`` class is required by some of the
538``distutils*`` classes to provide common Python2 support. 538``distutils*`` classes to provide common Python2 support.
@@ -574,22 +574,22 @@ that is external to the OpenEmbedded build system. Building software
574from an external source tree means that the build system's normal fetch, 574from an external source tree means that the build system's normal fetch,
575unpack, and patch process is not used. 575unpack, and patch process is not used.
576 576
577By default, the OpenEmbedded build system uses the ```S`` <#var-S>`__ 577By default, the OpenEmbedded build system uses the :term:`S`
578and ```B`` <#var-B>`__ variables to locate unpacked recipe source code 578and :term:`B` variables to locate unpacked recipe source code
579and to build it, respectively. When your recipe inherits the 579and to build it, respectively. When your recipe inherits the
580``externalsrc`` class, you use the 580``externalsrc`` class, you use the
581```EXTERNALSRC`` <#var-EXTERNALSRC>`__ and 581:term:`EXTERNALSRC` and
582```EXTERNALSRC_BUILD`` <#var-EXTERNALSRC_BUILD>`__ variables to 582:term:`EXTERNALSRC_BUILD` variables to
583ultimately define ``S`` and ``B``. 583ultimately define ``S`` and ``B``.
584 584
585By default, this class expects the source code to support recipe builds 585By default, this class expects the source code to support recipe builds
586that use the ```B`` <#var-B>`__ variable to point to the directory in 586that use the :term:`B` variable to point to the directory in
587which the OpenEmbedded build system places the generated objects built 587which the OpenEmbedded build system places the generated objects built
588from the recipes. By default, the ``B`` directory is set to the 588from the recipes. By default, the ``B`` directory is set to the
589following, which is separate from the source directory (``S``): 589following, which is separate from the source directory (``S``):
590${WORKDIR}/${BPN}/{PV}/ See these variables for more information: 590${WORKDIR}/${BPN}/{PV}/ See these variables for more information:
591```WORKDIR`` <#var-WORKDIR>`__, ```BPN`` <#var-BPN>`__, and 591:term:`WORKDIR`, :term:`BPN`, and
592```PV`` <#var-PV>`__, 592:term:`PV`,
593 593
594For more information on the ``externalsrc`` class, see the comments in 594For more information on the ``externalsrc`` class, see the comments in
595``meta/classes/externalsrc.bbclass`` in the `Source 595``meta/classes/externalsrc.bbclass`` in the `Source
@@ -607,7 +607,7 @@ The ``extrausers`` class allows additional user and group configuration
607to be applied at the image level. Inheriting this class either globally 607to be applied at the image level. Inheriting this class either globally
608or from an image recipe allows additional user and group operations to 608or from an image recipe allows additional user and group operations to
609be performed using the 609be performed using the
610```EXTRA_USERS_PARAMS`` <#var-EXTRA_USERS_PARAMS>`__ variable. 610:term:`EXTRA_USERS_PARAMS` variable.
611 611
612.. note:: 612.. note::
613 613
@@ -642,7 +642,7 @@ architecture-specific, ``fc-cache`` runs using QEMU if the postinst
642scriptlets need to be run on the build host during image creation. 642scriptlets need to be run on the build host during image creation.
643 643
644If the fonts being installed are in packages other than the main 644If the fonts being installed are in packages other than the main
645package, set ```FONT_PACKAGES`` <#var-FONT_PACKAGES>`__ to specify the 645package, set :term:`FONT_PACKAGES` to specify the
646packages containing the fonts. 646packages containing the fonts.
647 647
648.. _ref-classes-fs-uuid: 648.. _ref-classes-fs-uuid:
@@ -651,7 +651,7 @@ packages containing the fonts.
651=================== 651===================
652 652
653The ``fs-uuid`` class extracts UUID from 653The ``fs-uuid`` class extracts UUID from
654``${``\ ```ROOTFS`` <#var-ROOTFS>`__\ ``}``, which must have been built 654``${``\ :term:`ROOTFS`\ ``}``, which must have been built
655by the time that this function gets called. The ``fs-uuid`` class only 655by the time that this function gets called. The ``fs-uuid`` class only
656works on ``ext`` file systems and depends on ``tune2fs``. 656works on ``ext`` file systems and depends on ``tune2fs``.
657 657
@@ -662,7 +662,7 @@ works on ``ext`` file systems and depends on ``tune2fs``.
662 662
663The ``gconf`` class provides common functionality for recipes that need 663The ``gconf`` class provides common functionality for recipes that need
664to install GConf schemas. The schemas will be put into a separate 664to install GConf schemas. The schemas will be put into a separate
665package (``${``\ ```PN`` <#var-PN>`__\ ``}-gconf``) that is created 665package (``${``\ :term:`PN`\ ``}-gconf``) that is created
666automatically when this class is inherited. This package uses the 666automatically when this class is inherited. This package uses the
667appropriate post-install and post-remove (postinst/postrm) scriptlets to 667appropriate post-install and post-remove (postinst/postrm) scriptlets to
668register and unregister the schemas in the target image. 668register and unregister the schemas in the target image.
@@ -684,8 +684,8 @@ class.
684 684
685The ``gnomebase`` class is the base class for recipes that build 685The ``gnomebase`` class is the base class for recipes that build
686software from the GNOME stack. This class sets 686software from the GNOME stack. This class sets
687```SRC_URI`` <#var-SRC_URI>`__ to download the source from the GNOME 687:term:`SRC_URI` to download the source from the GNOME
688mirrors as well as extending ```FILES`` <#var-FILES>`__ with the typical 688mirrors as well as extending :term:`FILES` with the typical
689GNOME installation paths. 689GNOME installation paths.
690 690
691.. _ref-classes-gobject-introspection: 691.. _ref-classes-gobject-introspection:
@@ -696,9 +696,9 @@ GNOME installation paths.
696Provides support for recipes building software that supports GObject 696Provides support for recipes building software that supports GObject
697introspection. This functionality is only enabled if the 697introspection. This functionality is only enabled if the
698"gobject-introspection-data" feature is in 698"gobject-introspection-data" feature is in
699```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ as well as 699:term:`DISTRO_FEATURES` as well as
700"qemu-usermode" being in 700"qemu-usermode" being in
701```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__. 701:term:`MACHINE_FEATURES`.
702 702
703.. note:: 703.. note::
704 704
@@ -719,26 +719,26 @@ building bootable images.
719 719
720This class supports several variables: 720This class supports several variables:
721 721
722- ```INITRD`` <#var-INITRD>`__: Indicates list of filesystem images to 722- :term:`INITRD`: Indicates list of filesystem images to
723 concatenate and use as an initial RAM disk (initrd) (optional). 723 concatenate and use as an initial RAM disk (initrd) (optional).
724 724
725- ```ROOTFS`` <#var-ROOTFS>`__: Indicates a filesystem image to include 725- :term:`ROOTFS`: Indicates a filesystem image to include
726 as the root filesystem (optional). 726 as the root filesystem (optional).
727 727
728- ```GRUB_GFXSERIAL`` <#var-GRUB_GFXSERIAL>`__: Set this to "1" to have 728- :term:`GRUB_GFXSERIAL`: Set this to "1" to have
729 graphics and serial in the boot menu. 729 graphics and serial in the boot menu.
730 730
731- ```LABELS`` <#var-LABELS>`__: A list of targets for the automatic 731- :term:`LABELS`: A list of targets for the automatic
732 configuration. 732 configuration.
733 733
734- ```APPEND`` <#var-APPEND>`__: An override list of append strings for 734- :term:`APPEND`: An override list of append strings for
735 each ``LABEL``. 735 each ``LABEL``.
736 736
737- ```GRUB_OPTS`` <#var-GRUB_OPTS>`__: Additional options to add to the 737- :term:`GRUB_OPTS`: Additional options to add to the
738 configuration (optional). Options are delimited using semi-colon 738 configuration (optional). Options are delimited using semi-colon
739 characters (``;``). 739 characters (``;``).
740 740
741- ```GRUB_TIMEOUT`` <#var-GRUB_TIMEOUT>`__: Timeout before executing 741- :term:`GRUB_TIMEOUT`: Timeout before executing
742 the default ``LABEL`` (optional). 742 the default ``LABEL`` (optional).
743 743
744.. _ref-classes-gsettings: 744.. _ref-classes-gsettings:
@@ -788,7 +788,7 @@ need to be run on the build host during image creation.
788 788
789If the input method modules being installed are in packages other than 789If the input method modules being installed are in packages other than
790the main package, set 790the main package, set
791```GTKIMMODULES_PACKAGES`` <#var-GTKIMMODULES_PACKAGES>`__ to specify 791:term:`GTKIMMODULES_PACKAGES` to specify
792the packages containing the modules. 792the packages containing the modules.
793 793
794.. _ref-classes-gzipnative: 794.. _ref-classes-gzipnative:
@@ -826,9 +826,9 @@ The class handles all three different compile stages (i.e native
826``tar.gz`` file to be used by the remote machines. The class also 826``tar.gz`` file to be used by the remote machines. The class also
827supports SDK generation. 827supports SDK generation.
828 828
829If ```ICECC_PATH`` <#var-ICECC_PATH>`__ is not set in your 829If :term:`ICECC_PATH` is not set in your
830``local.conf`` file, then the class tries to locate the ``icecc`` binary 830``local.conf`` file, then the class tries to locate the ``icecc`` binary
831using ``which``. If ```ICECC_ENV_EXEC`` <#var-ICECC_ENV_EXEC>`__ is set 831using ``which``. If :term:`ICECC_ENV_EXEC` is set
832in your ``local.conf`` file, the variable should point to the 832in your ``local.conf`` file, the variable should point to the
833``icecc-create-env`` script provided by the user. If you do not point to 833``icecc-create-env`` script provided by the user. If you do not point to
834a user-provided script, the build system uses the default script 834a user-provided script, the build system uses the default script
@@ -843,15 +843,15 @@ provided by the recipe ``icecc-create-env-native.bb``.
843If you do not want the Icecream distributed compile support to apply to 843If you do not want the Icecream distributed compile support to apply to
844specific recipes or classes, you can effectively "blacklist" them by 844specific recipes or classes, you can effectively "blacklist" them by
845listing the recipes and classes using the 845listing the recipes and classes using the
846```ICECC_USER_PACKAGE_BL`` <#var-ICECC_USER_PACKAGE_BL>`__ and 846:term:`ICECC_USER_PACKAGE_BL` and
847```ICECC_USER_CLASS_BL`` <#var-ICECC_USER_CLASS_BL>`__, variables, 847:term:`ICECC_USER_CLASS_BL`, variables,
848respectively, in your ``local.conf`` file. Doing so causes the 848respectively, in your ``local.conf`` file. Doing so causes the
849OpenEmbedded build system to handle these compilations locally. 849OpenEmbedded build system to handle these compilations locally.
850 850
851Additionally, you can list recipes using the 851Additionally, you can list recipes using the
852```ICECC_USER_PACKAGE_WL`` <#var-ICECC_USER_PACKAGE_WL>`__ variable in 852:term:`ICECC_USER_PACKAGE_WL` variable in
853your ``local.conf`` file to force ``icecc`` to be enabled for recipes 853your ``local.conf`` file to force ``icecc`` to be enabled for recipes
854using an empty ```PARALLEL_MAKE`` <#var-PARALLEL_MAKE>`__ variable. 854using an empty :term:`PARALLEL_MAKE` variable.
855 855
856Inheriting the ``icecc`` class changes all sstate signatures. 856Inheriting the ``icecc`` class changes all sstate signatures.
857Consequently, if a development team has a dedicated build system that 857Consequently, if a development team has a dedicated build system that
@@ -862,7 +862,7 @@ system need to either inherit the ``icecc`` class or nobody should.
862At the distribution level, you can inherit the ``icecc`` class to be 862At the distribution level, you can inherit the ``icecc`` class to be
863sure that all builders start with the same sstate signatures. After 863sure that all builders start with the same sstate signatures. After
864inheriting the class, you can then disable the feature by setting the 864inheriting the class, you can then disable the feature by setting the
865```ICECC_DISABLED`` <#var-ICECC_DISABLED>`__ variable to "1" as follows: 865:term:`ICECC_DISABLED` variable to "1" as follows:
866INHERIT_DISTRO_append = " icecc" ICECC_DISABLED ??= "1" This practice 866INHERIT_DISTRO_append = " icecc" ICECC_DISABLED ??= "1" This practice
867makes sure everyone is using the same signatures but also requires 867makes sure everyone is using the same signatures but also requires
868individuals that do want to use Icecream to enable the feature 868individuals that do want to use Icecream to enable the feature
@@ -906,11 +906,11 @@ filesystem on ``/etc/build``.
906 906
907The ``image_types`` class defines all of the standard image output types 907The ``image_types`` class defines all of the standard image output types
908that you can enable through the 908that you can enable through the
909```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ variable. You can use this 909:term:`IMAGE_FSTYPES` variable. You can use this
910class as a reference on how to add support for custom image output 910class as a reference on how to add support for custom image output
911types. 911types.
912 912
913By default, the ```image`` <#ref-classes-image>`__ class automatically 913By default, the :ref:`image <ref-classes-image>` class automatically
914enables the ``image_types`` class. The ``image`` class uses the 914enables the ``image_types`` class. The ``image`` class uses the
915``IMGCLASSES`` variable as follows: IMGCLASSES = 915``IMGCLASSES`` variable as follows: IMGCLASSES =
916"rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" IMGCLASSES += 916"rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" IMGCLASSES +=
@@ -940,11 +940,11 @@ images.
940 940
941This class controls building "live" (i.e. HDDIMG and ISO) images. Live 941This class controls building "live" (i.e. HDDIMG and ISO) images. Live
942images contain syslinux for legacy booting, as well as the bootloader 942images contain syslinux for legacy booting, as well as the bootloader
943specified by ```EFI_PROVIDER`` <#var-EFI_PROVIDER>`__ if 943specified by :term:`EFI_PROVIDER` if
944```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__ contains "efi". 944:term:`MACHINE_FEATURES` contains "efi".
945 945
946Normally, you do not use this class directly. Instead, you add "live" to 946Normally, you do not use this class directly. Instead, you add "live" to
947```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__. 947:term:`IMAGE_FSTYPES`.
948 948
949.. _ref-classes-image-mklibs: 949.. _ref-classes-image-mklibs:
950 950
@@ -952,11 +952,11 @@ Normally, you do not use this class directly. Instead, you add "live" to
952======================== 952========================
953 953
954The ``image-mklibs`` class enables the use of the ``mklibs`` utility 954The ``image-mklibs`` class enables the use of the ``mklibs`` utility
955during the ```do_rootfs`` <#ref-tasks-rootfs>`__ task, which optimizes 955during the :ref:`ref-tasks-rootfs` task, which optimizes
956the size of libraries contained in the image. 956the size of libraries contained in the image.
957 957
958By default, the class is enabled in the ``local.conf.template`` using 958By default, the class is enabled in the ``local.conf.template`` using
959the ```USER_CLASSES`` <#var-USER_CLASSES>`__ variable as follows: 959the :term:`USER_CLASSES` variable as follows:
960USER_CLASSES ?= "buildstats image-mklibs image-prelink" 960USER_CLASSES ?= "buildstats image-mklibs image-prelink"
961 961
962.. _ref-classes-image-prelink: 962.. _ref-classes-image-prelink:
@@ -965,12 +965,12 @@ USER_CLASSES ?= "buildstats image-mklibs image-prelink"
965========================= 965=========================
966 966
967The ``image-prelink`` class enables the use of the ``prelink`` utility 967The ``image-prelink`` class enables the use of the ``prelink`` utility
968during the ```do_rootfs`` <#ref-tasks-rootfs>`__ task, which optimizes 968during the :ref:`ref-tasks-rootfs` task, which optimizes
969the dynamic linking of shared libraries to reduce executable startup 969the dynamic linking of shared libraries to reduce executable startup
970time. 970time.
971 971
972By default, the class is enabled in the ``local.conf.template`` using 972By default, the class is enabled in the ``local.conf.template`` using
973the ```USER_CLASSES`` <#var-USER_CLASSES>`__ variable as follows: 973the :term:`USER_CLASSES` variable as follows:
974USER_CLASSES ?= "buildstats image-mklibs image-prelink" 974USER_CLASSES ?= "buildstats image-mklibs image-prelink"
975 975
976.. _ref-classes-insane: 976.. _ref-classes-insane:
@@ -992,11 +992,11 @@ condition. See the "`QA Error and Warning Messages <#ref-qa-checks>`__"
992Chapter for a list of all the warning and error messages you might 992Chapter for a list of all the warning and error messages you might
993encounter using a default configuration. 993encounter using a default configuration.
994 994
995Use the ```WARN_QA`` <#var-WARN_QA>`__ and 995Use the :term:`WARN_QA` and
996```ERROR_QA`` <#var-ERROR_QA>`__ variables to control the behavior of 996:term:`ERROR_QA` variables to control the behavior of
997these checks at the global level (i.e. in your custom distro 997these checks at the global level (i.e. in your custom distro
998configuration). However, to skip one or more checks in recipes, you 998configuration). However, to skip one or more checks in recipes, you
999should use ```INSANE_SKIP`` <#var-INSANE_SKIP>`__. For example, to skip 999should use :term:`INSANE_SKIP`. For example, to skip
1000the check for symbolic link ``.so`` files in the main package of a 1000the check for symbolic link ``.so`` files in the main package of a
1001recipe, add the following to the recipe. You need to realize that the 1001recipe, add the following to the recipe. You need to realize that the
1002package name override, in this example ``${PN}``, must be used: 1002package name override, in this example ``${PN}``, must be used:
@@ -1026,17 +1026,17 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1026 positives and thus is not normally enabled. 1026 positives and thus is not normally enabled.
1027 1027
1028- *``build-deps:``* Determines if a build-time dependency that is 1028- *``build-deps:``* Determines if a build-time dependency that is
1029 specified through ```DEPENDS`` <#var-DEPENDS>`__, explicit 1029 specified through :term:`DEPENDS`, explicit
1030 ```RDEPENDS`` <#var-RDEPENDS>`__, or task-level dependencies exists 1030 :term:`RDEPENDS`, or task-level dependencies exists
1031 to match any runtime dependency. This determination is particularly 1031 to match any runtime dependency. This determination is particularly
1032 useful to discover where runtime dependencies are detected and added 1032 useful to discover where runtime dependencies are detected and added
1033 during packaging. If no explicit dependency has been specified within 1033 during packaging. If no explicit dependency has been specified within
1034 the metadata, at the packaging stage it is too late to ensure that 1034 the metadata, at the packaging stage it is too late to ensure that
1035 the dependency is built, and thus you can end up with an error when 1035 the dependency is built, and thus you can end up with an error when
1036 the package is installed into the image during the 1036 the package is installed into the image during the
1037 ```do_rootfs`` <#ref-tasks-rootfs>`__ task because the auto-detected 1037 :ref:`ref-tasks-rootfs` task because the auto-detected
1038 dependency was not satisfied. An example of this would be where the 1038 dependency was not satisfied. An example of this would be where the
1039 ```update-rc.d`` <#ref-classes-update-rc.d>`__ class automatically 1039 :ref:`update-rc.d <ref-classes-update-rc.d>` class automatically
1040 adds a dependency on the ``initscripts-functions`` package to 1040 adds a dependency on the ``initscripts-functions`` package to
1041 packages that install an initscript that refers to 1041 packages that install an initscript that refers to
1042 ``/etc/init.d/functions``. The recipe should really have an explicit 1042 ``/etc/init.d/functions``. The recipe should really have an explicit
@@ -1046,7 +1046,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1046 ``initscripts-functions`` package is made available. 1046 ``initscripts-functions`` package is made available.
1047 1047
1048- *``compile-host-path:``* Checks the 1048- *``compile-host-path:``* Checks the
1049 ```do_compile`` <#ref-tasks-compile>`__ log for indications that 1049 :ref:`ref-tasks-compile` log for indications that
1050 paths to locations on the build host were used. Using such paths 1050 paths to locations on the build host were used. Using such paths
1051 might result in host contamination of the build output. 1051 might result in host contamination of the build output.
1052 1052
@@ -1060,12 +1060,12 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1060 1060
1061- *``dep-cmp:``* Checks for invalid version comparison statements in 1061- *``dep-cmp:``* Checks for invalid version comparison statements in
1062 runtime dependency relationships between packages (i.e. in 1062 runtime dependency relationships between packages (i.e. in
1063 ```RDEPENDS`` <#var-RDEPENDS>`__, 1063 :term:`RDEPENDS`,
1064 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, 1064 :term:`RRECOMMENDS`,
1065 ```RSUGGESTS`` <#var-RSUGGESTS>`__, 1065 :term:`RSUGGESTS`,
1066 ```RPROVIDES`` <#var-RPROVIDES>`__, 1066 :term:`RPROVIDES`,
1067 ```RREPLACES`` <#var-RREPLACES>`__, and 1067 :term:`RREPLACES`, and
1068 ```RCONFLICTS`` <#var-RCONFLICTS>`__ variable values). Any invalid 1068 :term:`RCONFLICTS` variable values). Any invalid
1069 comparisons might trigger failures or undesirable behavior when 1069 comparisons might trigger failures or undesirable behavior when
1070 passed to the package manager. 1070 passed to the package manager.
1071 1071
@@ -1094,10 +1094,10 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1094 However, the lack of that functionality in the other two package 1094 However, the lack of that functionality in the other two package
1095 managers does not mean the dependencies do not still need resolving. 1095 managers does not mean the dependencies do not still need resolving.
1096 This QA check attempts to ensure that explicitly declared 1096 This QA check attempts to ensure that explicitly declared
1097 ```RDEPENDS`` <#var-RDEPENDS>`__ exist to handle any file-level 1097 :term:`RDEPENDS` exist to handle any file-level
1098 dependency detected in packaged files. 1098 dependency detected in packaged files.
1099 1099
1100- *``files-invalid:``* Checks for ```FILES`` <#var-FILES>`__ variable 1100- *``files-invalid:``* Checks for :term:`FILES` variable
1101 values that contain "//", which is invalid. 1101 values that contain "//", which is invalid.
1102 1102
1103- *``host-user-contaminated:``* Checks that no package produced by the 1103- *``host-user-contaminated:``* Checks that no package produced by the
@@ -1106,33 +1106,33 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1106 that the files are being installed with an incorrect UID/GID, since 1106 that the files are being installed with an incorrect UID/GID, since
1107 target IDs are independent from host IDs. For additional information, 1107 target IDs are independent from host IDs. For additional information,
1108 see the section describing the 1108 see the section describing the
1109 ```do_install`` <#ref-tasks-install>`__ task. 1109 :ref:`ref-tasks-install` task.
1110 1110
1111- *``incompatible-license:``* Report when packages are excluded from 1111- *``incompatible-license:``* Report when packages are excluded from
1112 being created due to being marked with a license that is in 1112 being created due to being marked with a license that is in
1113 ```INCOMPATIBLE_LICENSE`` <#var-INCOMPATIBLE_LICENSE>`__. 1113 :term:`INCOMPATIBLE_LICENSE`.
1114 1114
1115- *``install-host-path:``* Checks the 1115- *``install-host-path:``* Checks the
1116 ```do_install`` <#ref-tasks-install>`__ log for indications that 1116 :ref:`ref-tasks-install` log for indications that
1117 paths to locations on the build host were used. Using such paths 1117 paths to locations on the build host were used. Using such paths
1118 might result in host contamination of the build output. 1118 might result in host contamination of the build output.
1119 1119
1120- *``installed-vs-shipped:``* Reports when files have been installed 1120- *``installed-vs-shipped:``* Reports when files have been installed
1121 within ``do_install`` but have not been included in any package by 1121 within ``do_install`` but have not been included in any package by
1122 way of the ```FILES`` <#var-FILES>`__ variable. Files that do not 1122 way of the :term:`FILES` variable. Files that do not
1123 appear in any package cannot be present in an image later on in the 1123 appear in any package cannot be present in an image later on in the
1124 build process. Ideally, all installed files should be packaged or not 1124 build process. Ideally, all installed files should be packaged or not
1125 installed at all. These files can be deleted at the end of 1125 installed at all. These files can be deleted at the end of
1126 ``do_install`` if the files are not needed in any package. 1126 ``do_install`` if the files are not needed in any package.
1127 1127
1128- *``invalid-chars:``* Checks that the recipe metadata variables 1128- *``invalid-chars:``* Checks that the recipe metadata variables
1129 ```DESCRIPTION`` <#var-DESCRIPTION>`__, 1129 :term:`DESCRIPTION`,
1130 ```SUMMARY`` <#var-SUMMARY>`__, ```LICENSE`` <#var-LICENSE>`__, and 1130 :term:`SUMMARY`, :term:`LICENSE`, and
1131 ```SECTION`` <#var-SECTION>`__ do not contain non-UTF-8 characters. 1131 :term:`SECTION` do not contain non-UTF-8 characters.
1132 Some package managers do not support such characters. 1132 Some package managers do not support such characters.
1133 1133
1134- *``invalid-packageconfig:``* Checks that no undefined features are 1134- *``invalid-packageconfig:``* Checks that no undefined features are
1135 being added to ```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__. For 1135 being added to :term:`PACKAGECONFIG`. For
1136 example, any name "foo" for which the following form does not exist: 1136 example, any name "foo" for which the following form does not exist:
1137 PACKAGECONFIG[foo] = "..." 1137 PACKAGECONFIG[foo] = "..."
1138 1138
@@ -1141,7 +1141,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1141 correct sysroot prefix when using the files automatically itself. 1141 correct sysroot prefix when using the files automatically itself.
1142 1142
1143- *``ldflags:``* Ensures that the binaries were linked with the 1143- *``ldflags:``* Ensures that the binaries were linked with the
1144 ```LDFLAGS`` <#var-LDFLAGS>`__ options provided by the build system. 1144 :term:`LDFLAGS` options provided by the build system.
1145 If this test fails, check that the ``LDFLAGS`` variable is being 1145 If this test fails, check that the ``LDFLAGS`` variable is being
1146 passed to the linker command. 1146 passed to the linker command.
1147 1147
@@ -1156,7 +1156,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1156 variable has been set explicitly to ``/usr/libexec``. 1156 variable has been set explicitly to ``/usr/libexec``.
1157 1157
1158- *``packages-list:``* Checks for the same package being listed 1158- *``packages-list:``* Checks for the same package being listed
1159 multiple times through the ```PACKAGES`` <#var-PACKAGES>`__ variable 1159 multiple times through the :term:`PACKAGES` variable
1160 value. Installing the package in this manner can cause errors during 1160 value. Installing the package in this manner can cause errors during
1161 packaging. 1161 packaging.
1162 1162
@@ -1172,27 +1172,27 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1172- *``perms:``* Currently, this check is unused but reserved. 1172- *``perms:``* Currently, this check is unused but reserved.
1173 1173
1174- *``pkgconfig:``* Checks ``.pc`` files for any 1174- *``pkgconfig:``* Checks ``.pc`` files for any
1175 ```TMPDIR`` <#var-TMPDIR>`__/```WORKDIR`` <#var-WORKDIR>`__ paths. 1175 :term:`TMPDIR`/:term:`WORKDIR` paths.
1176 Any ``.pc`` file containing these paths is incorrect since 1176 Any ``.pc`` file containing these paths is incorrect since
1177 ``pkg-config`` itself adds the correct sysroot prefix when the files 1177 ``pkg-config`` itself adds the correct sysroot prefix when the files
1178 are accessed. 1178 are accessed.
1179 1179
1180- *``pkgname:``* Checks that all packages in 1180- *``pkgname:``* Checks that all packages in
1181 ```PACKAGES`` <#var-PACKAGES>`__ have names that do not contain 1181 :term:`PACKAGES` have names that do not contain
1182 invalid characters (i.e. characters other than 0-9, a-z, ., +, and 1182 invalid characters (i.e. characters other than 0-9, a-z, ., +, and
1183 -). 1183 -).
1184 1184
1185- *``pkgv-undefined:``* Checks to see if the ``PKGV`` variable is 1185- *``pkgv-undefined:``* Checks to see if the ``PKGV`` variable is
1186 undefined during ```do_package`` <#ref-tasks-package>`__. 1186 undefined during :ref:`ref-tasks-package`.
1187 1187
1188- *``pkgvarcheck:``* Checks through the variables 1188- *``pkgvarcheck:``* Checks through the variables
1189 ```RDEPENDS`` <#var-RDEPENDS>`__, 1189 :term:`RDEPENDS`,
1190 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, 1190 :term:`RRECOMMENDS`,
1191 ```RSUGGESTS`` <#var-RSUGGESTS>`__, 1191 :term:`RSUGGESTS`,
1192 ```RCONFLICTS`` <#var-RCONFLICTS>`__, 1192 :term:`RCONFLICTS`,
1193 ```RPROVIDES`` <#var-RPROVIDES>`__, 1193 :term:`RPROVIDES`,
1194 ```RREPLACES`` <#var-RREPLACES>`__, ```FILES`` <#var-FILES>`__, 1194 :term:`RREPLACES`, :term:`FILES`,
1195 ```ALLOW_EMPTY`` <#var-ALLOW_EMPTY>`__, ``pkg_preinst``, 1195 :term:`ALLOW_EMPTY`, ``pkg_preinst``,
1196 ``pkg_postinst``, ``pkg_prerm`` and ``pkg_postrm``, and reports if 1196 ``pkg_postinst``, ``pkg_prerm`` and ``pkg_postrm``, and reports if
1197 there are variable sets that are not package-specific. Using these 1197 there are variable sets that are not package-specific. Using these
1198 variables without a package suffix is bad practice, and might 1198 variables without a package suffix is bad practice, and might
@@ -1200,11 +1200,11 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1200 same recipe or have other unintended consequences. 1200 same recipe or have other unintended consequences.
1201 1201
1202- *``pn-overrides:``* Checks that a recipe does not have a name 1202- *``pn-overrides:``* Checks that a recipe does not have a name
1203 (```PN`` <#var-PN>`__) value that appears in 1203 (:term:`PN`) value that appears in
1204 ```OVERRIDES`` <#var-OVERRIDES>`__. If a recipe is named such that 1204 :term:`OVERRIDES`. If a recipe is named such that
1205 its ``PN`` value matches something already in ``OVERRIDES`` (e.g. 1205 its ``PN`` value matches something already in ``OVERRIDES`` (e.g.
1206 ``PN`` happens to be the same as ```MACHINE`` <#var-MACHINE>`__ or 1206 ``PN`` happens to be the same as :term:`MACHINE` or
1207 ```DISTRO`` <#var-DISTRO>`__), it can have unexpected consequences. 1207 :term:`DISTRO`), it can have unexpected consequences.
1208 For example, assignments such as ``FILES_${PN} = "xyz"`` effectively 1208 For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
1209 turn into ``FILES = "xyz"``. 1209 turn into ``FILES = "xyz"``.
1210 1210
@@ -1220,7 +1220,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1220 non-``staticdev`` packages. 1220 non-``staticdev`` packages.
1221 1221
1222- *``symlink-to-sysroot:``* Checks for symlinks in packages that point 1222- *``symlink-to-sysroot:``* Checks for symlinks in packages that point
1223 into ```TMPDIR`` <#var-TMPDIR>`__ on the host. Such symlinks will 1223 into :term:`TMPDIR` on the host. Such symlinks will
1224 work on the host, but are clearly invalid when running on the target. 1224 work on the host, but are clearly invalid when running on the target.
1225 1225
1226- *``textrel:``* Checks for ELF binaries that contain relocations in 1226- *``textrel:``* Checks for ELF binaries that contain relocations in
@@ -1231,7 +1231,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1231 1231
1232- *``unlisted-pkg-lics:``* Checks that all declared licenses applying 1232- *``unlisted-pkg-lics:``* Checks that all declared licenses applying
1233 for a package are also declared on the recipe level (i.e. any license 1233 for a package are also declared on the recipe level (i.e. any license
1234 in ``LICENSE_*`` should appear in ```LICENSE`` <#var-LICENSE>`__). 1234 in ``LICENSE_*`` should appear in :term:`LICENSE`).
1235 1235
1236- *``useless-rpaths:``* Checks for dynamic library load paths (rpaths) 1236- *``useless-rpaths:``* Checks for dynamic library load paths (rpaths)
1237 in the binaries that by default on a standard system are searched by 1237 in the binaries that by default on a standard system are searched by
@@ -1239,10 +1239,10 @@ The following list shows the tests you can list with the ``WARN_QA`` and
1239 not cause any breakage, they do waste space and are unnecessary. 1239 not cause any breakage, they do waste space and are unnecessary.
1240 1240
1241- *``var-undefined:``* Reports when variables fundamental to packaging 1241- *``var-undefined:``* Reports when variables fundamental to packaging
1242 (i.e. ```WORKDIR`` <#var-WORKDIR>`__, 1242 (i.e. :term:`WORKDIR`,
1243 ```DEPLOY_DIR`` <#var-DEPLOY_DIR>`__, ```D`` <#var-D>`__, 1243 :term:`DEPLOY_DIR`, :term:`D`,
1244 ```PN`` <#var-PN>`__, and ```PKGD`` <#var-PKGD>`__) are undefined 1244 :term:`PN`, and :term:`PKGD`) are undefined
1245 during ```do_package`` <#ref-tasks-package>`__. 1245 during :ref:`ref-tasks-package`.
1246 1246
1247- *``version-going-backwards:``* If Build History is enabled, reports 1247- *``version-going-backwards:``* If Build History is enabled, reports
1248 when a package being written out has a lower version than the 1248 when a package being written out has a lower version than the
@@ -1283,7 +1283,7 @@ themselves.
1283The ``kernel`` class handles building Linux kernels. The class contains 1283The ``kernel`` class handles building Linux kernels. The class contains
1284code to build all kernel trees. All needed headers are staged into the 1284code to build all kernel trees. All needed headers are staged into the
1285``STAGING_KERNEL_DIR`` directory to allow out-of-tree module builds 1285``STAGING_KERNEL_DIR`` directory to allow out-of-tree module builds
1286using the ```module`` <#ref-classes-module>`__ class. 1286using the :ref:`module <ref-classes-module>` class.
1287 1287
1288This means that each built kernel module is packaged separately and 1288This means that each built kernel module is packaged separately and
1289inter-module dependencies are created by parsing the ``modinfo`` output. 1289inter-module dependencies are created by parsing the ``modinfo`` output.
@@ -1299,9 +1299,9 @@ Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section in
1299the Yocto Project Development Tasks Manual. 1299the Yocto Project Development Tasks Manual.
1300 1300
1301Various other classes are used by the ``kernel`` and ``module`` classes 1301Various other classes are used by the ``kernel`` and ``module`` classes
1302internally including the ```kernel-arch`` <#ref-classes-kernel-arch>`__, 1302internally including the :ref:`kernel-arch <ref-classes-kernel-arch>`,
1303```module-base`` <#ref-classes-module-base>`__, and 1303:ref:`module-base <ref-classes-module-base>`, and
1304```linux-kernel-base`` <#ref-classes-linux-kernel-base>`__ classes. 1304:ref:`linux-kernel-base <ref-classes-linux-kernel-base>` classes.
1305 1305
1306.. _ref-classes-kernel-arch: 1306.. _ref-classes-kernel-arch:
1307 1307
@@ -1317,7 +1317,7 @@ Linux kernel compilation (including modules).
1317============================= 1317=============================
1318 1318
1319The ``kernel-devicetree`` class, which is inherited by the 1319The ``kernel-devicetree`` class, which is inherited by the
1320```kernel`` <#ref-classes-kernel>`__ class, supports device tree 1320:ref:`kernel <ref-classes-kernel>` class, supports device tree
1321generation. 1321generation.
1322 1322
1323.. _ref-classes-kernel-fitimage: 1323.. _ref-classes-kernel-fitimage:
@@ -1422,7 +1422,7 @@ The ``kernelsrc`` class sets the Linux kernel source and version.
1422The ``lib_package`` class supports recipes that build libraries and 1422The ``lib_package`` class supports recipes that build libraries and
1423produce executable binaries, where those binaries should not be 1423produce executable binaries, where those binaries should not be
1424installed by default along with the library. Instead, the binaries are 1424installed by default along with the library. Instead, the binaries are
1425added to a separate ``${``\ ```PN`` <#var-PN>`__\ ``}-bin`` package to 1425added to a separate ``${``\ :term:`PN`\ ``}-bin`` package to
1426make their installation optional. 1426make their installation optional.
1427 1427
1428.. _ref-classes-libc*: 1428.. _ref-classes-libc*:
@@ -1445,7 +1445,7 @@ The ``libc*`` classes support recipes that build packages with ``libc``:
1445 1445
1446The ``license`` class provides license manifest creation and license 1446The ``license`` class provides license manifest creation and license
1447exclusion. This class is enabled by default using the default value for 1447exclusion. This class is enabled by default using the default value for
1448the ```INHERIT_DISTRO`` <#var-INHERIT_DISTRO>`__ variable. 1448the :term:`INHERIT_DISTRO` variable.
1449 1449
1450.. _ref-classes-linux-kernel-base: 1450.. _ref-classes-linux-kernel-base:
1451 1451
@@ -1495,7 +1495,7 @@ recipes.
1495The ``metadata_scm`` class provides functionality for querying the 1495The ``metadata_scm`` class provides functionality for querying the
1496branch and revision of a Source Code Manager (SCM) repository. 1496branch and revision of a Source Code Manager (SCM) repository.
1497 1497
1498The ```base`` <#ref-classes-base>`__ class uses this class to print the 1498The :ref:`base <ref-classes-base>` class uses this class to print the
1499revisions of each layer before starting every build. The 1499revisions of each layer before starting every build. The
1500``metadata_scm`` class is enabled by default because it is inherited by 1500``metadata_scm`` class is enabled by default because it is inherited by
1501the ``base`` class. 1501the ``base`` class.
@@ -1524,12 +1524,12 @@ the shared database.
1524=================== 1524===================
1525 1525
1526The ``mirrors`` class sets up some standard 1526The ``mirrors`` class sets up some standard
1527```MIRRORS`` <#var-MIRRORS>`__ entries for source code mirrors. These 1527:term:`MIRRORS` entries for source code mirrors. These
1528mirrors provide a fall-back path in case the upstream source specified 1528mirrors provide a fall-back path in case the upstream source specified
1529in ```SRC_URI`` <#var-SRC_URI>`__ within recipes is unavailable. 1529in :term:`SRC_URI` within recipes is unavailable.
1530 1530
1531This class is enabled by default since it is inherited by the 1531This class is enabled by default since it is inherited by the
1532```base`` <#ref-classes-base>`__ class. 1532:ref:`base <ref-classes-base>` class.
1533 1533
1534.. _ref-classes-module: 1534.. _ref-classes-module:
1535 1535
@@ -1538,10 +1538,10 @@ This class is enabled by default since it is inherited by the
1538 1538
1539The ``module`` class provides support for building out-of-tree Linux 1539The ``module`` class provides support for building out-of-tree Linux
1540kernel modules. The class inherits the 1540kernel modules. The class inherits the
1541```module-base`` <#ref-classes-module-base>`__ and 1541:ref:`module-base <ref-classes-module-base>` and
1542```kernel-module-split`` <#ref-classes-kernel-module-split>`__ classes, 1542:ref:`kernel-module-split <ref-classes-kernel-module-split>` classes,
1543and implements the ```do_compile`` <#ref-tasks-compile>`__ and 1543and implements the :ref:`ref-tasks-compile` and
1544```do_install`` <#ref-tasks-install>`__ tasks. The class provides 1544:ref:`ref-tasks-install` tasks. The class provides
1545everything needed to build and package a kernel module. 1545everything needed to build and package a kernel module.
1546 1546
1547For general information on out-of-tree Linux kernel modules, see the 1547For general information on out-of-tree Linux kernel modules, see the
@@ -1558,7 +1558,7 @@ The ``module-base`` class provides the base functionality for building
1558Linux kernel modules. Typically, a recipe that builds software that 1558Linux kernel modules. Typically, a recipe that builds software that
1559includes one or more kernel modules and has its own means of building 1559includes one or more kernel modules and has its own means of building
1560the module inherits this class as opposed to inheriting the 1560the module inherits this class as opposed to inheriting the
1561```module`` <#ref-classes-module>`__ class. 1561:ref:`module <ref-classes-module>` class.
1562 1562
1563.. _ref-classes-multilib*: 1563.. _ref-classes-multilib*:
1564 1564
@@ -1604,7 +1604,7 @@ a couple different ways:
1604 caused by existing code that depends on that naming convention. 1604 caused by existing code that depends on that naming convention.
1605 1605
1606- Create or modify a target recipe that contains the following: 1606- Create or modify a target recipe that contains the following:
1607 ```BBCLASSEXTEND`` <#var-BBCLASSEXTEND>`__ = "native" Inside the 1607 :term:`BBCLASSEXTEND` = "native" Inside the
1608 recipe, use ``_class-native`` and ``_class-target`` overrides to 1608 recipe, use ``_class-native`` and ``_class-target`` overrides to
1609 specify any functionality specific to the respective native or target 1609 specify any functionality specific to the respective native or target
1610 case. 1610 case.
@@ -1621,7 +1621,7 @@ target. All common parts of the recipe are automatically shared.
1621 1621
1622The ``nativesdk`` class provides common functionality for recipes that 1622The ``nativesdk`` class provides common functionality for recipes that
1623wish to build tools to run as part of an SDK (i.e. tools that run on 1623wish to build tools to run as part of an SDK (i.e. tools that run on
1624```SDKMACHINE`` <#var-SDKMACHINE>`__). 1624:term:`SDKMACHINE`).
1625 1625
1626You can create a recipe that builds tools that run on the SDK machine a 1626You can create a recipe that builds tools that run on the SDK machine a
1627couple different ways: 1627couple different ways:
@@ -1632,7 +1632,7 @@ couple different ways:
1632 that the ``nativesdk`` class is inherited last. 1632 that the ``nativesdk`` class is inherited last.
1633 1633
1634- Create a ``nativesdk`` variant of any recipe by adding the following: 1634- Create a ``nativesdk`` variant of any recipe by adding the following:
1635 ```BBCLASSEXTEND`` <#var-BBCLASSEXTEND>`__ = "nativesdk" Inside the 1635 :term:`BBCLASSEXTEND` = "nativesdk" Inside the
1636 recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to 1636 recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to
1637 specify any functionality specific to the respective SDK machine or 1637 specify any functionality specific to the respective SDK machine or
1638 target case. 1638 target case.
@@ -1686,7 +1686,7 @@ section in the Yocto Project Development Tasks Manual.
1686================== 1686==================
1687 1687
1688The ``oelint`` class is an obsolete lint checking tool that exists in 1688The ``oelint`` class is an obsolete lint checking tool that exists in
1689``meta/classes`` in the `Source Directory <#source-directory>`__. 1689``meta/classes`` in the :term:`Source Directory`.
1690 1690
1691A number of classes exist that could be generally useful in OE-Core but 1691A number of classes exist that could be generally useful in OE-Core but
1692are never actually used within OE-Core itself. The ``oelint`` class is 1692are never actually used within OE-Core itself. The ``oelint`` class is
@@ -1700,12 +1700,12 @@ layers.
1700======================= 1700=======================
1701 1701
1702The ``own-mirrors`` class makes it easier to set up your own 1702The ``own-mirrors`` class makes it easier to set up your own
1703```PREMIRRORS`` <#var-PREMIRRORS>`__ from which to first fetch source 1703:term:`PREMIRRORS` from which to first fetch source
1704before attempting to fetch it from the upstream specified in 1704before attempting to fetch it from the upstream specified in
1705```SRC_URI`` <#var-SRC_URI>`__ within each recipe. 1705:term:`SRC_URI` within each recipe.
1706 1706
1707To use this class, inherit it globally and specify 1707To use this class, inherit it globally and specify
1708```SOURCE_MIRROR_URL`` <#var-SOURCE_MIRROR_URL>`__. Here is an example: 1708:term:`SOURCE_MIRROR_URL`. Here is an example:
1709INHERIT += "own-mirrors" SOURCE_MIRROR_URL = 1709INHERIT += "own-mirrors" SOURCE_MIRROR_URL =
1710"http://example.com/my-source-mirror" You can specify only a single URL 1710"http://example.com/my-source-mirror" You can specify only a single URL
1711in ``SOURCE_MIRROR_URL``. 1711in ``SOURCE_MIRROR_URL``.
@@ -1719,10 +1719,10 @@ The ``package`` class supports generating packages from a build's
1719output. The core generic functionality is in ``package.bbclass``. The 1719output. The core generic functionality is in ``package.bbclass``. The
1720code specific to particular package types resides in these 1720code specific to particular package types resides in these
1721package-specific classes: 1721package-specific classes:
1722```package_deb`` <#ref-classes-package_deb>`__, 1722:ref:`package_deb <ref-classes-package_deb>`,
1723```package_rpm`` <#ref-classes-package_rpm>`__, 1723:ref:`package_rpm <ref-classes-package_rpm>`,
1724```package_ipk`` <#ref-classes-package_ipk>`__, and 1724:ref:`package_ipk <ref-classes-package_ipk>`, and
1725```package_tar`` <#ref-classes-package_tar>`__. 1725:ref:`package_tar <ref-classes-package_tar>`.
1726 1726
1727.. note:: 1727.. note::
1728 1728
@@ -1753,7 +1753,7 @@ takes about thirty percent less time as compared to using RPM to build
1753the same or similar package. This comparison takes into account a 1753the same or similar package. This comparison takes into account a
1754complete build of the package with all dependencies previously built. 1754complete build of the package with all dependencies previously built.
1755The reason for this discrepancy is because the RPM package manager 1755The reason for this discrepancy is because the RPM package manager
1756creates and processes more `Metadata <#metadata>`__ than the IPK package 1756creates and processes more :term:`Metadata` than the IPK package
1757manager. Consequently, you might consider setting ``PACKAGE_CLASSES`` to 1757manager. Consequently, you might consider setting ``PACKAGE_CLASSES`` to
1758"package_ipk" if you are building smaller systems. 1758"package_ipk" if you are building smaller systems.
1759 1759
@@ -1786,10 +1786,10 @@ at these two Yocto Project mailing list links:
1786The ``package_deb`` class provides support for creating packages that 1786The ``package_deb`` class provides support for creating packages that
1787use the Debian (i.e. ``.deb``) file format. The class ensures the 1787use the Debian (i.e. ``.deb``) file format. The class ensures the
1788packages are written out in a ``.deb`` file format to the 1788packages are written out in a ``.deb`` file format to the
1789``${``\ ```DEPLOY_DIR_DEB`` <#var-DEPLOY_DIR_DEB>`__\ ``}`` directory. 1789``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory.
1790 1790
1791This class inherits the ```package`` <#ref-classes-package>`__ class and 1791This class inherits the :ref:`package <ref-classes-package>` class and
1792is enabled through the ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ 1792is enabled through the :term:`PACKAGE_CLASSES`
1793variable in the ``local.conf`` file. 1793variable in the ``local.conf`` file.
1794 1794
1795.. _ref-classes-package_ipk: 1795.. _ref-classes-package_ipk:
@@ -1800,10 +1800,10 @@ variable in the ``local.conf`` file.
1800The ``package_ipk`` class provides support for creating packages that 1800The ``package_ipk`` class provides support for creating packages that
1801use the IPK (i.e. ``.ipk``) file format. The class ensures the packages 1801use the IPK (i.e. ``.ipk``) file format. The class ensures the packages
1802are written out in a ``.ipk`` file format to the 1802are written out in a ``.ipk`` file format to the
1803``${``\ ```DEPLOY_DIR_IPK`` <#var-DEPLOY_DIR_IPK>`__\ ``}`` directory. 1803``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory.
1804 1804
1805This class inherits the ```package`` <#ref-classes-package>`__ class and 1805This class inherits the :ref:`package <ref-classes-package>` class and
1806is enabled through the ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ 1806is enabled through the :term:`PACKAGE_CLASSES`
1807variable in the ``local.conf`` file. 1807variable in the ``local.conf`` file.
1808 1808
1809.. _ref-classes-package_rpm: 1809.. _ref-classes-package_rpm:
@@ -1814,10 +1814,10 @@ variable in the ``local.conf`` file.
1814The ``package_rpm`` class provides support for creating packages that 1814The ``package_rpm`` class provides support for creating packages that
1815use the RPM (i.e. ``.rpm``) file format. The class ensures the packages 1815use the RPM (i.e. ``.rpm``) file format. The class ensures the packages
1816are written out in a ``.rpm`` file format to the 1816are written out in a ``.rpm`` file format to the
1817``${``\ ```DEPLOY_DIR_RPM`` <#var-DEPLOY_DIR_RPM>`__\ ``}`` directory. 1817``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory.
1818 1818
1819This class inherits the ```package`` <#ref-classes-package>`__ class and 1819This class inherits the :ref:`package <ref-classes-package>` class and
1820is enabled through the ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ 1820is enabled through the :term:`PACKAGE_CLASSES`
1821variable in the ``local.conf`` file. 1821variable in the ``local.conf`` file.
1822 1822
1823.. _ref-classes-package_tar: 1823.. _ref-classes-package_tar:
@@ -1827,10 +1827,10 @@ variable in the ``local.conf`` file.
1827 1827
1828The ``package_tar`` class provides support for creating tarballs. The 1828The ``package_tar`` class provides support for creating tarballs. The
1829class ensures the packages are written out in a tarball format to the 1829class ensures the packages are written out in a tarball format to the
1830``${``\ ```DEPLOY_DIR_TAR`` <#var-DEPLOY_DIR_TAR>`__\ ``}`` directory. 1830``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory.
1831 1831
1832This class inherits the ```package`` <#ref-classes-package>`__ class and 1832This class inherits the :ref:`package <ref-classes-package>` class and
1833is enabled through the ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ 1833is enabled through the :term:`PACKAGE_CLASSES`
1834variable in the ``local.conf`` file. 1834variable in the ``local.conf`` file.
1835 1835
1836.. note:: 1836.. note::
@@ -1853,12 +1853,12 @@ variable in the ``local.conf`` file.
1853======================= 1853=======================
1854 1854
1855The ``packagedata`` class provides common functionality for reading 1855The ``packagedata`` class provides common functionality for reading
1856``pkgdata`` files found in ```PKGDATA_DIR`` <#var-PKGDATA_DIR>`__. These 1856``pkgdata`` files found in :term:`PKGDATA_DIR`. These
1857files contain information about each output package produced by the 1857files contain information about each output package produced by the
1858OpenEmbedded build system. 1858OpenEmbedded build system.
1859 1859
1860This class is enabled by default because it is inherited by the 1860This class is enabled by default because it is inherited by the
1861```package`` <#ref-classes-package>`__ class. 1861:ref:`package <ref-classes-package>` class.
1862 1862
1863.. _ref-classes-packagegroup: 1863.. _ref-classes-packagegroup:
1864 1864
@@ -1883,10 +1883,10 @@ Previously, this class was called the ``task`` class.
1883================= 1883=================
1884 1884
1885The ``patch`` class provides all functionality for applying patches 1885The ``patch`` class provides all functionality for applying patches
1886during the ```do_patch`` <#ref-tasks-patch>`__ task. 1886during the :ref:`ref-tasks-patch` task.
1887 1887
1888This class is enabled by default because it is inherited by the 1888This class is enabled by default because it is inherited by the
1889```base`` <#ref-classes-base>`__ class. 1889:ref:`base <ref-classes-base>` class.
1890 1890
1891.. _ref-classes-perlnative: 1891.. _ref-classes-perlnative:
1892 1892
@@ -1912,7 +1912,7 @@ host during image creation.
1912 1912
1913If the pixbuf loaders being installed are in packages other than the 1913If the pixbuf loaders being installed are in packages other than the
1914recipe's main package, set 1914recipe's main package, set
1915```PIXBUF_PACKAGES`` <#var-PIXBUF_PACKAGES>`__ to specify the packages 1915:term:`PIXBUF_PACKAGES` to specify the packages
1916containing the loaders. 1916containing the loaders.
1917 1917
1918.. _ref-classes-pkgconfig: 1918.. _ref-classes-pkgconfig:
@@ -1936,7 +1936,7 @@ files.
1936 1936
1937The ``populate_sdk`` class provides support for SDK-only recipes. For 1937The ``populate_sdk`` class provides support for SDK-only recipes. For
1938information on advantages gained when building a cross-development 1938information on advantages gained when building a cross-development
1939toolchain using the ```do_populate_sdk`` <#ref-tasks-populate_sdk>`__ 1939toolchain using the :ref:`ref-tasks-populate_sdk`
1940task, see the "`Building an SDK 1940task, see the "`Building an SDK
1941Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__" 1941Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__"
1942section in the Yocto Project Application Development and the Extensible 1942section in the Yocto Project Application Development and the Extensible
@@ -1967,15 +1967,15 @@ following classes:
1967 1967
1968The ``populate_sdk_base`` class inherits the appropriate 1968The ``populate_sdk_base`` class inherits the appropriate
1969``populate_sdk_*`` (i.e. ``deb``, ``rpm``, and ``ipk``) based on 1969``populate_sdk_*`` (i.e. ``deb``, ``rpm``, and ``ipk``) based on
1970```IMAGE_PKGTYPE`` <#var-IMAGE_PKGTYPE>`__. 1970:term:`IMAGE_PKGTYPE`.
1971 1971
1972The base class ensures all source and destination directories are 1972The base class ensures all source and destination directories are
1973established and then populates the SDK. After populating the SDK, the 1973established and then populates the SDK. After populating the SDK, the
1974``populate_sdk_base`` class constructs two sysroots: 1974``populate_sdk_base`` class constructs two sysroots:
1975``${``\ ```SDK_ARCH`` <#var-SDK_ARCH>`__\ ``}-nativesdk``, which 1975``${``\ :term:`SDK_ARCH`\ ``}-nativesdk``, which
1976contains the cross-compiler and associated tooling, and the target, 1976contains the cross-compiler and associated tooling, and the target,
1977which contains a target root filesystem that is configured for the SDK 1977which contains a target root filesystem that is configured for the SDK
1978usage. These two images reside in ```SDK_OUTPUT`` <#var-SDK_OUTPUT>`__, 1978usage. These two images reside in :term:`SDK_OUTPUT`,
1979which consists of the following: 1979which consists of the following:
1980${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs 1980${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs
1981${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs 1981${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs
@@ -1993,7 +1993,7 @@ the "`Cross-Development Toolchain
1993Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" 1993Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
1994section in the Yocto Project Overview and Concepts Manual. For 1994section in the Yocto Project Overview and Concepts Manual. For
1995information on advantages gained when building a cross-development 1995information on advantages gained when building a cross-development
1996toolchain using the ```do_populate_sdk`` <#ref-tasks-populate_sdk>`__ 1996toolchain using the :ref:`ref-tasks-populate_sdk`
1997task, see the "`Building an SDK 1997task, see the "`Building an SDK
1998Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__" 1998Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__"
1999section in the Yocto Project Application Development and the Extensible 1999section in the Yocto Project Application Development and the Extensible
@@ -2005,7 +2005,7 @@ Software Development Kit (eSDK) manual.
2005==================== 2005====================
2006 2006
2007The ``prexport`` class provides functionality for exporting 2007The ``prexport`` class provides functionality for exporting
2008```PR`` <#var-PR>`__ values. 2008:term:`PR` values.
2009 2009
2010.. note:: 2010.. note::
2011 2011
@@ -2020,7 +2020,7 @@ The ``prexport`` class provides functionality for exporting
2020==================== 2020====================
2021 2021
2022The ``primport`` class provides functionality for importing 2022The ``primport`` class provides functionality for importing
2023```PR`` <#var-PR>`__ values. 2023:term:`PR` values.
2024 2024
2025.. note:: 2025.. note::
2026 2026
@@ -2036,13 +2036,13 @@ The ``primport`` class provides functionality for importing
2036 2036
2037The ``prserv`` class provides functionality for using a `PR 2037The ``prserv`` class provides functionality for using a `PR
2038service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__ in order to 2038service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__ in order to
2039automatically manage the incrementing of the ```PR`` <#var-PR>`__ 2039automatically manage the incrementing of the :term:`PR`
2040variable for each recipe. 2040variable for each recipe.
2041 2041
2042This class is enabled by default because it is inherited by the 2042This class is enabled by default because it is inherited by the
2043```package`` <#ref-classes-package>`__ class. However, the OpenEmbedded 2043:ref:`package <ref-classes-package>` class. However, the OpenEmbedded
2044build system will not enable the functionality of this class unless 2044build system will not enable the functionality of this class unless
2045```PRSERV_HOST`` <#var-PRSERV_HOST>`__ has been set. 2045:term:`PRSERV_HOST` has been set.
2046 2046
2047.. _ref-classes-ptest: 2047.. _ref-classes-ptest:
2048 2048
@@ -2054,7 +2054,7 @@ runtime tests for recipes that build software that provides these tests.
2054 2054
2055This class is intended to be inherited by individual recipes. However, 2055This class is intended to be inherited by individual recipes. However,
2056the class' functionality is largely disabled unless "ptest" appears in 2056the class' functionality is largely disabled unless "ptest" appears in
2057```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. See the "`Testing 2057:term:`DISTRO_FEATURES`. See the "`Testing
2058Packages With 2058Packages With
2059ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in 2059ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in
2060the Yocto Project Development Tasks Manual for more information on 2060the Yocto Project Development Tasks Manual for more information on
@@ -2126,9 +2126,9 @@ are set or software that is present).
2126The ``relocatable`` class enables relocation of binaries when they are 2126The ``relocatable`` class enables relocation of binaries when they are
2127installed into the sysroot. 2127installed into the sysroot.
2128 2128
2129This class makes use of the ```chrpath`` <#ref-classes-chrpath>`__ class 2129This class makes use of the :ref:`chrpath <ref-classes-chrpath>` class
2130and is used by both the ```cross`` <#ref-classes-cross>`__ and 2130and is used by both the :ref:`cross <ref-classes-cross>` and
2131```native`` <#ref-classes-native>`__ classes. 2131:ref:`native <ref-classes-native>` classes.
2132 2132
2133.. _ref-classes-remove-libtool: 2133.. _ref-classes-remove-libtool:
2134 2134
@@ -2136,7 +2136,7 @@ and is used by both the ```cross`` <#ref-classes-cross>`__ and
2136========================== 2136==========================
2137 2137
2138The ``remove-libtool`` class adds a post function to the 2138The ``remove-libtool`` class adds a post function to the
2139```do_install`` <#ref-tasks-install>`__ task to remove all ``.la`` files 2139:ref:`ref-tasks-install` task to remove all ``.la`` files
2140installed by ``libtool``. Removing these files results in them being 2140installed by ``libtool``. Removing these files results in them being
2141absent from both the sysroot and target packages. 2141absent from both the sysroot and target packages.
2142 2142
@@ -2163,7 +2163,7 @@ The class collects debug information for recipe, recipe version, task,
2163machine, distro, build system, target system, host distro, branch, 2163machine, distro, build system, target system, host distro, branch,
2164commit, and log. From the information, report files using a JSON format 2164commit, and log. From the information, report files using a JSON format
2165are created and stored in 2165are created and stored in
2166``${``\ ```LOG_DIR`` <#var-LOG_DIR>`__\ ``}/error-report``. 2166``${``\ :term:`LOG_DIR`\ ``}/error-report``.
2167 2167
2168.. _ref-classes-rm-work: 2168.. _ref-classes-rm-work:
2169 2169
@@ -2216,7 +2216,7 @@ image and consist of the following classes:
2216 2216
2217The root filesystem is created from packages using one of the 2217The root filesystem is created from packages using one of the
2218``rootfs*.bbclass`` files as determined by the 2218``rootfs*.bbclass`` files as determined by the
2219```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ variable. 2219:term:`PACKAGE_CLASSES` variable.
2220 2220
2221For information on how root filesystem images are created, see the 2221For information on how root filesystem images are created, see the
2222"`Image 2222"`Image
@@ -2242,7 +2242,7 @@ usually determines whether to include this class.
2242 2242
2243The ``scons`` class supports recipes that need to build software that 2243The ``scons`` class supports recipes that need to build software that
2244uses the SCons build system. You can use the 2244uses the SCons build system. You can use the
2245```EXTRA_OESCONS`` <#var-EXTRA_OESCONS>`__ variable to specify 2245:term:`EXTRA_OESCONS` variable to specify
2246additional configuration options you want to pass SCons command line. 2246additional configuration options you want to pass SCons command line.
2247 2247
2248.. _ref-classes-sdl: 2248.. _ref-classes-sdl:
@@ -2293,8 +2293,8 @@ Python bindings.
2293 2293
2294The ``siteconfig`` class provides functionality for handling site 2294The ``siteconfig`` class provides functionality for handling site
2295configuration. The class is used by the 2295configuration. The class is used by the
2296```autotools`` <#ref-classes-autotools>`__ class to accelerate the 2296:ref:`autotools <ref-classes-autotools>` class to accelerate the
2297```do_configure`` <#ref-tasks-configure>`__ task. 2297:ref:`ref-tasks-configure` task.
2298 2298
2299.. _ref-classes-siteinfo: 2299.. _ref-classes-siteinfo:
2300 2300
@@ -2337,7 +2337,7 @@ build.
2337 2337
2338The ``sstate`` class provides support for Shared State (sstate). By 2338The ``sstate`` class provides support for Shared State (sstate). By
2339default, the class is enabled through the 2339default, the class is enabled through the
2340```INHERIT_DISTRO`` <#var-INHERIT_DISTRO>`__ variable's default value. 2340:term:`INHERIT_DISTRO` variable's default value.
2341 2341
2342For more information on sstate, see the "`Shared State 2342For more information on sstate, see the "`Shared State
2343Cache <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__" section in the Yocto 2343Cache <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__" section in the Yocto
@@ -2351,15 +2351,15 @@ Project Overview and Concepts Manual.
2351The ``staging`` class installs files into individual recipe work 2351The ``staging`` class installs files into individual recipe work
2352directories for sysroots. The class contains the following key tasks: 2352directories for sysroots. The class contains the following key tasks:
2353 2353
2354- The ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task, 2354- The :ref:`ref-tasks-populate_sysroot` task,
2355 which is responsible for handing the files that end up in the recipe 2355 which is responsible for handing the files that end up in the recipe
2356 sysroots. 2356 sysroots.
2357 2357
2358- The 2358- The
2359 ```do_prepare_recipe_sysroot`` <#ref-tasks-prepare_recipe_sysroot>`__ 2359 :ref:`ref-tasks-prepare_recipe_sysroot`
2360 task (a "partner" task to the ``populate_sysroot`` task), which 2360 task (a "partner" task to the ``populate_sysroot`` task), which
2361 installs the files into the individual recipe work directories (i.e. 2361 installs the files into the individual recipe work directories (i.e.
2362 ```WORKDIR`` <#var-WORKDIR>`__). 2362 :term:`WORKDIR`).
2363 2363
2364The code in the ``staging`` class is complex and basically works in two 2364The code in the ``staging`` class is complex and basically works in two
2365stages: 2365stages:
@@ -2367,13 +2367,13 @@ stages:
2367- *Stage One:* The first stage addresses recipes that have files they 2367- *Stage One:* The first stage addresses recipes that have files they
2368 want to share with other recipes that have dependencies on the 2368 want to share with other recipes that have dependencies on the
2369 originating recipe. Normally these dependencies are installed through 2369 originating recipe. Normally these dependencies are installed through
2370 the ```do_install`` <#ref-tasks-install>`__ task into 2370 the :ref:`ref-tasks-install` task into
2371 ``${``\ ```D`` <#var-D>`__\ ``}``. The ``do_populate_sysroot`` task 2371 ``${``\ :term:`D`\ ``}``. The ``do_populate_sysroot`` task
2372 copies a subset of these files into ``${SYSROOT_DESTDIR}``. This 2372 copies a subset of these files into ``${SYSROOT_DESTDIR}``. This
2373 subset of files is controlled by the 2373 subset of files is controlled by the
2374 ```SYSROOT_DIRS`` <#var-SYSROOT_DIRS>`__, 2374 :term:`SYSROOT_DIRS`,
2375 ```SYSROOT_DIRS_NATIVE`` <#var-SYSROOT_DIRS_NATIVE>`__, and 2375 :term:`SYSROOT_DIRS_NATIVE`, and
2376 ```SYSROOT_DIRS_BLACKLIST`` <#var-SYSROOT_DIRS_BLACKLIST>`__ 2376 :term:`SYSROOT_DIRS_BLACKLIST`
2377 variables. 2377 variables.
2378 2378
2379 .. note:: 2379 .. note::
@@ -2391,17 +2391,17 @@ stages:
2391 hardcoded locations are replaced by tokens and a list of the files 2391 hardcoded locations are replaced by tokens and a list of the files
2392 needing such replacements is created. These adjustments are referred 2392 needing such replacements is created. These adjustments are referred
2393 to as "FIXMEs". The list of files that are scanned for paths is 2393 to as "FIXMEs". The list of files that are scanned for paths is
2394 controlled by the ```SSTATE_SCAN_FILES`` <#var-SSTATE_SCAN_FILES>`__ 2394 controlled by the :term:`SSTATE_SCAN_FILES`
2395 variable. 2395 variable.
2396 2396
2397- *Stage Two:* The second stage addresses recipes that want to use 2397- *Stage Two:* The second stage addresses recipes that want to use
2398 something from another recipe and declare a dependency on that recipe 2398 something from another recipe and declare a dependency on that recipe
2399 through the ```DEPENDS`` <#var-DEPENDS>`__ variable. The recipe will 2399 through the :term:`DEPENDS` variable. The recipe will
2400 have a 2400 have a
2401 ```do_prepare_recipe_sysroot`` <#ref-tasks-prepare_recipe_sysroot>`__ 2401 :ref:`ref-tasks-prepare_recipe_sysroot`
2402 task and when this task executes, it creates the ``recipe-sysroot`` 2402 task and when this task executes, it creates the ``recipe-sysroot``
2403 and ``recipe-sysroot-native`` in the recipe work directory (i.e. 2403 and ``recipe-sysroot-native`` in the recipe work directory (i.e.
2404 ```WORKDIR`` <#var-WORKDIR>`__). The OpenEmbedded build system 2404 :term:`WORKDIR`). The OpenEmbedded build system
2405 creates hard links to copies of the relevant files from 2405 creates hard links to copies of the relevant files from
2406 ``sysroots-components`` into the recipe work directory. 2406 ``sysroots-components`` into the recipe work directory.
2407 2407
@@ -2437,7 +2437,7 @@ stages:
2437 is used so that builds should be identical regardless of whether 2437 is used so that builds should be identical regardless of whether
2438 sstate was used or not. For a closer look, see the 2438 sstate was used or not. For a closer look, see the
2439 ``setscene_depvalid()`` function in the 2439 ``setscene_depvalid()`` function in the
2440 ```sstate`` <#ref-classes-sstate>`__ class. 2440 :ref:`sstate <ref-classes-sstate>` class.
2441 2441
2442 The build system is careful to maintain manifests of the files it 2442 The build system is careful to maintain manifests of the files it
2443 installs so that any given dependency can be installed as needed. The 2443 installs so that any given dependency can be installed as needed. The
@@ -2454,37 +2454,37 @@ bootable images.
2454 2454
2455The class supports the following variables: 2455The class supports the following variables:
2456 2456
2457- ```INITRD`` <#var-INITRD>`__: Indicates list of filesystem images to 2457- :term:`INITRD`: Indicates list of filesystem images to
2458 concatenate and use as an initial RAM disk (initrd). This variable is 2458 concatenate and use as an initial RAM disk (initrd). This variable is
2459 optional. 2459 optional.
2460 2460
2461- ```ROOTFS`` <#var-ROOTFS>`__: Indicates a filesystem image to include 2461- :term:`ROOTFS`: Indicates a filesystem image to include
2462 as the root filesystem. This variable is optional. 2462 as the root filesystem. This variable is optional.
2463 2463
2464- ```AUTO_SYSLINUXMENU`` <#var-AUTO_SYSLINUXMENU>`__: Enables creating 2464- :term:`AUTO_SYSLINUXMENU`: Enables creating
2465 an automatic menu when set to "1". 2465 an automatic menu when set to "1".
2466 2466
2467- ```LABELS`` <#var-LABELS>`__: Lists targets for automatic 2467- :term:`LABELS`: Lists targets for automatic
2468 configuration. 2468 configuration.
2469 2469
2470- ```APPEND`` <#var-APPEND>`__: Lists append string overrides for each 2470- :term:`APPEND`: Lists append string overrides for each
2471 label. 2471 label.
2472 2472
2473- ```SYSLINUX_OPTS`` <#var-SYSLINUX_OPTS>`__: Lists additional options 2473- :term:`SYSLINUX_OPTS`: Lists additional options
2474 to add to the syslinux file. Semicolon characters separate multiple 2474 to add to the syslinux file. Semicolon characters separate multiple
2475 options. 2475 options.
2476 2476
2477- ```SYSLINUX_SPLASH`` <#var-SYSLINUX_SPLASH>`__: Lists a background 2477- :term:`SYSLINUX_SPLASH`: Lists a background
2478 for the VGA boot menu when you are using the boot menu. 2478 for the VGA boot menu when you are using the boot menu.
2479 2479
2480- ```SYSLINUX_DEFAULT_CONSOLE`` <#var-SYSLINUX_DEFAULT_CONSOLE>`__: Set 2480- :term:`SYSLINUX_DEFAULT_CONSOLE`: Set
2481 to "console=ttyX" to change kernel boot default console. 2481 to "console=ttyX" to change kernel boot default console.
2482 2482
2483- ```SYSLINUX_SERIAL`` <#var-SYSLINUX_SERIAL>`__: Sets an alternate 2483- :term:`SYSLINUX_SERIAL`: Sets an alternate
2484 serial port. Or, turns off serial when the variable is set with an 2484 serial port. Or, turns off serial when the variable is set with an
2485 empty string. 2485 empty string.
2486 2486
2487- ```SYSLINUX_SERIAL_TTY`` <#var-SYSLINUX_SERIAL_TTY>`__: Sets an 2487- :term:`SYSLINUX_SERIAL_TTY`: Sets an
2488 alternate "console=tty..." kernel boot argument. 2488 alternate "console=tty..." kernel boot argument.
2489 2489
2490.. _ref-classes-systemd: 2490.. _ref-classes-systemd:
@@ -2496,24 +2496,24 @@ The ``systemd`` class provides support for recipes that install systemd
2496unit files. 2496unit files.
2497 2497
2498The functionality for this class is disabled unless you have "systemd" 2498The functionality for this class is disabled unless you have "systemd"
2499in ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. 2499in :term:`DISTRO_FEATURES`.
2500 2500
2501Under this class, the recipe or Makefile (i.e. whatever the recipe is 2501Under this class, the recipe or Makefile (i.e. whatever the recipe is
2502calling during the ```do_install`` <#ref-tasks-install>`__ task) 2502calling during the :ref:`ref-tasks-install` task)
2503installs unit files into 2503installs unit files into
2504``${``\ ```D`` <#var-D>`__\ ``}${systemd_unitdir}/system``. If the unit 2504``${``\ :term:`D`\ ``}${systemd_unitdir}/system``. If the unit
2505files being installed go into packages other than the main package, you 2505files being installed go into packages other than the main package, you
2506need to set ```SYSTEMD_PACKAGES`` <#var-SYSTEMD_PACKAGES>`__ in your 2506need to set :term:`SYSTEMD_PACKAGES` in your
2507recipe to identify the packages in which the files will be installed. 2507recipe to identify the packages in which the files will be installed.
2508 2508
2509You should set ```SYSTEMD_SERVICE`` <#var-SYSTEMD_SERVICE>`__ to the 2509You should set :term:`SYSTEMD_SERVICE` to the
2510name of the service file. You should also use a package name override to 2510name of the service file. You should also use a package name override to
2511indicate the package to which the value applies. If the value applies to 2511indicate the package to which the value applies. If the value applies to
2512the recipe's main package, use ``${``\ ```PN`` <#var-PN>`__\ ``}``. Here 2512the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here
2513is an example from the connman recipe: SYSTEMD_SERVICE_${PN} = 2513is an example from the connman recipe: SYSTEMD_SERVICE_${PN} =
2514"connman.service" Services are set up to start on boot automatically 2514"connman.service" Services are set up to start on boot automatically
2515unless you have set 2515unless you have set
2516```SYSTEMD_AUTO_ENABLE`` <#var-SYSTEMD_AUTO_ENABLE>`__ to "disable". 2516:term:`SYSTEMD_AUTO_ENABLE` to "disable".
2517 2517
2518For more information on ``systemd``, see the "`Selecting an 2518For more information on ``systemd``, see the "`Selecting an
2519Initialization 2519Initialization
@@ -2539,14 +2539,14 @@ internal class and is not intended to be used directly.
2539 systemd 2539 systemd
2540 project. 2540 project.
2541 2541
2542Set the ```EFI_PROVIDER`` <#var-EFI_PROVIDER>`__ variable to 2542Set the :term:`EFI_PROVIDER` variable to
2543"systemd-boot" to use this class. Doing so creates a standalone EFI 2543"systemd-boot" to use this class. Doing so creates a standalone EFI
2544bootloader that is not dependent on systemd. 2544bootloader that is not dependent on systemd.
2545 2545
2546For information on more variables used and supported in this class, see 2546For information on more variables used and supported in this class, see
2547the ```SYSTEMD_BOOT_CFG`` <#var-SYSTEMD_BOOT_CFG>`__, 2547the :term:`SYSTEMD_BOOT_CFG`,
2548```SYSTEMD_BOOT_ENTRIES`` <#var-SYSTEMD_BOOT_ENTRIES>`__, and 2548:term:`SYSTEMD_BOOT_ENTRIES`, and
2549```SYSTEMD_BOOT_TIMEOUT`` <#var-SYSTEMD_BOOT_TIMEOUT>`__ variables. 2549:term:`SYSTEMD_BOOT_TIMEOUT` variables.
2550 2550
2551You can also see the `Systemd-boot 2551You can also see the `Systemd-boot
2552documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__ 2552documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__
@@ -2558,15 +2558,15 @@ for more information.
2558==================== 2558====================
2559 2559
2560The ``terminal`` class provides support for starting a terminal session. 2560The ``terminal`` class provides support for starting a terminal session.
2561The ```OE_TERMINAL`` <#var-OE_TERMINAL>`__ variable controls which 2561The :term:`OE_TERMINAL` variable controls which
2562terminal emulator is used for the session. 2562terminal emulator is used for the session.
2563 2563
2564Other classes use the ``terminal`` class anywhere a separate terminal 2564Other classes use the ``terminal`` class anywhere a separate terminal
2565session needs to be started. For example, the 2565session needs to be started. For example, the
2566```patch`` <#ref-classes-patch>`__ class assuming 2566:ref:`patch <ref-classes-patch>` class assuming
2567```PATCHRESOLVE`` <#var-PATCHRESOLVE>`__ is set to "user", the 2567:term:`PATCHRESOLVE` is set to "user", the
2568```cml1`` <#ref-classes-cml1>`__ class, and the 2568```cml1`` <#ref-classes-cml1>`__ class, and the
2569```devshell`` <#ref-classes-devshell>`__ class all use the ``terminal`` 2569:ref:`devshell <ref-classes-devshell>` class all use the ``terminal``
2570class. 2570class.
2571 2571
2572.. _ref-classes-testimage*: 2572.. _ref-classes-testimage*:
@@ -2595,7 +2595,7 @@ test is written in Python and makes use of the ``unittest`` module.
2595The ``testimage.bbclass`` runs tests on an image when called using the 2595The ``testimage.bbclass`` runs tests on an image when called using the
2596following: $ bitbake -c testimage image The ``testimage-auto`` class 2596following: $ bitbake -c testimage image The ``testimage-auto`` class
2597runs tests on an image after the image is constructed (i.e. 2597runs tests on an image after the image is constructed (i.e.
2598```TESTIMAGE_AUTO`` <#var-TESTIMAGE_AUTO>`__ must be set to "1"). 2598:term:`TESTIMAGE_AUTO` must be set to "1").
2599 2599
2600For information on how to enable, run, and create new tests, see the 2600For information on how to enable, run, and create new tests, see the
2601"`Performing Automated Runtime 2601"`Performing Automated Runtime
@@ -2693,8 +2693,8 @@ The ``uboot-config`` class provides support for U-Boot configuration for
2693a machine. Specify the machine in your recipe as follows: UBOOT_CONFIG 2693a machine. Specify the machine in your recipe as follows: UBOOT_CONFIG
2694??= <default> UBOOT_CONFIG[foo] = "config,images" You can also specify 2694??= <default> UBOOT_CONFIG[foo] = "config,images" You can also specify
2695the machine using this method: UBOOT_MACHINE = "config" See the 2695the machine using this method: UBOOT_MACHINE = "config" See the
2696```UBOOT_CONFIG`` <#var-UBOOT_CONFIG>`__ and 2696:term:`UBOOT_CONFIG` and
2697```UBOOT_MACHINE`` <#var-UBOOT_MACHINE>`__ variables for additional 2697:term:`UBOOT_MACHINE` variables for additional
2698information. 2698information.
2699 2699
2700.. _ref-classes-uninative: 2700.. _ref-classes-uninative:
@@ -2738,13 +2738,13 @@ packages.
2738 2738
2739To use this class, you need to define a number of variables: 2739To use this class, you need to define a number of variables:
2740 2740
2741- ```ALTERNATIVE`` <#var-ALTERNATIVE>`__ 2741- :term:`ALTERNATIVE`
2742 2742
2743- ```ALTERNATIVE_LINK_NAME`` <#var-ALTERNATIVE_LINK_NAME>`__ 2743- :term:`ALTERNATIVE_LINK_NAME`
2744 2744
2745- ```ALTERNATIVE_TARGET`` <#var-ALTERNATIVE_TARGET>`__ 2745- :term:`ALTERNATIVE_TARGET`
2746 2746
2747- ```ALTERNATIVE_PRIORITY`` <#var-ALTERNATIVE_PRIORITY>`__ 2747- :term:`ALTERNATIVE_PRIORITY`
2748 2748
2749These variables list alternative commands needed by a package, provide 2749These variables list alternative commands needed by a package, provide
2750pathnames for links, default links for targets, and so forth. For 2750pathnames for links, default links for targets, and so forth. For
@@ -2783,7 +2783,7 @@ usage by the package on the target. For example, if you have packages
2783that contain system services that should be run under their own user or 2783that contain system services that should be run under their own user or
2784group, you can use these classes to enable creation of the user or 2784group, you can use these classes to enable creation of the user or
2785group. The ``meta-skeleton/recipes-skeleton/useradd/useradd-example.bb`` 2785group. The ``meta-skeleton/recipes-skeleton/useradd/useradd-example.bb``
2786recipe in the `Source Directory <#source-directory>`__ provides a simple 2786recipe in the :term:`Source Directory` provides a simple
2787example that shows how to add three users and groups to two packages. 2787example that shows how to add three users and groups to two packages.
2788See the ``useradd-example.bb`` recipe for more information on how to use 2788See the ``useradd-example.bb`` recipe for more information on how to use
2789these classes. 2789these classes.
@@ -2792,10 +2792,10 @@ The ``useradd_base`` class provides basic functionality for user or
2792groups settings. 2792groups settings.
2793 2793
2794The ``useradd*`` classes support the 2794The ``useradd*`` classes support the
2795```USERADD_PACKAGES`` <#var-USERADD_PACKAGES>`__, 2795:term:`USERADD_PACKAGES`,
2796```USERADD_PARAM`` <#var-USERADD_PARAM>`__, 2796:term:`USERADD_PARAM`,
2797```GROUPADD_PARAM`` <#var-GROUPADD_PARAM>`__, and 2797:term:`GROUPADD_PARAM`, and
2798```GROUPMEMS_PARAM`` <#var-GROUPMEMS_PARAM>`__ variables. 2798:term:`GROUPMEMS_PARAM` variables.
2799 2799
2800The ``useradd-staticids`` class supports the addition of users or groups 2800The ``useradd-staticids`` class supports the addition of users or groups
2801that have static user identification (``uid``) and group identification 2801that have static user identification (``uid``) and group identification
@@ -2810,15 +2810,15 @@ the final ``uid`` and ``gid`` values. However, if non-deterministic
2810``uid`` and ``gid`` values are a problem, you can override the default, 2810``uid`` and ``gid`` values are a problem, you can override the default,
2811dynamic application of these values by setting static values. When you 2811dynamic application of these values by setting static values. When you
2812set static values, the OpenEmbedded build system looks in 2812set static values, the OpenEmbedded build system looks in
2813```BBPATH`` <#var-BBPATH>`__ for ``files/passwd`` and ``files/group`` 2813:term:`BBPATH` for ``files/passwd`` and ``files/group``
2814files for the values. 2814files for the values.
2815 2815
2816To use static ``uid`` and ``gid`` values, you need to set some 2816To use static ``uid`` and ``gid`` values, you need to set some
2817variables. See the ```USERADDEXTENSION`` <#var-USERADDEXTENSION>`__, 2817variables. See the :term:`USERADDEXTENSION`,
2818```USERADD_UID_TABLES`` <#var-USERADD_UID_TABLES>`__, 2818:term:`USERADD_UID_TABLES`,
2819```USERADD_GID_TABLES`` <#var-USERADD_GID_TABLES>`__, and 2819:term:`USERADD_GID_TABLES`, and
2820```USERADD_ERROR_DYNAMIC`` <#var-USERADD_ERROR_DYNAMIC>`__ variables. 2820:term:`USERADD_ERROR_DYNAMIC` variables.
2821You can also see the ```useradd`` <#ref-classes-useradd>`__ class for 2821You can also see the :ref:`useradd <ref-classes-useradd>` class for
2822additional information. 2822additional information.
2823 2823
2824.. note:: 2824.. note::
@@ -2844,11 +2844,11 @@ additional information.
2844 2844
2845The ``utility-tasks`` class provides support for various "utility" type 2845The ``utility-tasks`` class provides support for various "utility" type
2846tasks that are applicable to all recipes, such as 2846tasks that are applicable to all recipes, such as
2847```do_clean`` <#ref-tasks-clean>`__ and 2847:ref:`ref-tasks-clean` and
2848```do_listtasks`` <#ref-tasks-listtasks>`__. 2848:ref:`ref-tasks-listtasks`.
2849 2849
2850This class is enabled by default because it is inherited by the 2850This class is enabled by default because it is inherited by the
2851```base`` <#ref-classes-base>`__ class. 2851:ref:`base <ref-classes-base>` class.
2852 2852
2853.. _ref-classes-utils: 2853.. _ref-classes-utils:
2854 2854
@@ -2860,7 +2860,7 @@ typically used in inline Python expressions (e.g. ``${@...}``). One
2860example use is for ``bb.utils.contains()``. 2860example use is for ``bb.utils.contains()``.
2861 2861
2862This class is enabled by default because it is inherited by the 2862This class is enabled by default because it is inherited by the
2863```base`` <#ref-classes-base>`__ class. 2863:ref:`base <ref-classes-base>` class.
2864 2864
2865.. _ref-classes-vala: 2865.. _ref-classes-vala:
2866 2866
@@ -2877,7 +2877,7 @@ using the Vala programming language.
2877 2877
2878The ``waf`` class supports recipes that need to build software that uses 2878The ``waf`` class supports recipes that need to build software that uses
2879the Waf build system. You can use the 2879the Waf build system. You can use the
2880```EXTRA_OECONF`` <#var-EXTRA_OECONF>`__ or 2880:term:`EXTRA_OECONF` or
2881```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__ variables 2881:term:`PACKAGECONFIG_CONFARGS` variables
2882to specify additional configuration options to be passed on the Waf 2882to specify additional configuration options to be passed on the Waf
2883command line. 2883command line.
diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst
index 5bb1a64d99..b0c4bcc7a0 100644
--- a/documentation/ref-manual/ref-devtool-reference.rst
+++ b/documentation/ref-manual/ref-devtool-reference.rst
@@ -217,7 +217,7 @@ Git, checks out a branch for development, and applies any patches from
217the recipe as commits on top. You can use the following command to 217the recipe as commits on top. You can use the following command to
218checkout the source files: $ devtool modify recipe Using the above 218checkout the source files: $ devtool modify recipe Using the above
219command form, ``devtool`` uses the existing recipe's 219command form, ``devtool`` uses the existing recipe's
220```SRC_URI`` <#var-SRC_URI>`__ statement to locate the upstream source, 220:term:`SRC_URI` statement to locate the upstream source,
221extracts the source into the default sources location in the workspace. 221extracts the source into the default sources location in the workspace.
222The default development branch used is "devtool". 222The default development branch used is "devtool".
223 223
@@ -360,9 +360,9 @@ When you use the ``devtool upgrade`` command, you must supply the root
360name of the recipe (i.e. no version, paths, or extensions), and you must 360name of the recipe (i.e. no version, paths, or extensions), and you must
361supply the directory to which you want the source extracted. Additional 361supply the directory to which you want the source extracted. Additional
362command options let you control things such as the version number to 362command options let you control things such as the version number to
363which you want to upgrade (i.e. the ```PV`` <#var-PV>`__), the source 363which you want to upgrade (i.e. the :term:`PV`), the source
364revision to which you want to upgrade (i.e. the 364revision to which you want to upgrade (i.e. the
365```SRCREV`` <#var-SRCREV>`__), whether or not to apply patches, and so 365:term:`SRCREV`), whether or not to apply patches, and so
366forth. 366forth.
367 367
368You can read more on the ``devtool upgrade`` workflow in the "`Use 368You can read more on the ``devtool upgrade`` workflow in the "`Use
@@ -439,7 +439,7 @@ The target is the address of the target machine, which must be running
439an SSH server (i.e. ``user@hostname[:destdir]``). 439an SSH server (i.e. ``user@hostname[:destdir]``).
440 440
441This command deploys all files installed during the 441This command deploys all files installed during the
442```do_install`` <#ref-tasks-install>`__ task. Furthermore, you do not 442:ref:`ref-tasks-install` task. Furthermore, you do not
443need to have package management enabled within the target machine. If 443need to have package management enabled within the target machine. If
444you do, the package manager is bypassed. 444you do, the package manager is bypassed.
445 445
@@ -492,7 +492,7 @@ Creating the Workspace Layer in an Alternative Location
492======================================================= 492=======================================================
493 493
494Use the ``devtool create-workspace`` command to create a new workspace 494Use the ``devtool create-workspace`` command to create a new workspace
495layer in your `Build Directory <#build-directory>`__. When you create a 495layer in your :term:`Build Directory`. When you create a
496new workspace layer, it is populated with the ``README`` file and the 496new workspace layer, it is populated with the ``README`` file and the
497``conf`` directory only. 497``conf`` directory only.
498 498
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst
index 1aa57a27d4..0e901edaeb 100644
--- a/documentation/ref-manual/ref-features.rst
+++ b/documentation/ref-manual/ref-features.rst
@@ -24,7 +24,7 @@ included if the distribution itself does not support them.
24 24
25One method you can use to determine which recipes are checking to see if 25One method you can use to determine which recipes are checking to see if
26a particular feature is contained or not is to ``grep`` through the 26a particular feature is contained or not is to ``grep`` through the
27`Metadata <#metadata>`__ for the feature. Here is an example that 27:term:`Metadata` for the feature. Here is an example that
28discovers the recipes whose build is potentially changed based on a 28discovers the recipes whose build is potentially changed based on a
29given feature: $ cd poky $ git grep 29given feature: $ cd poky $ git grep
30'contains.*MACHINE_FEATURES.*feature' 30'contains.*MACHINE_FEATURES.*feature'
@@ -35,12 +35,12 @@ Machine Features
35================ 35================
36 36
37The items below are features you can use with 37The items below are features you can use with
38```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__. Features do not have a 38:term:`MACHINE_FEATURES`. Features do not have a
39one-to-one correspondence to packages, and they can go beyond simply 39one-to-one correspondence to packages, and they can go beyond simply
40controlling the installation of a package or packages. Sometimes a 40controlling the installation of a package or packages. Sometimes a
41feature can influence how certain recipes are built. For example, a 41feature can influence how certain recipes are built. For example, a
42feature might determine whether a particular configure option is 42feature might determine whether a particular configure option is
43specified within the ```do_configure`` <#ref-tasks-configure>`__ task 43specified within the :ref:`ref-tasks-configure` task
44for a particular recipe. 44for a particular recipe.
45 45
46This feature list only represents features as shipped with the Yocto 46This feature list only represents features as shipped with the Yocto
@@ -92,18 +92,18 @@ Distro Features
92=============== 92===============
93 93
94The items below are features you can use with 94The items below are features you can use with
95```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ to enable features across 95:term:`DISTRO_FEATURES` to enable features across
96your distribution. Features do not have a one-to-one correspondence to 96your distribution. Features do not have a one-to-one correspondence to
97packages, and they can go beyond simply controlling the installation of 97packages, and they can go beyond simply controlling the installation of
98a package or packages. In most cases, the presence or absence of a 98a package or packages. In most cases, the presence or absence of a
99feature translates to the appropriate option supplied to the configure 99feature translates to the appropriate option supplied to the configure
100script during the ```do_configure`` <#ref-tasks-configure>`__ task for 100script during the :ref:`ref-tasks-configure` task for
101the recipes that optionally support the feature. 101the recipes that optionally support the feature.
102 102
103Some distro features are also machine features. These select features 103Some distro features are also machine features. These select features
104make sense to be controlled both at the machine and distribution 104make sense to be controlled both at the machine and distribution
105configuration level. See the 105configuration level. See the
106```COMBINED_FEATURES`` <#var-COMBINED_FEATURES>`__ variable for more 106:term:`COMBINED_FEATURES` variable for more
107information. 107information.
108 108
109This list only represents features as shipped with the Yocto Project 109This list only represents features as shipped with the Yocto Project
@@ -189,8 +189,8 @@ Image Features
189============== 189==============
190 190
191The contents of images generated by the OpenEmbedded build system can be 191The contents of images generated by the OpenEmbedded build system can be
192controlled by the ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ and 192controlled by the :term:`IMAGE_FEATURES` and
193```EXTRA_IMAGE_FEATURES`` <#var-EXTRA_IMAGE_FEATURES>`__ variables that 193:term:`EXTRA_IMAGE_FEATURES` variables that
194you typically configure in your image recipes. Through these variables, 194you typically configure in your image recipes. Through these variables,
195you can add several different predefined packages such as development 195you can add several different predefined packages such as development
196utilities or packages with debug information needed to investigate 196utilities or packages with debug information needed to investigate
@@ -254,7 +254,7 @@ The following image features are available for all images:
254 a given image. 254 a given image.
255 255
256Some image features are available only when you inherit the 256Some image features are available only when you inherit the
257```core-image`` <#ref-classes-core-image>`__ class. The current list of 257:ref:`core-image <ref-classes-core-image>` class. The current list of
258these valid features is as follows: 258these valid features is as follows:
259 259
260- *hwcodecs:* Installs hardware acceleration codecs. 260- *hwcodecs:* Installs hardware acceleration codecs.
@@ -299,8 +299,8 @@ Feature Backfilling
299=================== 299===================
300 300
301Sometimes it is necessary in the OpenEmbedded build system to extend 301Sometimes it is necessary in the OpenEmbedded build system to extend
302```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__ or 302:term:`MACHINE_FEATURES` or
303```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ to control functionality 303:term:`DISTRO_FEATURES` to control functionality
304that was previously enabled and not able to be disabled. For these 304that was previously enabled and not able to be disabled. For these
305cases, we need to add an additional feature item to appear in one of 305cases, we need to add an additional feature item to appear in one of
306these variables, but we do not want to force developers who have 306these variables, but we do not want to force developers who have
@@ -310,8 +310,8 @@ Thus, the OpenEmbedded build system has a mechanism to automatically
310"backfill" these added features into existing distro or machine 310"backfill" these added features into existing distro or machine
311configurations. You can see the list of features for which this is done 311configurations. You can see the list of features for which this is done
312by finding the 312by finding the
313```DISTRO_FEATURES_BACKFILL`` <#var-DISTRO_FEATURES_BACKFILL>`__ and 313:term:`DISTRO_FEATURES_BACKFILL` and
314```MACHINE_FEATURES_BACKFILL`` <#var-MACHINE_FEATURES_BACKFILL>`__ 314:term:`MACHINE_FEATURES_BACKFILL`
315variables in the ``meta/conf/bitbake.conf`` file. 315variables in the ``meta/conf/bitbake.conf`` file.
316 316
317Because such features are backfilled by default into all configurations 317Because such features are backfilled by default into all configurations
@@ -319,9 +319,9 @@ as described in the previous paragraph, developers who wish to disable
319the new features need to be able to selectively prevent the backfilling 319the new features need to be able to selectively prevent the backfilling
320from occurring. They can do this by adding the undesired feature or 320from occurring. They can do this by adding the undesired feature or
321features to the 321features to the
322```DISTRO_FEATURES_BACKFILL_CONSIDERED`` <#var-DISTRO_FEATURES_BACKFILL_CONSIDERED>`__ 322:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
323or 323or
324```MACHINE_FEATURES_BACKFILL_CONSIDERED`` <#var-MACHINE_FEATURES_BACKFILL_CONSIDERED>`__ 324:term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
325variables for distro features and machine features respectively. 325variables for distro features and machine features respectively.
326 326
327Here are two examples to help illustrate feature backfilling: 327Here are two examples to help illustrate feature backfilling:
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst
index f0f8398338..5aeaa43833 100644
--- a/documentation/ref-manual/ref-images.rst
+++ b/documentation/ref-manual/ref-images.rst
@@ -86,7 +86,7 @@ Following is a list of supported recipes:
86 has the Minimal RAM-based Initial Root Filesystem (initramfs) as part 86 has the Minimal RAM-based Initial Root Filesystem (initramfs) as part
87 of the kernel, which allows the system to find the first “init” 87 of the kernel, which allows the system to find the first “init”
88 program more efficiently. See the 88 program more efficiently. See the
89 ```PACKAGE_INSTALL`` <#var-PACKAGE_INSTALL>`__ variable for 89 :term:`PACKAGE_INSTALL` variable for
90 additional information helpful when working with initramfs images. 90 additional information helpful when working with initramfs images.
91 91
92- ``core-image-minimal-mtdutils``: A ``core-image-minimal`` image that 92- ``core-image-minimal-mtdutils``: A ``core-image-minimal`` image that
diff --git a/documentation/ref-manual/ref-kickstart.rst b/documentation/ref-manual/ref-kickstart.rst
index 599e38080c..5f8c834f33 100644
--- a/documentation/ref-manual/ref-kickstart.rst
+++ b/documentation/ref-manual/ref-kickstart.rst
@@ -167,7 +167,7 @@ the ``part`` and ``partition`` commands:
167 167
168- *``--fsuuid``:* This option is a Wic-specific option that specifies 168- *``--fsuuid``:* This option is a Wic-specific option that specifies
169 the filesystem UUID. You can generate or modify 169 the filesystem UUID. You can generate or modify
170 ```WKS_FILE`` <#var-WKS_FILE>`__ with this option if a preconfigured 170 :term:`WKS_FILE` with this option if a preconfigured
171 filesystem UUID is added to the kernel command line in the bootloader 171 filesystem UUID is added to the kernel command line in the bootloader
172 configuration before you run Wic. 172 configuration before you run Wic.
173 173
diff --git a/documentation/ref-manual/ref-qa-checks.rst b/documentation/ref-manual/ref-qa-checks.rst
index e83fad8e10..d60c0616f0 100644
--- a/documentation/ref-manual/ref-qa-checks.rst
+++ b/documentation/ref-manual/ref-qa-checks.rst
@@ -28,7 +28,7 @@ error form along with an explanation.
28.. note:: 28.. note::
29 29
30 - At the end of each message, the name of the associated QA test (as 30 - At the end of each message, the name of the associated QA test (as
31 listed in the "```insane.bbclass`` <#ref-classes-insane>`__" 31 listed in the ":ref:`insane.bbclass <ref-classes-insane>`"
32 section) appears within square brackets. 32 section) appears within square brackets.
33 33
34 - As mentioned, this list of error and warning messages is for QA 34 - As mentioned, this list of error and warning messages is for QA
@@ -56,10 +56,10 @@ Errors and Warnings
56 56
57 The specified binary produced by the recipe contains dynamic library 57 The specified binary produced by the recipe contains dynamic library
58 load paths (rpaths) that contain build system paths such as 58 load paths (rpaths) that contain build system paths such as
59 ```TMPDIR`` <#var-TMPDIR>`__, which are incorrect for the target and 59 :term:`TMPDIR`, which are incorrect for the target and
60 could potentially be a security issue. Check for bad ``-rpath`` 60 could potentially be a security issue. Check for bad ``-rpath``
61 options being passed to the linker in your 61 options being passed to the linker in your
62 ```do_compile`` <#ref-tasks-compile>`__ log. Depending on the build 62 :ref:`ref-tasks-compile` log. Depending on the build
63 system used by the software being built, there might be a configure 63 system used by the software being built, there might be a configure
64 option to disable rpath usage completely within the build of the 64 option to disable rpath usage completely within the build of the
65 software. 65 software.
@@ -82,7 +82,7 @@ Errors and Warnings
82 82
83 A file-level dependency has been identified from the specified 83 A file-level dependency has been identified from the specified
84 package on the specified files, but there is no explicit 84 package on the specified files, but there is no explicit
85 corresponding entry in ```RDEPENDS`` <#var-RDEPENDS>`__. If 85 corresponding entry in :term:`RDEPENDS`. If
86 particular files are required at runtime then ``RDEPENDS`` should be 86 particular files are required at runtime then ``RDEPENDS`` should be
87 declared in the recipe to ensure the packages providing them are 87 declared in the recipe to ensure the packages providing them are
88 built. 88 built.
@@ -95,7 +95,7 @@ Errors and Warnings
95 there is nothing explicit within the recipe to enable the 95 there is nothing explicit within the recipe to enable the
96 OpenEmbedded build system to ensure that dependency is satisfied. 96 OpenEmbedded build system to ensure that dependency is satisfied.
97 This condition is usually triggered by an 97 This condition is usually triggered by an
98 ```RDEPENDS`` <#var-RDEPENDS>`__ value being added at the packaging 98 :term:`RDEPENDS` value being added at the packaging
99 stage rather than up front, which is usually automatic based on the 99 stage rather than up front, which is usually automatic based on the
100 contents of the package. In most cases, you should change the recipe 100 contents of the package. In most cases, you should change the recipe
101 to add an explicit ``RDEPENDS`` for the dependency. 101 to add an explicit ``RDEPENDS`` for the dependency.
@@ -107,8 +107,8 @@ Errors and Warnings
107 Symlink ``.so`` files are for development only, and should therefore 107 Symlink ``.so`` files are for development only, and should therefore
108 go into the ``-dev`` package. This situation might occur if you add 108 go into the ``-dev`` package. This situation might occur if you add
109 ``*.so*`` rather than ``*.so.*`` to a non-dev package. Change 109 ``*.so*`` rather than ``*.so.*`` to a non-dev package. Change
110 ```FILES`` <#var-FILES>`__ (and possibly 110 :term:`FILES` (and possibly
111 ```PACKAGES`` <#var-PACKAGES>`__) such that the specified ``.so`` 111 :term:`PACKAGES`) such that the specified ``.so``
112 file goes into an appropriate ``-dev`` package. 112 file goes into an appropriate ``-dev`` package.
113 113
114   114  
@@ -116,8 +116,8 @@ Errors and Warnings
116- ``non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]`` 116- ``non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]``
117 117
118 Static ``.a`` library files should go into a ``-staticdev`` package. 118 Static ``.a`` library files should go into a ``-staticdev`` package.
119 Change ```FILES`` <#var-FILES>`__ (and possibly 119 Change :term:`FILES` (and possibly
120 ```PACKAGES`` <#var-PACKAGES>`__) such that the specified ``.a`` file 120 :term:`PACKAGES`) such that the specified ``.a`` file
121 goes into an appropriate ``-staticdev`` package. 121 goes into an appropriate ``-staticdev`` package.
122 122
123   123  
@@ -130,7 +130,7 @@ Errors and Warnings
130 "lib32". Another example is when recipes install 130 "lib32". Another example is when recipes install
131 ``/usr/lib64/foo.so`` when ``${libdir}`` is "/usr/lib". False 131 ``/usr/lib64/foo.so`` when ``${libdir}`` is "/usr/lib". False
132 positives occasionally exist. For these cases add "libdir" to 132 positives occasionally exist. For these cases add "libdir" to
133 ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. 133 :term:`INSANE_SKIP` for the package.
134 134
135   135  
136 136
@@ -141,7 +141,7 @@ Errors and Warnings
141 occur if you add a path which contains a ``.debug`` directory and do 141 occur if you add a path which contains a ``.debug`` directory and do
142 not explicitly add the ``.debug`` directory to the ``-dbg`` package. 142 not explicitly add the ``.debug`` directory to the ``-dbg`` package.
143 If this is the case, add the ``.debug`` directory explicitly to 143 If this is the case, add the ``.debug`` directory explicitly to
144 ``FILES_${PN}-dbg``. See ```FILES`` <#var-FILES>`__ for additional 144 ``FILES_${PN}-dbg``. See :term:`FILES` for additional
145 information on ``FILES``. 145 information on ``FILES``.
146 146
147   147  
@@ -158,8 +158,8 @@ Errors and Warnings
158 the error for is firmware that is not intended to be executed within 158 the error for is firmware that is not intended to be executed within
159 the target operating system or is intended to run on a separate 159 the target operating system or is intended to run on a separate
160 processor within the device, you can add "arch" to 160 processor within the device, you can add "arch" to
161 ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. Another 161 :term:`INSANE_SKIP` for the package. Another
162 option is to check the ```do_compile`` <#ref-tasks-compile>`__ log 162 option is to check the :ref:`ref-tasks-compile` log
163 and verify that the compiler options being used are correct. 163 and verify that the compiler options being used are correct.
164 164
165   165  
@@ -176,8 +176,8 @@ Errors and Warnings
176 the error for is firmware that is not intended to be executed within 176 the error for is firmware that is not intended to be executed within
177 the target operating system or is intended to run on a separate 177 the target operating system or is intended to run on a separate
178 processor within the device, you can add "arch" to 178 processor within the device, you can add "arch" to
179 ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. Another 179 :term:`INSANE_SKIP` for the package. Another
180 option is to check the ```do_compile`` <#ref-tasks-compile>`__ log 180 option is to check the :ref:`ref-tasks-compile` log
181 and verify that the compiler options being used are correct. 181 and verify that the compiler options being used are correct.
182 182
183   183  
@@ -194,8 +194,8 @@ Errors and Warnings
194 the error for is firmware that is not intended to be executed within 194 the error for is firmware that is not intended to be executed within
195 the target operating system or is intended to run on a separate 195 the target operating system or is intended to run on a separate
196 processor within the device, you can add "arch" to 196 processor within the device, you can add "arch" to
197 ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. Another 197 :term:`INSANE_SKIP` for the package. Another
198 option is to check the ```do_compile`` <#ref-tasks-compile>`__ log 198 option is to check the :ref:`ref-tasks-compile` log
199 and verify that the compiler options being used are correct. 199 and verify that the compiler options being used are correct.
200 200
201   201  
@@ -208,7 +208,7 @@ Errors and Warnings
208 208
209 Typically, the way to solve this performance issue is to add "-fPIC" 209 Typically, the way to solve this performance issue is to add "-fPIC"
210 or "-fpic" to the compiler command-line options. For example, given 210 or "-fpic" to the compiler command-line options. For example, given
211 software that reads ```CFLAGS`` <#var-CFLAGS>`__ when you build it, 211 software that reads :term:`CFLAGS` when you build it,
212 you could add the following to your recipe: CFLAGS_append = " -fPIC " 212 you could add the following to your recipe: CFLAGS_append = " -fPIC "
213 213
214 For more information on text relocations at runtime, see 214 For more information on text relocations at runtime, see
@@ -219,11 +219,11 @@ Errors and Warnings
219- ``No GNU_HASH in the elf binary: '<file>' [ldflags]`` 219- ``No GNU_HASH in the elf binary: '<file>' [ldflags]``
220 220
221 This indicates that binaries produced when building the recipe have 221 This indicates that binaries produced when building the recipe have
222 not been linked with the ```LDFLAGS`` <#var-LDFLAGS>`__ options 222 not been linked with the :term:`LDFLAGS` options
223 provided by the build system. Check to be sure that the ``LDFLAGS`` 223 provided by the build system. Check to be sure that the ``LDFLAGS``
224 variable is being passed to the linker command. A common workaround 224 variable is being passed to the linker command. A common workaround
225 for this situation is to pass in ``LDFLAGS`` using 225 for this situation is to pass in ``LDFLAGS`` using
226 ```TARGET_CC_ARCH`` <#var-TARGET_CC_ARCH>`__ within the recipe as 226 :term:`TARGET_CC_ARCH` within the recipe as
227 follows: TARGET_CC_ARCH += "${LDFLAGS}" 227 follows: TARGET_CC_ARCH += "${LDFLAGS}"
228 228
229   229  
@@ -243,7 +243,7 @@ Errors and Warnings
243- ``The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]`` 243- ``The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]``
244 244
245 The ``/usr/share/info/dir`` should not be packaged. Add the following 245 The ``/usr/share/info/dir`` should not be packaged. Add the following
246 line to your ```do_install`` <#ref-tasks-install>`__ task or to your 246 line to your :ref:`ref-tasks-install` task or to your
247 ``do_install_append`` within the recipe as follows: rm 247 ``do_install_append`` within the recipe as follows: rm
248 ${D}${infodir}/dir 248 ${D}${infodir}/dir
249 249
@@ -251,7 +251,7 @@ Errors and Warnings
251 251
252- ``Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]`` 252- ``Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]``
253 253
254 The specified symlink points into ```TMPDIR`` <#var-TMPDIR>`__ on the 254 The specified symlink points into :term:`TMPDIR` on the
255 host. Such symlinks will work on the host. However, they are clearly 255 host. Such symlinks will work on the host. However, they are clearly
256 invalid when running on the target. You should either correct the 256 invalid when running on the target. You should either correct the
257 symlink to use a relative path or remove the symlink. 257 symlink to use a relative path or remove the symlink.
@@ -260,7 +260,7 @@ Errors and Warnings
260 260
261- ``<file> failed sanity test (workdir) in path <path> [la]`` 261- ``<file> failed sanity test (workdir) in path <path> [la]``
262 262
263 The specified ``.la`` file contains ```TMPDIR`` <#var-TMPDIR>`__ 263 The specified ``.la`` file contains :term:`TMPDIR`
264 paths. Any ``.la`` file containing these paths is incorrect since 264 paths. Any ``.la`` file containing these paths is incorrect since
265 ``libtool`` adds the correct sysroot prefix when using the files 265 ``libtool`` adds the correct sysroot prefix when using the files
266 automatically itself. 266 automatically itself.
@@ -270,7 +270,7 @@ Errors and Warnings
270- ``<file> failed sanity test (tmpdir) in path <path> [pkgconfig]`` 270- ``<file> failed sanity test (tmpdir) in path <path> [pkgconfig]``
271 271
272 The specified ``.pc`` file contains 272 The specified ``.pc`` file contains
273 ```TMPDIR`` <#var-TMPDIR>`__\ ``/``\ ```WORKDIR`` <#var-WORKDIR>`__ 273 :term:`TMPDIR`\ ``/``\ :term:`WORKDIR`
274 paths. Any ``.pc`` file containing these paths is incorrect since 274 paths. Any ``.pc`` file containing these paths is incorrect since
275 ``pkg-config`` itself adds the correct sysroot prefix when the files 275 ``pkg-config`` itself adds the correct sysroot prefix when the files
276 are accessed. 276 are accessed.
@@ -285,9 +285,9 @@ Errors and Warnings
285 brought in using several different methods: 285 brought in using several different methods:
286 286
287 - Using the ``dbg-pkgs`` 287 - Using the ``dbg-pkgs``
288 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ value. 288 :term:`IMAGE_FEATURES` value.
289 289
290 - Using ```IMAGE_INSTALL`` <#var-IMAGE_INSTALL>`__. 290 - Using :term:`IMAGE_INSTALL`.
291 291
292 - As a dependency of another ``dbg`` package that was brought in 292 - As a dependency of another ``dbg`` package that was brought in
293 using one of the above methods. 293 using one of the above methods.
@@ -295,7 +295,7 @@ Errors and Warnings
295 The dependency might have been automatically added because the 295 The dependency might have been automatically added because the
296 ``dbg`` package erroneously contains files that it should not contain 296 ``dbg`` package erroneously contains files that it should not contain
297 (e.g. a non-symlink ``.so`` file) or it might have been added 297 (e.g. a non-symlink ``.so`` file) or it might have been added
298 manually (e.g. by adding to ```RDEPENDS`` <#var-RDEPENDS>`__). 298 manually (e.g. by adding to :term:`RDEPENDS`).
299 299
300   300  
301 301
@@ -307,9 +307,9 @@ Errors and Warnings
307 usually brought in using several different methods: 307 usually brought in using several different methods:
308 308
309 - Using the ``dev-pkgs`` 309 - Using the ``dev-pkgs``
310 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ value. 310 :term:`IMAGE_FEATURES` value.
311 311
312 - Using ```IMAGE_INSTALL`` <#var-IMAGE_INSTALL>`__. 312 - Using :term:`IMAGE_INSTALL`.
313 313
314 - As a dependency of another ``dev`` package that was brought in 314 - As a dependency of another ``dev`` package that was brought in
315 using one of the above methods. 315 using one of the above methods.
@@ -317,19 +317,19 @@ Errors and Warnings
317 The dependency might have been automatically added (because the 317 The dependency might have been automatically added (because the
318 ``dev`` package erroneously contains files that it should not have 318 ``dev`` package erroneously contains files that it should not have
319 (e.g. a non-symlink ``.so`` file) or it might have been added 319 (e.g. a non-symlink ``.so`` file) or it might have been added
320 manually (e.g. by adding to ```RDEPENDS`` <#var-RDEPENDS>`__). 320 manually (e.g. by adding to :term:`RDEPENDS`).
321 321
322   322  
323 323
324- ``<var>_<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp]`` 324- ``<var>_<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
325 325
326 If you are adding a versioned dependency relationship to one of the 326 If you are adding a versioned dependency relationship to one of the
327 dependency variables (```RDEPENDS`` <#var-RDEPENDS>`__, 327 dependency variables (:term:`RDEPENDS`,
328 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, 328 :term:`RRECOMMENDS`,
329 ```RSUGGESTS`` <#var-RSUGGESTS>`__, 329 :term:`RSUGGESTS`,
330 ```RPROVIDES`` <#var-RPROVIDES>`__, 330 :term:`RPROVIDES`,
331 ```RREPLACES`` <#var-RREPLACES>`__, or 331 :term:`RREPLACES`, or
332 ```RCONFLICTS`` <#var-RCONFLICTS>`__), you must only use the named 332 :term:`RCONFLICTS`), you must only use the named
333 comparison operators. Change the versioned dependency values you are 333 comparison operators. Change the versioned dependency values you are
334 adding to match those listed in the message. 334 adding to match those listed in the message.
335 335
@@ -337,7 +337,7 @@ Errors and Warnings
337 337
338- ``<recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path]`` 338- ``<recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path]``
339 339
340 The log for the ```do_compile`` <#ref-tasks-compile>`__ task 340 The log for the :ref:`ref-tasks-compile` task
341 indicates that paths on the host were searched for files, which is 341 indicates that paths on the host were searched for files, which is
342 not appropriate when cross-compiling. Look for "is unsafe for 342 not appropriate when cross-compiling. Look for "is unsafe for
343 cross-compilation" or "CROSS COMPILE Badness" in the specified log 343 cross-compilation" or "CROSS COMPILE Badness" in the specified log
@@ -347,7 +347,7 @@ Errors and Warnings
347 347
348- ``<recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path]`` 348- ``<recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path]``
349 349
350 The log for the ```do_install`` <#ref-tasks-install>`__ task 350 The log for the :ref:`ref-tasks-install` task
351 indicates that paths on the host were searched for files, which is 351 indicates that paths on the host were searched for files, which is
352 not appropriate when cross-compiling. Look for "is unsafe for 352 not appropriate when cross-compiling. Look for "is unsafe for
353 cross-compilation" or "CROSS COMPILE Badness" in the specified log 353 cross-compilation" or "CROSS COMPILE Badness" in the specified log
@@ -357,7 +357,7 @@ Errors and Warnings
357 357
358- ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>'`` 358- ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>'``
359 359
360 The log for the ```do_configure`` <#ref-tasks-configure>`__ task 360 The log for the :ref:`ref-tasks-configure` task
361 indicates that paths on the host were searched for files, which is 361 indicates that paths on the host were searched for files, which is
362 not appropriate when cross-compiling. Look for "is unsafe for 362 not appropriate when cross-compiling. Look for "is unsafe for
363 cross-compilation" or "CROSS COMPILE Badness" in the specified log 363 cross-compilation" or "CROSS COMPILE Badness" in the specified log
@@ -371,7 +371,7 @@ Errors and Warnings
371 enforced by the package manager itself) is to require that package 371 enforced by the package manager itself) is to require that package
372 names are all lower case and to allow a restricted set of characters. 372 names are all lower case and to allow a restricted set of characters.
373 If your recipe name does not match this, or you add packages to 373 If your recipe name does not match this, or you add packages to
374 ```PACKAGES`` <#var-PACKAGES>`__ that do not conform to the 374 :term:`PACKAGES` that do not conform to the
375 convention, then you will receive this error. Rename your recipe. Or, 375 convention, then you will receive this error. Rename your recipe. Or,
376 if you have added a non-conforming package name to ``PACKAGES``, 376 if you have added a non-conforming package name to ``PACKAGES``,
377 change the package name appropriately. 377 change the package name appropriately.
@@ -388,38 +388,38 @@ Errors and Warnings
388 upstream build documentation, the ``./configure --help`` output, and 388 upstream build documentation, the ``./configure --help`` output, and
389 the upstream change log or release notes. Once you have worked out 389 the upstream change log or release notes. Once you have worked out
390 what the appropriate change is, you can update 390 what the appropriate change is, you can update
391 ```EXTRA_OECONF`` <#var-EXTRA_OECONF>`__, 391 :term:`EXTRA_OECONF`,
392 ```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__, or the 392 :term:`PACKAGECONFIG_CONFARGS`, or the
393 individual ```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__ option values 393 individual :term:`PACKAGECONFIG` option values
394 accordingly. 394 accordingly.
395 395
396   396  
397 397
398- ``Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]`` 398- ``Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]``
399 399
400 The specified recipe has a name (```PN`` <#var-PN>`__) value that 400 The specified recipe has a name (:term:`PN`) value that
401 appears in ```OVERRIDES`` <#var-OVERRIDES>`__. If a recipe is named 401 appears in :term:`OVERRIDES`. If a recipe is named
402 such that its ``PN`` value matches something already in ``OVERRIDES`` 402 such that its ``PN`` value matches something already in ``OVERRIDES``
403 (e.g. ``PN`` happens to be the same as ```MACHINE`` <#var-MACHINE>`__ 403 (e.g. ``PN`` happens to be the same as :term:`MACHINE`
404 or ```DISTRO`` <#var-DISTRO>`__), it can have unexpected 404 or :term:`DISTRO`), it can have unexpected
405 consequences. For example, assignments such as 405 consequences. For example, assignments such as
406 ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. 406 ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``.
407 Rename your recipe (or if ``PN`` is being set explicitly, change the 407 Rename your recipe (or if ``PN`` is being set explicitly, change the
408 ``PN`` value) so that the conflict does not occur. See 408 ``PN`` value) so that the conflict does not occur. See
409 ```FILES`` <#var-FILES>`__ for additional information. 409 :term:`FILES` for additional information.
410 410
411   411  
412 412
413- ``<recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]`` 413- ``<recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]``
414 414
415 Certain variables (```RDEPENDS`` <#var-RDEPENDS>`__, 415 Certain variables (:term:`RDEPENDS`,
416 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, 416 :term:`RRECOMMENDS`,
417 ```RSUGGESTS`` <#var-RSUGGESTS>`__, 417 :term:`RSUGGESTS`,
418 ```RCONFLICTS`` <#var-RCONFLICTS>`__, 418 :term:`RCONFLICTS`,
419 ```RPROVIDES`` <#var-RPROVIDES>`__, 419 :term:`RPROVIDES`,
420 ```RREPLACES`` <#var-RREPLACES>`__, ```FILES`` <#var-FILES>`__, 420 :term:`RREPLACES`, :term:`FILES`,
421 ``pkg_preinst``, ``pkg_postinst``, ``pkg_prerm``, ``pkg_postrm``, and 421 ``pkg_preinst``, ``pkg_postinst``, ``pkg_prerm``, ``pkg_postrm``, and
422 ```ALLOW_EMPTY`` <#var-ALLOW_EMPTY>`__) should always be set specific 422 :term:`ALLOW_EMPTY`) should always be set specific
423 to a package (i.e. they should be set with a package name override 423 to a package (i.e. they should be set with a package name override
424 such as ``RDEPENDS_${PN} = "value"`` rather than 424 such as ``RDEPENDS_${PN} = "value"`` rather than
425 ``RDEPENDS = "value"``). If you receive this error, correct any 425 ``RDEPENDS = "value"``). If you receive this error, correct any
@@ -456,7 +456,7 @@ Errors and Warnings
456- ``<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]`` 456- ``<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]``
457 457
458 Package names must appear only once in the 458 Package names must appear only once in the
459 ```PACKAGES`` <#var-PACKAGES>`__ variable. You might receive this 459 :term:`PACKAGES` variable. You might receive this
460 error if you are attempting to add a package to ``PACKAGES`` that is 460 error if you are attempting to add a package to ``PACKAGES`` that is
461 already in the variable's value. 461 already in the variable's value.
462 462
@@ -465,7 +465,7 @@ Errors and Warnings
465- ``FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]`` 465- ``FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]``
466 466
467 The string "//" is invalid in a Unix path. Correct all occurrences 467 The string "//" is invalid in a Unix path. Correct all occurrences
468 where this string appears in a ```FILES`` <#var-FILES>`__ variable so 468 where this string appears in a :term:`FILES` variable so
469 that there is only a single "/". 469 that there is only a single "/".
470 470
471   471  
@@ -473,14 +473,14 @@ Errors and Warnings
473- ``<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]`` 473- ``<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]``
474 474
475 Files have been installed within the 475 Files have been installed within the
476 ```do_install`` <#ref-tasks-install>`__ task but have not been 476 :ref:`ref-tasks-install` task but have not been
477 included in any package by way of the ```FILES`` <#var-FILES>`__ 477 included in any package by way of the :term:`FILES`
478 variable. Files that do not appear in any package cannot be present 478 variable. Files that do not appear in any package cannot be present
479 in an image later on in the build process. You need to do one of the 479 in an image later on in the build process. You need to do one of the
480 following: 480 following:
481 481
482 - Add the files to ``FILES`` for the package you want them to appear 482 - Add the files to ``FILES`` for the package you want them to appear
483 in (e.g. ``FILES_${``\ ```PN`` <#var-PN>`__\ ``}`` for the main 483 in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main
484 package). 484 package).
485 485
486 - Delete the files at the end of the ``do_install`` task if the 486 - Delete the files at the end of the ``do_install`` task if the
@@ -496,15 +496,15 @@ Errors and Warnings
496 message might indicate that a private version of a library is being 496 message might indicate that a private version of a library is being
497 erroneously picked up as the provider for a common library. If that 497 erroneously picked up as the provider for a common library. If that
498 is the case, you should add the library's ``.so`` file name to 498 is the case, you should add the library's ``.so`` file name to
499 ```PRIVATE_LIBS`` <#var-PRIVATE_LIBS>`__ in the recipe that provides 499 :term:`PRIVATE_LIBS` in the recipe that provides
500 the private version of the library. 500 the private version of the library.
501 501
502- ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]`` 502- ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
503 503
504 The ```LICENSE`` <#var-LICENSE>`__ of the recipe should be a superset 504 The :term:`LICENSE` of the recipe should be a superset
505 of all the licenses of all packages produced by this recipe. In other 505 of all the licenses of all packages produced by this recipe. In other
506 words, any license in ``LICENSE_*`` should also appear in 506 words, any license in ``LICENSE_*`` should also appear in
507 ```LICENSE`` <#var-LICENSE>`__. 507 :term:`LICENSE`.
508 508
509   509  
510 510
@@ -513,11 +513,11 @@ Configuring and Disabling QA Checks
513 513
514You can configure the QA checks globally so that specific check failures 514You can configure the QA checks globally so that specific check failures
515either raise a warning or an error message, using the 515either raise a warning or an error message, using the
516```WARN_QA`` <#var-WARN_QA>`__ and ```ERROR_QA`` <#var-ERROR_QA>`__ 516:term:`WARN_QA` and :term:`ERROR_QA`
517variables, respectively. You can also disable checks within a particular 517variables, respectively. You can also disable checks within a particular
518recipe using ```INSANE_SKIP`` <#var-INSANE_SKIP>`__. For information on 518recipe using :term:`INSANE_SKIP`. For information on
519how to work with the QA checks, see the 519how to work with the QA checks, see the
520"```insane.bbclass`` <#ref-classes-insane>`__" section. 520":ref:`insane.bbclass <ref-classes-insane>`" section.
521 521
522.. note:: 522.. note::
523 523
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index c09fd7a075..95ec686a13 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -41,7 +41,7 @@ Major Release Codenames
41Each major release receives a codename that identifies the release in 41Each major release receives a codename that identifies the release in
42the `Yocto Project Source 42the `Yocto Project Source
43Repositories <&YOCTO_DOCS_OM_URL;#yocto-project-repositories>`__. The 43Repositories <&YOCTO_DOCS_OM_URL;#yocto-project-repositories>`__. The
44concept is that branches of `Metadata <#metadata>`__ with the same 44concept is that branches of :term:`Metadata` with the same
45codename are likely to be compatible and thus work together. 45codename are likely to be compatible and thus work together.
46 46
47.. note:: 47.. note::
@@ -107,12 +107,12 @@ consists of the following pieces:
107- ``bitbake-selftest``: A standalone command that runs unit tests on 107- ``bitbake-selftest``: A standalone command that runs unit tests on
108 key pieces of BitBake and its fetchers. 108 key pieces of BitBake and its fetchers.
109 109
110- ```sanity.bbclass`` <#ref-classes-sanity>`__: This automatically 110- :ref:`sanity.bbclass <ref-classes-sanity>`: This automatically
111 included class checks the build environment for missing tools (e.g. 111 included class checks the build environment for missing tools (e.g.
112 ``gcc``) or common misconfigurations such as 112 ``gcc``) or common misconfigurations such as
113 ```MACHINE`` <#var-MACHINE>`__ set incorrectly. 113 :term:`MACHINE` set incorrectly.
114 114
115- ```insane.bbclass`` <#ref-classes-insane>`__: This class checks the 115- :ref:`insane.bbclass <ref-classes-insane>`: This class checks the
116 generated output from builds for sanity. For example, if building for 116 generated output from builds for sanity. For example, if building for
117 an ARM target, did the build produce ARM binaries. If, for example, 117 an ARM target, did the build produce ARM binaries. If, for example,
118 the build produced PPC binaries then there is a problem. 118 the build produced PPC binaries then there is a problem.
@@ -149,7 +149,7 @@ efficiently.
149 149
150The Yocto Project's main Autobuilder (``autobuilder.yoctoproject.org``) 150The Yocto Project's main Autobuilder (``autobuilder.yoctoproject.org``)
151publicly tests each Yocto Project release's code in the 151publicly tests each Yocto Project release's code in the
152`OE-Core <#oe-core>`__, Poky, and BitBake repositories. The testing 152:term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
153occurs for both the current state of the "master" branch and also for 153occurs for both the current state of the "master" branch and also for
154submitted patches. Testing for submitted patches usually occurs in the 154submitted patches. Testing for submitted patches usually occurs in the
155"ross/mut" branch in the ``poky-contrib`` repository (i.e. the 155"ross/mut" branch in the ``poky-contrib`` repository (i.e. the
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index 5e30a08041..c63900e604 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -4,7 +4,7 @@
4Source Directory Structure 4Source Directory Structure
5************************** 5**************************
6 6
7The `Source Directory <#source-directory>`__ consists of numerous files, 7The :term:`Source Directory` consists of numerous files,
8directories and subdirectories; understanding their locations and 8directories and subdirectories; understanding their locations and
9contents is key to using the Yocto Project effectively. This chapter 9contents is key to using the Yocto Project effectively. This chapter
10describes the Source Directory and gives information about those files 10describes the Source Directory and gives information about those files
@@ -36,7 +36,7 @@ Directory <#source-directory>`__.
36 36
37This directory includes a copy of BitBake for ease of use. The copy 37This directory includes a copy of BitBake for ease of use. The copy
38usually matches the current stable BitBake release from the BitBake 38usually matches the current stable BitBake release from the BitBake
39project. BitBake, a `Metadata <#metadata>`__ interpreter, reads the 39project. BitBake, a :term:`Metadata` interpreter, reads the
40Yocto Project Metadata and runs the tasks defined by that data. Failures 40Yocto Project Metadata and runs the tasks defined by that data. Failures
41are usually caused by errors in your Metadata and not from BitBake 41are usually caused by errors in your Metadata and not from BitBake
42itself; consequently, most users do not need to worry about BitBake. 42itself; consequently, most users do not need to worry about BitBake.
@@ -63,7 +63,7 @@ the OpenEmbedded build environment setup script (i.e.
63````` <#structure-core-script>`__). 63````` <#structure-core-script>`__).
64 64
65It is also possible to place output and configuration files in a 65It is also possible to place output and configuration files in a
66directory separate from the `Source Directory <#source-directory>`__ by 66directory separate from the :term:`Source Directory` by
67providing a directory name when you ``source`` the setup script. For 67providing a directory name when you ``source`` the setup script. For
68information on separating output from your local Source Directory files 68information on separating output from your local Source Directory files
69(commonly described as an "out of tree" build), see the 69(commonly described as an "out of tree" build), see the
@@ -152,7 +152,7 @@ BitBake commands. The script uses other scripts within the ``scripts``
152directory to do the bulk of the work. 152directory to do the bulk of the work.
153 153
154When you run this script, your Yocto Project environment is set up, a 154When you run this script, your Yocto Project environment is set up, a
155`Build Directory <#build-directory>`__ is created, your working 155:term:`Build Directory` is created, your working
156directory becomes the Build Directory, and you are presented with some 156directory becomes the Build Directory, and you are presented with some
157simple suggestions as to what to do next, including a list of some 157simple suggestions as to what to do next, including a list of some
158possible targets to build. Here is an example: $ source 158possible targets to build. Here is an example: $ source
@@ -162,7 +162,7 @@ core-image-sato meta-toolchain meta-ide-support You can also run
162generated qemu images with a command like 'runqemu qemux86-64' The 162generated qemu images with a command like 'runqemu qemux86-64' The
163default output of the ``oe-init-build-env`` script is from the 163default output of the ``oe-init-build-env`` script is from the
164``conf-notes.txt`` file, which is found in the ``meta-poky`` directory 164``conf-notes.txt`` file, which is found in the ``meta-poky`` directory
165within the `Source Directory <#source-directory>`__. If you design a 165within the :term:`Source Directory`. If you design a
166custom distribution, you can include your own version of this 166custom distribution, you can include your own version of this
167configuration file to mention the targets defined by your distribution. 167configuration file to mention the targets defined by your distribution.
168See the "`Creating a Custom Template Configuration 168See the "`Creating a Custom Template Configuration
@@ -213,7 +213,7 @@ Directory a specific name when you run the setup script, the name
213defaults to ``build/``. 213defaults to ``build/``.
214 214
215For subsequent parsing and processing, the name of the Build directory 215For subsequent parsing and processing, the name of the Build directory
216is available via the ```TOPDIR`` <#var-TOPDIR>`__ variable. 216is available via the :term:`TOPDIR` variable.
217 217
218.. _structure-build-buildhistory: 218.. _structure-build-buildhistory:
219 219
@@ -243,7 +243,7 @@ relatively rare.
243 243
244At a minimum, you would normally edit this file to select the target 244At a minimum, you would normally edit this file to select the target
245``MACHINE``, which package types you wish to use 245``MACHINE``, which package types you wish to use
246(```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__), and the location from 246(:term:`PACKAGE_CLASSES`), and the location from
247which you want to access downloaded files (``DL_DIR``). 247which you want to access downloaded files (``DL_DIR``).
248 248
249If ``local.conf`` is not present when you start the build, the 249If ``local.conf`` is not present when you start the build, the
@@ -261,7 +261,7 @@ build environment from any layer by setting the variable in the
261top-level build environment setup script as follows: 261top-level build environment setup script as follows:
262TEMPLATECONF=your_layer/conf Once the build process gets the sample 262TEMPLATECONF=your_layer/conf Once the build process gets the sample
263file, it uses ``sed`` to substitute final 263file, it uses ``sed`` to substitute final
264``${``\ ```OEROOT`` <#var-OEROOT>`__\ ``}`` values for all 264``${``\ :term:`OEROOT`\ ``}`` values for all
265``##OEROOT##`` values. 265``##OEROOT##`` values.
266 266
267.. note:: 267.. note::
@@ -286,7 +286,7 @@ file, it uses ``sed`` to substitute final
286This configuration file defines 286This configuration file defines
287`layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__, 287`layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__,
288which are directory trees, traversed (or walked) by BitBake. The 288which are directory trees, traversed (or walked) by BitBake. The
289``bblayers.conf`` file uses the ```BBLAYERS`` <#var-BBLAYERS>`__ 289``bblayers.conf`` file uses the :term:`BBLAYERS`
290variable to list the layers BitBake tries to find. 290variable to list the layers BitBake tries to find.
291 291
292If ``bblayers.conf`` is not present when you start the build, the 292If ``bblayers.conf`` is not present when you start the build, the
@@ -304,7 +304,7 @@ implies that you can base your build from any layer by setting the
304variable in the top-level build environment setup script as follows: 304variable in the top-level build environment setup script as follows:
305TEMPLATECONF=your_layer/conf Once the build process gets the sample 305TEMPLATECONF=your_layer/conf Once the build process gets the sample
306file, it uses ``sed`` to substitute final 306file, it uses ``sed`` to substitute final
307``${``\ ```OEROOT`` <#var-OEROOT>`__\ ``}`` values for all 307``${``\ :term:`OEROOT`\ ``}`` values for all
308``##OEROOT##`` values. 308``##OEROOT##`` values.
309 309
310.. note:: 310.. note::
@@ -355,7 +355,7 @@ You can control the location of this directory through the
355-------------- 355--------------
356 356
357The OpenEmbedded build system creates and uses this directory for all 357The OpenEmbedded build system creates and uses this directory for all
358the build system's output. The ```TMPDIR`` <#var-TMPDIR>`__ variable 358the build system's output. The :term:`TMPDIR` variable
359points to this directory. 359points to this directory.
360 360
361BitBake creates this directory if it does not exist. As a last resort, 361BitBake creates this directory if it does not exist. As a last resort,
@@ -393,7 +393,7 @@ cache is reused. If the file has changed, it is reparsed.
393--------------------- 393---------------------
394 394
395This directory contains any "end result" output from the OpenEmbedded 395This directory contains any "end result" output from the OpenEmbedded
396build process. The ```DEPLOY_DIR`` <#var-DEPLOY_DIR>`__ variable points 396build process. The :term:`DEPLOY_DIR` variable points
397to this directory. For more detail on the contents of the ``deploy`` 397to this directory. For more detail on the contents of the ``deploy``
398directory, see the 398directory, see the
399"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and 399"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and
@@ -497,11 +497,11 @@ another.
497---------------------------------- 497----------------------------------
498 498
499This directory is the location of the sysroot contents that the task 499This directory is the location of the sysroot contents that the task
500```do_prepare_recipe_sysroot`` <#ref-tasks-prepare_recipe_sysroot>`__ 500:ref:`ref-tasks-prepare_recipe_sysroot`
501links or copies into the recipe-specific sysroot for each recipe listed 501links or copies into the recipe-specific sysroot for each recipe listed
502in ```DEPENDS`` <#var-DEPENDS>`__. Population of this directory is 502in :term:`DEPENDS`. Population of this directory is
503handled through shared state, while the path is specified by the 503handled through shared state, while the path is specified by the
504```COMPONENTS_DIR`` <#var-COMPONENTS_DIR>`__ variable. Apart from a few 504:term:`COMPONENTS_DIR` variable. Apart from a few
505unusual circumstances, handling of the ``sysroots-components`` directory 505unusual circumstances, handling of the ``sysroots-components`` directory
506should be automatic, and recipes should not directly reference 506should be automatic, and recipes should not directly reference
507``build/tmp/sysroots-components``. 507``build/tmp/sysroots-components``.
@@ -514,7 +514,7 @@ should be automatic, and recipes should not directly reference
514Previous versions of the OpenEmbedded build system used to create a 514Previous versions of the OpenEmbedded build system used to create a
515global shared sysroot per machine along with a native sysroot. Beginning 515global shared sysroot per machine along with a native sysroot. Beginning
516with the DISTRO version of the Yocto Project, sysroots exist in 516with the DISTRO version of the Yocto Project, sysroots exist in
517recipe-specific ```WORKDIR`` <#var-WORKDIR>`__ directories. Thus, the 517recipe-specific :term:`WORKDIR` directories. Thus, the
518``build/tmp/sysroots/`` directory is unused. 518``build/tmp/sysroots/`` directory is unused.
519 519
520.. note:: 520.. note::
@@ -566,7 +566,7 @@ directory. For example, the source for a particular package is unpacked,
566patched, configured and compiled all within its own work directory. 566patched, configured and compiled all within its own work directory.
567Within the work directory, organization is based on the package group 567Within the work directory, organization is based on the package group
568and version for which the source is being compiled as defined by the 568and version for which the source is being compiled as defined by the
569```WORKDIR`` <#var-WORKDIR>`__. 569:term:`WORKDIR`.
570 570
571It is worth considering the structure of a typical work directory. As an 571It is worth considering the structure of a typical work directory. As an
572example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86`` 572example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
@@ -599,12 +599,12 @@ As described earlier in the
599"```build/tmp/sysroots/`` <#structure-build-tmp-sysroots>`__" section, 599"```build/tmp/sysroots/`` <#structure-build-tmp-sysroots>`__" section,
600beginning with the DISTRO release of the Yocto Project, the OpenEmbedded 600beginning with the DISTRO release of the Yocto Project, the OpenEmbedded
601build system builds each recipe in its own work directory (i.e. 601build system builds each recipe in its own work directory (i.e.
602```WORKDIR`` <#var-WORKDIR>`__). The path to the work directory is 602:term:`WORKDIR`). The path to the work directory is
603constructed using the architecture of the given build (e.g. 603constructed using the architecture of the given build (e.g.
604```TUNE_PKGARCH`` <#var-TUNE_PKGARCH>`__, 604:term:`TUNE_PKGARCH`,
605```MACHINE_ARCH`` <#var-MACHINE_ARCH>`__, or "allarch"), the recipe 605:term:`MACHINE_ARCH`, or "allarch"), the recipe
606name, and the version of the recipe (i.e. 606name, and the version of the recipe (i.e.
607```PE`` <#var-PE>`__\ ``:``\ ```PV`` <#var-PV>`__\ ``-``\ ```PR`` <#var-PR>`__). 607:term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).
608 608
609A number of key subdirectories exist within each recipe work directory: 609A number of key subdirectories exist within each recipe work directory:
610 610
@@ -614,17 +614,17 @@ A number of key subdirectories exist within each recipe work directory:
614 which tasks were executed. 614 which tasks were executed.
615 615
616- ``${WORKDIR}/image``: Contains the output of the 616- ``${WORKDIR}/image``: Contains the output of the
617 ```do_install`` <#ref-tasks-install>`__ task, which corresponds to 617 :ref:`ref-tasks-install` task, which corresponds to
618 the ``${``\ ```D`` <#var-D>`__\ ``}`` variable in that task. 618 the ``${``\ :term:`D`\ ``}`` variable in that task.
619 619
620- ``${WORKDIR}/pseudo``: Contains the pseudo database and log for any 620- ``${WORKDIR}/pseudo``: Contains the pseudo database and log for any
621 tasks executed under pseudo for the recipe. 621 tasks executed under pseudo for the recipe.
622 622
623- ``${WORKDIR}/sysroot-destdir``: Contains the output of the 623- ``${WORKDIR}/sysroot-destdir``: Contains the output of the
624 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task. 624 :ref:`ref-tasks-populate_sysroot` task.
625 625
626- ``${WORKDIR}/package``: Contains the output of the 626- ``${WORKDIR}/package``: Contains the output of the
627 ```do_package`` <#ref-tasks-package>`__ task before the output is 627 :ref:`ref-tasks-package` task before the output is
628 split into individual packages. 628 split into individual packages.
629 629
630- ``${WORKDIR}/packages-split``: Contains the output of the 630- ``${WORKDIR}/packages-split``: Contains the output of the
@@ -645,7 +645,7 @@ A number of key subdirectories exist within each recipe work directory:
645- ``${WORKDIR}/build``: This subdirectory applies only to recipes that 645- ``${WORKDIR}/build``: This subdirectory applies only to recipes that
646 support builds where the source is separate from the build artifacts. 646 support builds where the source is separate from the build artifacts.
647 The OpenEmbedded build system uses this directory as a separate build 647 The OpenEmbedded build system uses this directory as a separate build
648 directory (i.e. ``${``\ ```B`` <#var-B>`__\ ``}``). 648 directory (i.e. ``${``\ :term:`B`\ ``}``).
649 649
650.. _structure-build-work-shared: 650.. _structure-build-work-shared:
651 651
@@ -662,7 +662,7 @@ recipes. In practice, this is only used for ``gcc`` and its variants
662The Metadata - ``meta/`` 662The Metadata - ``meta/``
663======================== 663========================
664 664
665As mentioned previously, `Metadata <#metadata>`__ is the core of the 665As mentioned previously, :term:`Metadata` is the core of the
666Yocto Project. Metadata has several important subdivisions: 666Yocto Project. Metadata has several important subdivisions:
667 667
668.. _structure-meta-classes: 668.. _structure-meta-classes:
@@ -681,7 +681,7 @@ generation or packaging also have their specific class files such as
681``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``. 681``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``.
682 682
683For reference information on classes, see the 683For reference information on classes, see the
684"`Classes <#ref-classes>`__" chapter. 684":ref:`ref-manual/ref-classes:Classes`" chapter.
685 685
686.. _structure-meta-conf: 686.. _structure-meta-conf:
687 687
@@ -726,7 +726,7 @@ file mainly inherits its configuration from Poky.
726 726
727The OpenEmbedded build system searches this directory for configuration 727The OpenEmbedded build system searches this directory for configuration
728files that correspond to the value of 728files that correspond to the value of
729```SDKMACHINE`` <#var-SDKMACHINE>`__. By default, 32-bit and 64-bit x86 729:term:`SDKMACHINE`. By default, 32-bit and 64-bit x86
730files ship with the Yocto Project that support some SDK hosts. However, 730files ship with the Yocto Project that support some SDK hosts. However,
731it is possible to extend that support to other SDK hosts by adding 731it is possible to extend that support to other SDK hosts by adding
732additional configuration files in this subdirectory within another 732additional configuration files in this subdirectory within another
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index 1e4b8197a0..aa7c0df552 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -32,7 +32,7 @@ tasks required to build a recipe.
32-------------- 32--------------
33 33
34Compiles the source code. This task runs with the current working 34Compiles the source code. This task runs with the current working
35directory set to ``${``\ ```B`` <#var-B>`__\ ``}``. 35directory set to ``${``\ :term:`B`\ ``}``.
36 36
37The default behavior of this task is to run the ``oe_runmake`` function 37The default behavior of this task is to run the ``oe_runmake`` function
38if a makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found. 38if a makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found.
@@ -52,11 +52,11 @@ Compiles the runtime test suite included in the software being built.
52 52
53Configures the source by enabling and disabling any build-time and 53Configures the source by enabling and disabling any build-time and
54configuration options for the software being built. The task runs with 54configuration options for the software being built. The task runs with
55the current working directory set to ``${``\ ```B`` <#var-B>`__\ ``}``. 55the current working directory set to ``${``\ :term:`B`\ ``}``.
56 56
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```CLEANBROKEN`` <#var-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 ``CLEANBROKEN`` variable is set to "1", the
61``do_configure`` task does nothing. 61``do_configure`` task does nothing.
62 62
@@ -73,13 +73,13 @@ Configures the runtime test suite included in the software being built.
73------------- 73-------------
74 74
75Writes output files that are to be deployed to 75Writes output files that are to be deployed to
76``${``\ ```DEPLOY_DIR_IMAGE`` <#var-DEPLOY_DIR_IMAGE>`__\ ``}``. The 76``${``\ :term:`DEPLOY_DIR_IMAGE`\ ``}``. The
77task runs with the current working directory set to 77task runs with the current working directory set to
78``${``\ ```B`` <#var-B>`__\ ``}``. 78``${``\ :term:`B`\ ``}``.
79 79
80Recipes implementing this task should inherit the 80Recipes implementing this task should inherit the
81```deploy`` <#ref-classes-deploy>`__ class and should write the output 81:ref:`deploy <ref-classes-deploy>` class and should write the output
82to ``${``\ ```DEPLOYDIR`` <#var-DEPLOYDIR>`__\ ``}``, which is not to be 82to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
83confused with ``${DEPLOY_DIR}``. The ``deploy`` class sets up 83confused with ``${DEPLOY_DIR}``. The ``deploy`` class sets up
84``do_deploy`` as a shared state (sstate) task that can be accelerated 84``do_deploy`` as a shared state (sstate) task that can be accelerated
85through sstate use. The sstate mechanism takes care of copying the 85through sstate use. The sstate mechanism takes care of copying the
@@ -93,7 +93,7 @@ output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
93 93
94The ``do_deploy`` task is not added as a task by default and 94The ``do_deploy`` task is not added as a task by default and
95consequently needs to be added manually. If you want the task to run 95consequently needs to be added manually. If you want the task to run
96after ```do_compile`` <#ref-tasks-compile>`__, you can add it by doing 96after :ref:`ref-tasks-compile`, you can add it by doing
97the following: addtask deploy after do_compile Adding ``do_deploy`` 97the following: addtask deploy after do_compile Adding ``do_deploy``
98after other tasks works the same way. 98after other tasks works the same way.
99 99
@@ -124,7 +124,7 @@ If the ``do_deploy`` task re-executes, any previous output is removed
124------------ 124------------
125 125
126Fetches the source code. This task uses the 126Fetches the source code. This task uses the
127```SRC_URI`` <#var-SRC_URI>`__ variable and the argument's prefix to 127:term:`SRC_URI` variable and the argument's prefix to
128determine the correct `fetcher <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ 128determine the correct `fetcher <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__
129module. 129module.
130 130
@@ -135,12 +135,12 @@ module.
135 135
136Starts the image generation process. The ``do_image`` task runs after 136Starts the image generation process. The ``do_image`` task runs after
137the OpenEmbedded build system has run the 137the OpenEmbedded build system has run the
138```do_rootfs`` <#ref-tasks-rootfs>`__ task during which packages are 138:ref:`ref-tasks-rootfs` task during which packages are
139identified for installation into the image and the root filesystem is 139identified for installation into the image and the root filesystem is
140created, complete with post-processing. 140created, complete with post-processing.
141 141
142The ``do_image`` task performs pre-processing on the image through the 142The ``do_image`` task performs pre-processing on the image through the
143```IMAGE_PREPROCESS_COMMAND`` <#var-IMAGE_PREPROCESS_COMMAND>`__ and 143:term:`IMAGE_PREPROCESS_COMMAND` and
144dynamically generates supporting ``do_image_*`` tasks as needed. 144dynamically generates supporting ``do_image_*`` tasks as needed.
145 145
146For more information on image creation, see the "`Image 146For more information on image creation, see the "`Image
@@ -154,13 +154,13 @@ section in the Yocto Project Overview and Concepts Manual.
154 154
155Completes the image generation process. The ``do_image_complete`` task 155Completes the image generation process. The ``do_image_complete`` task
156runs after the OpenEmbedded build system has run the 156runs after the OpenEmbedded build system has run the
157```do_image`` <#ref-tasks-image>`__ task during which image 157:ref:`ref-tasks-image` task during which image
158pre-processing occurs and through dynamically generated ``do_image_*`` 158pre-processing occurs and through dynamically generated ``do_image_*``
159tasks the image is constructed. 159tasks the image is constructed.
160 160
161The ``do_image_complete`` task performs post-processing on the image 161The ``do_image_complete`` task performs post-processing on the image
162through the 162through the
163```IMAGE_POSTPROCESS_COMMAND`` <#var-IMAGE_POSTPROCESS_COMMAND>`__. 163:term:`IMAGE_POSTPROCESS_COMMAND`.
164 164
165For more information on image creation, see the "`Image 165For more information on image creation, see the "`Image
166Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" 166Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
@@ -172,13 +172,13 @@ section in the Yocto Project Overview and Concepts Manual.
172-------------- 172--------------
173 173
174Copies files that are to be packaged into the holding area 174Copies files that are to be packaged into the holding area
175``${``\ ```D`` <#var-D>`__\ ``}``. This task runs with the current 175``${``\ :term:`D`\ ``}``. This task runs with the current
176working directory set to ``${``\ ```B`` <#var-B>`__\ ``}``, which is the 176working directory set to ``${``\ :term:`B`\ ``}``, which is the
177compilation directory. The ``do_install`` task, as well as other tasks 177compilation directory. The ``do_install`` task, as well as other tasks
178that either directly or indirectly depend on the installed files (e.g. 178that either directly or indirectly depend on the installed files (e.g.
179```do_package`` <#ref-tasks-package>`__, 179:ref:`ref-tasks-package`,
180```do_package_write_*`` <#ref-tasks-package_write_deb>`__, and 180```do_package_write_*`` <#ref-tasks-package_write_deb>`__, and
181```do_rootfs`` <#ref-tasks-rootfs>`__), run under 181:ref:`ref-tasks-rootfs`), run under
182`fakeroot <&YOCTO_DOCS_OM_URL;#fakeroot-and-pseudo>`__. 182`fakeroot <&YOCTO_DOCS_OM_URL;#fakeroot-and-pseudo>`__.
183 183
184.. note:: 184.. note::
@@ -199,7 +199,7 @@ that either directly or indirectly depend on the installed files (e.g.
199 199
200 - The ``tar`` command with the "--no-same-owner" option. See the 200 - The ``tar`` command with the "--no-same-owner" option. See the
201 ``bin_package.bbclass`` file in the ``meta/classes`` directory of 201 ``bin_package.bbclass`` file in the ``meta/classes`` directory of
202 the `Source Directory <#source-directory>`__ for an example. 202 the :term:`Source Directory` for an example.
203 203
204.. _ref-tasks-install_ptest_base: 204.. _ref-tasks-install_ptest_base:
205 205
@@ -215,15 +215,15 @@ holding area.
215-------------- 215--------------
216 216
217Analyzes the content of the holding area 217Analyzes the content of the holding area
218``${``\ ```D`` <#var-D>`__\ ``}`` and splits the content into subsets 218``${``\ :term:`D`\ ``}`` and splits the content into subsets
219based on available packages and files. This task makes use of the 219based on available packages and files. This task makes use of the
220```PACKAGES`` <#var-PACKAGES>`__ and ```FILES`` <#var-FILES>`__ 220:term:`PACKAGES` and :term:`FILES`
221variables. 221variables.
222 222
223The ``do_package`` task, in conjunction with the 223The ``do_package`` task, in conjunction with the
224```do_packagedata`` <#ref-tasks-packagedata>`__ task, also saves some 224:ref:`ref-tasks-packagedata` task, also saves some
225important package metadata. For additional information, see the 225important package metadata. For additional information, see the
226```PKGDESTWORK`` <#var-PKGDESTWORK>`__ variable and the "`Automatically 226:term:`PKGDESTWORK` variable and the "`Automatically
227Added Runtime 227Added Runtime
228Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__" 228Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
229section in the Yocto Project Overview and Concepts Manual. 229section in the Yocto Project Overview and Concepts Manual.
@@ -234,7 +234,7 @@ section in the Yocto Project Overview and Concepts Manual.
234----------------- 234-----------------
235 235
236Runs QA checks on packaged files. For more information on these checks, 236Runs QA checks on packaged files. For more information on these checks,
237see the ```insane`` <#ref-classes-insane>`__ class. 237see the :ref:`insane <ref-classes-insane>` class.
238 238
239.. _ref-tasks-package_write_deb: 239.. _ref-tasks-package_write_deb:
240 240
@@ -242,7 +242,7 @@ see the ```insane`` <#ref-classes-insane>`__ class.
242------------------------ 242------------------------
243 243
244Creates Debian packages (i.e. ``*.deb`` files) and places them in the 244Creates Debian packages (i.e. ``*.deb`` files) and places them in the
245``${``\ ```DEPLOY_DIR_DEB`` <#var-DEPLOY_DIR_DEB>`__\ ``}`` directory in 245``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in
246the package feeds area. For more information, see the "`Package 246the package feeds area. For more information, see the "`Package
247Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in 247Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
248the Yocto Project Overview and Concepts Manual. 248the Yocto Project Overview and Concepts Manual.
@@ -253,7 +253,7 @@ the Yocto Project Overview and Concepts Manual.
253------------------------ 253------------------------
254 254
255Creates IPK packages (i.e. ``*.ipk`` files) and places them in the 255Creates IPK packages (i.e. ``*.ipk`` files) and places them in the
256``${``\ ```DEPLOY_DIR_IPK`` <#var-DEPLOY_DIR_IPK>`__\ ``}`` directory in 256``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in
257the package feeds area. For more information, see the "`Package 257the package feeds area. For more information, see the "`Package
258Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in 258Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
259the Yocto Project Overview and Concepts Manual. 259the Yocto Project Overview and Concepts Manual.
@@ -264,7 +264,7 @@ the Yocto Project Overview and Concepts Manual.
264------------------------ 264------------------------
265 265
266Creates RPM packages (i.e. ``*.rpm`` files) and places them in the 266Creates RPM packages (i.e. ``*.rpm`` files) and places them in the
267``${``\ ```DEPLOY_DIR_RPM`` <#var-DEPLOY_DIR_RPM>`__\ ``}`` directory in 267``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in
268the package feeds area. For more information, see the "`Package 268the package feeds area. For more information, see the "`Package
269Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in 269Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
270the Yocto Project Overview and Concepts Manual. 270the Yocto Project Overview and Concepts Manual.
@@ -275,7 +275,7 @@ the Yocto Project Overview and Concepts Manual.
275------------------------ 275------------------------
276 276
277Creates tarballs and places them in the 277Creates tarballs and places them in the
278``${``\ ```DEPLOY_DIR_TAR`` <#var-DEPLOY_DIR_TAR>`__\ ``}`` directory in 278``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in
279the package feeds area. For more information, see the "`Package 279the package feeds area. For more information, see the "`Package
280Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in 280Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in
281the Yocto Project Overview and Concepts Manual. 281the Yocto Project Overview and Concepts Manual.
@@ -286,8 +286,8 @@ the Yocto Project Overview and Concepts Manual.
286------------------ 286------------------
287 287
288Saves package metadata generated by the 288Saves package metadata generated by the
289```do_package`` <#ref-tasks-package>`__ task in 289:ref:`ref-tasks-package` task in
290```PKGDATA_DIR`` <#var-PKGDATA_DIR>`__ to make it available globally. 290:term:`PKGDATA_DIR` to make it available globally.
291 291
292.. _ref-tasks-patch: 292.. _ref-tasks-patch:
293 293
@@ -297,7 +297,7 @@ Saves package metadata generated by the
297Locates patch files and applies them to the source code. 297Locates patch files and applies them to the source code.
298 298
299After fetching and unpacking source files, the build system uses the 299After fetching and unpacking source files, the build system uses the
300recipe's ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements 300recipe's :term:`SRC_URI` statements
301to locate and apply patch files to the source code. 301to locate and apply patch files to the source code.
302 302
303.. note:: 303.. note::
@@ -375,7 +375,7 @@ information.
375----------------------- 375-----------------------
376 376
377Stages (copies) a subset of the files installed by the 377Stages (copies) a subset of the files installed by the
378```do_install`` <#ref-tasks-install>`__ task into the appropriate 378:ref:`ref-tasks-install` task into the appropriate
379sysroot. For information on how to access these files from other 379sysroot. For information on how to access these files from other
380recipes, see the ```STAGING_DIR*`` <#var-STAGING_DIR_HOST>`__ variables. 380recipes, see the ```STAGING_DIR*`` <#var-STAGING_DIR_HOST>`__ variables.
381Directories that would typically not be needed by other recipes at build 381Directories that would typically not be needed by other recipes at build
@@ -398,9 +398,9 @@ that if the task is re-executed, any previous output is removed (i.e.
398 398
399Installs the files into the individual recipe specific sysroots (i.e. 399Installs the files into the individual recipe specific sysroots (i.e.
400``recipe-sysroot`` and ``recipe-sysroot-native`` under 400``recipe-sysroot`` and ``recipe-sysroot-native`` under
401``${``\ ```WORKDIR`` <#var-WORKDIR>`__\ ``}`` based upon the 401``${``\ :term:`WORKDIR`\ ``}`` based upon the
402dependencies specified by ```DEPENDS`` <#var-DEPENDS>`__). See the 402dependencies specified by :term:`DEPENDS`). See the
403"```staging`` <#ref-classes-staging>`__" class for more information. 403":ref:`staging <ref-classes-staging>`" class for more information.
404 404
405.. _ref-tasks-rm_work: 405.. _ref-tasks-rm_work:
406 406
@@ -417,7 +417,7 @@ them. You can learn more by looking at the
417------------- 417-------------
418 418
419Unpacks the source code into a working directory pointed to by 419Unpacks the source code into a working directory pointed to by
420``${``\ ```WORKDIR`` <#var-WORKDIR>`__\ ``}``. The ```S`` <#var-S>`__ 420``${``\ :term:`WORKDIR`\ ``}``. The :term:`S`
421variable also plays a role in where unpacked source files ultimately 421variable also plays a role in where unpacked source files ultimately
422reside. For more information on how source files are unpacked, see the 422reside. For more information on how source files are unpacked, see the
423"`Source 423"`Source
@@ -459,7 +459,7 @@ default, the results are stored in ```$LOG_DIR`` <#var-LOG_DIR>`__ (e.g.
459``do_checkuri`` 459``do_checkuri``
460--------------- 460---------------
461 461
462Validates the ```SRC_URI`` <#var-SRC_URI>`__ value. 462Validates the :term:`SRC_URI` value.
463 463
464.. _ref-tasks-clean: 464.. _ref-tasks-clean:
465 465
@@ -467,11 +467,11 @@ Validates the ```SRC_URI`` <#var-SRC_URI>`__ value.
467------------ 467------------
468 468
469Removes all output files for a target from the 469Removes all output files for a target from the
470```do_unpack`` <#ref-tasks-unpack>`__ task forward (i.e. ``do_unpack``, 470:ref:`ref-tasks-unpack` task forward (i.e. ``do_unpack``,
471```do_configure`` <#ref-tasks-configure>`__, 471:ref:`ref-tasks-configure`,
472```do_compile`` <#ref-tasks-compile>`__, 472:ref:`ref-tasks-compile`,
473```do_install`` <#ref-tasks-install>`__, and 473:ref:`ref-tasks-install`, and
474```do_package`` <#ref-tasks-package>`__). 474:ref:`ref-tasks-package`).
475 475
476You can run this task using BitBake as follows: $ bitbake -c clean 476You can run this task using BitBake as follows: $ bitbake -c clean
477recipe 477recipe
@@ -481,7 +481,7 @@ Running this task does not remove the
481Consequently, if no changes have been made and the recipe is rebuilt 481Consequently, if no changes have been made and the recipe is rebuilt
482after cleaning, output files are simply restored from the sstate cache. 482after cleaning, output files are simply restored from the sstate cache.
483If you want to remove the sstate cache files for the recipe, you need to 483If you want to remove the sstate cache files for the recipe, you need to
484use the ```do_cleansstate`` <#ref-tasks-cleansstate>`__ task instead 484use the :ref:`ref-tasks-cleansstate` task instead
485(i.e. ``bitbake -c cleansstate`` recipe). 485(i.e. ``bitbake -c cleansstate`` recipe).
486 486
487.. _ref-tasks-cleanall: 487.. _ref-tasks-cleanall:
@@ -492,15 +492,15 @@ use the ```do_cleansstate`` <#ref-tasks-cleansstate>`__ task instead
492Removes all output files, shared state 492Removes all output files, shared state
493(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache, and 493(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache, and
494downloaded source files for a target (i.e. the contents of 494downloaded source files for a target (i.e. the contents of
495```DL_DIR`` <#var-DL_DIR>`__). Essentially, the ``do_cleanall`` task is 495:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
496identical to the ```do_cleansstate`` <#ref-tasks-cleansstate>`__ task 496identical to the :ref:`ref-tasks-cleansstate` task
497with the added removal of downloaded source files. 497with the added removal of downloaded source files.
498 498
499You can run this task using BitBake as follows: $ bitbake -c cleanall 499You can run this task using BitBake as follows: $ bitbake -c cleanall
500recipe 500recipe
501 501
502Typically, you would not normally use the ``cleanall`` task. Do so only 502Typically, you would not normally use the ``cleanall`` task. Do so only
503if you want to start fresh with the ```do_fetch`` <#ref-tasks-fetch>`__ 503if you want to start fresh with the :ref:`ref-tasks-fetch`
504task. 504task.
505 505
506.. _ref-tasks-cleansstate: 506.. _ref-tasks-cleansstate:
@@ -511,7 +511,7 @@ task.
511Removes all output files and shared state 511Removes all output files and shared state
512(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache for a 512(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache for a
513target. Essentially, the ``do_cleansstate`` task is identical to the 513target. Essentially, the ``do_cleansstate`` task is identical to the
514```do_clean`` <#ref-tasks-clean>`__ task with the added removal of 514:ref:`ref-tasks-clean` task with the added removal of
515shared state (`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) 515shared state (`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__)
516cache. 516cache.
517 517
@@ -596,7 +596,7 @@ The following tasks are applicable to image recipes.
596-------------- 596--------------
597 597
598Creates a bootable live image. See the 598Creates a bootable live image. See the
599```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ variable for additional 599:term:`IMAGE_FSTYPES` variable for additional
600information on live image types. 600information on live image types.
601 601
602.. _ref-tasks-bundle_initramfs: 602.. _ref-tasks-bundle_initramfs:
@@ -606,7 +606,7 @@ information on live image types.
606 606
607Combines an initial RAM disk (initramfs) image and kernel together to 607Combines an initial RAM disk (initramfs) image and kernel together to
608form a single image. The 608form a single image. The
609```CONFIG_INITRAMFS_SOURCE`` <#var-CONFIG_INITRAMFS_SOURCE>`__ variable 609:term:`CONFIG_INITRAMFS_SOURCE` variable
610has some more information about these types of images. 610has some more information about these types of images.
611 611
612.. _ref-tasks-rootfs: 612.. _ref-tasks-rootfs:
@@ -638,7 +638,7 @@ section in the Yocto Project Development Tasks Manual.
638 638
639Boots an image and performs runtime tests within the image immediately 639Boots an image and performs runtime tests within the image immediately
640after it has been built. This task is enabled when you set 640after it has been built. This task is enabled when you set
641```TESTIMAGE_AUTO`` <#var-TESTIMAGE_AUTO>`__ equal to "1". 641:term:`TESTIMAGE_AUTO` equal to "1".
642 642
643For information on automatically testing images, see the "`Performing 643For information on automatically testing images, see the "`Performing
644Automated Runtime 644Automated Runtime
@@ -649,7 +649,7 @@ Kernel-Related Tasks
649==================== 649====================
650 650
651The following tasks are applicable to kernel recipes. Some of these 651The following tasks are applicable to kernel recipes. Some of these
652tasks (e.g. the ```do_menuconfig`` <#ref-tasks-menuconfig>`__ task) are 652tasks (e.g. the :ref:`ref-tasks-menuconfig` task) are
653also applicable to recipes that use Linux kernel style configuration 653also applicable to recipes that use Linux kernel style configuration
654such as the BusyBox recipe. 654such as the BusyBox recipe.
655 655
@@ -669,9 +669,9 @@ kernel consists of two steps: 1) the kernel (``vmlinux``) is built, and
669 669
670When invoked by the user, this task creates a file containing the 670When invoked by the user, this task creates a file containing the
671differences between the original config as produced by 671differences between the original config as produced by
672```do_kernel_configme`` <#ref-tasks-kernel_configme>`__ task and the 672:ref:`ref-tasks-kernel_configme` task and the
673changes made by the user with other methods (i.e. using 673changes made by the user with other methods (i.e. using
674(```do_kernel_menuconfig`` <#ref-tasks-kernel_menuconfig>`__). Once the 674(:ref:`ref-tasks-kernel_menuconfig`). Once the
675file of differences is created, it can be used to create a config 675file of differences is created, it can be used to create a config
676fragment that only contains the differences. You can invoke this task 676fragment that only contains the differences. You can invoke this task
677from the command line as follows: $ bitbake linux-yocto -c diffconfig 677from the command line as follows: $ bitbake linux-yocto -c diffconfig
@@ -696,7 +696,7 @@ kernel with the correct branches checked out.
696------------------------- 696-------------------------
697 697
698Validates the configuration produced by the 698Validates the configuration produced by the
699```do_kernel_menuconfig`` <#ref-tasks-kernel_menuconfig>`__ task. The 699:ref:`ref-tasks-kernel_menuconfig` task. The
700``do_kernel_configcheck`` task produces warnings when a requested 700``do_kernel_configcheck`` task produces warnings when a requested
701configuration does not appear in the final ``.config`` file or when you 701configuration does not appear in the final ``.config`` file or when you
702override a policy configuration in a hardware configuration fragment. 702override a policy configuration in a hardware configuration fragment.
@@ -711,7 +711,7 @@ section in the Yocto Project Linux Kernel Development Manual.
711``do_kernel_configme`` 711``do_kernel_configme``
712---------------------- 712----------------------
713 713
714After the kernel is patched by the ```do_patch`` <#ref-tasks-patch>`__ 714After the kernel is patched by the :ref:`ref-tasks-patch`
715task, the ``do_kernel_configme`` task assembles and merges all the 715task, the ``do_kernel_configme`` task assembles and merges all the
716kernel config fragments into a merged configuration that can then be 716kernel config fragments into a merged configuration that can then be
717passed to the kernel configuration phase proper. This is also the time 717passed to the kernel configuration phase proper. This is also the time
@@ -746,12 +746,12 @@ information on this configuration tool.
746---------------------- 746----------------------
747 747
748Collects all the features required for a given kernel build, whether the 748Collects all the features required for a given kernel build, whether the
749features come from ```SRC_URI`` <#var-SRC_URI>`__ or from Git 749features come from :term:`SRC_URI` or from Git
750repositories. After collection, the ``do_kernel_metadata`` task 750repositories. After collection, the ``do_kernel_metadata`` task
751processes the features into a series of config fragments and patches, 751processes the features into a series of config fragments and patches,
752which can then be applied by subsequent tasks such as 752which can then be applied by subsequent tasks such as
753```do_patch`` <#ref-tasks-patch>`__ and 753:ref:`ref-tasks-patch` and
754```do_kernel_configme`` <#ref-tasks-kernel_configme>`__. 754:ref:`ref-tasks-kernel_configme`.
755 755
756.. _ref-tasks-menuconfig: 756.. _ref-tasks-menuconfig:
757 757
@@ -772,7 +772,7 @@ When invoked by the user, creates a defconfig file that can be used
772instead of the default defconfig. The saved defconfig contains the 772instead of the default defconfig. The saved defconfig contains the
773differences between the default defconfig and the changes made by the 773differences between the default defconfig and the changes made by the
774user using other methods (i.e. the 774user using other methods (i.e. the
775```do_kernel_menuconfig`` <#ref-tasks-kernel_menuconfig>`__ task. You 775:ref:`ref-tasks-kernel_menuconfig` task. You
776can invoke the task using the following command: $ bitbake linux-yocto 776can invoke the task using the following command: $ bitbake linux-yocto
777-c savedefconfig 777-c savedefconfig
778 778
@@ -785,7 +785,7 @@ After the kernel has been compiled but before the kernel modules have
785been compiled, this task copies files required for module builds and 785been compiled, this task copies files required for module builds and
786which are generated from the kernel build into the shared work 786which are generated from the kernel build into the shared work
787directory. With these copies successfully copied, the 787directory. With these copies successfully copied, the
788```do_compile_kernelmodules`` <#ref-tasks-compile_kernelmodules>`__ task 788:ref:`ref-tasks-compile_kernelmodules` task
789can successfully build the kernel modules in the next step of the build. 789can successfully build the kernel modules in the next step of the build.
790 790
791.. _ref-tasks-sizecheck: 791.. _ref-tasks-sizecheck:
@@ -795,7 +795,7 @@ can successfully build the kernel modules in the next step of the build.
795 795
796After the kernel has been built, this task checks the size of the 796After the kernel has been built, this task checks the size of the
797stripped kernel image against 797stripped kernel image against
798```KERNEL_IMAGE_MAXSIZE`` <#var-KERNEL_IMAGE_MAXSIZE>`__. If that 798:term:`KERNEL_IMAGE_MAXSIZE`. If that
799variable was set and the size of the stripped kernel exceeds that size, 799variable was set and the size of the stripped kernel exceeds that size,
800the kernel build produces a warning to that effect. 800the kernel build produces a warning to that effect.
801 801
@@ -816,9 +816,9 @@ sections from a size-sensitive configuration.
816 816
817After the kernel is unpacked but before it is patched, this task makes 817After the kernel is unpacked but before it is patched, this task makes
818sure that the machine and metadata branches as specified by the 818sure that the machine and metadata branches as specified by the
819```SRCREV`` <#var-SRCREV>`__ variables actually exist on the specified 819:term:`SRCREV` variables actually exist on the specified
820branches. If these branches do not exist and 820branches. If these branches do not exist and
821```AUTOREV`` <#var-AUTOREV>`__ is not being used, the 821:term:`AUTOREV` is not being used, the
822``do_validate_branches`` task fails during the build. 822``do_validate_branches`` task fails during the build.
823 823
824Miscellaneous Tasks 824Miscellaneous Tasks
@@ -833,4 +833,4 @@ The following sections describe miscellaneous tasks.
833 833
834A build stage that takes the source code and scans it on a remote 834A build stage that takes the source code and scans it on a remote
835FOSSOLOGY server in order to produce an SPDX document. This task applies 835FOSSOLOGY server in order to produce an SPDX document. This task applies
836only to the ```spdx`` <#ref-classes-spdx>`__ class. 836only to the :ref:`spdx <ref-classes-spdx>` class.
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 59100e9c88..4298e04965 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -113,7 +113,7 @@ universal, the list includes them just in case:
113 Files that provide for logic encapsulation and inheritance so that 113 Files that provide for logic encapsulation and inheritance so that
114 commonly used patterns can be defined once and then easily used in 114 commonly used patterns can be defined once and then easily used in
115 multiple recipes. For reference information on the Yocto Project classes, 115 multiple recipes. For reference information on the Yocto Project classes,
116 see the "`Classes <#ref-classes>`__" chapter. Class files end with the 116 see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the
117 ``.bbclass`` filename extension. 117 ``.bbclass`` filename extension.
118 118
119 Configuration File 119 Configuration File
@@ -200,7 +200,7 @@ universal, the list includes them just in case:
200 Metadata 200 Metadata
201 A key element of the Yocto Project is the Metadata that 201 A key element of the Yocto Project is the Metadata that
202 is used to construct a Linux distribution and is contained in the 202 is used to construct a Linux distribution and is contained in the
203 files that the `OpenEmbedded build system <#build-system-term>`__ 203 files that the :term:`OpenEmbedded Build System`
204 parses when building an image. In general, Metadata includes recipes, 204 parses when building an image. In general, Metadata includes recipes,
205 configuration files, and other information that refers to the build 205 configuration files, and other information that refers to the build
206 instructions themselves, as well as the data used to control what 206 instructions themselves, as well as the data used to control what
@@ -233,7 +233,7 @@ universal, the list includes them just in case:
233 OpenEmbedded Build System 233 OpenEmbedded Build System
234 The build system specific to the Yocto 234 The build system specific to the Yocto
235 Project. The OpenEmbedded build system is based on another project 235 Project. The OpenEmbedded build system is based on another project
236 known as "Poky", which uses `BitBake <#bitbake-term>`__ as the task 236 known as "Poky", which uses :term:`BitBake` as the task
237 executor. Throughout the Yocto Project documentation set, the 237 executor. Throughout the Yocto Project documentation set, the
238 OpenEmbedded build system is sometimes referred to simply as "the 238 OpenEmbedded build system is sometimes referred to simply as "the
239 build system". If other build systems, such as a host or target build 239 build system". If other build systems, such as a host or target build
@@ -262,8 +262,8 @@ universal, the list includes them just in case:
262 Another point worth noting is that historically within the Yocto 262 Another point worth noting is that historically within the Yocto
263 Project, recipes were referred to as packages - thus, the existence 263 Project, recipes were referred to as packages - thus, the existence
264 of several BitBake variables that are seemingly mis-named, (e.g. 264 of several BitBake variables that are seemingly mis-named, (e.g.
265 ```PR`` <#var-PR>`__, ```PV`` <#var-PV>`__, and 265 :term:`PR`, :term:`PV`, and
266 ```PE`` <#var-PE>`__). 266 :term:`PE`).
267 267
268 Package Groups 268 Package Groups
269 Arbitrary groups of software Recipes. You use 269 Arbitrary groups of software Recipes. You use
@@ -373,9 +373,9 @@ universal, the list includes them just in case:
373 373
374 Task 374 Task
375 A unit of execution for BitBake (e.g. 375 A unit of execution for BitBake (e.g.
376 ```do_compile`` <#ref-tasks-compile>`__, 376 :ref:`ref-tasks-compile`,
377 ```do_fetch`` <#ref-tasks-fetch>`__, 377 :ref:`ref-tasks-fetch`,
378 ```do_patch`` <#ref-tasks-patch>`__, and so forth). 378 :ref:`ref-tasks-patch`, and so forth).
379 379
380 Toaster 380 Toaster
381 A web interface to the Yocto Project's `OpenEmbedded Build 381 A web interface to the Yocto Project's `OpenEmbedded Build
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index b84640c6a7..3eae836fd6 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -7,12 +7,12 @@ Variables Glossary
7This chapter lists common variables used in the OpenEmbedded build 7This chapter lists common variables used in the OpenEmbedded build
8system and gives an overview of their function and contents. 8system and gives an overview of their function and contents.
9 9
10`A <#var-ABIEXTENSION>`__ `B <#var-B>`__ `C <#var-CACHE>`__ 10`A <#var-ABIEXTENSION>`__ :term:`B` `C <#var-CACHE>`__
11`D <#var-D>`__ `E <#var-EFI_PROVIDER>`__ `F <#var-FEATURE_PACKAGES>`__ 11:term:`D` `E <#var-EFI_PROVIDER>`__ `F <#var-FEATURE_PACKAGES>`__
12`G <#var-GCCPIE>`__ `H <#var-HOMEPAGE>`__ `I <#var-ICECC_DISABLED>`__ 12`G <#var-GCCPIE>`__ `H <#var-HOMEPAGE>`__ `I <#var-ICECC_DISABLED>`__
13`K <#var-KARCH>`__ `L <#var-LABELS>`__ `M <#var-MACHINE>`__ 13`K <#var-KARCH>`__ `L <#var-LABELS>`__ `M <#var-MACHINE>`__
14`N <#var-NATIVELSBSTRING>`__ `O <#var-OBJCOPY>`__ `P <#var-P>`__ 14`N <#var-NATIVELSBSTRING>`__ `O <#var-OBJCOPY>`__ :term:`P`
15`R <#var-RANLIB>`__ `S <#var-S>`__ `T <#var-T>`__ 15`R <#var-RANLIB>`__ :term:`S` :term:`T`
16`U <#var-UBOOT_CONFIG>`__ `V <#var-VOLATILE_LOG_DIR>`__ 16`U <#var-UBOOT_CONFIG>`__ `V <#var-VOLATILE_LOG_DIR>`__
17`W <#var-WARN_QA>`__ `X <#var-XSERVER>`__ 17`W <#var-WARN_QA>`__ `X <#var-XSERVER>`__
18 18
@@ -30,7 +30,7 @@ system and gives an overview of their function and contents.
30 Specifies whether to produce an output package even if it is empty. 30 Specifies whether to produce an output package even if it is empty.
31 By default, BitBake does not produce empty packages. This default 31 By default, BitBake does not produce empty packages. This default
32 behavior can cause issues when there is an 32 behavior can cause issues when there is an
33 ```RDEPENDS`` <#var-RDEPENDS>`__ or some other hard runtime 33 :term:`RDEPENDS` or some other hard runtime
34 requirement on the existence of the package. 34 requirement on the existence of the package.
35 35
36 Like all package-controlling variables, you must always use them in 36 Like all package-controlling variables, you must always use them in
@@ -49,7 +49,7 @@ system and gives an overview of their function and contents.
49 has four commands that also exist as part of another package, you 49 has four commands that also exist as part of another package, you
50 identify them as follows: ALTERNATIVE_busybox = "sh sed test bracket" 50 identify them as follows: ALTERNATIVE_busybox = "sh sed test bracket"
51 For more information on the alternatives system, see the 51 For more information on the alternatives system, see the
52 "```update-alternatives.bbclass`` <#ref-classes-update-alternatives>`__" 52 ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
53 section. 53 section.
54 54
55 ALTERNATIVE_LINK_NAME 55 ALTERNATIVE_LINK_NAME
@@ -72,7 +72,7 @@ system and gives an overview of their function and contents.
72 . 72 .
73 73
74 For more information on the alternatives system, see the 74 For more information on the alternatives system, see the
75 "```update-alternatives.bbclass`` <#ref-classes-update-alternatives>`__" 75 ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
76 section. 76 section.
77 77
78 ALTERNATIVE_PRIORITY 78 ALTERNATIVE_PRIORITY
@@ -86,7 +86,7 @@ system and gives an overview of their function and contents.
86 ALTERNATIVE_PRIORITY_pkg[name] = "priority" 86 ALTERNATIVE_PRIORITY_pkg[name] = "priority"
87 87
88 For more information on the alternatives system, see the 88 For more information on the alternatives system, see the
89 "```update-alternatives.bbclass`` <#ref-classes-update-alternatives>`__" 89 ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
90 section. 90 section.
91 91
92 ALTERNATIVE_TARGET 92 ALTERNATIVE_TARGET
@@ -103,7 +103,7 @@ system and gives an overview of their function and contents.
103 103
104 If ``ALTERNATIVE_TARGET`` is not defined, it inherits the value 104 If ``ALTERNATIVE_TARGET`` is not defined, it inherits the value
105 from the 105 from the
106 ```ALTERNATIVE_LINK_NAME`` <#var-ALTERNATIVE_LINK_NAME>`__ 106 :term:`ALTERNATIVE_LINK_NAME`
107 variable. 107 variable.
108 108
109 If ``ALTERNATIVE_LINK_NAME`` and ``ALTERNATIVE_TARGET`` are the 109 If ``ALTERNATIVE_LINK_NAME`` and ``ALTERNATIVE_TARGET`` are the
@@ -112,25 +112,25 @@ system and gives an overview of their function and contents.
112 112
113 Finally, if the file referenced has not been renamed, the 113 Finally, if the file referenced has not been renamed, the
114 alternatives system will rename it to avoid the need to rename 114 alternatives system will rename it to avoid the need to rename
115 alternative files in the ```do_install`` <#ref-tasks-install>`__ 115 alternative files in the :ref:`ref-tasks-install`
116 task while retaining support for the command if necessary. 116 task while retaining support for the command if necessary.
117 117
118 For more information on the alternatives system, see the 118 For more information on the alternatives system, see the
119 "```update-alternatives.bbclass`` <#ref-classes-update-alternatives>`__" 119 ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
120 section. 120 section.
121 121
122 APPEND 122 APPEND
123 An override list of append strings for each target specified with 123 An override list of append strings for each target specified with
124 ```LABELS`` <#var-LABELS>`__. 124 :term:`LABELS`.
125 125
126 See the ```grub-efi`` <#ref-classes-grub-efi>`__ class for more 126 See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
127 information on how this variable is used. 127 information on how this variable is used.
128 128
129 AR 129 AR
130 The minimal command and arguments used to run ``ar``. 130 The minimal command and arguments used to run ``ar``.
131 131
132 ARCHIVER_MODE 132 ARCHIVER_MODE
133 When used with the ```archiver`` <#ref-classes-archiver>`__ class, 133 When used with the :ref:`archiver <ref-classes-archiver>` class,
134 determines the type of information used to create a released archive. 134 determines the type of information used to create a released archive.
135 You can use this variable to create archives of patched source, 135 You can use this variable to create archives of patched source,
136 original source, configured source, and so forth by employing the 136 original source, configured source, and so forth by employing the
@@ -151,7 +151,7 @@ system and gives an overview of their function and contents.
151 Minimal command and arguments needed to run the assembler. 151 Minimal command and arguments needed to run the assembler.
152 152
153 ASSUME_PROVIDED 153 ASSUME_PROVIDED
154 Lists recipe names (```PN`` <#var-PN>`__ values) BitBake does not 154 Lists recipe names (:term:`PN` values) BitBake does not
155 attempt to build. Instead, BitBake assumes these recipes have already 155 attempt to build. Instead, BitBake assumes these recipes have already
156 been built. 156 been built.
157 157
@@ -178,7 +178,7 @@ system and gives an overview of their function and contents.
178 order to send patches and forward bugs. 178 order to send patches and forward bugs.
179 179
180 AUTO_LIBNAME_PKGS 180 AUTO_LIBNAME_PKGS
181 When the ```debian`` <#ref-classes-debian>`__ class is inherited, 181 When the :ref:`debian <ref-classes-debian>` class is inherited,
182 which is the default behavior, ``AUTO_LIBNAME_PKGS`` specifies which 182 which is the default behavior, ``AUTO_LIBNAME_PKGS`` specifies which
183 packages should be checked for libraries and renamed according to 183 packages should be checked for libraries and renamed according to
184 Debian library package naming. 184 Debian library package naming.
@@ -189,7 +189,7 @@ system and gives an overview of their function and contents.
189 AUTO_SYSLINUXMENU 189 AUTO_SYSLINUXMENU
190 Enables creating an automatic menu for the syslinux bootloader. You 190 Enables creating an automatic menu for the syslinux bootloader. You
191 must set this variable in your recipe. The 191 must set this variable in your recipe. The
192 ```syslinux`` <#ref-classes-syslinux>`__ class checks this variable. 192 :ref:`syslinux <ref-classes-syslinux>` class checks this variable.
193 193
194 AUTOREV 194 AUTOREV
195 When ``SRCREV`` is set to the value of this variable, it specifies to 195 When ``SRCREV`` is set to the value of this variable, it specifies to
@@ -197,10 +197,10 @@ system and gives an overview of their function and contents.
197 SRCREV = "${AUTOREV}" 197 SRCREV = "${AUTOREV}"
198 198
199 If you use the previous statement to retrieve the latest version of 199 If you use the previous statement to retrieve the latest version of
200 software, you need to be sure ```PV`` <#var-PV>`__ contains 200 software, you need to be sure :term:`PV` contains
201 ``${``\ ```SRCPV`` <#var-SRCPV>`__\ ``}``. For example, suppose you 201 ``${``\ :term:`SRCPV`\ ``}``. For example, suppose you
202 have a kernel recipe that inherits the 202 have a kernel recipe that inherits the
203 `kernel <#ref-classes-kernel>`__ class and you use the previous 203 :ref:`kernel <ref-classes-kernel>` class and you use the previous
204 statement. In this example, ``${SRCPV}`` does not automatically get 204 statement. In this example, ``${SRCPV}`` does not automatically get
205 into ``PV``. Consequently, you need to change ``PV`` in your recipe 205 into ``PV``. Consequently, you need to change ``PV`` in your recipe
206 so that it does contain ``${SRCPV}``. 206 so that it does contain ``${SRCPV}``.
@@ -212,8 +212,8 @@ system and gives an overview of their function and contents.
212 212
213 AVAILABLE_LICENSES 213 AVAILABLE_LICENSES
214 List of licenses found in the directories specified by 214 List of licenses found in the directories specified by
215 ```COMMON_LICENSE_DIR`` <#var-COMMON_LICENSE_DIR>`__ and 215 :term:`COMMON_LICENSE_DIR` and
216 ```LICENSE_PATH`` <#var-LICENSE_PATH>`__. 216 :term:`LICENSE_PATH`.
217 217
218 .. note:: 218 .. note::
219 219
@@ -245,10 +245,10 @@ system and gives an overview of their function and contents.
245 User Manual for more information. 245 User Manual for more information.
246 246
247 B 247 B
248 The directory within the `Build Directory <#build-directory>`__ in 248 The directory within the :term:`Build Directory` in
249 which the OpenEmbedded build system places generated objects during a 249 which the OpenEmbedded build system places generated objects during a
250 recipe's build process. By default, this directory is the same as the 250 recipe's build process. By default, this directory is the same as the
251 ```S`` <#var-S>`__ directory, which is defined as: S = 251 :term:`S` directory, which is defined as: S =
252 "${WORKDIR}/${BP}" 252 "${WORKDIR}/${BP}"
253 253
254 You can separate the (``S``) directory and the directory pointed to 254 You can separate the (``S``) directory and the directory pointed to
@@ -259,7 +259,7 @@ system and gives an overview of their function and contents.
259 BAD_RECOMMENDATIONS 259 BAD_RECOMMENDATIONS
260 Lists "recommended-only" packages to not install. Recommended-only 260 Lists "recommended-only" packages to not install. Recommended-only
261 packages are packages installed only through the 261 packages are packages installed only through the
262 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__ variable. You can prevent any 262 :term:`RRECOMMENDS` variable. You can prevent any
263 of these "recommended" packages from being installed by listing them 263 of these "recommended" packages from being installed by listing them
264 with the ``BAD_RECOMMENDATIONS`` variable: BAD_RECOMMENDATIONS = 264 with the ``BAD_RECOMMENDATIONS`` variable: BAD_RECOMMENDATIONS =
265 "package_name package_name package_name ..." 265 "package_name package_name package_name ..."
@@ -270,15 +270,15 @@ system and gives an overview of their function and contents.
270 270
271 It is important to realize that if you choose to not install packages 271 It is important to realize that if you choose to not install packages
272 using this variable and some other packages are dependent on them 272 using this variable and some other packages are dependent on them
273 (i.e. listed in a recipe's ```RDEPENDS`` <#var-RDEPENDS>`__ 273 (i.e. listed in a recipe's :term:`RDEPENDS`
274 variable), the OpenEmbedded build system ignores your request and 274 variable), the OpenEmbedded build system ignores your request and
275 will install the packages to avoid dependency errors. 275 will install the packages to avoid dependency errors.
276 276
277 Support for this variable exists only when using the IPK and RPM 277 Support for this variable exists only when using the IPK and RPM
278 packaging backend. Support does not exist for DEB. 278 packaging backend. Support does not exist for DEB.
279 279
280 See the ```NO_RECOMMENDATIONS`` <#var-NO_RECOMMENDATIONS>`__ and the 280 See the :term:`NO_RECOMMENDATIONS` and the
281 ```PACKAGE_EXCLUDE`` <#var-PACKAGE_EXCLUDE>`__ variables for related 281 :term:`PACKAGE_EXCLUDE` variables for related
282 information. 282 information.
283 283
284 BASE_LIB 284 BASE_LIB
@@ -291,7 +291,7 @@ system and gives an overview of their function and contents.
291 on Multilib. 291 on Multilib.
292 292
293 The ``BASE_LIB`` variable is defined in the machine include files in 293 The ``BASE_LIB`` variable is defined in the machine include files in
294 the `Source Directory <#source-directory>`__. If Multilib is not 294 the :term:`Source Directory`. If Multilib is not
295 being used, the value defaults to "lib". 295 being used, the value defaults to "lib".
296 296
297 BASE_WORKDIR 297 BASE_WORKDIR
@@ -327,10 +327,10 @@ system and gives an overview of their function and contents.
327 - Attempts to access networks not in the host list cause a failure. 327 - Attempts to access networks not in the host list cause a failure.
328 328
329 Using ``BB_ALLOWED_NETWORKS`` in conjunction with 329 Using ``BB_ALLOWED_NETWORKS`` in conjunction with
330 ```PREMIRRORS`` <#var-PREMIRRORS>`__ is very useful. Adding the host 330 :term:`PREMIRRORS` is very useful. Adding the host
331 you want to use to ``PREMIRRORS`` results in the source code being 331 you want to use to ``PREMIRRORS`` results in the source code being
332 fetched from an allowed location and avoids raising an error when a 332 fetched from an allowed location and avoids raising an error when a
333 host that is not allowed is in a ```SRC_URI`` <#var-SRC_URI>`__ 333 host that is not allowed is in a :term:`SRC_URI`
334 statement. This is because the fetcher does not attempt to use the 334 statement. This is because the fetcher does not attempt to use the
335 host listed in ``SRC_URI`` after a successful fetch from the 335 host listed in ``SRC_URI`` after a successful fetch from the
336 ``PREMIRRORS`` occurs. 336 ``PREMIRRORS`` occurs.
@@ -349,7 +349,7 @@ system and gives an overview of their function and contents.
349 349
350 You can change the default behavior by setting this variable to "1", 350 You can change the default behavior by setting this variable to "1",
351 "yes", or "true" in your ``local.conf`` file, which is located in the 351 "yes", or "true" in your ``local.conf`` file, which is located in the
352 `Build Directory <#build-directory>`__: Here is an example: 352 :term:`Build Directory`: Here is an example:
353 BB_DANGLINGAPPENDS_WARNONLY = "1" 353 BB_DANGLINGAPPENDS_WARNONLY = "1"
354 354
355 BB_DISKMON_DIRS 355 BB_DISKMON_DIRS
@@ -358,7 +358,7 @@ system and gives an overview of their function and contents.
358 358
359 Disk space monitoring is disabled by default. To enable monitoring, 359 Disk space monitoring is disabled by default. To enable monitoring,
360 add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file 360 add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file
361 found in the `Build Directory <#build-directory>`__. Use the 361 found in the :term:`Build Directory`. Use the
362 following form: BB_DISKMON_DIRS = "action,dir,threshold [...]" where: 362 following form: BB_DISKMON_DIRS = "action,dir,threshold [...]" where:
363 action is: ABORT: Immediately abort the build when a threshold is 363 action is: ABORT: Immediately abort the build when a threshold is
364 broken. STOPTASKS: Stop the build after the currently executing tasks 364 broken. STOPTASKS: Stop the build after the currently executing tasks
@@ -379,7 +379,7 @@ system and gives an overview of their function and contents.
379 WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS = 379 WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS =
380 "STOPTASKS,${TMPDIR},1G" BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" 380 "STOPTASKS,${TMPDIR},1G" BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
381 The first example works only if you also provide the 381 The first example works only if you also provide the
382 ```BB_DISKMON_WARNINTERVAL`` <#var-BB_DISKMON_WARNINTERVAL>`__ 382 :term:`BB_DISKMON_WARNINTERVAL`
383 variable in the ``conf/local.conf``. This example causes the build 383 variable in the ``conf/local.conf``. This example causes the build
384 system to immediately abort when either the disk space in 384 system to immediately abort when either the disk space in
385 ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops 385 ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops
@@ -402,10 +402,10 @@ system and gives an overview of their function and contents.
402 BB_DISKMON_WARNINTERVAL 402 BB_DISKMON_WARNINTERVAL
403 Defines the disk space and free inode warning intervals. To set these 403 Defines the disk space and free inode warning intervals. To set these
404 intervals, define the variable in your ``conf/local.conf`` file in 404 intervals, define the variable in your ``conf/local.conf`` file in
405 the `Build Directory <#build-directory>`__. 405 the :term:`Build Directory`.
406 406
407 If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you 407 If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you
408 must also use the ```BB_DISKMON_DIRS`` <#var-BB_DISKMON_DIRS>`__ 408 must also use the :term:`BB_DISKMON_DIRS`
409 variable and define its action as "WARN". During the build, 409 variable and define its action as "WARN". During the build,
410 subsequent warnings are issued each time disk space or number of free 410 subsequent warnings are issued each time disk space or number of free
411 inodes further reduces by the respective interval. 411 inodes further reduces by the respective interval.
@@ -436,12 +436,12 @@ system and gives an overview of their function and contents.
436 BB_GENERATE_MIRROR_TARBALLS 436 BB_GENERATE_MIRROR_TARBALLS
437 Causes tarballs of the source control repositories (e.g. Git 437 Causes tarballs of the source control repositories (e.g. Git
438 repositories), including metadata, to be placed in the 438 repositories), including metadata, to be placed in the
439 ```DL_DIR`` <#var-DL_DIR>`__ directory. 439 :term:`DL_DIR` directory.
440 440
441 For performance reasons, creating and placing tarballs of these 441 For performance reasons, creating and placing tarballs of these
442 repositories is not the default action by the OpenEmbedded build 442 repositories is not the default action by the OpenEmbedded build
443 system. BB_GENERATE_MIRROR_TARBALLS = "1" Set this variable in your 443 system. BB_GENERATE_MIRROR_TARBALLS = "1" Set this variable in your
444 ``local.conf`` file in the `Build Directory <#build-directory>`__. 444 ``local.conf`` file in the :term:`Build Directory`.
445 445
446 Once you have the tarballs containing your source files, you can 446 Once you have the tarballs containing your source files, you can
447 clean up your ``DL_DIR`` directory by deleting any Git or other 447 clean up your ``DL_DIR`` directory by deleting any Git or other
@@ -481,7 +481,7 @@ system and gives an overview of their function and contents.
481 ``quilt-native``, which is a copy of Quilt built to run on the build 481 ``quilt-native``, which is a copy of Quilt built to run on the build
482 system; "crosses" such as ``gcc-cross``, which is a compiler built to 482 system; "crosses" such as ``gcc-cross``, which is a compiler built to
483 run on the build machine but produces binaries that run on the target 483 run on the build machine but produces binaries that run on the target
484 ```MACHINE`` <#var-MACHINE>`__; "nativesdk", which targets the SDK 484 :term:`MACHINE`; "nativesdk", which targets the SDK
485 machine instead of ``MACHINE``; and "mulitlibs" in the form 485 machine instead of ``MACHINE``; and "mulitlibs" in the form
486 "``multilib:``\ multilib_name". 486 "``multilib:``\ multilib_name".
487 487
@@ -495,7 +495,7 @@ system and gives an overview of their function and contents.
495 Internally, the ``BBCLASSEXTEND`` mechanism generates recipe 495 Internally, the ``BBCLASSEXTEND`` mechanism generates recipe
496 variants by rewriting variable values and applying overrides such 496 variants by rewriting variable values and applying overrides such
497 as ``_class-native``. For example, to generate a native version of 497 as ``_class-native``. For example, to generate a native version of
498 a recipe, a ```DEPENDS`` <#var-DEPENDS>`__ on "foo" is rewritten 498 a recipe, a :term:`DEPENDS` on "foo" is rewritten
499 to a ``DEPENDS`` on "foo-native". 499 to a ``DEPENDS`` on "foo-native".
500 500
501 Even when using ``BBCLASSEXTEND``, the recipe is only parsed once. 501 Even when using ``BBCLASSEXTEND``, the recipe is only parsed once.
@@ -511,7 +511,7 @@ system and gives an overview of their function and contents.
511 511
512 BBFILE_PATTERN 512 BBFILE_PATTERN
513 Variable that expands to match files from 513 Variable that expands to match files from
514 ```BBFILES`` <#var-BBFILES>`__ in a particular layer. This variable 514 :term:`BBFILES` in a particular layer. This variable
515 is used in the ``conf/layer.conf`` file and must be suffixed with the 515 is used in the ``conf/layer.conf`` file and must be suffixed with the
516 name of the specific layer (e.g. ``BBFILE_PATTERN_emenlow``). 516 name of the specific layer (e.g. ``BBFILE_PATTERN_emenlow``).
517 517
@@ -523,7 +523,7 @@ system and gives an overview of their function and contents.
523 prioritize a layer against other layers that contain the same recipe 523 prioritize a layer against other layers that contain the same recipe
524 - effectively letting you control the precedence for the multiple 524 - effectively letting you control the precedence for the multiple
525 layers. The precedence established through this variable stands 525 layers. The precedence established through this variable stands
526 regardless of a recipe's version (```PV`` <#var-PV>`__ variable). For 526 regardless of a recipe's version (:term:`PV` variable). For
527 example, a layer that has a recipe with a higher ``PV`` value but for 527 example, a layer that has a recipe with a higher ``PV`` value but for
528 which the ``BBFILE_PRIORITY`` is set to have a lower precedence still 528 which the ``BBFILE_PRIORITY`` is set to have a lower precedence still
529 has a lower precedence. 529 has a lower precedence.
@@ -576,7 +576,7 @@ system and gives an overview of their function and contents.
576 Variable that controls how BitBake displays logs on build failure. 576 Variable that controls how BitBake displays logs on build failure.
577 577
578 BBINCLUDELOGS_LINES 578 BBINCLUDELOGS_LINES
579 If ```BBINCLUDELOGS`` <#var-BBINCLUDELOGS>`__ is set, specifies the 579 If :term:`BBINCLUDELOGS` is set, specifies the
580 maximum number of lines from the task log file to print when 580 maximum number of lines from the task log file to print when
581 reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``, 581 reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``,
582 the entire log is printed. 582 the entire log is printed.
@@ -629,7 +629,7 @@ system and gives an overview of their function and contents.
629 multiconfigname for each configuration file you are using. For 629 multiconfigname for each configuration file you are using. For
630 example, the following line specifies three configuration files: 630 example, the following line specifies three configuration files:
631 BBMULTICONFIG = "configA configB configC" Each configuration file you 631 BBMULTICONFIG = "configA configB configC" Each configuration file you
632 use must reside in the `Build Directory <#build-directory>`__ 632 use must reside in the :term:`Build Directory`
633 ``conf/multiconfig`` directory (e.g. 633 ``conf/multiconfig`` directory (e.g.
634 build_directory\ ``/conf/multiconfig/configA.conf``). 634 build_directory\ ``/conf/multiconfig/configA.conf``).
635 635
@@ -672,7 +672,7 @@ system and gives an overview of their function and contents.
672 672
673 BINCONFIG 673 BINCONFIG
674 When inheriting the 674 When inheriting the
675 ```binconfig-disabled`` <#ref-classes-binconfig-disabled>`__ class, 675 :ref:`binconfig-disabled <ref-classes-binconfig-disabled>` class,
676 this variable specifies binary configuration scripts to disable in 676 this variable specifies binary configuration scripts to disable in
677 favor of using ``pkg-config`` to query the information. The 677 favor of using ``pkg-config`` to query the information. The
678 ``binconfig-disabled`` class will modify the specified scripts to 678 ``binconfig-disabled`` class will modify the specified scripts to
@@ -684,7 +684,7 @@ system and gives an overview of their function and contents.
684 ${bindir}/libpng16-config" 684 ${bindir}/libpng16-config"
685 685
686 BINCONFIG_GLOB 686 BINCONFIG_GLOB
687 When inheriting the ```binconfig`` <#ref-classes-binconfig>`__ class, 687 When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
688 this variable specifies a wildcard for configuration scripts that 688 this variable specifies a wildcard for configuration scripts that
689 need editing. The scripts are edited to correct any paths that have 689 need editing. The scripts are edited to correct any paths that have
690 been set up during compilation so that they are correct for use when 690 been set up during compilation so that they are correct for use when
@@ -708,7 +708,7 @@ system and gives an overview of their function and contents.
708 ``meta/classes/binconfig.bbclass`` in the `Source 708 ``meta/classes/binconfig.bbclass`` in the `Source
709 Directory <#source-directory>`__. You can also find general 709 Directory <#source-directory>`__. You can also find general
710 information on the class in the 710 information on the class in the
711 "```binconfig.bbclass`` <#ref-classes-binconfig>`__" section. 711 ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
712 712
713 BP 713 BP
714 The base recipe name and version but without any special recipe name 714 The base recipe name and version but without any special recipe name
@@ -716,12 +716,12 @@ system and gives an overview of their function and contents.
716 comprised of the following: ${BPN}-${PV} 716 comprised of the following: ${BPN}-${PV}
717 717
718 BPN 718 BPN
719 This variable is a version of the ```PN`` <#var-PN>`__ variable with 719 This variable is a version of the :term:`PN` variable with
720 common prefixes and suffixes removed, such as ``nativesdk-``, 720 common prefixes and suffixes removed, such as ``nativesdk-``,
721 ``-cross``, ``-native``, and multilib's ``lib64-`` and ``lib32-``. 721 ``-cross``, ``-native``, and multilib's ``lib64-`` and ``lib32-``.
722 The exact lists of prefixes and suffixes removed are specified by the 722 The exact lists of prefixes and suffixes removed are specified by the
723 ```MLPREFIX`` <#var-MLPREFIX>`__ and 723 :term:`MLPREFIX` and
724 ```SPECIAL_PKGSUFFIX`` <#var-SPECIAL_PKGSUFFIX>`__ variables, 724 :term:`SPECIAL_PKGSUFFIX` variables,
725 respectively. 725 respectively.
726 726
727 BUGTRACKER 727 BUGTRACKER
@@ -747,37 +747,37 @@ system and gives an overview of their function and contents.
747 Specifies the linker command to be used for the build host when the C 747 Specifies the linker command to be used for the build host when the C
748 compiler is being used as the linker. By default, ``BUILD_CCLD`` 748 compiler is being used as the linker. By default, ``BUILD_CCLD``
749 points to GCC and passes as arguments the value of 749 points to GCC and passes as arguments the value of
750 ```BUILD_CC_ARCH`` <#var-BUILD_CC_ARCH>`__, assuming 750 :term:`BUILD_CC_ARCH`, assuming
751 ``BUILD_CC_ARCH`` is set. 751 ``BUILD_CC_ARCH`` is set.
752 752
753 BUILD_CFLAGS 753 BUILD_CFLAGS
754 Specifies the flags to pass to the C compiler when building for the 754 Specifies the flags to pass to the C compiler when building for the
755 build host. When building in the ``-native`` context, 755 build host. When building in the ``-native`` context,
756 ```CFLAGS`` <#var-CFLAGS>`__ is set to the value of this variable by 756 :term:`CFLAGS` is set to the value of this variable by
757 default. 757 default.
758 758
759 BUILD_CPPFLAGS 759 BUILD_CPPFLAGS
760 Specifies the flags to pass to the C preprocessor (i.e. to both the C 760 Specifies the flags to pass to the C preprocessor (i.e. to both the C
761 and the C++ compilers) when building for the build host. When 761 and the C++ compilers) when building for the build host. When
762 building in the ``-native`` context, ```CPPFLAGS`` <#var-CPPFLAGS>`__ 762 building in the ``-native`` context, :term:`CPPFLAGS`
763 is set to the value of this variable by default. 763 is set to the value of this variable by default.
764 764
765 BUILD_CXXFLAGS 765 BUILD_CXXFLAGS
766 Specifies the flags to pass to the C++ compiler when building for the 766 Specifies the flags to pass to the C++ compiler when building for the
767 build host. When building in the ``-native`` context, 767 build host. When building in the ``-native`` context,
768 ```CXXFLAGS`` <#var-CXXFLAGS>`__ is set to the value of this variable 768 :term:`CXXFLAGS` is set to the value of this variable
769 by default. 769 by default.
770 770
771 BUILD_FC 771 BUILD_FC
772 Specifies the Fortran compiler command for the build host. By 772 Specifies the Fortran compiler command for the build host. By
773 default, ``BUILD_FC`` points to Gfortran and passes as arguments the 773 default, ``BUILD_FC`` points to Gfortran and passes as arguments the
774 value of ```BUILD_CC_ARCH`` <#var-BUILD_CC_ARCH>`__, assuming 774 value of :term:`BUILD_CC_ARCH`, assuming
775 ``BUILD_CC_ARCH`` is set. 775 ``BUILD_CC_ARCH`` is set.
776 776
777 BUILD_LD 777 BUILD_LD
778 Specifies the linker command for the build host. By default, 778 Specifies the linker command for the build host. By default,
779 ``BUILD_LD`` points to the GNU linker (ld) and passes as arguments 779 ``BUILD_LD`` points to the GNU linker (ld) and passes as arguments
780 the value of ```BUILD_LD_ARCH`` <#var-BUILD_LD_ARCH>`__, assuming 780 the value of :term:`BUILD_LD_ARCH`, assuming
781 ``BUILD_LD_ARCH`` is set. 781 ``BUILD_LD_ARCH`` is set.
782 782
783 BUILD_LD_ARCH 783 BUILD_LD_ARCH
@@ -787,14 +787,14 @@ system and gives an overview of their function and contents.
787 BUILD_LDFLAGS 787 BUILD_LDFLAGS
788 Specifies the flags to pass to the linker when building for the build 788 Specifies the flags to pass to the linker when building for the build
789 host. When building in the ``-native`` context, 789 host. When building in the ``-native`` context,
790 ```LDFLAGS`` <#var-LDFLAGS>`__ is set to the value of this variable 790 :term:`LDFLAGS` is set to the value of this variable
791 by default. 791 by default.
792 792
793 BUILD_OPTIMIZATION 793 BUILD_OPTIMIZATION
794 Specifies the optimization flags passed to the C compiler when 794 Specifies the optimization flags passed to the C compiler when
795 building for the build host or the SDK. The flags are passed through 795 building for the build host or the SDK. The flags are passed through
796 the ```BUILD_CFLAGS`` <#var-BUILD_CFLAGS>`__ and 796 the :term:`BUILD_CFLAGS` and
797 ```BUILDSDK_CFLAGS`` <#var-BUILDSDK_CFLAGS>`__ default values. 797 :term:`BUILDSDK_CFLAGS` default values.
798 798
799 The default value of the ``BUILD_OPTIMIZATION`` variable is "-O2 799 The default value of the ``BUILD_OPTIMIZATION`` variable is "-O2
800 -pipe". 800 -pipe".
@@ -808,14 +808,14 @@ system and gives an overview of their function and contents.
808 BUILD_PREFIX 808 BUILD_PREFIX
809 The toolchain binary prefix used for native recipes. The OpenEmbedded 809 The toolchain binary prefix used for native recipes. The OpenEmbedded
810 build system uses the ``BUILD_PREFIX`` value to set the 810 build system uses the ``BUILD_PREFIX`` value to set the
811 ```TARGET_PREFIX`` <#var-TARGET_PREFIX>`__ when building for 811 :term:`TARGET_PREFIX` when building for
812 ``native`` recipes. 812 ``native`` recipes.
813 813
814 BUILD_STRIP 814 BUILD_STRIP
815 Specifies the command to be used to strip debugging symbols from 815 Specifies the command to be used to strip debugging symbols from
816 binaries produced for the build host. By default, ``BUILD_STRIP`` 816 binaries produced for the build host. By default, ``BUILD_STRIP``
817 points to 817 points to
818 ``${``\ ```BUILD_PREFIX`` <#var-BUILD_PREFIX>`__\ ``}strip``. 818 ``${``\ :term:`BUILD_PREFIX`\ ``}strip``.
819 819
820 BUILD_SYS 820 BUILD_SYS
821 Specifies the system, including the architecture and the operating 821 Specifies the system, including the architecture and the operating
@@ -823,9 +823,9 @@ system and gives an overview of their function and contents.
823 ``native`` recipes). 823 ``native`` recipes).
824 824
825 The OpenEmbedded build system automatically sets this variable based 825 The OpenEmbedded build system automatically sets this variable based
826 on ```BUILD_ARCH`` <#var-BUILD_ARCH>`__, 826 on :term:`BUILD_ARCH`,
827 ```BUILD_VENDOR`` <#var-BUILD_VENDOR>`__, and 827 :term:`BUILD_VENDOR`, and
828 ```BUILD_OS`` <#var-BUILD_OS>`__. You do not need to set the 828 :term:`BUILD_OS`. You do not need to set the
829 ``BUILD_SYS`` variable yourself. 829 ``BUILD_SYS`` variable yourself.
830 830
831 BUILD_VENDOR 831 BUILD_VENDOR
@@ -833,7 +833,7 @@ system and gives an overview of their function and contents.
833 The default value is an empty string (""). 833 The default value is an empty string ("").
834 834
835 BUILDDIR 835 BUILDDIR
836 Points to the location of the `Build Directory <#build-directory>`__. 836 Points to the location of the :term:`Build Directory`.
837 You can define this directory indirectly through the 837 You can define this directory indirectly through the
838 ````` <#structure-core-script>`__ script by passing in a Build 838 ````` <#structure-core-script>`__ script by passing in a Build
839 Directory path when you run the script. If you run the script and do 839 Directory path when you run the script. If you run the script and do
@@ -841,7 +841,7 @@ system and gives an overview of their function and contents.
841 ``build`` in the current directory. 841 ``build`` in the current directory.
842 842
843 BUILDHISTORY_COMMIT 843 BUILDHISTORY_COMMIT
844 When inheriting the ```buildhistory`` <#ref-classes-buildhistory>`__ 844 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
845 class, this variable specifies whether or not to commit the build 845 class, this variable specifies whether or not to commit the build
846 history output in a local Git repository. If set to "1", this local 846 history output in a local Git repository. If set to "1", this local
847 repository will be maintained automatically by the ``buildhistory`` 847 repository will be maintained automatically by the ``buildhistory``
@@ -854,10 +854,10 @@ system and gives an overview of their function and contents.
854 history output in a local Git repository: BUILDHISTORY_COMMIT ?= "0" 854 history output in a local Git repository: BUILDHISTORY_COMMIT ?= "0"
855 855
856 BUILDHISTORY_COMMIT_AUTHOR 856 BUILDHISTORY_COMMIT_AUTHOR
857 When inheriting the ```buildhistory`` <#ref-classes-buildhistory>`__ 857 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
858 class, this variable specifies the author to use for each Git commit. 858 class, this variable specifies the author to use for each Git commit.
859 In order for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable to work, the 859 In order for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable to work, the
860 ```BUILDHISTORY_COMMIT`` <#var-BUILDHISTORY_COMMIT>`__ variable must 860 :term:`BUILDHISTORY_COMMIT` variable must
861 be set to "1". 861 be set to "1".
862 862
863 Git requires that the value you provide for the 863 Git requires that the value you provide for the
@@ -869,7 +869,7 @@ system and gives an overview of their function and contents.
869 BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>" 869 BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
870 870
871 BUILDHISTORY_DIR 871 BUILDHISTORY_DIR
872 When inheriting the ```buildhistory`` <#ref-classes-buildhistory>`__ 872 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
873 class, this variable specifies the directory in which build history 873 class, this variable specifies the directory in which build history
874 information is kept. For more information on how the variable works, 874 information is kept. For more information on how the variable works,
875 see the ``buildhistory.class``. 875 see the ``buildhistory.class``.
@@ -878,7 +878,7 @@ system and gives an overview of their function and contents.
878 BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory" 878 BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
879 879
880 BUILDHISTORY_FEATURES 880 BUILDHISTORY_FEATURES
881 When inheriting the ```buildhistory`` <#ref-classes-buildhistory>`__ 881 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
882 class, this variable specifies the build history features to be 882 class, this variable specifies the build history features to be
883 enabled. For more information on how build history works, see the 883 enabled. For more information on how build history works, see the
884 "`Maintaining Build Output 884 "`Maintaining Build Output
@@ -904,7 +904,7 @@ system and gives an overview of their function and contents.
904 features: BUILDHISTORY_FEATURES ?= "image package sdk" 904 features: BUILDHISTORY_FEATURES ?= "image package sdk"
905 905
906 BUILDHISTORY_IMAGE_FILES 906 BUILDHISTORY_IMAGE_FILES
907 When inheriting the ```buildhistory`` <#ref-classes-buildhistory>`__ 907 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
908 class, this variable specifies a list of paths to files copied from 908 class, this variable specifies a list of paths to files copied from
909 the image contents into the build history directory under an 909 the image contents into the build history directory under an
910 "image-files" directory in the directory for the image, so that you 910 "image-files" directory in the directory for the image, so that you
@@ -918,11 +918,11 @@ system and gives an overview of their function and contents.
918 following files: BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group" 918 following files: BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
919 919
920 BUILDHISTORY_PUSH_REPO 920 BUILDHISTORY_PUSH_REPO
921 When inheriting the ```buildhistory`` <#ref-classes-buildhistory>`__ 921 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
922 class, this variable optionally specifies a remote repository to 922 class, this variable optionally specifies a remote repository to
923 which build history pushes Git changes. In order for 923 which build history pushes Git changes. In order for
924 ``BUILDHISTORY_PUSH_REPO`` to work, 924 ``BUILDHISTORY_PUSH_REPO`` to work,
925 ```BUILDHISTORY_COMMIT`` <#var-BUILDHISTORY_COMMIT>`__ must be set to 925 :term:`BUILDHISTORY_COMMIT` must be set to
926 "1". 926 "1".
927 927
928 The repository should correspond to a remote address that specifies a 928 The repository should correspond to a remote address that specifies a
@@ -936,33 +936,33 @@ system and gives an overview of their function and contents.
936 BUILDSDK_CFLAGS 936 BUILDSDK_CFLAGS
937 Specifies the flags to pass to the C compiler when building for the 937 Specifies the flags to pass to the C compiler when building for the
938 SDK. When building in the ``nativesdk-`` context, 938 SDK. When building in the ``nativesdk-`` context,
939 ```CFLAGS`` <#var-CFLAGS>`__ is set to the value of this variable by 939 :term:`CFLAGS` is set to the value of this variable by
940 default. 940 default.
941 941
942 BUILDSDK_CPPFLAGS 942 BUILDSDK_CPPFLAGS
943 Specifies the flags to pass to the C pre-processor (i.e. to both the 943 Specifies the flags to pass to the C pre-processor (i.e. to both the
944 C and the C++ compilers) when building for the SDK. When building in 944 C and the C++ compilers) when building for the SDK. When building in
945 the ``nativesdk-`` context, ```CPPFLAGS`` <#var-CPPFLAGS>`__ is set 945 the ``nativesdk-`` context, :term:`CPPFLAGS` is set
946 to the value of this variable by default. 946 to the value of this variable by default.
947 947
948 BUILDSDK_CXXFLAGS 948 BUILDSDK_CXXFLAGS
949 Specifies the flags to pass to the C++ compiler when building for the 949 Specifies the flags to pass to the C++ compiler when building for the
950 SDK. When building in the ``nativesdk-`` context, 950 SDK. When building in the ``nativesdk-`` context,
951 ```CXXFLAGS`` <#var-CXXFLAGS>`__ is set to the value of this variable 951 :term:`CXXFLAGS` is set to the value of this variable
952 by default. 952 by default.
953 953
954 BUILDSDK_LDFLAGS 954 BUILDSDK_LDFLAGS
955 Specifies the flags to pass to the linker when building for the SDK. 955 Specifies the flags to pass to the linker when building for the SDK.
956 When building in the ``nativesdk-`` context, 956 When building in the ``nativesdk-`` context,
957 ```LDFLAGS`` <#var-LDFLAGS>`__ is set to the value of this variable 957 :term:`LDFLAGS` is set to the value of this variable
958 by default. 958 by default.
959 959
960 BUILDSTATS_BASE 960 BUILDSTATS_BASE
961 Points to the location of the directory that holds build statistics 961 Points to the location of the directory that holds build statistics
962 when you use and enable the 962 when you use and enable the
963 ```buildstats`` <#ref-classes-buildstats>`__ class. The 963 :ref:`buildstats <ref-classes-buildstats>` class. The
964 ``BUILDSTATS_BASE`` directory defaults to 964 ``BUILDSTATS_BASE`` directory defaults to
965 ``${``\ ```TMPDIR`` <#var-TMPDIR>`__\ ``}/buildstats/``. 965 ``${``\ :term:`TMPDIR`\ ``}/buildstats/``.
966 966
967 BUSYBOX_SPLIT_SUID 967 BUSYBOX_SPLIT_SUID
968 For the BusyBox recipe, specifies whether to split the output 968 For the BusyBox recipe, specifies whether to split the output
@@ -976,7 +976,7 @@ system and gives an overview of their function and contents.
976 976
977 CACHE 977 CACHE
978 Specifies the directory BitBake uses to store a cache of the 978 Specifies the directory BitBake uses to store a cache of the
979 `Metadata <#metadata>`__ so it does not need to be parsed every time 979 :term:`Metadata` so it does not need to be parsed every time
980 BitBake is started. 980 BitBake is started.
981 981
982 CC 982 CC
@@ -990,21 +990,21 @@ system and gives an overview of their function and contents.
990 Default initialization for ``CFLAGS`` varies depending on what is 990 Default initialization for ``CFLAGS`` varies depending on what is
991 being built: 991 being built:
992 992
993 - ```TARGET_CFLAGS`` <#var-TARGET_CFLAGS>`__ when building for the 993 - :term:`TARGET_CFLAGS` when building for the
994 target 994 target
995 995
996 - ```BUILD_CFLAGS`` <#var-BUILD_CFLAGS>`__ when building for the 996 - :term:`BUILD_CFLAGS` when building for the
997 build host (i.e. ``-native``) 997 build host (i.e. ``-native``)
998 998
999 - ```BUILDSDK_CFLAGS`` <#var-BUILDSDK_CFLAGS>`__ when building for 999 - :term:`BUILDSDK_CFLAGS` when building for
1000 an SDK (i.e. ``nativesdk-``) 1000 an SDK (i.e. ``nativesdk-``)
1001 1001
1002 CLASSOVERRIDE 1002 CLASSOVERRIDE
1003 An internal variable specifying the special class override that 1003 An internal variable specifying the special class override that
1004 should currently apply (e.g. "class-target", "class-native", and so 1004 should currently apply (e.g. "class-target", "class-native", and so
1005 forth). The classes that use this variable (e.g. 1005 forth). The classes that use this variable (e.g.
1006 ```native`` <#ref-classes-native>`__, 1006 :ref:`native <ref-classes-native>`,
1007 ```nativesdk`` <#ref-classes-nativesdk>`__, and so forth) set the 1007 :ref:`nativesdk <ref-classes-nativesdk>`, and so forth) set the
1008 variable to appropriate values. 1008 variable to appropriate values.
1009 1009
1010 .. note:: 1010 .. note::
@@ -1022,19 +1022,19 @@ system and gives an overview of their function and contents.
1022 building for the build host: FOO_class-native = "native" FOO = 1022 building for the build host: FOO_class-native = "native" FOO =
1023 "other" The underlying mechanism behind ``CLASSOVERRIDE`` is simply 1023 "other" The underlying mechanism behind ``CLASSOVERRIDE`` is simply
1024 that it is included in the default value of 1024 that it is included in the default value of
1025 ```OVERRIDES`` <#var-OVERRIDES>`__. 1025 :term:`OVERRIDES`.
1026 1026
1027 CLEANBROKEN 1027 CLEANBROKEN
1028 If set to "1" within a recipe, ``CLEANBROKEN`` specifies that the 1028 If set to "1" within a recipe, ``CLEANBROKEN`` specifies that the
1029 ``make clean`` command does not work for the software being built. 1029 ``make clean`` command does not work for the software being built.
1030 Consequently, the OpenEmbedded build system will not try to run 1030 Consequently, the OpenEmbedded build system will not try to run
1031 ``make clean`` during the ```do_configure`` <#ref-tasks-configure>`__ 1031 ``make clean`` during the :ref:`ref-tasks-configure`
1032 task, which is the default behavior. 1032 task, which is the default behavior.
1033 1033
1034 COMBINED_FEATURES 1034 COMBINED_FEATURES
1035 Provides a list of hardware features that are enabled in both 1035 Provides a list of hardware features that are enabled in both
1036 ```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__ and 1036 :term:`MACHINE_FEATURES` and
1037 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. This select list of 1037 :term:`DISTRO_FEATURES`. This select list of
1038 features contains features that make sense to be controlled both at 1038 features contains features that make sense to be controlled both at
1039 the machine and distribution configuration level. For example, the 1039 the machine and distribution configuration level. For example, the
1040 "bluetooth" feature requires hardware support but should also be 1040 "bluetooth" feature requires hardware support but should also be
@@ -1050,7 +1050,7 @@ system and gives an overview of their function and contents.
1050 A regular expression that resolves to one or more hosts (when the 1050 A regular expression that resolves to one or more hosts (when the
1051 recipe is native) or one or more targets (when the recipe is 1051 recipe is native) or one or more targets (when the recipe is
1052 non-native) with which a recipe is compatible. The regular expression 1052 non-native) with which a recipe is compatible. The regular expression
1053 is matched against ```HOST_SYS`` <#var-HOST_SYS>`__. You can use the 1053 is matched against :term:`HOST_SYS`. You can use the
1054 variable to stop recipes from being built for classes of systems with 1054 variable to stop recipes from being built for classes of systems with
1055 which the recipes are not compatible. Stopping these builds is 1055 which the recipes are not compatible. Stopping these builds is
1056 particularly useful with kernels. The variable also helps to increase 1056 particularly useful with kernels. The variable also helps to increase
@@ -1060,7 +1060,7 @@ system and gives an overview of their function and contents.
1060 COMPATIBLE_MACHINE 1060 COMPATIBLE_MACHINE
1061 A regular expression that resolves to one or more target machines 1061 A regular expression that resolves to one or more target machines
1062 with which a recipe is compatible. The regular expression is matched 1062 with which a recipe is compatible. The regular expression is matched
1063 against ```MACHINEOVERRIDES`` <#var-MACHINEOVERRIDES>`__. You can use 1063 against :term:`MACHINEOVERRIDES`. You can use
1064 the variable to stop recipes from being built for machines with which 1064 the variable to stop recipes from being built for machines with which
1065 the recipes are not compatible. Stopping these builds is particularly 1065 the recipes are not compatible. Stopping these builds is particularly
1066 useful with kernels. The variable also helps to increase parsing 1066 useful with kernels. The variable also helps to increase parsing
@@ -1084,7 +1084,7 @@ system and gives an overview of their function and contents.
1084 1084
1085 The resulting list of complementary packages is associated with an 1085 The resulting list of complementary packages is associated with an
1086 item that can be added to 1086 item that can be added to
1087 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__. An example usage of 1087 :term:`IMAGE_FEATURES`. An example usage of
1088 this is the "dev-pkgs" item that when added to ``IMAGE_FEATURES`` 1088 this is the "dev-pkgs" item that when added to ``IMAGE_FEATURES``
1089 will install -dev packages (containing headers and other development 1089 will install -dev packages (containing headers and other development
1090 files) for every package in the image. 1090 files) for every package in the image.
@@ -1099,9 +1099,9 @@ system and gives an overview of their function and contents.
1099 sysroots for other recipes. 1099 sysroots for other recipes.
1100 1100
1101 The default is 1101 The default is
1102 "``${``\ ```STAGING_DIR`` <#var-STAGING_DIR>`__\ ``}-components``." 1102 "``${``\ :term:`STAGING_DIR`\ ``}-components``."
1103 (i.e. 1103 (i.e.
1104 "``${``\ ```TMPDIR`` <#var-TMPDIR>`__\ ``}/sysroots-components``"). 1104 "``${``\ :term:`TMPDIR`\ ``}/sysroots-components``").
1105 1105
1106 CONF_VERSION 1106 CONF_VERSION
1107 Tracks the version of the local configuration file (i.e. 1107 Tracks the version of the local configuration file (i.e.
@@ -1183,7 +1183,7 @@ system and gives an overview of their function and contents.
1183 1183
1184 CONFLICT_DISTRO_FEATURES 1184 CONFLICT_DISTRO_FEATURES
1185 When inheriting the 1185 When inheriting the
1186 ```distro_features_check`` <#ref-classes-distro_features_check>`__ 1186 :ref:`distro_features_check <ref-classes-distro_features_check>`
1187 class, this variable identifies distribution features that would be 1187 class, this variable identifies distribution features that would be
1188 in conflict should the recipe be built. In other words, if the 1188 in conflict should the recipe be built. In other words, if the
1189 ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also 1189 ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also
@@ -1192,9 +1192,9 @@ system and gives an overview of their function and contents.
1192 1192
1193 COPYLEFT_LICENSE_EXCLUDE 1193 COPYLEFT_LICENSE_EXCLUDE
1194 A space-separated list of licenses to exclude from the source 1194 A space-separated list of licenses to exclude from the source
1195 archived by the ```archiver`` <#ref-classes-archiver>`__ class. In 1195 archived by the :ref:`archiver <ref-classes-archiver>` class. In
1196 other words, if a license in a recipe's 1196 other words, if a license in a recipe's
1197 ```LICENSE`` <#var-LICENSE>`__ value is in the value of 1197 :term:`LICENSE` value is in the value of
1198 ``COPYLEFT_LICENSE_EXCLUDE``, then its source is not archived by the 1198 ``COPYLEFT_LICENSE_EXCLUDE``, then its source is not archived by the
1199 class. 1199 class.
1200 1200
@@ -1208,62 +1208,62 @@ system and gives an overview of their function and contents.
1208 1208
1209 The default value, which is "CLOSED Proprietary", for 1209 The default value, which is "CLOSED Proprietary", for
1210 ``COPYLEFT_LICENSE_EXCLUDE`` is set by the 1210 ``COPYLEFT_LICENSE_EXCLUDE`` is set by the
1211 ```copyleft_filter`` <#ref-classes-copyleft_filter>`__ class, which 1211 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1212 is inherited by the ``archiver`` class. 1212 is inherited by the ``archiver`` class.
1213 1213
1214 COPYLEFT_LICENSE_INCLUDE 1214 COPYLEFT_LICENSE_INCLUDE
1215 A space-separated list of licenses to include in the source archived 1215 A space-separated list of licenses to include in the source archived
1216 by the ```archiver`` <#ref-classes-archiver>`__ class. In other 1216 by the :ref:`archiver <ref-classes-archiver>` class. In other
1217 words, if a license in a recipe's ```LICENSE`` <#var-LICENSE>`__ 1217 words, if a license in a recipe's :term:`LICENSE`
1218 value is in the value of ``COPYLEFT_LICENSE_INCLUDE``, then its 1218 value is in the value of ``COPYLEFT_LICENSE_INCLUDE``, then its
1219 source is archived by the class. 1219 source is archived by the class.
1220 1220
1221 The default value is set by the 1221 The default value is set by the
1222 ```copyleft_filter`` <#ref-classes-copyleft_filter>`__ class, which 1222 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1223 is inherited by the ``archiver`` class. The default value includes 1223 is inherited by the ``archiver`` class. The default value includes
1224 "GPL*", "LGPL*", and "AGPL*". 1224 "GPL*", "LGPL*", and "AGPL*".
1225 1225
1226 COPYLEFT_PN_EXCLUDE 1226 COPYLEFT_PN_EXCLUDE
1227 A list of recipes to exclude in the source archived by the 1227 A list of recipes to exclude in the source archived by the
1228 ```archiver`` <#ref-classes-archiver>`__ class. The 1228 :ref:`archiver <ref-classes-archiver>` class. The
1229 ``COPYLEFT_PN_EXCLUDE`` variable overrides the license inclusion and 1229 ``COPYLEFT_PN_EXCLUDE`` variable overrides the license inclusion and
1230 exclusion caused through the 1230 exclusion caused through the
1231 ```COPYLEFT_LICENSE_INCLUDE`` <#var-COPYLEFT_LICENSE_INCLUDE>`__ and 1231 :term:`COPYLEFT_LICENSE_INCLUDE` and
1232 ```COPYLEFT_LICENSE_EXCLUDE`` <#var-COPYLEFT_LICENSE_EXCLUDE>`__ 1232 :term:`COPYLEFT_LICENSE_EXCLUDE`
1233 variables, respectively. 1233 variables, respectively.
1234 1234
1235 The default value, which is "" indicating to not explicitly exclude 1235 The default value, which is "" indicating to not explicitly exclude
1236 any recipes by name, for ``COPYLEFT_PN_EXCLUDE`` is set by the 1236 any recipes by name, for ``COPYLEFT_PN_EXCLUDE`` is set by the
1237 ```copyleft_filter`` <#ref-classes-copyleft_filter>`__ class, which 1237 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1238 is inherited by the ``archiver`` class. 1238 is inherited by the ``archiver`` class.
1239 1239
1240 COPYLEFT_PN_INCLUDE 1240 COPYLEFT_PN_INCLUDE
1241 A list of recipes to include in the source archived by the 1241 A list of recipes to include in the source archived by the
1242 ```archiver`` <#ref-classes-archiver>`__ class. The 1242 :ref:`archiver <ref-classes-archiver>` class. The
1243 ``COPYLEFT_PN_INCLUDE`` variable overrides the license inclusion and 1243 ``COPYLEFT_PN_INCLUDE`` variable overrides the license inclusion and
1244 exclusion caused through the 1244 exclusion caused through the
1245 ```COPYLEFT_LICENSE_INCLUDE`` <#var-COPYLEFT_LICENSE_INCLUDE>`__ and 1245 :term:`COPYLEFT_LICENSE_INCLUDE` and
1246 ```COPYLEFT_LICENSE_EXCLUDE`` <#var-COPYLEFT_LICENSE_EXCLUDE>`__ 1246 :term:`COPYLEFT_LICENSE_EXCLUDE`
1247 variables, respectively. 1247 variables, respectively.
1248 1248
1249 The default value, which is "" indicating to not explicitly include 1249 The default value, which is "" indicating to not explicitly include
1250 any recipes by name, for ``COPYLEFT_PN_INCLUDE`` is set by the 1250 any recipes by name, for ``COPYLEFT_PN_INCLUDE`` is set by the
1251 ```copyleft_filter`` <#ref-classes-copyleft_filter>`__ class, which 1251 :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
1252 is inherited by the ``archiver`` class. 1252 is inherited by the ``archiver`` class.
1253 1253
1254 COPYLEFT_RECIPE_TYPES 1254 COPYLEFT_RECIPE_TYPES
1255 A space-separated list of recipe types to include in the source 1255 A space-separated list of recipe types to include in the source
1256 archived by the ```archiver`` <#ref-classes-archiver>`__ class. 1256 archived by the :ref:`archiver <ref-classes-archiver>` class.
1257 Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``, 1257 Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``,
1258 ``crosssdk``, and ``cross-canadian``. 1258 ``crosssdk``, and ``cross-canadian``.
1259 1259
1260 The default value, which is "target*", for ``COPYLEFT_RECIPE_TYPES`` 1260 The default value, which is "target*", for ``COPYLEFT_RECIPE_TYPES``
1261 is set by the ```copyleft_filter`` <#ref-classes-copyleft_filter>`__ 1261 is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
1262 class, which is inherited by the ``archiver`` class. 1262 class, which is inherited by the ``archiver`` class.
1263 1263
1264 COPY_LIC_DIRS 1264 COPY_LIC_DIRS
1265 If set to "1" along with the 1265 If set to "1" along with the
1266 ```COPY_LIC_MANIFEST`` <#var-COPY_LIC_MANIFEST>`__ variable, the 1266 :term:`COPY_LIC_MANIFEST` variable, the
1267 OpenEmbedded build system copies into the image the license files, 1267 OpenEmbedded build system copies into the image the license files,
1268 which are located in ``/usr/share/common-licenses``, for each 1268 which are located in ``/usr/share/common-licenses``, for each
1269 package. The license files are placed in directories within the image 1269 package. The license files are placed in directories within the image
@@ -1304,7 +1304,7 @@ system and gives an overview of their function and contents.
1304 CORE_IMAGE_EXTRA_INSTALL 1304 CORE_IMAGE_EXTRA_INSTALL
1305 Specifies the list of packages to be added to the image. You should 1305 Specifies the list of packages to be added to the image. You should
1306 only set this variable in the ``local.conf`` configuration file found 1306 only set this variable in the ``local.conf`` configuration file found
1307 in the `Build Directory <#build-directory>`__. 1307 in the :term:`Build Directory`.
1308 1308
1309 This variable replaces ``POKY_EXTRA_INSTALL``, which is no longer 1309 This variable replaces ``POKY_EXTRA_INSTALL``, which is no longer
1310 supported. 1310 supported.
@@ -1321,7 +1321,7 @@ system and gives an overview of their function and contents.
1321 the ``poky/meta`` layer. 1321 the ``poky/meta`` layer.
1322 1322
1323 COREBASE_FILES 1323 COREBASE_FILES
1324 Lists files from the ```COREBASE`` <#var-COREBASE>`__ directory that 1324 Lists files from the :term:`COREBASE` directory that
1325 should be copied other than the layers listed in the 1325 should be copied other than the layers listed in the
1326 ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for 1326 ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for
1327 the purpose of copying metadata from the OpenEmbedded build system 1327 the purpose of copying metadata from the OpenEmbedded build system
@@ -1345,19 +1345,19 @@ system and gives an overview of their function and contents.
1345 Default initialization for ``CPPFLAGS`` varies depending on what is 1345 Default initialization for ``CPPFLAGS`` varies depending on what is
1346 being built: 1346 being built:
1347 1347
1348 - ```TARGET_CPPFLAGS`` <#var-TARGET_CPPFLAGS>`__ when building for 1348 - :term:`TARGET_CPPFLAGS` when building for
1349 the target 1349 the target
1350 1350
1351 - ```BUILD_CPPFLAGS`` <#var-BUILD_CPPFLAGS>`__ when building for the 1351 - :term:`BUILD_CPPFLAGS` when building for the
1352 build host (i.e. ``-native``) 1352 build host (i.e. ``-native``)
1353 1353
1354 - ```BUILDSDK_CPPFLAGS`` <#var-BUILDSDK_CPPFLAGS>`__ when building 1354 - :term:`BUILDSDK_CPPFLAGS` when building
1355 for an SDK (i.e. ``nativesdk-``) 1355 for an SDK (i.e. ``nativesdk-``)
1356 1356
1357 CROSS_COMPILE 1357 CROSS_COMPILE
1358 The toolchain binary prefix for the target tools. The 1358 The toolchain binary prefix for the target tools. The
1359 ``CROSS_COMPILE`` variable is the same as the 1359 ``CROSS_COMPILE`` variable is the same as the
1360 ```TARGET_PREFIX`` <#var-TARGET_PREFIX>`__ variable. 1360 :term:`TARGET_PREFIX` variable.
1361 1361
1362 .. note:: 1362 .. note::
1363 1363
@@ -1381,19 +1381,19 @@ system and gives an overview of their function and contents.
1381 Default initialization for ``CXXFLAGS`` varies depending on what is 1381 Default initialization for ``CXXFLAGS`` varies depending on what is
1382 being built: 1382 being built:
1383 1383
1384 - ```TARGET_CXXFLAGS`` <#var-TARGET_CXXFLAGS>`__ when building for 1384 - :term:`TARGET_CXXFLAGS` when building for
1385 the target 1385 the target
1386 1386
1387 - ```BUILD_CXXFLAGS`` <#var-BUILD_CXXFLAGS>`__ when building for the 1387 - :term:`BUILD_CXXFLAGS` when building for the
1388 build host (i.e. ``-native``) 1388 build host (i.e. ``-native``)
1389 1389
1390 - ```BUILDSDK_CXXFLAGS`` <#var-BUILDSDK_CXXFLAGS>`__ when building 1390 - :term:`BUILDSDK_CXXFLAGS` when building
1391 for an SDK (i.e. ``nativesdk-``) 1391 for an SDK (i.e. ``nativesdk-``)
1392 1392
1393 D 1393 D
1394 The destination directory. The location in the `Build 1394 The destination directory. The location in the `Build
1395 Directory <#build-directory>`__ where components are installed by the 1395 Directory <#build-directory>`__ where components are installed by the
1396 ```do_install`` <#ref-tasks-install>`__ task. This location defaults 1396 :ref:`ref-tasks-install` task. This location defaults
1397 to: ${WORKDIR}/image 1397 to: ${WORKDIR}/image
1398 1398
1399 .. note:: 1399 .. note::
@@ -1411,7 +1411,7 @@ system and gives an overview of their function and contents.
1411 suitable for timestamps. 1411 suitable for timestamps.
1412 1412
1413 DEBIAN_NOAUTONAME 1413 DEBIAN_NOAUTONAME
1414 When the ```debian`` <#ref-classes-debian>`__ class is inherited, 1414 When the :ref:`debian <ref-classes-debian>` class is inherited,
1415 which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a 1415 which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a
1416 particular package should not be renamed according to Debian library 1416 particular package should not be renamed according to Debian library
1417 package naming. You must use the package name as an override when you 1417 package naming. You must use the package name as an override when you
@@ -1419,7 +1419,7 @@ system and gives an overview of their function and contents.
1419 DEBIAN_NOAUTONAME_fontconfig-utils = "1" 1419 DEBIAN_NOAUTONAME_fontconfig-utils = "1"
1420 1420
1421 DEBIANNAME 1421 DEBIANNAME
1422 When the ```debian`` <#ref-classes-debian>`__ class is inherited, 1422 When the :ref:`debian <ref-classes-debian>` class is inherited,
1423 which is the default behavior, ``DEBIANNAME`` allows you to override 1423 which is the default behavior, ``DEBIANNAME`` allows you to override
1424 the library name for an individual package. Overriding the library 1424 the library name for an individual package. Overriding the library
1425 name in these cases is rare. You must use the package name as an 1425 name in these cases is rare. You must use the package name as an
@@ -1457,12 +1457,12 @@ system and gives an overview of their function and contents.
1457 The default CPU and Application Binary Interface (ABI) tunings (i.e. 1457 The default CPU and Application Binary Interface (ABI) tunings (i.e.
1458 the "tune") used by the OpenEmbedded build system. The 1458 the "tune") used by the OpenEmbedded build system. The
1459 ``DEFAULTTUNE`` helps define 1459 ``DEFAULTTUNE`` helps define
1460 ```TUNE_FEATURES`` <#var-TUNE_FEATURES>`__. 1460 :term:`TUNE_FEATURES`.
1461 1461
1462 The default tune is either implicitly or explicitly set by the 1462 The default tune is either implicitly or explicitly set by the
1463 machine (```MACHINE`` <#var-MACHINE>`__). However, you can override 1463 machine (:term:`MACHINE`). However, you can override
1464 the setting using available tunes as defined with 1464 the setting using available tunes as defined with
1465 ```AVAILTUNES`` <#var-AVAILTUNES>`__. 1465 :term:`AVAILTUNES`.
1466 1466
1467 DEPENDS 1467 DEPENDS
1468 Lists a recipe's build-time dependencies. These are dependencies on 1468 Lists a recipe's build-time dependencies. These are dependencies on
@@ -1474,12 +1474,12 @@ system and gives an overview of their function and contents.
1474 assignment is that all files installed by bar will be available in 1474 assignment is that all files installed by bar will be available in
1475 the appropriate staging sysroot, given by the 1475 the appropriate staging sysroot, given by the
1476 ```STAGING_DIR*`` <#var-STAGING_DIR>`__ variables, by the time the 1476 ```STAGING_DIR*`` <#var-STAGING_DIR>`__ variables, by the time the
1477 ```do_configure`` <#ref-tasks-configure>`__ task for ``foo`` runs. 1477 :ref:`ref-tasks-configure` task for ``foo`` runs.
1478 This mechanism is implemented by having ``do_configure`` depend on 1478 This mechanism is implemented by having ``do_configure`` depend on
1479 the ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task of 1479 the :ref:`ref-tasks-populate_sysroot` task of
1480 each recipe listed in ``DEPENDS``, through a 1480 each recipe listed in ``DEPENDS``, through a
1481 ``[``\ ```deptask`` <&YOCTO_DOCS_BB_URL;#variable-flags>`__\ ``]`` 1481 ``[``\ ```deptask`` <&YOCTO_DOCS_BB_URL;#variable-flags>`__\ ``]``
1482 declaration in the ```base`` <#ref-classes-base>`__ class. 1482 declaration in the :ref:`base <ref-classes-base>` class.
1483 1483
1484 .. note:: 1484 .. note::
1485 1485
@@ -1492,13 +1492,13 @@ system and gives an overview of their function and contents.
1492 that run on the build machine during the build. For example, a recipe 1492 that run on the build machine during the build. For example, a recipe
1493 that makes use of a code generator built by the recipe ``codegen`` 1493 that makes use of a code generator built by the recipe ``codegen``
1494 might have the following: DEPENDS = "codegen-native" For more 1494 might have the following: DEPENDS = "codegen-native" For more
1495 information, see the ```native`` <#ref-classes-native>`__ class and 1495 information, see the :ref:`native <ref-classes-native>` class and
1496 the ```EXTRANATIVEPATH`` <#var-EXTRANATIVEPATH>`__ variable. 1496 the :term:`EXTRANATIVEPATH` variable.
1497 1497
1498 .. note:: 1498 .. note::
1499 1499
1500 - ``DEPENDS`` is a list of recipe names. Or, to be more precise, 1500 - ``DEPENDS`` is a list of recipe names. Or, to be more precise,
1501 it is a list of ```PROVIDES`` <#var-PROVIDES>`__ names, which 1501 it is a list of :term:`PROVIDES` names, which
1502 usually match recipe names. Putting a package name such as 1502 usually match recipe names. Putting a package name such as
1503 "foo-dev" in ``DEPENDS`` does not make sense. Use "foo" 1503 "foo-dev" in ``DEPENDS`` does not make sense. Use "foo"
1504 instead, as this will put files from all the packages that make 1504 instead, as this will put files from all the packages that make
@@ -1524,7 +1524,7 @@ system and gives an overview of their function and contents.
1524 fail to link against ``libfoo``. 1524 fail to link against ``libfoo``.
1525 1525
1526 For information on runtime dependencies, see the 1526 For information on runtime dependencies, see the
1527 ```RDEPENDS`` <#var-RDEPENDS>`__ variable. You can also see the 1527 :term:`RDEPENDS` variable. You can also see the
1528 "`Tasks <&YOCTO_DOCS_BB_URL;#tasks>`__" and 1528 "`Tasks <&YOCTO_DOCS_BB_URL;#tasks>`__" and
1529 "`Dependencies <&YOCTO_DOCS_BB_URL;#dependencies>`__" sections in the 1529 "`Dependencies <&YOCTO_DOCS_BB_URL;#dependencies>`__" sections in the
1530 BitBake User Manual for additional information on tasks and 1530 BitBake User Manual for additional information on tasks and
@@ -1534,7 +1534,7 @@ system and gives an overview of their function and contents.
1534 Points to the general area that the OpenEmbedded build system uses to 1534 Points to the general area that the OpenEmbedded build system uses to
1535 place images, packages, SDKs, and other output files that are ready 1535 place images, packages, SDKs, and other output files that are ready
1536 to be used outside of the build system. By default, this directory 1536 to be used outside of the build system. By default, this directory
1537 resides within the `Build Directory <#build-directory>`__ as 1537 resides within the :term:`Build Directory` as
1538 ``${TMPDIR}/deploy``. 1538 ``${TMPDIR}/deploy``.
1539 1539
1540 For more information on the structure of the Build Directory, see 1540 For more information on the structure of the Build Directory, see
@@ -1550,17 +1550,17 @@ system and gives an overview of their function and contents.
1550 Points to the area that the OpenEmbedded build system uses to place 1550 Points to the area that the OpenEmbedded build system uses to place
1551 Debian packages that are ready to be used outside of the build 1551 Debian packages that are ready to be used outside of the build
1552 system. This variable applies only when 1552 system. This variable applies only when
1553 ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ contains 1553 :term:`PACKAGE_CLASSES` contains
1554 "package_deb". 1554 "package_deb".
1555 1555
1556 The BitBake configuration file initially defines the 1556 The BitBake configuration file initially defines the
1557 ``DEPLOY_DIR_DEB`` variable as a sub-folder of 1557 ``DEPLOY_DIR_DEB`` variable as a sub-folder of
1558 ```DEPLOY_DIR`` <#var-DEPLOY_DIR>`__: DEPLOY_DIR_DEB = 1558 :term:`DEPLOY_DIR`: DEPLOY_DIR_DEB =
1559 "${DEPLOY_DIR}/deb" 1559 "${DEPLOY_DIR}/deb"
1560 1560
1561 The ```package_deb`` <#ref-classes-package_deb>`__ class uses the 1561 The :ref:`package_deb <ref-classes-package_deb>` class uses the
1562 ``DEPLOY_DIR_DEB`` variable to make sure the 1562 ``DEPLOY_DIR_DEB`` variable to make sure the
1563 ```do_package_write_deb`` <#ref-tasks-package_write_deb>`__ task 1563 :ref:`ref-tasks-package_write_deb` task
1564 writes Debian packages into the appropriate folder. For more 1564 writes Debian packages into the appropriate folder. For more
1565 information on how packaging works, see the "`Package 1565 information on how packaging works, see the "`Package
1566 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section 1566 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
@@ -1571,7 +1571,7 @@ system and gives an overview of their function and contents.
1571 images and other associated output files that are ready to be 1571 images and other associated output files that are ready to be
1572 deployed onto the target machine. The directory is machine-specific 1572 deployed onto the target machine. The directory is machine-specific
1573 as it contains the ``${MACHINE}`` name. By default, this directory 1573 as it contains the ``${MACHINE}`` name. By default, this directory
1574 resides within the `Build Directory <#build-directory>`__ as 1574 resides within the :term:`Build Directory` as
1575 ``${DEPLOY_DIR}/images/${MACHINE}/``. 1575 ``${DEPLOY_DIR}/images/${MACHINE}/``.
1576 1576
1577 For more information on the structure of the Build Directory, see 1577 For more information on the structure of the Build Directory, see
@@ -1586,16 +1586,16 @@ system and gives an overview of their function and contents.
1586 Points to the area that the OpenEmbedded build system uses to place 1586 Points to the area that the OpenEmbedded build system uses to place
1587 IPK packages that are ready to be used outside of the build system. 1587 IPK packages that are ready to be used outside of the build system.
1588 This variable applies only when 1588 This variable applies only when
1589 ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ contains 1589 :term:`PACKAGE_CLASSES` contains
1590 "package_ipk". 1590 "package_ipk".
1591 1591
1592 The BitBake configuration file initially defines this variable as a 1592 The BitBake configuration file initially defines this variable as a
1593 sub-folder of ```DEPLOY_DIR`` <#var-DEPLOY_DIR>`__: DEPLOY_DIR_IPK = 1593 sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_IPK =
1594 "${DEPLOY_DIR}/ipk" 1594 "${DEPLOY_DIR}/ipk"
1595 1595
1596 The ```package_ipk`` <#ref-classes-package_ipk>`__ class uses the 1596 The :ref:`package_ipk <ref-classes-package_ipk>` class uses the
1597 ``DEPLOY_DIR_IPK`` variable to make sure the 1597 ``DEPLOY_DIR_IPK`` variable to make sure the
1598 ```do_package_write_ipk`` <#ref-tasks-package_write_ipk>`__ task 1598 :ref:`ref-tasks-package_write_ipk` task
1599 writes IPK packages into the appropriate folder. For more information 1599 writes IPK packages into the appropriate folder. For more information
1600 on how packaging works, see the "`Package 1600 on how packaging works, see the "`Package
1601 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section 1601 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
@@ -1605,16 +1605,16 @@ system and gives an overview of their function and contents.
1605 Points to the area that the OpenEmbedded build system uses to place 1605 Points to the area that the OpenEmbedded build system uses to place
1606 RPM packages that are ready to be used outside of the build system. 1606 RPM packages that are ready to be used outside of the build system.
1607 This variable applies only when 1607 This variable applies only when
1608 ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ contains 1608 :term:`PACKAGE_CLASSES` contains
1609 "package_rpm". 1609 "package_rpm".
1610 1610
1611 The BitBake configuration file initially defines this variable as a 1611 The BitBake configuration file initially defines this variable as a
1612 sub-folder of ```DEPLOY_DIR`` <#var-DEPLOY_DIR>`__: DEPLOY_DIR_RPM = 1612 sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_RPM =
1613 "${DEPLOY_DIR}/rpm" 1613 "${DEPLOY_DIR}/rpm"
1614 1614
1615 The ```package_rpm`` <#ref-classes-package_rpm>`__ class uses the 1615 The :ref:`package_rpm <ref-classes-package_rpm>` class uses the
1616 ``DEPLOY_DIR_RPM`` variable to make sure the 1616 ``DEPLOY_DIR_RPM`` variable to make sure the
1617 ```do_package_write_rpm`` <#ref-tasks-package_write_rpm>`__ task 1617 :ref:`ref-tasks-package_write_rpm` task
1618 writes RPM packages into the appropriate folder. For more information 1618 writes RPM packages into the appropriate folder. For more information
1619 on how packaging works, see the "`Package 1619 on how packaging works, see the "`Package
1620 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section 1620 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
@@ -1624,40 +1624,40 @@ system and gives an overview of their function and contents.
1624 Points to the area that the OpenEmbedded build system uses to place 1624 Points to the area that the OpenEmbedded build system uses to place
1625 tarballs that are ready to be used outside of the build system. This 1625 tarballs that are ready to be used outside of the build system. This
1626 variable applies only when 1626 variable applies only when
1627 ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ contains 1627 :term:`PACKAGE_CLASSES` contains
1628 "package_tar". 1628 "package_tar".
1629 1629
1630 The BitBake configuration file initially defines this variable as a 1630 The BitBake configuration file initially defines this variable as a
1631 sub-folder of ```DEPLOY_DIR`` <#var-DEPLOY_DIR>`__: DEPLOY_DIR_TAR = 1631 sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_TAR =
1632 "${DEPLOY_DIR}/tar" 1632 "${DEPLOY_DIR}/tar"
1633 1633
1634 The ```package_tar`` <#ref-classes-package_tar>`__ class uses the 1634 The :ref:`package_tar <ref-classes-package_tar>` class uses the
1635 ``DEPLOY_DIR_TAR`` variable to make sure the 1635 ``DEPLOY_DIR_TAR`` variable to make sure the
1636 ```do_package_write_tar`` <#ref-tasks-package_write_tar>`__ task 1636 :ref:`ref-tasks-package_write_tar` task
1637 writes TAR packages into the appropriate folder. For more information 1637 writes TAR packages into the appropriate folder. For more information
1638 on how packaging works, see the "`Package 1638 on how packaging works, see the "`Package
1639 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section 1639 Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
1640 in the Yocto Project Overview and Concepts Manual. 1640 in the Yocto Project Overview and Concepts Manual.
1641 1641
1642 DEPLOYDIR 1642 DEPLOYDIR
1643 When inheriting the ```deploy`` <#ref-classes-deploy>`__ class, the 1643 When inheriting the :ref:`deploy <ref-classes-deploy>` class, the
1644 ``DEPLOYDIR`` points to a temporary work area for deployed files that 1644 ``DEPLOYDIR`` points to a temporary work area for deployed files that
1645 is set in the ``deploy`` class as follows: DEPLOYDIR = 1645 is set in the ``deploy`` class as follows: DEPLOYDIR =
1646 "${WORKDIR}/deploy-${```PN`` <#var-PN>`__}" 1646 "${WORKDIR}/deploy-${:term:`PN`}"
1647 1647
1648 Recipes inheriting the ``deploy`` class should copy files to be 1648 Recipes inheriting the ``deploy`` class should copy files to be
1649 deployed into ``DEPLOYDIR``, and the class will take care of copying 1649 deployed into ``DEPLOYDIR``, and the class will take care of copying
1650 them into ```DEPLOY_DIR_IMAGE`` <#var-DEPLOY_DIR_IMAGE>`__ 1650 them into :term:`DEPLOY_DIR_IMAGE`
1651 afterwards. 1651 afterwards.
1652 1652
1653 DESCRIPTION 1653 DESCRIPTION
1654 The package description used by package managers. If not set, 1654 The package description used by package managers. If not set,
1655 ``DESCRIPTION`` takes the value of the ```SUMMARY`` <#var-SUMMARY>`__ 1655 ``DESCRIPTION`` takes the value of the :term:`SUMMARY`
1656 variable. 1656 variable.
1657 1657
1658 DISTRO 1658 DISTRO
1659 The short name of the distribution. For information on the long name 1659 The short name of the distribution. For information on the long name
1660 of the distribution, see the ```DISTRO_NAME`` <#var-DISTRO_NAME>`__ 1660 of the distribution, see the :term:`DISTRO_NAME`
1661 variable. 1661 variable.
1662 1662
1663 The ``DISTRO`` variable corresponds to a distribution configuration 1663 The ``DISTRO`` variable corresponds to a distribution configuration
@@ -1671,7 +1671,7 @@ system and gives an overview of their function and contents.
1671 follows: DISTRO = "poky" 1671 follows: DISTRO = "poky"
1672 1672
1673 Distribution configuration files are located in a ``conf/distro`` 1673 Distribution configuration files are located in a ``conf/distro``
1674 directory within the `Metadata <#metadata>`__ that contains the 1674 directory within the :term:`Metadata` that contains the
1675 distribution configuration. The value for ``DISTRO`` must not contain 1675 distribution configuration. The value for ``DISTRO`` must not contain
1676 spaces, and is typically all lower-case. 1676 spaces, and is typically all lower-case.
1677 1677
@@ -1709,7 +1709,7 @@ system and gives an overview of their function and contents.
1709 In most cases, the presence or absence of a feature in 1709 In most cases, the presence or absence of a feature in
1710 ``DISTRO_FEATURES`` is translated to the appropriate option supplied 1710 ``DISTRO_FEATURES`` is translated to the appropriate option supplied
1711 to the configure script during the 1711 to the configure script during the
1712 ```do_configure`` <#ref-tasks-configure>`__ task for recipes that 1712 :ref:`ref-tasks-configure` task for recipes that
1713 optionally support the feature. For example, specifying "x11" in 1713 optionally support the feature. For example, specifying "x11" in
1714 ``DISTRO_FEATURES``, causes every piece of software built for the 1714 ``DISTRO_FEATURES``, causes every piece of software built for the
1715 target that can optionally support X11 to have its X11 support 1715 target that can optionally support X11 to have its X11 support
@@ -1744,59 +1744,59 @@ system and gives an overview of their function and contents.
1744 1744
1745 When creating a custom distribution, you might find it useful to be 1745 When creating a custom distribution, you might find it useful to be
1746 able to reuse the default 1746 able to reuse the default
1747 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ options without the 1747 :term:`DISTRO_FEATURES` options without the
1748 need to write out the full set. Here is an example that uses 1748 need to write out the full set. Here is an example that uses
1749 ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file: 1749 ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file:
1750 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" 1750 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
1751 1751
1752 DISTRO_FEATURES_FILTER_NATIVE 1752 DISTRO_FEATURES_FILTER_NATIVE
1753 Specifies a list of features that if present in the target 1753 Specifies a list of features that if present in the target
1754 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ value should be 1754 :term:`DISTRO_FEATURES` value should be
1755 included in ``DISTRO_FEATURES`` when building native recipes. This 1755 included in ``DISTRO_FEATURES`` when building native recipes. This
1756 variable is used in addition to the features filtered using the 1756 variable is used in addition to the features filtered using the
1757 ```DISTRO_FEATURES_NATIVE`` <#var-DISTRO_FEATURES_NATIVE>`__ 1757 :term:`DISTRO_FEATURES_NATIVE`
1758 variable. 1758 variable.
1759 1759
1760 DISTRO_FEATURES_FILTER_NATIVESDK 1760 DISTRO_FEATURES_FILTER_NATIVESDK
1761 Specifies a list of features that if present in the target 1761 Specifies a list of features that if present in the target
1762 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ value should be 1762 :term:`DISTRO_FEATURES` value should be
1763 included in ``DISTRO_FEATURES`` when building nativesdk recipes. This 1763 included in ``DISTRO_FEATURES`` when building nativesdk recipes. This
1764 variable is used in addition to the features filtered using the 1764 variable is used in addition to the features filtered using the
1765 ```DISTRO_FEATURES_NATIVESDK`` <#var-DISTRO_FEATURES_NATIVESDK>`__ 1765 :term:`DISTRO_FEATURES_NATIVESDK`
1766 variable. 1766 variable.
1767 1767
1768 DISTRO_FEATURES_NATIVE 1768 DISTRO_FEATURES_NATIVE
1769 Specifies a list of features that should be included in 1769 Specifies a list of features that should be included in
1770 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ when building native 1770 :term:`DISTRO_FEATURES` when building native
1771 recipes. This variable is used in addition to the features filtered 1771 recipes. This variable is used in addition to the features filtered
1772 using the 1772 using the
1773 ```DISTRO_FEATURES_FILTER_NATIVE`` <#var-DISTRO_FEATURES_FILTER_NATIVE>`__ 1773 :term:`DISTRO_FEATURES_FILTER_NATIVE`
1774 variable. 1774 variable.
1775 1775
1776 DISTRO_FEATURES_NATIVESDK 1776 DISTRO_FEATURES_NATIVESDK
1777 Specifies a list of features that should be included in 1777 Specifies a list of features that should be included in
1778 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ when building 1778 :term:`DISTRO_FEATURES` when building
1779 nativesdk recipes. This variable is used in addition to the features 1779 nativesdk recipes. This variable is used in addition to the features
1780 filtered using the 1780 filtered using the
1781 ```DISTRO_FEATURES_FILTER_NATIVESDK`` <#var-DISTRO_FEATURES_FILTER_NATIVESDK>`__ 1781 :term:`DISTRO_FEATURES_FILTER_NATIVESDK`
1782 variable. 1782 variable.
1783 1783
1784 DISTRO_NAME 1784 DISTRO_NAME
1785 The long name of the distribution. For information on the short name 1785 The long name of the distribution. For information on the short name
1786 of the distribution, see the ```DISTRO`` <#var-DISTRO>`__ variable. 1786 of the distribution, see the :term:`DISTRO` variable.
1787 1787
1788 The ``DISTRO_NAME`` variable corresponds to a distribution 1788 The ``DISTRO_NAME`` variable corresponds to a distribution
1789 configuration file whose root name is the same as the variable's 1789 configuration file whose root name is the same as the variable's
1790 argument and whose filename extension is ``.conf``. For example, the 1790 argument and whose filename extension is ``.conf``. For example, the
1791 distribution configuration file for the Poky distribution is named 1791 distribution configuration file for the Poky distribution is named
1792 ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory 1792 ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory
1793 of the `Source Directory <#source-directory>`__. 1793 of the :term:`Source Directory`.
1794 1794
1795 Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set 1795 Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set
1796 as follows: DISTRO_NAME = "Poky (Yocto Project Reference Distro)" 1796 as follows: DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
1797 1797
1798 Distribution configuration files are located in a ``conf/distro`` 1798 Distribution configuration files are located in a ``conf/distro``
1799 directory within the `Metadata <#metadata>`__ that contains the 1799 directory within the :term:`Metadata` that contains the
1800 distribution configuration. 1800 distribution configuration.
1801 1801
1802 .. note:: 1802 .. note::
@@ -1814,27 +1814,27 @@ system and gives an overview of their function and contents.
1814 DISTROOVERRIDES 1814 DISTROOVERRIDES
1815 A colon-separated list of overrides specific to the current 1815 A colon-separated list of overrides specific to the current
1816 distribution. By default, this list includes the value of 1816 distribution. By default, this list includes the value of
1817 ```DISTRO`` <#var-DISTRO>`__. 1817 :term:`DISTRO`.
1818 1818
1819 You can extend ``DISTROOVERRIDES`` to add extra overrides that should 1819 You can extend ``DISTROOVERRIDES`` to add extra overrides that should
1820 apply to the distribution. 1820 apply to the distribution.
1821 1821
1822 The underlying mechanism behind ``DISTROOVERRIDES`` is simply that it 1822 The underlying mechanism behind ``DISTROOVERRIDES`` is simply that it
1823 is included in the default value of 1823 is included in the default value of
1824 ```OVERRIDES`` <#var-OVERRIDES>`__. 1824 :term:`OVERRIDES`.
1825 1825
1826 DL_DIR 1826 DL_DIR
1827 The central download directory used by the build process to store 1827 The central download directory used by the build process to store
1828 downloads. By default, ``DL_DIR`` gets files suitable for mirroring 1828 downloads. By default, ``DL_DIR`` gets files suitable for mirroring
1829 for everything except Git repositories. If you want tarballs of Git 1829 for everything except Git repositories. If you want tarballs of Git
1830 repositories, use the 1830 repositories, use the
1831 ```BB_GENERATE_MIRROR_TARBALLS`` <#var-BB_GENERATE_MIRROR_TARBALLS>`__ 1831 :term:`BB_GENERATE_MIRROR_TARBALLS`
1832 variable. 1832 variable.
1833 1833
1834 You can set this directory by defining the ``DL_DIR`` variable in the 1834 You can set this directory by defining the ``DL_DIR`` variable in the
1835 ``conf/local.conf`` file. This directory is self-maintaining and you 1835 ``conf/local.conf`` file. This directory is self-maintaining and you
1836 should not have to touch it. By default, the directory is 1836 should not have to touch it. By default, the directory is
1837 ``downloads`` in the `Build Directory <#build-directory>`__. #DL_DIR 1837 ``downloads`` in the :term:`Build Directory`. #DL_DIR
1838 ?= "${TOPDIR}/downloads" To specify a different download directory, 1838 ?= "${TOPDIR}/downloads" To specify a different download directory,
1839 simply remove the comment from the line and provide your directory. 1839 simply remove the comment from the line and provide your directory.
1840 1840
@@ -1859,7 +1859,7 @@ system and gives an overview of their function and contents.
1859 page. 1859 page.
1860 1860
1861 DOC_COMPRESS 1861 DOC_COMPRESS
1862 When inheriting the ```compress_doc`` <#ref-classes-compress_doc>`__ 1862 When inheriting the :ref:`compress_doc <ref-classes-compress_doc>`
1863 class, this variable sets the compression policy used when the 1863 class, this variable sets the compression policy used when the
1864 OpenEmbedded build system compresses man pages and info pages. By 1864 OpenEmbedded build system compresses man pages and info pages. By
1865 default, the compression method used is gz (gzip). Other policies 1865 default, the compression method used is gz (gzip). Other policies
@@ -1870,12 +1870,12 @@ system and gives an overview of their function and contents.
1870 1870
1871 EFI_PROVIDER 1871 EFI_PROVIDER
1872 When building bootable images (i.e. where ``hddimg``, ``iso``, or 1872 When building bootable images (i.e. where ``hddimg``, ``iso``, or
1873 ``wic.vmdk`` is in ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__), the 1873 ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the
1874 ``EFI_PROVIDER`` variable specifies the EFI bootloader to use. The 1874 ``EFI_PROVIDER`` variable specifies the EFI bootloader to use. The
1875 default is "grub-efi", but "systemd-boot" can be used instead. 1875 default is "grub-efi", but "systemd-boot" can be used instead.
1876 1876
1877 See the ```systemd-boot`` <#ref-classes-systemd-boot>`__ and 1877 See the :ref:`systemd-boot <ref-classes-systemd-boot>` and
1878 ```image-live`` <#ref-classes-image-live>`__ classes for more 1878 :ref:`image-live <ref-classes-image-live>` classes for more
1879 information. 1879 information.
1880 1880
1881 ENABLE_BINARY_LOCALE_GENERATION 1881 ENABLE_BINARY_LOCALE_GENERATION
@@ -1884,13 +1884,13 @@ system and gives an overview of their function and contents.
1884 less). 1884 less).
1885 1885
1886 ERR_REPORT_DIR 1886 ERR_REPORT_DIR
1887 When used with the ```report-error`` <#ref-classes-report-error>`__ 1887 When used with the :ref:`report-error <ref-classes-report-error>`
1888 class, specifies the path used for storing the debug files created by 1888 class, specifies the path used for storing the debug files created by
1889 the `error reporting 1889 the `error reporting
1890 tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which 1890 tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which
1891 allows you to submit build errors you encounter to a central 1891 allows you to submit build errors you encounter to a central
1892 database. By default, the value of this variable is 1892 database. By default, the value of this variable is
1893 ``${``\ ```LOG_DIR`` <#var-LOG_DIR>`__\ ``}/error-report``. 1893 ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
1894 1894
1895 You can set ``ERR_REPORT_DIR`` to the path you want the error 1895 You can set ``ERR_REPORT_DIR`` to the path you want the error
1896 reporting tool to store the debug files as follows in your 1896 reporting tool to store the debug files as follows in your
@@ -1901,7 +1901,7 @@ system and gives an overview of their function and contents.
1901 errors by the OpenEmbedded build system. You set this variable in 1901 errors by the OpenEmbedded build system. You set this variable in
1902 your distribution configuration file. For a list of the checks you 1902 your distribution configuration file. For a list of the checks you
1903 can control with this variable, see the 1903 can control with this variable, see the
1904 "```insane.bbclass`` <#ref-classes-insane>`__" section. 1904 ":ref:`insane.bbclass <ref-classes-insane>`" section.
1905 1905
1906 EXCLUDE_FROM_SHLIBS 1906 EXCLUDE_FROM_SHLIBS
1907 Triggers the OpenEmbedded build system's shared libraries resolver to 1907 Triggers the OpenEmbedded build system's shared libraries resolver to
@@ -1918,7 +1918,7 @@ system and gives an overview of their function and contents.
1918 implicitly define some dependencies between packages. 1918 implicitly define some dependencies between packages.
1919 1919
1920 The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the 1920 The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the
1921 ```PRIVATE_LIBS`` <#var-PRIVATE_LIBS>`__ variable, which excludes a 1921 :term:`PRIVATE_LIBS` variable, which excludes a
1922 package's particular libraries only and not the whole package. 1922 package's particular libraries only and not the whole package.
1923 1923
1924 Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a 1924 Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a
@@ -1945,13 +1945,13 @@ system and gives an overview of their function and contents.
1945 1945
1946 EXTENDPE 1946 EXTENDPE
1947 Used with file and pathnames to create a prefix for a recipe's 1947 Used with file and pathnames to create a prefix for a recipe's
1948 version based on the recipe's ```PE`` <#var-PE>`__ value. If ``PE`` 1948 version based on the recipe's :term:`PE` value. If ``PE``
1949 is set and greater than zero for a recipe, ``EXTENDPE`` becomes that 1949 is set and greater than zero for a recipe, ``EXTENDPE`` becomes that
1950 value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1_"). 1950 value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1_").
1951 If a recipe's ``PE`` is not set (the default) or is equal to zero, 1951 If a recipe's ``PE`` is not set (the default) or is equal to zero,
1952 ``EXTENDPE`` becomes "". 1952 ``EXTENDPE`` becomes "".
1953 1953
1954 See the ```STAMP`` <#var-STAMP>`__ variable for an example. 1954 See the :term:`STAMP` variable for an example.
1955 1955
1956 EXTENDPKGV 1956 EXTENDPKGV
1957 The full package version specification as it appears on the final 1957 The full package version specification as it appears on the final
@@ -1971,43 +1971,43 @@ system and gives an overview of their function and contents.
1971 any externally installed tools. Setting the ``EXTERNAL_KERNEL_TOOLS`` 1971 any externally installed tools. Setting the ``EXTERNAL_KERNEL_TOOLS``
1972 variable tells the OpenEmbedded build system to prefer the installed 1972 variable tells the OpenEmbedded build system to prefer the installed
1973 external tools. See the 1973 external tools. See the
1974 ```kernel-yocto`` <#ref-classes-kernel-yocto>`__ class in 1974 :ref:`kernel-yocto <ref-classes-kernel-yocto>` class in
1975 ``meta/classes`` to see how the variable is used. 1975 ``meta/classes`` to see how the variable is used.
1976 1976
1977 EXTERNALSRC 1977 EXTERNALSRC
1978 When inheriting the ```externalsrc`` <#ref-classes-externalsrc>`__ 1978 When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
1979 class, this variable points to the source tree, which is outside of 1979 class, this variable points to the source tree, which is outside of
1980 the OpenEmbedded build system. When set, this variable sets the 1980 the OpenEmbedded build system. When set, this variable sets the
1981 ```S`` <#var-S>`__ variable, which is what the OpenEmbedded build 1981 :term:`S` variable, which is what the OpenEmbedded build
1982 system uses to locate unpacked recipe source code. 1982 system uses to locate unpacked recipe source code.
1983 1983
1984 For more information on ``externalsrc.bbclass``, see the 1984 For more information on ``externalsrc.bbclass``, see the
1985 "```externalsrc.bbclass`` <#ref-classes-externalsrc>`__" section. You 1985 ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
1986 can also find information on how to use this variable in the 1986 can also find information on how to use this variable in the
1987 "`Building Software from an External 1987 "`Building Software from an External
1988 Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" 1988 Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
1989 section in the Yocto Project Development Tasks Manual. 1989 section in the Yocto Project Development Tasks Manual.
1990 1990
1991 EXTERNALSRC_BUILD 1991 EXTERNALSRC_BUILD
1992 When inheriting the ```externalsrc`` <#ref-classes-externalsrc>`__ 1992 When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
1993 class, this variable points to the directory in which the recipe's 1993 class, this variable points to the directory in which the recipe's
1994 source code is built, which is outside of the OpenEmbedded build 1994 source code is built, which is outside of the OpenEmbedded build
1995 system. When set, this variable sets the ```B`` <#var-B>`__ variable, 1995 system. When set, this variable sets the :term:`B` variable,
1996 which is what the OpenEmbedded build system uses to locate the Build 1996 which is what the OpenEmbedded build system uses to locate the Build
1997 Directory. 1997 Directory.
1998 1998
1999 For more information on ``externalsrc.bbclass``, see the 1999 For more information on ``externalsrc.bbclass``, see the
2000 "```externalsrc.bbclass`` <#ref-classes-externalsrc>`__" section. You 2000 ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
2001 can also find information on how to use this variable in the 2001 can also find information on how to use this variable in the
2002 "`Building Software from an External 2002 "`Building Software from an External
2003 Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" 2003 Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
2004 section in the Yocto Project Development Tasks Manual. 2004 section in the Yocto Project Development Tasks Manual.
2005 2005
2006 EXTRA_AUTORECONF 2006 EXTRA_AUTORECONF
2007 For recipes inheriting the ```autotools`` <#ref-classes-autotools>`__ 2007 For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
2008 class, you can use ``EXTRA_AUTORECONF`` to specify extra options to 2008 class, you can use ``EXTRA_AUTORECONF`` to specify extra options to
2009 pass to the ``autoreconf`` command that is executed during the 2009 pass to the ``autoreconf`` command that is executed during the
2010 ```do_configure`` <#ref-tasks-configure>`__ task. 2010 :ref:`ref-tasks-configure` task.
2011 2011
2012 The default value is "--exclude=autopoint". 2012 The default value is "--exclude=autopoint".
2013 2013
@@ -2016,7 +2016,7 @@ system and gives an overview of their function and contents.
2016 more than one feature, separate them with a space. 2016 more than one feature, separate them with a space.
2017 2017
2018 Typically, you configure this variable in your ``local.conf`` file, 2018 Typically, you configure this variable in your ``local.conf`` file,
2019 which is found in the `Build Directory <#build-directory>`__. 2019 which is found in the :term:`Build Directory`.
2020 Although you can use this variable from within a recipe, best 2020 Although you can use this variable from within a recipe, best
2021 practices dictate that you do not. 2021 practices dictate that you do not.
2022 2022
@@ -2055,7 +2055,7 @@ system and gives an overview of their function and contents.
2055 2055
2056 EXTRA_IMAGECMD 2056 EXTRA_IMAGECMD
2057 Specifies additional options for the image creation command that has 2057 Specifies additional options for the image creation command that has
2058 been specified in ```IMAGE_CMD`` <#var-IMAGE_CMD>`__. When setting 2058 been specified in :term:`IMAGE_CMD`. When setting
2059 this variable, use an override for the associated image type. Here is 2059 this variable, use an override for the associated image type. Here is
2060 an example: EXTRA_IMAGECMD_ext3 ?= "-i 4096" 2060 an example: EXTRA_IMAGECMD_ext3 ?= "-i 4096"
2061 2061
@@ -2080,7 +2080,7 @@ system and gives an overview of their function and contents.
2080 2080
2081 EXTRANATIVEPATH 2081 EXTRANATIVEPATH
2082 A list of subdirectories of 2082 A list of subdirectories of
2083 ``${``\ ```STAGING_BINDIR_NATIVE`` <#var-STAGING_BINDIR_NATIVE>`__\ ``}`` 2083 ``${``\ :term:`STAGING_BINDIR_NATIVE`\ ``}``
2084 added to the beginning of the environment variable ``PATH``. As an 2084 added to the beginning of the environment variable ``PATH``. As an
2085 example, the following prepends 2085 example, the following prepends
2086 "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to 2086 "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to
@@ -2088,11 +2088,11 @@ system and gives an overview of their function and contents.
2088 2088
2089 EXTRA_OECMAKE 2089 EXTRA_OECMAKE
2090 Additional `CMake <https://cmake.org/overview/>`__ options. See the 2090 Additional `CMake <https://cmake.org/overview/>`__ options. See the
2091 ```cmake`` <#ref-classes-cmake>`__ class for additional information. 2091 :ref:`cmake <ref-classes-cmake>` class for additional information.
2092 2092
2093 EXTRA_OECONF 2093 EXTRA_OECONF
2094 Additional ``configure`` script options. See 2094 Additional ``configure`` script options. See
2095 ```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__ for 2095 :term:`PACKAGECONFIG_CONFARGS` for
2096 additional information on passing configure script options. 2096 additional information on passing configure script options.
2097 2097
2098 EXTRA_OEMAKE 2098 EXTRA_OEMAKE
@@ -2101,21 +2101,21 @@ system and gives an overview of their function and contents.
2101 Because the ``EXTRA_OEMAKE`` defaults to "", you need to set the 2101 Because the ``EXTRA_OEMAKE`` defaults to "", you need to set the
2102 variable to specify any required GNU options. 2102 variable to specify any required GNU options.
2103 2103
2104 ```PARALLEL_MAKE`` <#var-PARALLEL_MAKE>`__ and 2104 :term:`PARALLEL_MAKE` and
2105 ```PARALLEL_MAKEINST`` <#var-PARALLEL_MAKEINST>`__ also make use of 2105 :term:`PARALLEL_MAKEINST` also make use of
2106 ``EXTRA_OEMAKE`` to pass the required flags. 2106 ``EXTRA_OEMAKE`` to pass the required flags.
2107 2107
2108 EXTRA_OESCONS 2108 EXTRA_OESCONS
2109 When inheriting the ```scons`` <#ref-classes-scons>`__ class, this 2109 When inheriting the :ref:`scons <ref-classes-scons>` class, this
2110 variable specifies additional configuration options you want to pass 2110 variable specifies additional configuration options you want to pass
2111 to the ``scons`` command line. 2111 to the ``scons`` command line.
2112 2112
2113 EXTRA_USERS_PARAMS 2113 EXTRA_USERS_PARAMS
2114 When inheriting the ```extrausers`` <#ref-classes-extrausers>`__ 2114 When inheriting the :ref:`extrausers <ref-classes-extrausers>`
2115 class, this variable provides image level user and group operations. 2115 class, this variable provides image level user and group operations.
2116 This is a more global method of providing user and group 2116 This is a more global method of providing user and group
2117 configuration as compared to using the 2117 configuration as compared to using the
2118 ```useradd`` <#ref-classes-useradd>`__ class, which ties user and 2118 :ref:`useradd <ref-classes-useradd>` class, which ties user and
2119 group configurations to a specific recipe. 2119 group configurations to a specific recipe.
2120 2120
2121 The set list of commands you can configure using the 2121 The set list of commands you can configure using the
@@ -2127,7 +2127,7 @@ system and gives an overview of their function and contents.
2127 2127
2128 FEATURE_PACKAGES 2128 FEATURE_PACKAGES
2129 Defines one or more packages to include in an image when a specific 2129 Defines one or more packages to include in an image when a specific
2130 item is included in ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__. 2130 item is included in :term:`IMAGE_FEATURES`.
2131 When setting the value, ``FEATURE_PACKAGES`` should have the name of 2131 When setting the value, ``FEATURE_PACKAGES`` should have the name of
2132 the feature item as an override. Here is an example: 2132 the feature item as an override. Here is an example:
2133 FEATURE_PACKAGES_widget = "package1 package2" 2133 FEATURE_PACKAGES_widget = "package1 package2"
@@ -2161,7 +2161,7 @@ system and gives an overview of their function and contents.
2161 2161
2162 FILES 2162 FILES
2163 The list of files and directories that are placed in a package. The 2163 The list of files and directories that are placed in a package. The
2164 ```PACKAGES`` <#var-PACKAGES>`__ variable lists the packages 2164 :term:`PACKAGES` variable lists the packages
2165 generated by a recipe. 2165 generated by a recipe.
2166 2166
2167 To use the ``FILES`` variable, provide a package name override that 2167 To use the ``FILES`` variable, provide a package name override that
@@ -2183,7 +2183,7 @@ system and gives an overview of their function and contents.
2183 use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}`` 2183 use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}``
2184 rather than ``/usr/bin``. You can find a list of these 2184 rather than ``/usr/bin``. You can find a list of these
2185 variables at the top of the ``meta/conf/bitbake.conf`` file in 2185 variables at the top of the ``meta/conf/bitbake.conf`` file in
2186 the `Source Directory <#source-directory>`__. You will also 2186 the :term:`Source Directory`. You will also
2187 find the default values of the various ``FILES_*`` variables in 2187 find the default values of the various ``FILES_*`` variables in
2188 this file. 2188 this file.
2189 2189
@@ -2191,12 +2191,12 @@ system and gives an overview of their function and contents.
2191 editable and you know they should not be overwritten during the 2191 editable and you know they should not be overwritten during the
2192 package update process by the Package Management System (PMS), you 2192 package update process by the Package Management System (PMS), you
2193 can identify these files so that the PMS will not overwrite them. See 2193 can identify these files so that the PMS will not overwrite them. See
2194 the ```CONFFILES`` <#var-CONFFILES>`__ variable for information on 2194 the :term:`CONFFILES` variable for information on
2195 how to identify these files to the PMS. 2195 how to identify these files to the PMS.
2196 2196
2197 FILES_SOLIBSDEV 2197 FILES_SOLIBSDEV
2198 Defines the file specification to match 2198 Defines the file specification to match
2199 ```SOLIBSDEV`` <#var-SOLIBSDEV>`__. In other words, 2199 :term:`SOLIBSDEV`. In other words,
2200 ``FILES_SOLIBSDEV`` defines the full path name of the development 2200 ``FILES_SOLIBSDEV`` defines the full path name of the development
2201 symbolic link (symlink) for shared libraries on the target platform. 2201 symbolic link (symlink) for shared libraries on the target platform.
2202 2202
@@ -2208,7 +2208,7 @@ system and gives an overview of their function and contents.
2208 Extends the search path the OpenEmbedded build system uses when 2208 Extends the search path the OpenEmbedded build system uses when
2209 looking for files and patches as it processes recipes and append 2209 looking for files and patches as it processes recipes and append
2210 files. The default directories BitBake uses when it processes recipes 2210 files. The default directories BitBake uses when it processes recipes
2211 are initially defined by the ```FILESPATH`` <#var-FILESPATH>`__ 2211 are initially defined by the :term:`FILESPATH`
2212 variable. You can extend ``FILESPATH`` variable by using 2212 variable. You can extend ``FILESPATH`` variable by using
2213 ``FILESEXTRAPATHS``. 2213 ``FILESEXTRAPATHS``.
2214 2214
@@ -2223,7 +2223,7 @@ system and gives an overview of their function and contents.
2223 2223
2224 When extending ``FILESEXTRAPATHS``, be sure to use the immediate 2224 When extending ``FILESEXTRAPATHS``, be sure to use the immediate
2225 expansion (``:=``) operator. Immediate expansion makes sure that 2225 expansion (``:=``) operator. Immediate expansion makes sure that
2226 BitBake evaluates ```THISDIR`` <#var-THISDIR>`__ at the time the 2226 BitBake evaluates :term:`THISDIR` at the time the
2227 directive is encountered rather than at some later time when 2227 directive is encountered rather than at some later time when
2228 expansion might result in a directory that does not contain the 2228 expansion might result in a directory that does not contain the
2229 files you need. 2229 files you need.
@@ -2242,14 +2242,14 @@ system and gives an overview of their function and contents.
2242 FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:" 2242 FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
2243 2243
2244 A final example shows how you can extend the search path and include 2244 A final example shows how you can extend the search path and include
2245 a ```MACHINE`` <#var-MACHINE>`__-specific override, which is useful 2245 a :term:`MACHINE`-specific override, which is useful
2246 in a BSP layer: FILESEXTRAPATHS_prepend_intel-x86-common := 2246 in a BSP layer: FILESEXTRAPATHS_prepend_intel-x86-common :=
2247 "${THISDIR}/${PN}:" The previous statement appears in the 2247 "${THISDIR}/${PN}:" The previous statement appears in the
2248 ``linux-yocto-dev.bbappend`` file, which is found in the Yocto 2248 ``linux-yocto-dev.bbappend`` file, which is found in the Yocto
2249 Project `Source 2249 Project `Source
2250 Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ in 2250 Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ in
2251 ``meta-intel/common/recipes-kernel/linux``. Here, the machine 2251 ``meta-intel/common/recipes-kernel/linux``. Here, the machine
2252 override is a special ```PACKAGE_ARCH`` <#var-PACKAGE_ARCH>`__ 2252 override is a special :term:`PACKAGE_ARCH`
2253 definition for multiple ``meta-intel`` machines. 2253 definition for multiple ``meta-intel`` machines.
2254 2254
2255 .. note:: 2255 .. note::
@@ -2264,12 +2264,12 @@ system and gives an overview of their function and contents.
2264 recipe to correctly extend the path. 2264 recipe to correctly extend the path.
2265 2265
2266 FILESOVERRIDES 2266 FILESOVERRIDES
2267 A subset of ```OVERRIDES`` <#var-OVERRIDES>`__ used by the 2267 A subset of :term:`OVERRIDES` used by the
2268 OpenEmbedded build system for creating 2268 OpenEmbedded build system for creating
2269 ```FILESPATH`` <#var-FILESPATH>`__. The ``FILESOVERRIDES`` variable 2269 :term:`FILESPATH`. The ``FILESOVERRIDES`` variable
2270 uses overrides to automatically extend the 2270 uses overrides to automatically extend the
2271 ```FILESPATH`` <#var-FILESPATH>`__ variable. For an example of how 2271 :term:`FILESPATH` variable. For an example of how
2272 that works, see the ```FILESPATH`` <#var-FILESPATH>`__ variable 2272 that works, see the :term:`FILESPATH` variable
2273 description. Additionally, you find more information on how overrides 2273 description. Additionally, you find more information on how overrides
2274 are handled in the "`Conditional Syntax 2274 are handled in the "`Conditional Syntax
2275 (Overrides) <&YOCTO_DOCS_BB_URL;#conditional-syntax-overrides>`__" 2275 (Overrides) <&YOCTO_DOCS_BB_URL;#conditional-syntax-overrides>`__"
@@ -2293,7 +2293,7 @@ system and gives an overview of their function and contents.
2293 During the build process, BitBake searches each directory in 2293 During the build process, BitBake searches each directory in
2294 ``FILESPATH`` in the specified order when looking for files and 2294 ``FILESPATH`` in the specified order when looking for files and
2295 patches specified by each ``file://`` URI in a recipe's 2295 patches specified by each ``file://`` URI in a recipe's
2296 ```SRC_URI`` <#var-SRC_URI>`__ statements. 2296 :term:`SRC_URI` statements.
2297 2297
2298 The default value for the ``FILESPATH`` variable is defined in the 2298 The default value for the ``FILESPATH`` variable is defined in the
2299 ``base.bbclass`` class found in ``meta/classes`` in the `Source 2299 ``base.bbclass`` class found in ``meta/classes`` in the `Source
@@ -2301,14 +2301,14 @@ system and gives an overview of their function and contents.
2301 "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\ 2301 "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\
2302 "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The 2302 "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The
2303 ``FILESPATH`` variable is automatically extended using the overrides 2303 ``FILESPATH`` variable is automatically extended using the overrides
2304 from the ```FILESOVERRIDES`` <#var-FILESOVERRIDES>`__ variable. 2304 from the :term:`FILESOVERRIDES` variable.
2305 2305
2306 .. note:: 2306 .. note::
2307 2307
2308 - Do not hand-edit the ``FILESPATH`` variable. If you want the 2308 - Do not hand-edit the ``FILESPATH`` variable. If you want the
2309 build system to look in directories other than the defaults, 2309 build system to look in directories other than the defaults,
2310 extend the ``FILESPATH`` variable by using the 2310 extend the ``FILESPATH`` variable by using the
2311 ```FILESEXTRAPATHS`` <#var-FILESEXTRAPATHS>`__ variable. 2311 :term:`FILESEXTRAPATHS` variable.
2312 2312
2313 - Be aware that the default ``FILESPATH`` directories do not map 2313 - Be aware that the default ``FILESPATH`` directories do not map
2314 to directories in custom layers where append files 2314 to directories in custom layers where append files
@@ -2323,7 +2323,7 @@ system and gives an overview of their function and contents.
2323 files/defconfig files/MACHINEA/defconfig files/MACHINEB/defconfig 2323 files/defconfig files/MACHINEA/defconfig files/MACHINEB/defconfig
2324 Also in the example, the ``SRC_URI`` statement contains 2324 Also in the example, the ``SRC_URI`` statement contains
2325 "file://defconfig". Given this scenario, you can set 2325 "file://defconfig". Given this scenario, you can set
2326 ```MACHINE`` <#var-MACHINE>`__ to "MACHINEA" and cause the build 2326 :term:`MACHINE` to "MACHINEA" and cause the build
2327 system to use files from ``files/MACHINEA``. Set ``MACHINE`` to 2327 system to use files from ``files/MACHINEA``. Set ``MACHINE`` to
2328 "MACHINEB" and the build system uses files from ``files/MACHINEB``. 2328 "MACHINEB" and the build system uses files from ``files/MACHINEB``.
2329 Finally, for any machine other than "MACHINEA" and "MACHINEB", the 2329 Finally, for any machine other than "MACHINEA" and "MACHINEB", the
@@ -2334,7 +2334,7 @@ system and gives an overview of their function and contents.
2334 in the Yocto Project Overview and Concepts Manual and the "`Patching 2334 in the Yocto Project Overview and Concepts Manual and the "`Patching
2335 Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in 2335 Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in
2336 the Yocto Project Development Tasks Manual. See the 2336 the Yocto Project Development Tasks Manual. See the
2337 ```do_patch`` <#ref-tasks-patch>`__ task as well. 2337 :ref:`ref-tasks-patch` task as well.
2338 2338
2339 FILESYSTEM_PERMS_TABLES 2339 FILESYSTEM_PERMS_TABLES
2340 Allows you to define your own file permissions settings table as part 2340 Allows you to define your own file permissions settings table as part
@@ -2354,7 +2354,7 @@ system and gives an overview of their function and contents.
2354 Directory <#build-directory>`__, to point to your custom 2354 Directory <#build-directory>`__, to point to your custom
2355 ``fs-perms.txt``. You can specify more than a single file permissions 2355 ``fs-perms.txt``. You can specify more than a single file permissions
2356 setting table. The paths you specify to these files must be defined 2356 setting table. The paths you specify to these files must be defined
2357 within the ```BBPATH`` <#var-BBPATH>`__ variable. 2357 within the :term:`BBPATH` variable.
2358 2358
2359 For guidance on how to create your own file permissions settings 2359 For guidance on how to create your own file permissions settings
2360 table file, examine the existing ``fs-perms.txt``. 2360 table file, examine the existing ``fs-perms.txt``.
@@ -2367,16 +2367,16 @@ system and gives an overview of their function and contents.
2367 For e.g. rsa2048. 2367 For e.g. rsa2048.
2368 2368
2369 FONT_EXTRA_RDEPENDS 2369 FONT_EXTRA_RDEPENDS
2370 When inheriting the ```fontcache`` <#ref-classes-fontcache>`__ class, 2370 When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
2371 this variable specifies the runtime dependencies for font packages. 2371 this variable specifies the runtime dependencies for font packages.
2372 By default, the ``FONT_EXTRA_RDEPENDS`` is set to "fontconfig-utils". 2372 By default, the ``FONT_EXTRA_RDEPENDS`` is set to "fontconfig-utils".
2373 2373
2374 FONT_PACKAGES 2374 FONT_PACKAGES
2375 When inheriting the ```fontcache`` <#ref-classes-fontcache>`__ class, 2375 When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
2376 this variable identifies packages containing font files that need to 2376 this variable identifies packages containing font files that need to
2377 be cached by Fontconfig. By default, the ``fontcache`` class assumes 2377 be cached by Fontconfig. By default, the ``fontcache`` class assumes
2378 that fonts are in the recipe's main package (i.e. 2378 that fonts are in the recipe's main package (i.e.
2379 ``${``\ ```PN`` <#var-PN>`__\ ``}``). Use this variable if fonts you 2379 ``${``\ :term:`PN`\ ``}``). Use this variable if fonts you
2380 need are in a package other than that main package. 2380 need are in a package other than that main package.
2381 2381
2382 FORCE_RO_REMOVE 2382 FORCE_RO_REMOVE
@@ -2429,7 +2429,7 @@ system and gives an overview of their function and contents.
2429 "en_GB.UTF-8 en_US.UTF-8" 2429 "en_GB.UTF-8 en_US.UTF-8"
2430 2430
2431 GROUPADD_PARAM 2431 GROUPADD_PARAM
2432 When inheriting the ```useradd`` <#ref-classes-useradd>`__ class, 2432 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
2433 this variable specifies for a package what parameters should be 2433 this variable specifies for a package what parameters should be
2434 passed to the ``groupadd`` command if you wish to add a group to the 2434 passed to the ``groupadd`` command if you wish to add a group to the
2435 system when the package is installed. 2435 system when the package is installed.
@@ -2439,7 +2439,7 @@ system and gives an overview of their function and contents.
2439 ``groupadd``, see ` <http://linux.die.net/man/8/groupadd>`__. 2439 ``groupadd``, see ` <http://linux.die.net/man/8/groupadd>`__.
2440 2440
2441 GROUPMEMS_PARAM 2441 GROUPMEMS_PARAM
2442 When inheriting the ```useradd`` <#ref-classes-useradd>`__ class, 2442 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
2443 this variable specifies for a package what parameters should be 2443 this variable specifies for a package what parameters should be
2444 passed to the ``groupmems`` command if you wish to modify the members 2444 passed to the ``groupmems`` command if you wish to modify the members
2445 of a group when the package is installed. 2445 of a group when the package is installed.
@@ -2453,7 +2453,7 @@ system and gives an overview of their function and contents.
2453 ``local.conf`` or distribution configuration file to enable graphics 2453 ``local.conf`` or distribution configuration file to enable graphics
2454 and serial in the menu. 2454 and serial in the menu.
2455 2455
2456 See the ```grub-efi`` <#ref-classes-grub-efi>`__ class for more 2456 See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
2457 information on how this variable is used. 2457 information on how this variable is used.
2458 2458
2459 GRUB_OPTS 2459 GRUB_OPTS
@@ -2462,7 +2462,7 @@ system and gives an overview of their function and contents.
2462 multiple options. 2462 multiple options.
2463 2463
2464 The ``GRUB_OPTS`` variable is optional. See the 2464 The ``GRUB_OPTS`` variable is optional. See the
2465 ```grub-efi`` <#ref-classes-grub-efi>`__ class for more information 2465 :ref:`grub-efi <ref-classes-grub-efi>` class for more information
2466 on how this variable is used. 2466 on how this variable is used.
2467 2467
2468 GRUB_TIMEOUT 2468 GRUB_TIMEOUT
@@ -2470,12 +2470,12 @@ system and gives an overview of their function and contents.
2470 GNU GRand Unified Bootloader (GRUB). 2470 GNU GRand Unified Bootloader (GRUB).
2471 2471
2472 The ``GRUB_TIMEOUT`` variable is optional. See the 2472 The ``GRUB_TIMEOUT`` variable is optional. See the
2473 ```grub-efi`` <#ref-classes-grub-efi>`__ class for more information 2473 :ref:`grub-efi <ref-classes-grub-efi>` class for more information
2474 on how this variable is used. 2474 on how this variable is used.
2475 2475
2476 GTKIMMODULES_PACKAGES 2476 GTKIMMODULES_PACKAGES
2477 When inheriting the 2477 When inheriting the
2478 ```gtk-immodules-cache`` <#ref-classes-gtk-immodules-cache>`__ class, 2478 :ref:`gtk-immodules-cache <ref-classes-gtk-immodules-cache>` class,
2479 this variable specifies the packages that contain the GTK+ input 2479 this variable specifies the packages that contain the GTK+ input
2480 method modules being installed when the modules are in packages other 2480 method modules being installed when the modules are in packages other
2481 than the main package. 2481 than the main package.
@@ -2486,7 +2486,7 @@ system and gives an overview of their function and contents.
2486 2486
2487 HOST_ARCH 2487 HOST_ARCH
2488 The name of the target architecture, which is normally the same as 2488 The name of the target architecture, which is normally the same as
2489 ```TARGET_ARCH`` <#var-TARGET_ARCH>`__. The OpenEmbedded build system 2489 :term:`TARGET_ARCH`. The OpenEmbedded build system
2490 supports many architectures. Here is an example list of architectures 2490 supports many architectures. Here is an example list of architectures
2491 supported. This list is by no means complete as the architecture is 2491 supported. This list is by no means complete as the architecture is
2492 configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel 2492 configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel
@@ -2498,7 +2498,7 @@ system and gives an overview of their function and contents.
2498 Default initialization for ``HOST_CC_ARCH`` varies depending on what 2498 Default initialization for ``HOST_CC_ARCH`` varies depending on what
2499 is being built: 2499 is being built:
2500 2500
2501 - ```TARGET_CC_ARCH`` <#var-TARGET_CC_ARCH>`__ when building for the 2501 - :term:`TARGET_CC_ARCH` when building for the
2502 target 2502 target
2503 2503
2504 - ``BUILD_CC_ARCH`` when building for the build host (i.e. 2504 - ``BUILD_CC_ARCH`` when building for the build host (i.e.
@@ -2509,14 +2509,14 @@ system and gives an overview of their function and contents.
2509 2509
2510 HOST_OS 2510 HOST_OS
2511 Specifies the name of the target operating system, which is normally 2511 Specifies the name of the target operating system, which is normally
2512 the same as the ```TARGET_OS`` <#var-TARGET_OS>`__. The variable can 2512 the same as the :term:`TARGET_OS`. The variable can
2513 be set to "linux" for ``glibc``-based systems and to "linux-musl" for 2513 be set to "linux" for ``glibc``-based systems and to "linux-musl" for
2514 ``musl``. For ARM/EABI targets, there are also "linux-gnueabi" and 2514 ``musl``. For ARM/EABI targets, there are also "linux-gnueabi" and
2515 "linux-musleabi" values possible. 2515 "linux-musleabi" values possible.
2516 2516
2517 HOST_PREFIX 2517 HOST_PREFIX
2518 Specifies the prefix for the cross-compile toolchain. ``HOST_PREFIX`` 2518 Specifies the prefix for the cross-compile toolchain. ``HOST_PREFIX``
2519 is normally the same as ```TARGET_PREFIX`` <#var-TARGET_PREFIX>`__. 2519 is normally the same as :term:`TARGET_PREFIX`.
2520 2520
2521 HOST_SYS 2521 HOST_SYS
2522 Specifies the system, including the architecture and the operating 2522 Specifies the system, including the architecture and the operating
@@ -2524,9 +2524,9 @@ system and gives an overview of their function and contents.
2524 current recipe. 2524 current recipe.
2525 2525
2526 The OpenEmbedded build system automatically sets this variable based 2526 The OpenEmbedded build system automatically sets this variable based
2527 on ```HOST_ARCH`` <#var-HOST_ARCH>`__, 2527 on :term:`HOST_ARCH`,
2528 ```HOST_VENDOR`` <#var-HOST_VENDOR>`__, and 2528 :term:`HOST_VENDOR`, and
2529 ```HOST_OS`` <#var-HOST_OS>`__ variables. 2529 :term:`HOST_OS` variables.
2530 2530
2531 .. note:: 2531 .. note::
2532 2532
@@ -2549,25 +2549,25 @@ system and gives an overview of their function and contents.
2549 is not started. 2549 is not started.
2550 2550
2551 For additional information, see 2551 For additional information, see
2552 ```HOSTTOOLS_NONFATAL`` <#var-HOSTTOOLS_NONFATAL>`__. 2552 :term:`HOSTTOOLS_NONFATAL`.
2553 2553
2554 HOSTTOOLS_NONFATAL 2554 HOSTTOOLS_NONFATAL
2555 A space-separated list (filter) of tools on the build host that 2555 A space-separated list (filter) of tools on the build host that
2556 should be allowed to be called from within build tasks. Using this 2556 should be allowed to be called from within build tasks. Using this
2557 filter helps reduce the possibility of host contamination. Unlike 2557 filter helps reduce the possibility of host contamination. Unlike
2558 ```HOSTTOOLS`` <#var-HOSTTOOLS>`__, the OpenEmbedded build system 2558 :term:`HOSTTOOLS`, the OpenEmbedded build system
2559 does not produce an error if a tool specified in the value of 2559 does not produce an error if a tool specified in the value of
2560 ``HOSTTOOLS_NONFATAL`` is not found on the build host. Thus, you can 2560 ``HOSTTOOLS_NONFATAL`` is not found on the build host. Thus, you can
2561 use ``HOSTTOOLS_NONFATAL`` to filter optional host tools. 2561 use ``HOSTTOOLS_NONFATAL`` to filter optional host tools.
2562 2562
2563 HOST_VENDOR 2563 HOST_VENDOR
2564 Specifies the name of the vendor. ``HOST_VENDOR`` is normally the 2564 Specifies the name of the vendor. ``HOST_VENDOR`` is normally the
2565 same as ```TARGET_VENDOR`` <#var-TARGET_VENDOR>`__. 2565 same as :term:`TARGET_VENDOR`.
2566 2566
2567 ICECC_DISABLED 2567 ICECC_DISABLED
2568 Disables or enables the ``icecc`` (Icecream) function. For more 2568 Disables or enables the ``icecc`` (Icecream) function. For more
2569 information on this function and best practices for using this 2569 information on this function and best practices for using this
2570 variable, see the "```icecc.bbclass`` <#ref-classes-icecc>`__" 2570 variable, see the ":ref:`icecc.bbclass <ref-classes-icecc>`"
2571 section. 2571 section.
2572 2572
2573 Setting this variable to "1" in your ``local.conf`` disables the 2573 Setting this variable to "1" in your ``local.conf`` disables the
@@ -2576,7 +2576,7 @@ system and gives an overview of their function and contents.
2576 2576
2577 ICECC_ENV_EXEC 2577 ICECC_ENV_EXEC
2578 Points to the ``icecc-create-env`` script that you provide. This 2578 Points to the ``icecc-create-env`` script that you provide. This
2579 variable is used by the ```icecc`` <#ref-classes-icecc>`__ class. You 2579 variable is used by the :ref:`icecc <ref-classes-icecc>` class. You
2580 set this variable in your ``local.conf`` file. 2580 set this variable in your ``local.conf`` file.
2581 2581
2582 If you do not point to a script that you provide, the OpenEmbedded 2582 If you do not point to a script that you provide, the OpenEmbedded
@@ -2586,7 +2586,7 @@ system and gives an overview of their function and contents.
2586 2586
2587 ICECC_PARALLEL_MAKE 2587 ICECC_PARALLEL_MAKE
2588 Extra options passed to the ``make`` command during the 2588 Extra options passed to the ``make`` command during the
2589 ```do_compile`` <#ref-tasks-compile>`__ task that specify parallel 2589 :ref:`ref-tasks-compile` task that specify parallel
2590 compilation. This variable usually takes the form of "-j x", where x 2590 compilation. This variable usually takes the form of "-j x", where x
2591 represents the maximum number of parallel threads ``make`` can run. 2591 represents the maximum number of parallel threads ``make`` can run.
2592 2592
@@ -2602,7 +2602,7 @@ system and gives an overview of their function and contents.
2602 performance could take some experimentation since machine speed, 2602 performance could take some experimentation since machine speed,
2603 network lag, available memory, and existing machine loads can all 2603 network lag, available memory, and existing machine loads can all
2604 affect build time. Consequently, unlike the 2604 affect build time. Consequently, unlike the
2605 ```PARALLEL_MAKE`` <#var-PARALLEL_MAKE>`__ variable, there is no 2605 :term:`PARALLEL_MAKE` variable, there is no
2606 rule-of-thumb for setting ``ICECC_PARALLEL_MAKE`` to achieve optimal 2606 rule-of-thumb for setting ``ICECC_PARALLEL_MAKE`` to achieve optimal
2607 performance. 2607 performance.
2608 2608
@@ -2613,13 +2613,13 @@ system and gives an overview of their function and contents.
2613 ICECC_PATH 2613 ICECC_PATH
2614 The location of the ``icecc`` binary. You can set this variable in 2614 The location of the ``icecc`` binary. You can set this variable in
2615 your ``local.conf`` file. If your ``local.conf`` file does not define 2615 your ``local.conf`` file. If your ``local.conf`` file does not define
2616 this variable, the ```icecc`` <#ref-classes-icecc>`__ class attempts 2616 this variable, the :ref:`icecc <ref-classes-icecc>` class attempts
2617 to define it by locating ``icecc`` using ``which``. 2617 to define it by locating ``icecc`` using ``which``.
2618 2618
2619 ICECC_USER_CLASS_BL 2619 ICECC_USER_CLASS_BL
2620 Identifies user classes that you do not want the Icecream distributed 2620 Identifies user classes that you do not want the Icecream distributed
2621 compile support to consider. This variable is used by the 2621 compile support to consider. This variable is used by the
2622 ```icecc`` <#ref-classes-icecc>`__ class. You set this variable in 2622 :ref:`icecc <ref-classes-icecc>` class. You set this variable in
2623 your ``local.conf`` file. 2623 your ``local.conf`` file.
2624 2624
2625 When you list classes using this variable, you are "blacklisting" 2625 When you list classes using this variable, you are "blacklisting"
@@ -2629,7 +2629,7 @@ system and gives an overview of their function and contents.
2629 ICECC_USER_PACKAGE_BL 2629 ICECC_USER_PACKAGE_BL
2630 Identifies user recipes that you do not want the Icecream distributed 2630 Identifies user recipes that you do not want the Icecream distributed
2631 compile support to consider. This variable is used by the 2631 compile support to consider. This variable is used by the
2632 ```icecc`` <#ref-classes-icecc>`__ class. You set this variable in 2632 :ref:`icecc <ref-classes-icecc>` class. You set this variable in
2633 your ``local.conf`` file. 2633 your ``local.conf`` file.
2634 2634
2635 When you list packages using this variable, you are "blacklisting" 2635 When you list packages using this variable, you are "blacklisting"
@@ -2638,15 +2638,15 @@ system and gives an overview of their function and contents.
2638 2638
2639 ICECC_USER_PACKAGE_WL 2639 ICECC_USER_PACKAGE_WL
2640 Identifies user recipes that use an empty 2640 Identifies user recipes that use an empty
2641 ```PARALLEL_MAKE`` <#var-PARALLEL_MAKE>`__ variable that you want to 2641 :term:`PARALLEL_MAKE` variable that you want to
2642 force remote distributed compilation on using the Icecream 2642 force remote distributed compilation on using the Icecream
2643 distributed compile support. This variable is used by the 2643 distributed compile support. This variable is used by the
2644 ```icecc`` <#ref-classes-icecc>`__ class. You set this variable in 2644 :ref:`icecc <ref-classes-icecc>` class. You set this variable in
2645 your ``local.conf`` file. 2645 your ``local.conf`` file.
2646 2646
2647 IMAGE_BASENAME 2647 IMAGE_BASENAME
2648 The base name of image output files. This variable defaults to the 2648 The base name of image output files. This variable defaults to the
2649 recipe name (``${``\ ```PN`` <#var-PN>`__\ ``}``). 2649 recipe name (``${``\ :term:`PN`\ ``}``).
2650 2650
2651 IMAGE_BOOT_FILES 2651 IMAGE_BOOT_FILES
2652 A space-separated list of files installed into the boot partition 2652 A space-separated list of files installed into the boot partition
@@ -2656,7 +2656,7 @@ system and gives an overview of their function and contents.
2656 installed under the same name as the source files. To change the 2656 installed under the same name as the source files. To change the
2657 installed name, separate it from the original name with a semi-colon 2657 installed name, separate it from the original name with a semi-colon
2658 (;). Source files need to be located in 2658 (;). Source files need to be located in
2659 ```DEPLOY_DIR_IMAGE`` <#var-DEPLOY_DIR_IMAGE>`__. Here are two 2659 :term:`DEPLOY_DIR_IMAGE`. Here are two
2660 examples: IMAGE_BOOT_FILES = "u-boot.img uImage;kernel" 2660 examples: IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
2661 IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}" 2661 IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
2662 2662
@@ -2687,12 +2687,12 @@ system and gives an overview of their function and contents.
2687 configuration file. 2687 configuration file.
2688 2688
2689 For more information, see ``meta/classes/image_types.bbclass`` in the 2689 For more information, see ``meta/classes/image_types.bbclass`` in the
2690 `Source Directory <#source-directory>`__. 2690 :term:`Source Directory`.
2691 2691
2692 IMAGE_CMD 2692 IMAGE_CMD
2693 Specifies the command to create the image file for a specific image 2693 Specifies the command to create the image file for a specific image
2694 type, which corresponds to the value set set in 2694 type, which corresponds to the value set set in
2695 ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__, (e.g. ``ext3``, 2695 :term:`IMAGE_FSTYPES`, (e.g. ``ext3``,
2696 ``btrfs``, and so forth). When setting this variable, you should use 2696 ``btrfs``, and so forth). When setting this variable, you should use
2697 an override for the associated type. Here is an example: 2697 an override for the associated type. Here is an example:
2698 IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \\ --faketime 2698 IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \\ --faketime
@@ -2701,7 +2701,7 @@ system and gives an overview of their function and contents.
2701 2701
2702 You typically do not need to set this variable unless you are adding 2702 You typically do not need to set this variable unless you are adding
2703 support for a new image type. For more examples on how to set this 2703 support for a new image type. For more examples on how to set this
2704 variable, see the ```image_types`` <#ref-classes-image_types>`__ 2704 variable, see the :ref:`image_types <ref-classes-image_types>`
2705 class file, which is ``meta/classes/image_types.bbclass``. 2705 class file, which is ``meta/classes/image_types.bbclass``.
2706 2706
2707 IMAGE_DEVICE_TABLES 2707 IMAGE_DEVICE_TABLES
@@ -2710,7 +2710,7 @@ system and gives an overview of their function and contents.
2710 These files list basic device nodes that should be created under 2710 These files list basic device nodes that should be created under
2711 ``/dev`` within the image. If ``IMAGE_DEVICE_TABLES`` is not set, 2711 ``/dev`` within the image. If ``IMAGE_DEVICE_TABLES`` is not set,
2712 ``files/device_table-minimal.txt`` is used, which is located by 2712 ``files/device_table-minimal.txt`` is used, which is located by
2713 ```BBPATH`` <#var-BBPATH>`__. For details on how you should write 2713 :term:`BBPATH`. For details on how you should write
2714 device table files, see ``meta/files/device_table-minimal.txt`` as an 2714 device table files, see ``meta/files/device_table-minimal.txt`` as an
2715 example. 2715 example.
2716 2716
@@ -2744,7 +2744,7 @@ system and gives an overview of their function and contents.
2744 IMAGE_FSTYPES = "ext3 tar.bz2" 2744 IMAGE_FSTYPES = "ext3 tar.bz2"
2745 2745
2746 For the complete list of supported image formats from which you can 2746 For the complete list of supported image formats from which you can
2747 choose, see ```IMAGE_TYPES`` <#var-IMAGE_TYPES>`__. 2747 choose, see :term:`IMAGE_TYPES`.
2748 2748
2749 .. note:: 2749 .. note::
2750 2750
@@ -2759,13 +2759,13 @@ system and gives an overview of their function and contents.
2759 2759
2760 IMAGE_INSTALL 2760 IMAGE_INSTALL
2761 Used by recipes to specify the packages to install into an image 2761 Used by recipes to specify the packages to install into an image
2762 through the ```image`` <#ref-classes-image>`__ class. Use the 2762 through the :ref:`image <ref-classes-image>` class. Use the
2763 ``IMAGE_INSTALL`` variable with care to avoid ordering issues. 2763 ``IMAGE_INSTALL`` variable with care to avoid ordering issues.
2764 2764
2765 Image recipes set ``IMAGE_INSTALL`` to specify the packages to 2765 Image recipes set ``IMAGE_INSTALL`` to specify the packages to
2766 install into an image through ``image.bbclass``. Additionally, 2766 install into an image through ``image.bbclass``. Additionally,
2767 "helper" classes such as the 2767 "helper" classes such as the
2768 ```core-image`` <#ref-classes-core-image>`__ class exist that can 2768 :ref:`core-image <ref-classes-core-image>` class exist that can
2769 take lists used with ``IMAGE_FEATURES`` and turn them into 2769 take lists used with ``IMAGE_FEATURES`` and turn them into
2770 auto-generated entries in ``IMAGE_INSTALL`` in addition to its 2770 auto-generated entries in ``IMAGE_INSTALL`` in addition to its
2771 default contents. 2771 default contents.
@@ -2781,7 +2781,7 @@ system and gives an overview of their function and contents.
2781 ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__ 2781 ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
2782 image, do not use the ``IMAGE_INSTALL`` variable to specify 2782 image, do not use the ``IMAGE_INSTALL`` variable to specify
2783 packages for installation. Instead, use the 2783 packages for installation. Instead, use the
2784 ```PACKAGE_INSTALL`` <#var-PACKAGE_INSTALL>`__ variable, which 2784 :term:`PACKAGE_INSTALL` variable, which
2785 allows the initial RAM filesystem (initramfs) recipe to use a 2785 allows the initial RAM filesystem (initramfs) recipe to use a
2786 fixed set of packages and not be affected by ``IMAGE_INSTALL``. 2786 fixed set of packages and not be affected by ``IMAGE_INSTALL``.
2787 For information on creating an initramfs, see the "`Building an 2787 For information on creating an initramfs, see the "`Building an
@@ -2820,7 +2820,7 @@ system and gives an overview of their function and contents.
2820 only provide locale files by language and not by country-specific 2820 only provide locale files by language and not by country-specific
2821 language). 2821 language).
2822 2822
2823 See the ```GLIBC_GENERATE_LOCALES`` <#var-GLIBC_GENERATE_LOCALES>`__ 2823 See the :term:`GLIBC_GENERATE_LOCALES`
2824 variable for information on generating GLIBC locales. 2824 variable for information on generating GLIBC locales.
2825 2825
2826 IMAGE_MANIFEST 2826 IMAGE_MANIFEST
@@ -2829,19 +2829,19 @@ system and gives an overview of their function and contents.
2829 information on a line-per-package basis as follows: packagename 2829 information on a line-per-package basis as follows: packagename
2830 packagearch version 2830 packagearch version
2831 2831
2832 The ```image`` <#ref-classes-image>`__ class defines the manifest 2832 The :ref:`image <ref-classes-image>` class defines the manifest
2833 file as follows: IMAGE_MANIFEST = 2833 file as follows: IMAGE_MANIFEST =
2834 "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" The location is 2834 "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" The location is
2835 derived using the ```DEPLOY_DIR_IMAGE`` <#var-DEPLOY_DIR_IMAGE>`__ 2835 derived using the :term:`DEPLOY_DIR_IMAGE`
2836 and ```IMAGE_NAME`` <#var-IMAGE_NAME>`__ variables. You can find 2836 and :term:`IMAGE_NAME` variables. You can find
2837 information on how the image is created in the "`Image 2837 information on how the image is created in the "`Image
2838 Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" 2838 Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
2839 section in the Yocto Project Overview and Concepts Manual. 2839 section in the Yocto Project Overview and Concepts Manual.
2840 2840
2841 IMAGE_NAME 2841 IMAGE_NAME
2842 The name of the output image files minus the extension. This variable 2842 The name of the output image files minus the extension. This variable
2843 is derived using the ```IMAGE_BASENAME`` <#var-IMAGE_BASENAME>`__, 2843 is derived using the :term:`IMAGE_BASENAME`,
2844 ```MACHINE`` <#var-MACHINE>`__, and ```DATETIME`` <#var-DATETIME>`__ 2844 :term:`MACHINE`, and :term:`DATETIME`
2845 variables: IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" 2845 variables: IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
2846 2846
2847 IMAGE_OVERHEAD_FACTOR 2847 IMAGE_OVERHEAD_FACTOR
@@ -2874,10 +2874,10 @@ system and gives an overview of their function and contents.
2874 IMAGE_PKGTYPE 2874 IMAGE_PKGTYPE
2875 Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the 2875 Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the
2876 OpenEmbedded build system. The variable is defined appropriately by 2876 OpenEmbedded build system. The variable is defined appropriately by
2877 the ```package_deb`` <#ref-classes-package_deb>`__, 2877 the :ref:`package_deb <ref-classes-package_deb>`,
2878 ```package_rpm`` <#ref-classes-package_rpm>`__, 2878 :ref:`package_rpm <ref-classes-package_rpm>`,
2879 ```package_ipk`` <#ref-classes-package_ipk>`__, or 2879 :ref:`package_ipk <ref-classes-package_ipk>`, or
2880 ```package_tar`` <#ref-classes-package_tar>`__ class. 2880 :ref:`package_tar <ref-classes-package_tar>` class.
2881 2881
2882 .. note:: 2882 .. note::
2883 2883
@@ -2887,13 +2887,13 @@ system and gives an overview of their function and contents.
2887 do not use it. 2887 do not use it.
2888 2888
2889 The ```populate_sdk_*`` <#ref-classes-populate-sdk-*>`__ and 2889 The ```populate_sdk_*`` <#ref-classes-populate-sdk-*>`__ and
2890 ```image`` <#ref-classes-image>`__ classes use the ``IMAGE_PKGTYPE`` 2890 :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE``
2891 for packaging up images and SDKs. 2891 for packaging up images and SDKs.
2892 2892
2893 You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the 2893 You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the
2894 variable is set indirectly through the appropriate 2894 variable is set indirectly through the appropriate
2895 ```package_*`` <#ref-classes-package>`__ class using the 2895 ```package_*`` <#ref-classes-package>`__ class using the
2896 ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__ variable. The 2896 :term:`PACKAGE_CLASSES` variable. The
2897 OpenEmbedded build system uses the first package type (e.g. DEB, RPM, 2897 OpenEmbedded build system uses the first package type (e.g. DEB, RPM,
2898 or IPK) that appears with the variable 2898 or IPK) that appears with the variable
2899 2899
@@ -2913,7 +2913,7 @@ system and gives an overview of their function and contents.
2913 If you need to pass the root filesystem path to a command within the 2913 If you need to pass the root filesystem path to a command within the
2914 function, you can use ``${IMAGE_ROOTFS}``, which points to the 2914 function, you can use ``${IMAGE_ROOTFS}``, which points to the
2915 directory that becomes the root filesystem image. See the 2915 directory that becomes the root filesystem image. See the
2916 ```IMAGE_ROOTFS`` <#var-IMAGE_ROOTFS>`__ variable for more 2916 :term:`IMAGE_ROOTFS` variable for more
2917 information. 2917 information.
2918 2918
2919 IMAGE_PREPROCESS_COMMAND 2919 IMAGE_PREPROCESS_COMMAND
@@ -2925,19 +2925,19 @@ system and gives an overview of their function and contents.
2925 If you need to pass the root filesystem path to a command within the 2925 If you need to pass the root filesystem path to a command within the
2926 function, you can use ``${IMAGE_ROOTFS}``, which points to the 2926 function, you can use ``${IMAGE_ROOTFS}``, which points to the
2927 directory that becomes the root filesystem image. See the 2927 directory that becomes the root filesystem image. See the
2928 ```IMAGE_ROOTFS`` <#var-IMAGE_ROOTFS>`__ variable for more 2928 :term:`IMAGE_ROOTFS` variable for more
2929 information. 2929 information.
2930 2930
2931 IMAGE_ROOTFS 2931 IMAGE_ROOTFS
2932 The location of the root filesystem while it is under construction 2932 The location of the root filesystem while it is under construction
2933 (i.e. during the ```do_rootfs`` <#ref-tasks-rootfs>`__ task). This 2933 (i.e. during the :ref:`ref-tasks-rootfs` task). This
2934 variable is not configurable. Do not change it. 2934 variable is not configurable. Do not change it.
2935 2935
2936 IMAGE_ROOTFS_ALIGNMENT 2936 IMAGE_ROOTFS_ALIGNMENT
2937 Specifies the alignment for the output image file in Kbytes. If the 2937 Specifies the alignment for the output image file in Kbytes. If the
2938 size of the image is not a multiple of this value, then the size is 2938 size of the image is not a multiple of this value, then the size is
2939 rounded up to the nearest multiple of the value. The default value is 2939 rounded up to the nearest multiple of the value. The default value is
2940 "1". See ```IMAGE_ROOTFS_SIZE`` <#var-IMAGE_ROOTFS_SIZE>`__ for 2940 "1". See :term:`IMAGE_ROOTFS_SIZE` for
2941 additional information. 2941 additional information.
2942 2942
2943 IMAGE_ROOTFS_EXTRA_SPACE 2943 IMAGE_ROOTFS_EXTRA_SPACE
@@ -2971,17 +2971,17 @@ system and gives an overview of their function and contents.
2971 internal-rootfs-size = Initial root filesystem size before any 2971 internal-rootfs-size = Initial root filesystem size before any
2972 modifications. xspace = IMAGE_ROOTFS_EXTRA_SPACE 2972 modifications. xspace = IMAGE_ROOTFS_EXTRA_SPACE
2973 2973
2974 See the ```IMAGE_OVERHEAD_FACTOR`` <#var-IMAGE_OVERHEAD_FACTOR>`__ 2974 See the :term:`IMAGE_OVERHEAD_FACTOR`
2975 and ```IMAGE_ROOTFS_EXTRA_SPACE`` <#var-IMAGE_ROOTFS_EXTRA_SPACE>`__ 2975 and :term:`IMAGE_ROOTFS_EXTRA_SPACE`
2976 variables for related information. 2976 variables for related information.
2977 2977
2978 IMAGE_TYPEDEP 2978 IMAGE_TYPEDEP
2979 Specifies a dependency from one image type on another. Here is an 2979 Specifies a dependency from one image type on another. Here is an
2980 example from the ```image-live`` <#ref-classes-image-live>`__ class: 2980 example from the :ref:`image-live <ref-classes-image-live>` class:
2981 IMAGE_TYPEDEP_live = "ext3" 2981 IMAGE_TYPEDEP_live = "ext3"
2982 2982
2983 In the previous example, the variable ensures that when "live" is 2983 In the previous example, the variable ensures that when "live" is
2984 listed with the ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ variable, 2984 listed with the :term:`IMAGE_FSTYPES` variable,
2985 the OpenEmbedded build system produces an ``ext3`` image first since 2985 the OpenEmbedded build system produces an ``ext3`` image first since
2986 one of the components of the live image is an ``ext3`` formatted 2986 one of the components of the live image is an ``ext3`` formatted
2987 partition containing the root filesystem. 2987 partition containing the root filesystem.
@@ -3005,7 +3005,7 @@ system and gives an overview of their function and contents.
3005 3005
3006 Suppose, for example, you have a set of recipes that are used across 3006 Suppose, for example, you have a set of recipes that are used across
3007 several projects. And, within each of those recipes the revision (its 3007 several projects. And, within each of those recipes the revision (its
3008 ```PR`` <#var-PR>`__ value) is set accordingly. In this case, when 3008 :term:`PR` value) is set accordingly. In this case, when
3009 the revision of those recipes changes, the burden is on you to find 3009 the revision of those recipes changes, the burden is on you to find
3010 all those recipes and be sure that they get changed to reflect the 3010 all those recipes and be sure that they get changed to reflect the
3011 updated version of the recipe. In this scenario, it can get 3011 updated version of the recipe. In this scenario, it can get
@@ -3034,7 +3034,7 @@ system and gives an overview of their function and contents.
3034 3034
3035 INCOMPATIBLE_LICENSE 3035 INCOMPATIBLE_LICENSE
3036 Specifies a space-separated list of license names (as they would 3036 Specifies a space-separated list of license names (as they would
3037 appear in ```LICENSE`` <#var-LICENSE>`__) that should be excluded 3037 appear in :term:`LICENSE`) that should be excluded
3038 from the build. Recipes that provide no alternatives to listed 3038 from the build. Recipes that provide no alternatives to listed
3039 incompatible licenses are not built. Packages that are individually 3039 incompatible licenses are not built. Packages that are individually
3040 licensed with the specified incompatible licenses will be deleted. 3040 licensed with the specified incompatible licenses will be deleted.
@@ -3095,7 +3095,7 @@ system and gives an overview of their function and contents.
3095 3095
3096 INHIBIT_DEFAULT_DEPS 3096 INHIBIT_DEFAULT_DEPS
3097 Prevents the default dependencies, namely the C compiler and standard 3097 Prevents the default dependencies, namely the C compiler and standard
3098 C library (libc), from being added to ```DEPENDS`` <#var-DEPENDS>`__. 3098 C library (libc), from being added to :term:`DEPENDS`.
3099 This variable is usually used within recipes that do not require any 3099 This variable is usually used within recipes that do not require any
3100 compilation using the C compiler. 3100 compilation using the C compiler.
3101 3101
@@ -3106,9 +3106,9 @@ system and gives an overview of their function and contents.
3106 Prevents the OpenEmbedded build system from splitting out debug 3106 Prevents the OpenEmbedded build system from splitting out debug
3107 information during packaging. By default, the build system splits out 3107 information during packaging. By default, the build system splits out
3108 debugging information during the 3108 debugging information during the
3109 ```do_package`` <#ref-tasks-package>`__ task. For more information on 3109 :ref:`ref-tasks-package` task. For more information on
3110 how debug information is split out, see the 3110 how debug information is split out, see the
3111 ```PACKAGE_DEBUG_SPLIT_STYLE`` <#var-PACKAGE_DEBUG_SPLIT_STYLE>`__ 3111 :term:`PACKAGE_DEBUG_SPLIT_STYLE`
3112 variable. 3112 variable.
3113 3113
3114 To prevent the build system from splitting out debug information 3114 To prevent the build system from splitting out debug information
@@ -3121,7 +3121,7 @@ system and gives an overview of their function and contents.
3121 files. 3121 files.
3122 3122
3123 By default, the OpenEmbedded build system strips binaries and puts 3123 By default, the OpenEmbedded build system strips binaries and puts
3124 the debugging symbols into ``${``\ ```PN`` <#var-PN>`__\ ``}-dbg``. 3124 the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``.
3125 Consequently, you should not set ``INHIBIT_PACKAGE_STRIP`` when you 3125 Consequently, you should not set ``INHIBIT_PACKAGE_STRIP`` when you
3126 plan to debug in general. 3126 plan to debug in general.
3127 3127
@@ -3135,7 +3135,7 @@ system and gives an overview of their function and contents.
3135 this stripping. 3135 this stripping.
3136 3136
3137 If you want to use this variable, include the 3137 If you want to use this variable, include the
3138 ```staging`` <#ref-classes-staging>`__ class. This class uses a 3138 :ref:`staging <ref-classes-staging>` class. This class uses a
3139 ``sys_strip()`` function to test for the variable and acts 3139 ``sys_strip()`` function to test for the variable and acts
3140 accordingly. 3140 accordingly.
3141 3141
@@ -3153,7 +3153,7 @@ system and gives an overview of their function and contents.
3153 Defines the format for the output image of an initial RAM filesystem 3153 Defines the format for the output image of an initial RAM filesystem
3154 (initramfs), which is used during boot. Supported formats are the 3154 (initramfs), which is used during boot. Supported formats are the
3155 same as those supported by the 3155 same as those supported by the
3156 ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ variable. 3156 :term:`IMAGE_FSTYPES` variable.
3157 3157
3158 The default value of this variable, which is set in the 3158 The default value of this variable, which is set in the
3159 ``meta/conf/bitbake.conf`` configuration file in the `Source 3159 ``meta/conf/bitbake.conf`` configuration file in the `Source
@@ -3163,14 +3163,14 @@ system and gives an overview of their function and contents.
3163 an optionally compressed cpio archive. 3163 an optionally compressed cpio archive.
3164 3164
3165 INITRAMFS_IMAGE 3165 INITRAMFS_IMAGE
3166 Specifies the ```PROVIDES`` <#var-PROVIDES>`__ name of an image 3166 Specifies the :term:`PROVIDES` name of an image
3167 recipe that is used to build an initial RAM filesystem (initramfs) 3167 recipe that is used to build an initial RAM filesystem (initramfs)
3168 image. In other words, the ``INITRAMFS_IMAGE`` variable causes an 3168 image. In other words, the ``INITRAMFS_IMAGE`` variable causes an
3169 additional recipe to be built as a dependency to whatever root 3169 additional recipe to be built as a dependency to whatever root
3170 filesystem recipe you might be using (e.g. ``core-image-sato``). The 3170 filesystem recipe you might be using (e.g. ``core-image-sato``). The
3171 initramfs image recipe you provide should set 3171 initramfs image recipe you provide should set
3172 ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ to 3172 :term:`IMAGE_FSTYPES` to
3173 ```INITRAMFS_FSTYPES`` <#var-INITRAMFS_FSTYPES>`__. 3173 :term:`INITRAMFS_FSTYPES`.
3174 3174
3175 An initramfs image provides a temporary root filesystem used for 3175 An initramfs image provides a temporary root filesystem used for
3176 early system initialization (e.g. loading of modules needed to locate 3176 early system initialization (e.g. loading of modules needed to locate
@@ -3189,15 +3189,15 @@ system and gives an overview of their function and contents.
3189 3189
3190 You can also find more information by referencing the 3190 You can also find more information by referencing the
3191 ``meta-poky/conf/local.conf.sample.extended`` configuration file in 3191 ``meta-poky/conf/local.conf.sample.extended`` configuration file in
3192 the Source Directory, the ```image`` <#ref-classes-image>`__ class, 3192 the Source Directory, the :ref:`image <ref-classes-image>` class,
3193 and the ```kernel`` <#ref-classes-kernel>`__ class to see how to use 3193 and the :ref:`kernel <ref-classes-kernel>` class to see how to use
3194 the ``INITRAMFS_IMAGE`` variable. 3194 the ``INITRAMFS_IMAGE`` variable.
3195 3195
3196 If ``INITRAMFS_IMAGE`` is empty, which is the default, then no 3196 If ``INITRAMFS_IMAGE`` is empty, which is the default, then no
3197 initramfs image is built. 3197 initramfs image is built.
3198 3198
3199 For more information, you can also see the 3199 For more information, you can also see the
3200 ```INITRAMFS_IMAGE_BUNDLE`` <#var-INITRAMFS_IMAGE_BUNDLE>`__ 3200 :term:`INITRAMFS_IMAGE_BUNDLE`
3201 variable, which allows the generated image to be bundled inside the 3201 variable, which allows the generated image to be bundled inside the
3202 kernel image. Additionally, for information on creating an initramfs 3202 kernel image. Additionally, for information on creating an initramfs
3203 image, see the "`Building an Initial RAM Filesystem (initramfs) 3203 image, see the "`Building an Initial RAM Filesystem (initramfs)
@@ -3206,13 +3206,13 @@ system and gives an overview of their function and contents.
3206 3206
3207 INITRAMFS_IMAGE_BUNDLE 3207 INITRAMFS_IMAGE_BUNDLE
3208 Controls whether or not the image recipe specified by 3208 Controls whether or not the image recipe specified by
3209 ```INITRAMFS_IMAGE`` <#var-INITRAMFS_IMAGE>`__ is run through an 3209 :term:`INITRAMFS_IMAGE` is run through an
3210 extra pass 3210 extra pass
3211 (```do_bundle_initramfs`` <#ref-tasks-bundle_initramfs>`__) during 3211 (:ref:`ref-tasks-bundle_initramfs`) during
3212 kernel compilation in order to build a single binary that contains 3212 kernel compilation in order to build a single binary that contains
3213 both the kernel image and the initial RAM filesystem (initramfs) 3213 both the kernel image and the initial RAM filesystem (initramfs)
3214 image. This makes use of the 3214 image. This makes use of the
3215 ```CONFIG_INITRAMFS_SOURCE`` <#var-CONFIG_INITRAMFS_SOURCE>`__ kernel 3215 :term:`CONFIG_INITRAMFS_SOURCE` kernel
3216 feature. 3216 feature.
3217 3217
3218 .. note:: 3218 .. note::
@@ -3225,13 +3225,13 @@ system and gives an overview of their function and contents.
3225 since the initramfs is bundled inside the kernel image. 3225 since the initramfs is bundled inside the kernel image.
3226 3226
3227 The combined binary is deposited into the ``tmp/deploy`` directory, 3227 The combined binary is deposited into the ``tmp/deploy`` directory,
3228 which is part of the `Build Directory <#build-directory>`__. 3228 which is part of the :term:`Build Directory`.
3229 3229
3230 Setting the variable to "1" in a configuration file causes the 3230 Setting the variable to "1" in a configuration file causes the
3231 OpenEmbedded build system to generate a kernel image with the 3231 OpenEmbedded build system to generate a kernel image with the
3232 initramfs specified in ``INITRAMFS_IMAGE`` bundled within: 3232 initramfs specified in ``INITRAMFS_IMAGE`` bundled within:
3233 INITRAMFS_IMAGE_BUNDLE = "1" By default, the 3233 INITRAMFS_IMAGE_BUNDLE = "1" By default, the
3234 ```kernel`` <#ref-classes-kernel>`__ class sets this variable to a 3234 :ref:`kernel <ref-classes-kernel>` class sets this variable to a
3235 null string as follows: INITRAMFS_IMAGE_BUNDLE ?= "" 3235 null string as follows: INITRAMFS_IMAGE_BUNDLE ?= ""
3236 3236
3237 .. note:: 3237 .. note::
@@ -3257,14 +3257,14 @@ system and gives an overview of their function and contents.
3257 file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= 3257 file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
3258 "${MACHINE}" 3258 "${MACHINE}"
3259 3259
3260 See the ```MACHINE`` <#var-MACHINE>`__ variable for additional 3260 See the :term:`MACHINE` variable for additional
3261 information. 3261 information.
3262 3262
3263 INITRAMFS_NAME 3263 INITRAMFS_NAME
3264 The base name of the initial RAM filesystem image. This variable is 3264 The base name of the initial RAM filesystem image. This variable is
3265 set in the ``meta/classes/kernel-artifact-names.bbclass`` file as 3265 set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
3266 follows: INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" The 3266 follows: INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" The
3267 value of the ```KERNEL_ARTIFACT_NAME`` <#var-KERNEL_ARTIFACT_NAME>`__ 3267 value of the :term:`KERNEL_ARTIFACT_NAME`
3268 variable, which is set in the same file, has the following value: 3268 variable, which is set in the same file, has the following value:
3269 KERNEL_ARTIFACT_NAME ?= 3269 KERNEL_ARTIFACT_NAME ?=
3270 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" 3270 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
@@ -3274,16 +3274,16 @@ system and gives an overview of their function and contents.
3274 initial RAM disk (``initrd``). 3274 initial RAM disk (``initrd``).
3275 3275
3276 The ``INITRD`` variable is an optional variable used with the 3276 The ``INITRD`` variable is an optional variable used with the
3277 ```image-live`` <#ref-classes-image-live>`__ class. 3277 :ref:`image-live <ref-classes-image-live>` class.
3278 3278
3279 INITRD_IMAGE 3279 INITRD_IMAGE
3280 When building a "live" bootable image (i.e. when 3280 When building a "live" bootable image (i.e. when
3281 ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ contains "live"), 3281 :term:`IMAGE_FSTYPES` contains "live"),
3282 ``INITRD_IMAGE`` specifies the image recipe that should be built to 3282 ``INITRD_IMAGE`` specifies the image recipe that should be built to
3283 provide the initial RAM disk image. The default value is 3283 provide the initial RAM disk image. The default value is
3284 "core-image-minimal-initramfs". 3284 "core-image-minimal-initramfs".
3285 3285
3286 See the ```image-live`` <#ref-classes-image-live>`__ class for more 3286 See the :ref:`image-live <ref-classes-image-live>` class for more
3287 information. 3287 information.
3288 3288
3289 INITSCRIPT_NAME 3289 INITSCRIPT_NAME
@@ -3299,7 +3299,7 @@ system and gives an overview of their function and contents.
3299 ``INITSCRIPT_*`` as an override. 3299 ``INITSCRIPT_*`` as an override.
3300 3300
3301 This variable is used in recipes when using ``update-rc.d.bbclass``. 3301 This variable is used in recipes when using ``update-rc.d.bbclass``.
3302 The variable is optional and defaults to the ```PN`` <#var-PN>`__ 3302 The variable is optional and defaults to the :term:`PN`
3303 variable. 3303 variable.
3304 3304
3305 INITSCRIPT_PARAMS 3305 INITSCRIPT_PARAMS
@@ -3310,7 +3310,7 @@ system and gives an overview of their function and contents.
3310 in initlevels 2 and 5, and stops the script in levels 0, 1 and 6. 3310 in initlevels 2 and 5, and stops the script in levels 0, 1 and 6.
3311 3311
3312 The variable's default value is "defaults", which is set in the 3312 The variable's default value is "defaults", which is set in the
3313 ```update-rc.d`` <#ref-classes-update-rc.d>`__ class. 3313 :ref:`update-rc.d <ref-classes-update-rc.d>` class.
3314 3314
3315 The value in ``INITSCRIPT_PARAMS`` is passed through to the 3315 The value in ``INITSCRIPT_PARAMS`` is passed through to the
3316 ``update-rc.d`` command. For more information on valid parameters, 3316 ``update-rc.d`` command. For more information on valid parameters,
@@ -3324,7 +3324,7 @@ system and gives an overview of their function and contents.
3324 recipe. The package name override must be used, which in this example 3324 recipe. The package name override must be used, which in this example
3325 is ``${PN}``: INSANE_SKIP_${PN} += "dev-so" 3325 is ``${PN}``: INSANE_SKIP_${PN} += "dev-so"
3326 3326
3327 See the "```insane.bbclass`` <#ref-classes-insane>`__" section for a 3327 See the ":ref:`insane.bbclass <ref-classes-insane>`" section for a
3328 list of the valid QA checks you can specify using this variable. 3328 list of the valid QA checks you can specify using this variable.
3329 3329
3330 INSTALL_TIMEZONE_FILE 3330 INSTALL_TIMEZONE_FILE
@@ -3376,7 +3376,7 @@ system and gives an overview of their function and contents.
3376 BSP. 3376 BSP.
3377 3377
3378 KBUILD_DEFCONFIG 3378 KBUILD_DEFCONFIG
3379 When used with the ```kernel-yocto`` <#ref-classes-kernel-yocto>`__ 3379 When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
3380 class, specifies an "in-tree" kernel configuration file for use 3380 class, specifies an "in-tree" kernel configuration file for use
3381 during a kernel build. 3381 during a kernel build.
3382 3382
@@ -3386,7 +3386,7 @@ system and gives an overview of their function and contents.
3386 "out-of-tree"). However, if you want to use a ``defconfig`` file that 3386 "out-of-tree"). However, if you want to use a ``defconfig`` file that
3387 is part of the kernel tree (i.e. "in-tree"), you can use the 3387 is part of the kernel tree (i.e. "in-tree"), you can use the
3388 ``KBUILD_DEFCONFIG`` variable and append the 3388 ``KBUILD_DEFCONFIG`` variable and append the
3389 ```KMACHINE`` <#var-KMACHINE>`__ variable to point to the 3389 :term:`KMACHINE` variable to point to the
3390 ``defconfig`` file. 3390 ``defconfig`` file.
3391 3391
3392 To use the variable, set it in the append file for your kernel recipe 3392 To use the variable, set it in the append file for your kernel recipe
@@ -3404,7 +3404,7 @@ system and gives an overview of their function and contents.
3404 KERNEL_ALT_IMAGETYPE 3404 KERNEL_ALT_IMAGETYPE
3405 Specifies an alternate kernel image type for creation in addition to 3405 Specifies an alternate kernel image type for creation in addition to
3406 the kernel image type specified using the 3406 the kernel image type specified using the
3407 ```KERNEL_IMAGETYPE`` <#var-KERNEL_IMAGETYPE>`__ variable. 3407 :term:`KERNEL_IMAGETYPE` variable.
3408 3408
3409 KERNEL_ARTIFACT_NAME 3409 KERNEL_ARTIFACT_NAME
3410 Specifies the name of all of the build artifacts. You can change the 3410 Specifies the name of all of the build artifacts. You can change the
@@ -3416,8 +3416,8 @@ system and gives an overview of their function and contents.
3416 following default value: KERNEL_ARTIFACT_NAME ?= 3416 following default value: KERNEL_ARTIFACT_NAME ?=
3417 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" 3417 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
3418 3418
3419 See the ```PKGE`` <#var-PKGE>`__, ```PKGV`` <#var-PKGV>`__, 3419 See the :term:`PKGE`, :term:`PKGV`,
3420 ```PKGR`` <#var-PKGR>`__, and ```MACHINE`` <#var-MACHINE>`__ 3420 :term:`PKGR`, and :term:`MACHINE`
3421 variables for additional information. 3421 variables for additional information.
3422 3422
3423 .. note:: 3423 .. note::
@@ -3430,7 +3430,7 @@ system and gives an overview of their function and contents.
3430 3430
3431 KERNEL_CLASSES 3431 KERNEL_CLASSES
3432 A list of classes defining kernel image types that the 3432 A list of classes defining kernel image types that the
3433 ```kernel`` <#ref-classes-kernel>`__ class should inherit. You 3433 :ref:`kernel <ref-classes-kernel>` class should inherit. You
3434 typically append this variable to enable extended image types. An 3434 typically append this variable to enable extended image types. An
3435 example is the "kernel-fitimage", which enables fitImage support and 3435 example is the "kernel-fitimage", which enables fitImage support and
3436 resides in ``meta/classes/kernel-fitimage.bbclass``. You can register 3436 resides in ``meta/classes/kernel-fitimage.bbclass``. You can register
@@ -3449,7 +3449,7 @@ system and gives an overview of their function and contents.
3449 file is preferred. 3449 file is preferred.
3450 3450
3451 In order to use this variable, the 3451 In order to use this variable, the
3452 ```kernel-devicetree`` <#ref-classes-kernel-devicetree>`__ class must 3452 :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class must
3453 be inherited. 3453 be inherited.
3454 3454
3455 KERNEL_DTB_LINK_NAME 3455 KERNEL_DTB_LINK_NAME
@@ -3460,14 +3460,14 @@ system and gives an overview of their function and contents.
3460 the same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= 3460 the same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
3461 "${MACHINE}" 3461 "${MACHINE}"
3462 3462
3463 See the ```MACHINE`` <#var-MACHINE>`__ variable for additional 3463 See the :term:`MACHINE` variable for additional
3464 information. 3464 information.
3465 3465
3466 KERNEL_DTB_NAME 3466 KERNEL_DTB_NAME
3467 The base name of the kernel device tree binary (DTB). This variable 3467 The base name of the kernel device tree binary (DTB). This variable
3468 is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as 3468 is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
3469 follows: KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of 3469 follows: KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of
3470 the ```KERNEL_ARTIFACT_NAME`` <#var-KERNEL_ARTIFACT_NAME>`__ 3470 the :term:`KERNEL_ARTIFACT_NAME`
3471 variable, which is set in the same file, has the following value: 3471 variable, which is set in the same file, has the following value:
3472 KERNEL_ARTIFACT_NAME ?= 3472 KERNEL_ARTIFACT_NAME ?=
3473 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" 3473 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
@@ -3479,8 +3479,8 @@ system and gives an overview of their function and contents.
3479 KERNEL_FEATURES 3479 KERNEL_FEATURES
3480 Includes additional kernel metadata. In the OpenEmbedded build 3480 Includes additional kernel metadata. In the OpenEmbedded build
3481 system, the default Board Support Packages (BSPs) 3481 system, the default Board Support Packages (BSPs)
3482 `Metadata <#metadata>`__ is provided through the 3482 :term:`Metadata` is provided through the
3483 ```KMACHINE`` <#var-KMACHINE>`__ and ```KBRANCH`` <#var-KBRANCH>`__ 3483 :term:`KMACHINE` and :term:`KBRANCH`
3484 variables. You can use the ``KERNEL_FEATURES`` variable from within 3484 variables. You can use the ``KERNEL_FEATURES`` variable from within
3485 the kernel recipe or kernel append file to further add metadata for 3485 the kernel recipe or kernel append file to further add metadata for
3486 all BSPs or specific BSPs. 3486 all BSPs or specific BSPs.
@@ -3511,14 +3511,14 @@ system and gives an overview of their function and contents.
3511 file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= 3511 file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
3512 "${MACHINE}" 3512 "${MACHINE}"
3513 3513
3514 See the ```MACHINE`` <#var-MACHINE>`__ variable for additional 3514 See the :term:`MACHINE` variable for additional
3515 information. 3515 information.
3516 3516
3517 KERNEL_FIT_NAME 3517 KERNEL_FIT_NAME
3518 The base name of the kernel flattened image tree (FIT) image. This 3518 The base name of the kernel flattened image tree (FIT) image. This
3519 variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` 3519 variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
3520 file as follows: KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" The 3520 file as follows: KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" The
3521 value of the ```KERNEL_ARTIFACT_NAME`` <#var-KERNEL_ARTIFACT_NAME>`__ 3521 value of the :term:`KERNEL_ARTIFACT_NAME`
3522 variable, which is set in the same file, has the following value: 3522 variable, which is set in the same file, has the following value:
3523 KERNEL_ARTIFACT_NAME ?= 3523 KERNEL_ARTIFACT_NAME ?=
3524 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" 3524 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
@@ -3531,14 +3531,14 @@ system and gives an overview of their function and contents.
3531 file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= 3531 file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
3532 "${MACHINE}" 3532 "${MACHINE}"
3533 3533
3534 See the ```MACHINE`` <#var-MACHINE>`__ variable for additional 3534 See the :term:`MACHINE` variable for additional
3535 information. 3535 information.
3536 3536
3537 KERNEL_IMAGE_MAXSIZE 3537 KERNEL_IMAGE_MAXSIZE
3538 Specifies the maximum size of the kernel image file in kilobytes. If 3538 Specifies the maximum size of the kernel image file in kilobytes. If
3539 ``KERNEL_IMAGE_MAXSIZE`` is set, the size of the kernel image file is 3539 ``KERNEL_IMAGE_MAXSIZE`` is set, the size of the kernel image file is
3540 checked against the set value during the 3540 checked against the set value during the
3541 ```do_sizecheck`` <#ref-tasks-sizecheck>`__ task. The task fails if 3541 :ref:`ref-tasks-sizecheck` task. The task fails if
3542 the kernel image file is larger than the setting. 3542 the kernel image file is larger than the setting.
3543 3543
3544 ``KERNEL_IMAGE_MAXSIZE`` is useful for target devices that have a 3544 ``KERNEL_IMAGE_MAXSIZE`` is useful for target devices that have a
@@ -3551,7 +3551,7 @@ system and gives an overview of their function and contents.
3551 The base name of the kernel image. This variable is set in the 3551 The base name of the kernel image. This variable is set in the
3552 ``meta/classes/kernel-artifact-names.bbclass`` file as follows: 3552 ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
3553 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the 3553 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the
3554 ```KERNEL_ARTIFACT_NAME`` <#var-KERNEL_ARTIFACT_NAME>`__ variable, 3554 :term:`KERNEL_ARTIFACT_NAME` variable,
3555 which is set in the same file, has the following value: 3555 which is set in the same file, has the following value:
3556 KERNEL_ARTIFACT_NAME ?= 3556 KERNEL_ARTIFACT_NAME ?=
3557 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" 3557 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
@@ -3563,7 +3563,7 @@ system and gives an overview of their function and contents.
3563 build. 3563 build.
3564 3564
3565 If you want to build an alternate kernel image type, use the 3565 If you want to build an alternate kernel image type, use the
3566 ```KERNEL_ALT_IMAGETYPE`` <#var-KERNEL_ALT_IMAGETYPE>`__ variable. 3566 :term:`KERNEL_ALT_IMAGETYPE` variable.
3567 3567
3568 KERNEL_MODULE_AUTOLOAD 3568 KERNEL_MODULE_AUTOLOAD
3569 Lists kernel modules that need to be auto-loaded during boot. 3569 Lists kernel modules that need to be auto-loaded during boot.
@@ -3591,7 +3591,7 @@ system and gives an overview of their function and contents.
3591 3591
3592 For information on how to populate the ``modname.conf`` file with 3592 For information on how to populate the ``modname.conf`` file with
3593 ``modprobe.d`` syntax lines, see the 3593 ``modprobe.d`` syntax lines, see the
3594 ```KERNEL_MODULE_PROBECONF`` <#var-KERNEL_MODULE_PROBECONF>`__ 3594 :term:`KERNEL_MODULE_PROBECONF`
3595 variable. 3595 variable.
3596 3596
3597 KERNEL_MODULE_PROBECONF 3597 KERNEL_MODULE_PROBECONF
@@ -3603,29 +3603,29 @@ system and gives an overview of their function and contents.
3603 3603
3604 KERNEL_PATH 3604 KERNEL_PATH
3605 The location of the kernel sources. This variable is set to the value 3605 The location of the kernel sources. This variable is set to the value
3606 of the ```STAGING_KERNEL_DIR`` <#var-STAGING_KERNEL_DIR>`__ within 3606 of the :term:`STAGING_KERNEL_DIR` within
3607 the ```module`` <#ref-classes-module>`__ class. For information on 3607 the :ref:`module <ref-classes-module>` class. For information on
3608 how this variable is used, see the "`Incorporating Out-of-Tree 3608 how this variable is used, see the "`Incorporating Out-of-Tree
3609 Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__" 3609 Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
3610 section in the Yocto Project Linux Kernel Development Manual. 3610 section in the Yocto Project Linux Kernel Development Manual.
3611 3611
3612 To help maximize compatibility with out-of-tree drivers used to build 3612 To help maximize compatibility with out-of-tree drivers used to build
3613 modules, the OpenEmbedded build system also recognizes and uses the 3613 modules, the OpenEmbedded build system also recognizes and uses the
3614 ```KERNEL_SRC`` <#var-KERNEL_SRC>`__ variable, which is identical to 3614 :term:`KERNEL_SRC` variable, which is identical to
3615 the ``KERNEL_PATH`` variable. Both variables are common variables 3615 the ``KERNEL_PATH`` variable. Both variables are common variables
3616 used by external Makefiles to point to the kernel source directory. 3616 used by external Makefiles to point to the kernel source directory.
3617 3617
3618 KERNEL_SRC 3618 KERNEL_SRC
3619 The location of the kernel sources. This variable is set to the value 3619 The location of the kernel sources. This variable is set to the value
3620 of the ```STAGING_KERNEL_DIR`` <#var-STAGING_KERNEL_DIR>`__ within 3620 of the :term:`STAGING_KERNEL_DIR` within
3621 the ```module`` <#ref-classes-module>`__ class. For information on 3621 the :ref:`module <ref-classes-module>` class. For information on
3622 how this variable is used, see the "`Incorporating Out-of-Tree 3622 how this variable is used, see the "`Incorporating Out-of-Tree
3623 Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__" 3623 Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
3624 section in the Yocto Project Linux Kernel Development Manual. 3624 section in the Yocto Project Linux Kernel Development Manual.
3625 3625
3626 To help maximize compatibility with out-of-tree drivers used to build 3626 To help maximize compatibility with out-of-tree drivers used to build
3627 modules, the OpenEmbedded build system also recognizes and uses the 3627 modules, the OpenEmbedded build system also recognizes and uses the
3628 ```KERNEL_PATH`` <#var-KERNEL_PATH>`__ variable, which is identical 3628 :term:`KERNEL_PATH` variable, which is identical
3629 to the ``KERNEL_SRC`` variable. Both variables are common variables 3629 to the ``KERNEL_SRC`` variable. Both variables are common variables
3630 used by external Makefiles to point to the kernel source directory. 3630 used by external Makefiles to point to the kernel source directory.
3631 3631
@@ -3638,7 +3638,7 @@ system and gives an overview of their function and contents.
3638 3638
3639 KERNELDEPMODDEPEND 3639 KERNELDEPMODDEPEND
3640 Specifies whether the data referenced through 3640 Specifies whether the data referenced through
3641 ```PKGDATA_DIR`` <#var-PKGDATA_DIR>`__ is needed or not. The 3641 :term:`PKGDATA_DIR` is needed or not. The
3642 ``KERNELDEPMODDEPEND`` does not control whether or not that data 3642 ``KERNELDEPMODDEPEND`` does not control whether or not that data
3643 exists, but simply whether or not it is used. If you do not need to 3643 exists, but simply whether or not it is used. If you do not need to
3644 use the data, set the ``KERNELDEPMODDEPEND`` variable in your 3644 use the data, set the ``KERNELDEPMODDEPEND`` variable in your
@@ -3690,13 +3690,13 @@ system and gives an overview of their function and contents.
3690 You define the ``KTYPE`` variable in the `BSP 3690 You define the ``KTYPE`` variable in the `BSP
3691 Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__. The 3691 Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__. The
3692 value you use must match the value used for the 3692 value you use must match the value used for the
3693 ```LINUX_KERNEL_TYPE`` <#var-LINUX_KERNEL_TYPE>`__ value used by the 3693 :term:`LINUX_KERNEL_TYPE` value used by the
3694 kernel recipe. 3694 kernel recipe.
3695 3695
3696 LABELS 3696 LABELS
3697 Provides a list of targets for automatic configuration. 3697 Provides a list of targets for automatic configuration.
3698 3698
3699 See the ```grub-efi`` <#ref-classes-grub-efi>`__ class for more 3699 See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
3700 information on how this variable is used. 3700 information on how this variable is used.
3701 3701
3702 LAYERDEPENDS 3702 LAYERDEPENDS
@@ -3705,7 +3705,7 @@ system and gives an overview of their function and contents.
3705 by adding it to the end of the layer name. Here is an example: 3705 by adding it to the end of the layer name. Here is an example:
3706 LAYERDEPENDS_mylayer = "anotherlayer (=3)" In this previous example, 3706 LAYERDEPENDS_mylayer = "anotherlayer (=3)" In this previous example,
3707 version 3 of "anotherlayer" is compared against 3707 version 3 of "anotherlayer" is compared against
3708 ```LAYERVERSION`` <#var-LAYERVERSION>`__\ ``_anotherlayer``. 3708 :term:`LAYERVERSION`\ ``_anotherlayer``.
3709 3709
3710 An error is produced if any dependency is missing or the version 3710 An error is produced if any dependency is missing or the version
3711 numbers (if specified) do not match exactly. This variable is used in 3711 numbers (if specified) do not match exactly. This variable is used in
@@ -3733,7 +3733,7 @@ system and gives an overview of their function and contents.
3733 ``LAYERRECOMMENDS_mylayer``). 3733 ``LAYERRECOMMENDS_mylayer``).
3734 3734
3735 LAYERSERIES_COMPAT 3735 LAYERSERIES_COMPAT
3736 Lists the versions of the `OpenEmbedded-Core <#oe-core>`__ for which 3736 Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which
3737 a layer is compatible. Using the ``LAYERSERIES_COMPAT`` variable 3737 a layer is compatible. Using the ``LAYERSERIES_COMPAT`` variable
3738 allows the layer maintainer to indicate which combinations of the 3738 allows the layer maintainer to indicate which combinations of the
3739 layer and OE-Core can be expected to work. The variable gives the 3739 layer and OE-Core can be expected to work. The variable gives the
@@ -3762,7 +3762,7 @@ system and gives an overview of their function and contents.
3762 3762
3763 LAYERVERSION 3763 LAYERVERSION
3764 Optionally specifies the version of a layer as a single number. You 3764 Optionally specifies the version of a layer as a single number. You
3765 can use this within ```LAYERDEPENDS`` <#var-LAYERDEPENDS>`__ for 3765 can use this within :term:`LAYERDEPENDS` for
3766 another layer in order to depend on a specific version of the layer. 3766 another layer in order to depend on a specific version of the layer.
3767 This variable is used in the ``conf/layer.conf`` file and must be 3767 This variable is used in the ``conf/layer.conf`` file and must be
3768 suffixed with the name of the specific layer (e.g. 3768 suffixed with the name of the specific layer (e.g.
@@ -3779,18 +3779,18 @@ system and gives an overview of their function and contents.
3779 Default initialization for ``LDFLAGS`` varies depending on what is 3779 Default initialization for ``LDFLAGS`` varies depending on what is
3780 being built: 3780 being built:
3781 3781
3782 - ```TARGET_LDFLAGS`` <#var-TARGET_LDFLAGS>`__ when building for the 3782 - :term:`TARGET_LDFLAGS` when building for the
3783 target 3783 target
3784 3784
3785 - ```BUILD_LDFLAGS`` <#var-BUILD_LDFLAGS>`__ when building for the 3785 - :term:`BUILD_LDFLAGS` when building for the
3786 build host (i.e. ``-native``) 3786 build host (i.e. ``-native``)
3787 3787
3788 - ```BUILDSDK_LDFLAGS`` <#var-BUILDSDK_LDFLAGS>`__ when building for 3788 - :term:`BUILDSDK_LDFLAGS` when building for
3789 an SDK (i.e. ``nativesdk-``) 3789 an SDK (i.e. ``nativesdk-``)
3790 3790
3791 LEAD_SONAME 3791 LEAD_SONAME
3792 Specifies the lead (or primary) compiled library file (i.e. ``.so``) 3792 Specifies the lead (or primary) compiled library file (i.e. ``.so``)
3793 that the ```debian`` <#ref-classes-debian>`__ class applies its 3793 that the :ref:`debian <ref-classes-debian>` class applies its
3794 naming policy to given a recipe that packages multiple libraries. 3794 naming policy to given a recipe that packages multiple libraries.
3795 3795
3796 This variable works in conjunction with the ``debian`` class. 3796 This variable works in conjunction with the ``debian`` class.
@@ -3804,7 +3804,7 @@ system and gives an overview of their function and contents.
3804 license change. 3804 license change.
3805 3805
3806 This variable must be defined for all recipes (unless 3806 This variable must be defined for all recipes (unless
3807 ```LICENSE`` <#var-LICENSE>`__ is set to "CLOSED"). 3807 :term:`LICENSE` is set to "CLOSED").
3808 3808
3809 For more information, see the "`Tracking License 3809 For more information, see the "`Tracking License
3810 Changes <&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-LIC_FILES_CHKSUM>`__" 3810 Changes <&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-LIC_FILES_CHKSUM>`__"
@@ -3825,7 +3825,7 @@ system and gives an overview of their function and contents.
3825 3825
3826 - For standard licenses, use the names of the files in 3826 - For standard licenses, use the names of the files in
3827 ``meta/files/common-licenses/`` or the 3827 ``meta/files/common-licenses/`` or the
3828 ```SPDXLICENSEMAP`` <#var-SPDXLICENSEMAP>`__ flag names defined in 3828 :term:`SPDXLICENSEMAP` flag names defined in
3829 ``meta/conf/licenses.conf``. 3829 ``meta/conf/licenses.conf``.
3830 3830
3831 Here are some examples: LICENSE = "LGPLv2.1 \| GPLv3" LICENSE = 3831 Here are some examples: LICENSE = "LGPLv2.1 \| GPLv3" LICENSE =
@@ -3847,34 +3847,34 @@ system and gives an overview of their function and contents.
3847 LICENSE_CREATE_PACKAGE 3847 LICENSE_CREATE_PACKAGE
3848 Setting ``LICENSE_CREATE_PACKAGE`` to "1" causes the OpenEmbedded 3848 Setting ``LICENSE_CREATE_PACKAGE`` to "1" causes the OpenEmbedded
3849 build system to create an extra package (i.e. 3849 build system to create an extra package (i.e.
3850 ``${``\ ```PN`` <#var-PN>`__\ ``}-lic``) for each recipe and to add 3850 ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add
3851 those packages to the 3851 those packages to the
3852 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__\ ``_${PN}``. 3852 :term:`RRECOMMENDS`\ ``_${PN}``.
3853 3853
3854 The ``${PN}-lic`` package installs a directory in 3854 The ``${PN}-lic`` package installs a directory in
3855 ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base 3855 ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base
3856 name, and installs files in that directory that contain license and 3856 name, and installs files in that directory that contain license and
3857 copyright information (i.e. copies of the appropriate license files 3857 copyright information (i.e. copies of the appropriate license files
3858 from ``meta/common-licenses`` that match the licenses specified in 3858 from ``meta/common-licenses`` that match the licenses specified in
3859 the ```LICENSE`` <#var-LICENSE>`__ variable of the recipe metadata 3859 the :term:`LICENSE` variable of the recipe metadata
3860 and copies of files marked in 3860 and copies of files marked in
3861 ```LIC_FILES_CHKSUM`` <#var-LIC_FILES_CHKSUM>`__ as containing 3861 :term:`LIC_FILES_CHKSUM` as containing
3862 license text). 3862 license text).
3863 3863
3864 For related information on providing license text, see the 3864 For related information on providing license text, see the
3865 ```COPY_LIC_DIRS`` <#var-COPY_LIC_DIRS>`__ variable, the 3865 :term:`COPY_LIC_DIRS` variable, the
3866 ```COPY_LIC_MANIFEST`` <#var-COPY_LIC_MANIFEST>`__ variable, and the 3866 :term:`COPY_LIC_MANIFEST` variable, and the
3867 "`Providing License 3867 "`Providing License
3868 Text <&YOCTO_DOCS_DEV_URL;#providing-license-text>`__" section in the 3868 Text <&YOCTO_DOCS_DEV_URL;#providing-license-text>`__" section in the
3869 Yocto Project Development Tasks Manual. 3869 Yocto Project Development Tasks Manual.
3870 3870
3871 LICENSE_FLAGS 3871 LICENSE_FLAGS
3872 Specifies additional flags for a recipe you must whitelist through 3872 Specifies additional flags for a recipe you must whitelist through
3873 ```LICENSE_FLAGS_WHITELIST`` <#var-LICENSE_FLAGS_WHITELIST>`__ in 3873 :term:`LICENSE_FLAGS_WHITELIST` in
3874 order to allow the recipe to be built. When providing multiple flags, 3874 order to allow the recipe to be built. When providing multiple flags,
3875 separate them with spaces. 3875 separate them with spaces.
3876 3876
3877 This value is independent of ```LICENSE`` <#var-LICENSE>`__ and is 3877 This value is independent of :term:`LICENSE` and is
3878 typically used to mark recipes that might require additional licenses 3878 typically used to mark recipes that might require additional licenses
3879 in order to be used in a commercial product. For more information, 3879 in order to be used in a commercial product. For more information,
3880 see the "`Enabling Commercially Licensed 3880 see the "`Enabling Commercially Licensed
@@ -3883,7 +3883,7 @@ system and gives an overview of their function and contents.
3883 3883
3884 LICENSE_FLAGS_WHITELIST 3884 LICENSE_FLAGS_WHITELIST
3885 Lists license flags that when specified in 3885 Lists license flags that when specified in
3886 ```LICENSE_FLAGS`` <#var-LICENSE_FLAGS>`__ within a recipe should not 3886 :term:`LICENSE_FLAGS` within a recipe should not
3887 prevent that recipe from being built. This practice is otherwise 3887 prevent that recipe from being built. This practice is otherwise
3888 known as "whitelisting" license flags. For more information, see the 3888 known as "whitelisting" license flags. For more information, see the
3889 "`Enabling Commercially Licensed 3889 "`Enabling Commercially Licensed
@@ -3907,10 +3907,10 @@ system and gives an overview of their function and contents.
3907 kernel types. 3907 kernel types.
3908 3908
3909 If you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to 3909 If you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to
3910 "standard". Together with ```KMACHINE`` <#var-KMACHINE>`__, the 3910 "standard". Together with :term:`KMACHINE`, the
3911 ``LINUX_KERNEL_TYPE`` variable defines the search arguments used by 3911 ``LINUX_KERNEL_TYPE`` variable defines the search arguments used by
3912 the kernel tools to find the appropriate description within the 3912 the kernel tools to find the appropriate description within the
3913 kernel `Metadata <#metadata>`__ with which to build out the sources 3913 kernel :term:`Metadata` with which to build out the sources
3914 and configuration. 3914 and configuration.
3915 3915
3916 LINUX_VERSION 3916 LINUX_VERSION
@@ -3921,7 +3921,7 @@ system and gives an overview of their function and contents.
3921 ``meta/recipes-kernel/linux`` defines the variables as follows: 3921 ``meta/recipes-kernel/linux`` defines the variables as follows:
3922 LINUX_VERSION ?= "3.4.24" 3922 LINUX_VERSION ?= "3.4.24"
3923 3923
3924 The ``LINUX_VERSION`` variable is used to define ```PV`` <#var-PV>`__ 3924 The ``LINUX_VERSION`` variable is used to define :term:`PV`
3925 for the recipe: PV = "${LINUX_VERSION}+git${SRCPV}" 3925 for the recipe: PV = "${LINUX_VERSION}+git${SRCPV}"
3926 3926
3927 LINUX_VERSION_EXTENSION 3927 LINUX_VERSION_EXTENSION
@@ -3929,7 +3929,7 @@ system and gives an overview of their function and contents.
3929 kernel built with the OpenEmbedded build system. You define this 3929 kernel built with the OpenEmbedded build system. You define this
3930 variable in the kernel recipe. For example, the linux-yocto kernel 3930 variable in the kernel recipe. For example, the linux-yocto kernel
3931 recipes all define the variable as follows: LINUX_VERSION_EXTENSION 3931 recipes all define the variable as follows: LINUX_VERSION_EXTENSION
3932 ?= "-yocto-${`LINUX_KERNEL_TYPE <#var-LINUX_KERNEL_TYPE>`__}" 3932 ?= "-yocto-${:term:`LINUX_KERNEL_TYPE`}"
3933 3933
3934 Defining this variable essentially sets the Linux kernel 3934 Defining this variable essentially sets the Linux kernel
3935 configuration item ``CONFIG_LOCALVERSION``, which is visible through 3935 configuration item ``CONFIG_LOCALVERSION``, which is visible through
@@ -3941,7 +3941,7 @@ system and gives an overview of their function and contents.
3941 overall log files. The default directory is ``${TMPDIR}/log``. 3941 overall log files. The default directory is ``${TMPDIR}/log``.
3942 3942
3943 For the directory containing logs specific to each task, see the 3943 For the directory containing logs specific to each task, see the
3944 ```T`` <#var-T>`__ variable. 3944 :term:`T` variable.
3945 3945
3946 MACHINE 3946 MACHINE
3947 Specifies the target device for which the image is built. You define 3947 Specifies the target device for which the image is built. You define
@@ -3954,7 +3954,7 @@ system and gives an overview of their function and contents.
3954 name, through which machine-specific configurations are set. Thus, 3954 name, through which machine-specific configurations are set. Thus,
3955 when ``MACHINE`` is set to "qemux86" there exists the corresponding 3955 when ``MACHINE`` is set to "qemux86" there exists the corresponding
3956 ``qemux86.conf`` machine configuration file, which can be found in 3956 ``qemux86.conf`` machine configuration file, which can be found in
3957 the `Source Directory <#source-directory>`__ in 3957 the :term:`Source Directory` in
3958 ``meta/conf/machine``. 3958 ``meta/conf/machine``.
3959 3959
3960 The list of machines supported by the Yocto Project as shipped 3960 The list of machines supported by the Yocto Project as shipped
@@ -3974,8 +3974,8 @@ system and gives an overview of their function and contents.
3974 3974
3975 MACHINE_ARCH 3975 MACHINE_ARCH
3976 Specifies the name of the machine-specific architecture. This 3976 Specifies the name of the machine-specific architecture. This
3977 variable is set automatically from ```MACHINE`` <#var-MACHINE>`__ or 3977 variable is set automatically from :term:`MACHINE` or
3978 ```TUNE_PKGARCH`` <#var-TUNE_PKGARCH>`__. You should not hand-edit 3978 :term:`TUNE_PKGARCH`. You should not hand-edit
3979 the ``MACHINE_ARCH`` variable. 3979 the ``MACHINE_ARCH`` variable.
3980 3980
3981 MACHINE_ESSENTIAL_EXTRA_RDEPENDS 3981 MACHINE_ESSENTIAL_EXTRA_RDEPENDS
@@ -4094,11 +4094,11 @@ system and gives an overview of their function and contents.
4094 4094
4095 MACHINE_FEATURES 4095 MACHINE_FEATURES
4096 Specifies the list of hardware features the 4096 Specifies the list of hardware features the
4097 ```MACHINE`` <#var-MACHINE>`__ is capable of supporting. For related 4097 :term:`MACHINE` is capable of supporting. For related
4098 information on enabling features, see the 4098 information on enabling features, see the
4099 ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__, 4099 :term:`DISTRO_FEATURES`,
4100 ```COMBINED_FEATURES`` <#var-COMBINED_FEATURES>`__, and 4100 :term:`COMBINED_FEATURES`, and
4101 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ variables. 4101 :term:`IMAGE_FEATURES` variables.
4102 4102
4103 For a list of hardware features supported by the Yocto Project as 4103 For a list of hardware features supported by the Yocto Project as
4104 shipped, see the "`Machine Features <#ref-features-machine>`__" 4104 shipped, see the "`Machine Features <#ref-features-machine>`__"
@@ -4124,7 +4124,7 @@ system and gives an overview of their function and contents.
4124 MACHINEOVERRIDES 4124 MACHINEOVERRIDES
4125 A colon-separated list of overrides that apply to the current 4125 A colon-separated list of overrides that apply to the current
4126 machine. By default, this list includes the value of 4126 machine. By default, this list includes the value of
4127 ```MACHINE`` <#var-MACHINE>`__. 4127 :term:`MACHINE`.
4128 4128
4129 You can extend ``MACHINEOVERRIDES`` to add extra overrides that 4129 You can extend ``MACHINEOVERRIDES`` to add extra overrides that
4130 should apply to a machine. For example, all machines emulated in QEMU 4130 should apply to a machine. For example, all machines emulated in QEMU
@@ -4136,7 +4136,7 @@ system and gives an overview of their function and contents.
4136 recipe: SRC_URI_append_qemuall = "file://wired.config \\ 4136 recipe: SRC_URI_append_qemuall = "file://wired.config \\
4137 file://wired-setup \\ " The underlying mechanism behind 4137 file://wired-setup \\ " The underlying mechanism behind
4138 ``MACHINEOVERRIDES`` is simply that it is included in the default 4138 ``MACHINEOVERRIDES`` is simply that it is included in the default
4139 value of ```OVERRIDES`` <#var-OVERRIDES>`__. 4139 value of :term:`OVERRIDES`.
4140 4140
4141 MAINTAINER 4141 MAINTAINER
4142 The email address of the distribution maintainer. 4142 The email address of the distribution maintainer.
@@ -4146,18 +4146,18 @@ system and gives an overview of their function and contents.
4146 gets source code. When the build system searches for source code, it 4146 gets source code. When the build system searches for source code, it
4147 first tries the local download directory. If that location fails, the 4147 first tries the local download directory. If that location fails, the
4148 build system tries locations defined by 4148 build system tries locations defined by
4149 ```PREMIRRORS`` <#var-PREMIRRORS>`__, the upstream source, and then 4149 :term:`PREMIRRORS`, the upstream source, and then
4150 locations specified by ``MIRRORS`` in that order. 4150 locations specified by ``MIRRORS`` in that order.
4151 4151
4152 Assuming your distribution (```DISTRO`` <#var-DISTRO>`__) is "poky", 4152 Assuming your distribution (:term:`DISTRO`) is "poky",
4153 the default value for ``MIRRORS`` is defined in the 4153 the default value for ``MIRRORS`` is defined in the
4154 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository. 4154 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
4155 4155
4156 MLPREFIX 4156 MLPREFIX
4157 Specifies a prefix has been added to ```PN`` <#var-PN>`__ to create a 4157 Specifies a prefix has been added to :term:`PN` to create a
4158 special version of a recipe or package (i.e. a Multilib version). The 4158 special version of a recipe or package (i.e. a Multilib version). The
4159 variable is used in places where the prefix needs to be added to or 4159 variable is used in places where the prefix needs to be added to or
4160 removed from a the name (e.g. the ```BPN`` <#var-BPN>`__ variable). 4160 removed from a the name (e.g. the :term:`BPN` variable).
4161 ``MLPREFIX`` gets set when a prefix has been added to ``PN``. 4161 ``MLPREFIX`` gets set when a prefix has been added to ``PN``.
4162 4162
4163 .. note:: 4163 .. note::
@@ -4174,10 +4174,10 @@ system and gives an overview of their function and contents.
4174 for it as well. 4174 for it as well.
4175 4175
4176 To help understand when ``MLPREFIX`` might be needed, consider when 4176 To help understand when ``MLPREFIX`` might be needed, consider when
4177 ```BBCLASSEXTEND`` <#var-BBCLASSEXTEND>`__ is used to provide a 4177 :term:`BBCLASSEXTEND` is used to provide a
4178 ``nativesdk`` version of a recipe in addition to the target version. 4178 ``nativesdk`` version of a recipe in addition to the target version.
4179 If that recipe declares build-time dependencies on tasks in other 4179 If that recipe declares build-time dependencies on tasks in other
4180 recipes by using ```DEPENDS`` <#var-DEPENDS>`__, then a dependency on 4180 recipes by using :term:`DEPENDS`, then a dependency on
4181 "foo" will automatically get rewritten to a dependency on 4181 "foo" will automatically get rewritten to a dependency on
4182 "nativesdk-foo". However, dependencies like the following will not 4182 "nativesdk-foo". However, dependencies like the following will not
4183 get rewritten automatically: do_foo[depends] += "recipe:do_foo" If 4183 get rewritten automatically: do_foo[depends] += "recipe:do_foo" If
@@ -4191,7 +4191,7 @@ system and gives an overview of their function and contents.
4191 module_autoload_rfcomm = "rfcomm" 4191 module_autoload_rfcomm = "rfcomm"
4192 4192
4193 should now be replaced with: KERNEL_MODULE_AUTOLOAD += "rfcomm" See 4193 should now be replaced with: KERNEL_MODULE_AUTOLOAD += "rfcomm" See
4194 the ```KERNEL_MODULE_AUTOLOAD`` <#var-KERNEL_MODULE_AUTOLOAD>`__ 4194 the :term:`KERNEL_MODULE_AUTOLOAD`
4195 variable for more information. 4195 variable for more information.
4196 4196
4197 module_conf 4197 module_conf
@@ -4204,7 +4204,7 @@ system and gives an overview of their function and contents.
4204 configuration file, a distribution configuration file, an append file 4204 configuration file, a distribution configuration file, an append file
4205 for the recipe, or the recipe itself). If you use this variable, you 4205 for the recipe, or the recipe itself). If you use this variable, you
4206 must also be sure to list the module name in the 4206 must also be sure to list the module name in the
4207 ```KERNEL_MODULE_AUTOLOAD`` <#var-KERNEL_MODULE_AUTOLOAD>`__ 4207 :term:`KERNEL_MODULE_AUTOLOAD`
4208 variable. 4208 variable.
4209 4209
4210 Here is the general syntax: module_conf_module_name = 4210 Here is the general syntax: module_conf_module_name =
@@ -4221,7 +4221,7 @@ system and gives an overview of their function and contents.
4221 4221
4222 For information on how to specify kernel modules to auto-load on 4222 For information on how to specify kernel modules to auto-load on
4223 boot, see the 4223 boot, see the
4224 ```KERNEL_MODULE_AUTOLOAD`` <#var-KERNEL_MODULE_AUTOLOAD>`__ 4224 :term:`KERNEL_MODULE_AUTOLOAD`
4225 variable. 4225 variable.
4226 4226
4227 MODULE_TARBALL_DEPLOY 4227 MODULE_TARBALL_DEPLOY
@@ -4237,14 +4237,14 @@ system and gives an overview of their function and contents.
4237 same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= 4237 same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
4238 "${MACHINE}" 4238 "${MACHINE}"
4239 4239
4240 See the ```MACHINE`` <#var-MACHINE>`__ variable for additional 4240 See the :term:`MACHINE` variable for additional
4241 information. 4241 information.
4242 4242
4243 MODULE_TARBALL_NAME 4243 MODULE_TARBALL_NAME
4244 The base name of the kernel module tarball. This variable is set in 4244 The base name of the kernel module tarball. This variable is set in
4245 the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: 4245 the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
4246 MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the 4246 MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the
4247 ```KERNEL_ARTIFACT_NAME`` <#var-KERNEL_ARTIFACT_NAME>`__ variable, 4247 :term:`KERNEL_ARTIFACT_NAME` variable,
4248 which is set in the same file, has the following value: 4248 which is set in the same file, has the following value:
4249 KERNEL_ARTIFACT_NAME ?= 4249 KERNEL_ARTIFACT_NAME ?=
4250 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" 4250 "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
@@ -4257,11 +4257,11 @@ system and gives an overview of their function and contents.
4257 4257
4258 The default value of this variable is: 4258 The default value of this variable is:
4259 ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} Some classes (e.g. 4259 ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} Some classes (e.g.
4260 ```cross-canadian`` <#ref-classes-cross-canadian>`__) modify the 4260 :ref:`cross-canadian <ref-classes-cross-canadian>`) modify the
4261 ``MULTIMACH_TARGET_SYS`` value. 4261 ``MULTIMACH_TARGET_SYS`` value.
4262 4262
4263 See the ```STAMP`` <#var-STAMP>`__ variable for an example. See the 4263 See the :term:`STAMP` variable for an example. See the
4264 ```STAGING_DIR_TARGET`` <#var-STAGING_DIR_TARGET>`__ variable for 4264 :term:`STAGING_DIR_TARGET` variable for
4265 more information. 4265 more information.
4266 4266
4267 NATIVELSBSTRING 4267 NATIVELSBSTRING
@@ -4276,7 +4276,7 @@ system and gives an overview of their function and contents.
4276 packages for different distributions (e.g. to avoid problems with 4276 packages for different distributions (e.g. to avoid problems with
4277 ``glibc`` version incompatibilities). Additionally, the variable is 4277 ``glibc`` version incompatibilities). Additionally, the variable is
4278 checked against 4278 checked against
4279 ```SANITY_TESTED_DISTROS`` <#var-SANITY_TESTED_DISTROS>`__ if that 4279 :term:`SANITY_TESTED_DISTROS` if that
4280 variable is set. 4280 variable is set.
4281 4281
4282 NM 4282 NM
@@ -4300,7 +4300,7 @@ system and gives an overview of their function and contents.
4300 NO_RECOMMENDATIONS 4300 NO_RECOMMENDATIONS
4301 Prevents installation of all "recommended-only" packages. 4301 Prevents installation of all "recommended-only" packages.
4302 Recommended-only packages are packages installed only through the 4302 Recommended-only packages are packages installed only through the
4303 ```RRECOMMENDS`` <#var-RRECOMMENDS>`__ variable). Setting the 4303 :term:`RRECOMMENDS` variable). Setting the
4304 ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: 4304 ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on:
4305 NO_RECOMMENDATIONS = "1" 4305 NO_RECOMMENDATIONS = "1"
4306 4306
@@ -4310,7 +4310,7 @@ system and gives an overview of their function and contents.
4310 4310
4311 It is important to realize that if you choose to not install packages 4311 It is important to realize that if you choose to not install packages
4312 using this variable and some other packages are dependent on them 4312 using this variable and some other packages are dependent on them
4313 (i.e. listed in a recipe's ```RDEPENDS`` <#var-RDEPENDS>`__ 4313 (i.e. listed in a recipe's :term:`RDEPENDS`
4314 variable), the OpenEmbedded build system ignores your request and 4314 variable), the OpenEmbedded build system ignores your request and
4315 will install the packages to avoid dependency errors. 4315 will install the packages to avoid dependency errors.
4316 4316
@@ -4325,8 +4325,8 @@ system and gives an overview of their function and contents.
4325 Support for this variable exists only when using the IPK and RPM 4325 Support for this variable exists only when using the IPK and RPM
4326 packaging backend. Support does not exist for DEB. 4326 packaging backend. Support does not exist for DEB.
4327 4327
4328 See the ```BAD_RECOMMENDATIONS`` <#var-BAD_RECOMMENDATIONS>`__ and 4328 See the :term:`BAD_RECOMMENDATIONS` and
4329 the ```PACKAGE_EXCLUDE`` <#var-PACKAGE_EXCLUDE>`__ variables for 4329 the :term:`PACKAGE_EXCLUDE` variables for
4330 related information. 4330 related information.
4331 4331
4332 NOAUTOPACKAGEDEBUG 4332 NOAUTOPACKAGEDEBUG
@@ -4345,7 +4345,7 @@ system and gives an overview of their function and contents.
4345 The minimal command and arguments to run ``objdump``. 4345 The minimal command and arguments to run ``objdump``.
4346 4346
4347 OE_BINCONFIG_EXTRA_MANGLE 4347 OE_BINCONFIG_EXTRA_MANGLE
4348 When inheriting the ```binconfig`` <#ref-classes-binconfig>`__ class, 4348 When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
4349 this variable specifies additional arguments passed to the "sed" 4349 this variable specifies additional arguments passed to the "sed"
4350 command. The sed command alters any paths in configuration scripts 4350 command. The sed command alters any paths in configuration scripts
4351 that have been set up during compilation. Inheriting this class 4351 that have been set up during compilation. Inheriting this class
@@ -4357,7 +4357,7 @@ system and gives an overview of their function and contents.
4357 Directory <#source-directory>`__ for details on how this class 4357 Directory <#source-directory>`__ for details on how this class
4358 applies these additional sed command arguments. For general 4358 applies these additional sed command arguments. For general
4359 information on the ``binconfig`` class, see the 4359 information on the ``binconfig`` class, see the
4360 "```binconfig.bbclass`` <#ref-classes-binconfig>`__" section. 4360 ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
4361 4361
4362 OE_IMPORTS 4362 OE_IMPORTS
4363 An internal variable used to tell the OpenEmbedded build system what 4363 An internal variable used to tell the OpenEmbedded build system what
@@ -4424,9 +4424,9 @@ system and gives an overview of their function and contents.
4424 overrides mechanism. 4424 overrides mechanism.
4425 4425
4426 The default value of ``OVERRIDES`` includes the values of the 4426 The default value of ``OVERRIDES`` includes the values of the
4427 ```CLASSOVERRIDE`` <#var-CLASSOVERRIDE>`__, 4427 :term:`CLASSOVERRIDE`,
4428 ```MACHINEOVERRIDES`` <#var-MACHINEOVERRIDES>`__, and 4428 :term:`MACHINEOVERRIDES`, and
4429 ```DISTROOVERRIDES`` <#var-DISTROOVERRIDES>`__ variables. Another 4429 :term:`DISTROOVERRIDES` variables. Another
4430 important override included by default is ``pn-${PN}``. This override 4430 important override included by default is ``pn-${PN}``. This override
4431 allows variables to be set for a single recipe within configuration 4431 allows variables to be set for a single recipe within configuration
4432 (``.conf``) files. Here is an example: FOO_pn-myrecipe = 4432 (``.conf``) files. Here is an example: FOO_pn-myrecipe =
@@ -4468,8 +4468,8 @@ system and gives an overview of their function and contents.
4468 The architecture of the resulting package or packages. 4468 The architecture of the resulting package or packages.
4469 4469
4470 By default, the value of this variable is set to 4470 By default, the value of this variable is set to
4471 ```TUNE_PKGARCH`` <#var-TUNE_PKGARCH>`__ when building for the 4471 :term:`TUNE_PKGARCH` when building for the
4472 target, ```BUILD_ARCH`` <#var-BUILD_ARCH>`__ when building for the 4472 target, :term:`BUILD_ARCH` when building for the
4473 build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building for the 4473 build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building for the
4474 SDK. 4474 SDK.
4475 4475
@@ -4482,7 +4482,7 @@ system and gives an overview of their function and contents.
4482 However, if your recipe's output packages are built specific to the 4482 However, if your recipe's output packages are built specific to the
4483 target machine rather than generally for the architecture of the 4483 target machine rather than generally for the architecture of the
4484 machine, you should set ``PACKAGE_ARCH`` to the value of 4484 machine, you should set ``PACKAGE_ARCH`` to the value of
4485 ```MACHINE_ARCH`` <#var-MACHINE_ARCH>`__ in the recipe as follows: 4485 :term:`MACHINE_ARCH` in the recipe as follows:
4486 PACKAGE_ARCH = "${MACHINE_ARCH}" 4486 PACKAGE_ARCH = "${MACHINE_ARCH}"
4487 4487
4488 PACKAGE_ARCHS 4488 PACKAGE_ARCHS
@@ -4524,7 +4524,7 @@ system and gives an overview of their function and contents.
4524 4524
4525 For information on packaging and build performance effects as a 4525 For information on packaging and build performance effects as a
4526 result of the package manager in use, see the 4526 result of the package manager in use, see the
4527 "```package.bbclass`` <#ref-classes-package>`__" section. 4527 ":ref:`package.bbclass <ref-classes-package>`" section.
4528 4528
4529 PACKAGE_DEBUG_SPLIT_STYLE 4529 PACKAGE_DEBUG_SPLIT_STYLE
4530 Determines how to split up the binary and debug information when 4530 Determines how to split up the binary and debug information when
@@ -4566,7 +4566,7 @@ system and gives an overview of their function and contents.
4566 4566
4567 You might find that you want to prevent installing certain packages 4567 You might find that you want to prevent installing certain packages
4568 when you are installing complementary packages. For example, if you 4568 when you are installing complementary packages. For example, if you
4569 are using ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ to install 4569 are using :term:`IMAGE_FEATURES` to install
4570 ``dev-pkgs``, you might not want to install all packages from a 4570 ``dev-pkgs``, you might not want to install all packages from a
4571 particular multilib. If you find yourself in this situation, you can 4571 particular multilib. If you find yourself in this situation, you can
4572 use the ``PACKAGE_EXCLUDE_COMPLEMENTARY`` variable to specify regular 4572 use the ``PACKAGE_EXCLUDE_COMPLEMENTARY`` variable to specify regular
@@ -4583,7 +4583,7 @@ system and gives an overview of their function and contents.
4583 4583
4584 If you choose to not install a package using this variable and some 4584 If you choose to not install a package using this variable and some
4585 other package is dependent on it (i.e. listed in a recipe's 4585 other package is dependent on it (i.e. listed in a recipe's
4586 ```RDEPENDS`` <#var-RDEPENDS>`__ variable), the OpenEmbedded build 4586 :term:`RDEPENDS` variable), the OpenEmbedded build
4587 system generates a fatal installation error. Because the build system 4587 system generates a fatal installation error. Because the build system
4588 halts the process with a fatal error, you can use the variable with 4588 halts the process with a fatal error, you can use the variable with
4589 an iterative development process to remove specific components from a 4589 an iterative development process to remove specific components from a
@@ -4592,8 +4592,8 @@ system and gives an overview of their function and contents.
4592 Support for this variable exists only when using the IPK and RPM 4592 Support for this variable exists only when using the IPK and RPM
4593 packaging backend. Support does not exist for DEB. 4593 packaging backend. Support does not exist for DEB.
4594 4594
4595 See the ```NO_RECOMMENDATIONS`` <#var-NO_RECOMMENDATIONS>`__ and the 4595 See the :term:`NO_RECOMMENDATIONS` and the
4596 ```BAD_RECOMMENDATIONS`` <#var-BAD_RECOMMENDATIONS>`__ variables for 4596 :term:`BAD_RECOMMENDATIONS` variables for
4597 related information. 4597 related information.
4598 4598
4599 PACKAGE_EXTRA_ARCHS 4599 PACKAGE_EXTRA_ARCHS
@@ -4606,8 +4606,8 @@ system and gives an overview of their function and contents.
4606 package feed URIs during the build. When used, the 4606 package feed URIs during the build. When used, the
4607 ``PACKAGE_FEED_ARCHS`` variable is appended to the final package feed 4607 ``PACKAGE_FEED_ARCHS`` variable is appended to the final package feed
4608 URI, which is constructed using the 4608 URI, which is constructed using the
4609 ```PACKAGE_FEED_URIS`` <#var-PACKAGE_FEED_URIS>`__ and 4609 :term:`PACKAGE_FEED_URIS` and
4610 ```PACKAGE_FEED_BASE_PATHS`` <#var-PACKAGE_FEED_BASE_PATHS>`__ 4610 :term:`PACKAGE_FEED_BASE_PATHS`
4611 variables. 4611 variables.
4612 4612
4613 .. note:: 4613 .. note::
@@ -4640,8 +4640,8 @@ system and gives an overview of their function and contents.
4640 Specifies the base path used when constructing package feed URIs. The 4640 Specifies the base path used when constructing package feed URIs. The
4641 ``PACKAGE_FEED_BASE_PATHS`` variable makes up the middle portion of a 4641 ``PACKAGE_FEED_BASE_PATHS`` variable makes up the middle portion of a
4642 package feed URI used by the OpenEmbedded build system. The base path 4642 package feed URI used by the OpenEmbedded build system. The base path
4643 lies between the ```PACKAGE_FEED_URIS`` <#var-PACKAGE_FEED_URIS>`__ 4643 lies between the :term:`PACKAGE_FEED_URIS`
4644 and ```PACKAGE_FEED_ARCHS`` <#var-PACKAGE_FEED_ARCHS>`__ variables. 4644 and :term:`PACKAGE_FEED_ARCHS` variables.
4645 4645
4646 Consider the following example where the ``PACKAGE_FEED_URIS``, 4646 Consider the following example where the ``PACKAGE_FEED_URIS``,
4647 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are 4647 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
@@ -4663,8 +4663,8 @@ system and gives an overview of their function and contents.
4663 Specifies the front portion of the package feed URI used by the 4663 Specifies the front portion of the package feed URI used by the
4664 OpenEmbedded build system. Each final package feed URI is comprised 4664 OpenEmbedded build system. Each final package feed URI is comprised
4665 of ``PACKAGE_FEED_URIS``, 4665 of ``PACKAGE_FEED_URIS``,
4666 ```PACKAGE_FEED_BASE_PATHS`` <#var-PACKAGE_FEED_BASE_PATHS>`__, and 4666 :term:`PACKAGE_FEED_BASE_PATHS`, and
4667 ```PACKAGE_FEED_ARCHS`` <#var-PACKAGE_FEED_ARCHS>`__ variables. 4667 :term:`PACKAGE_FEED_ARCHS` variables.
4668 4668
4669 Consider the following example where the ``PACKAGE_FEED_URIS``, 4669 Consider the following example where the ``PACKAGE_FEED_URIS``,
4670 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are 4670 ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
@@ -4691,7 +4691,7 @@ system and gives an overview of their function and contents.
4691 not the final list of packages that are actually installed. This 4691 not the final list of packages that are actually installed. This
4692 variable is internal to the image construction code. Consequently, in 4692 variable is internal to the image construction code. Consequently, in
4693 general, you should use the 4693 general, you should use the
4694 ```IMAGE_INSTALL`` <#var-IMAGE_INSTALL>`__ variable to specify 4694 :term:`IMAGE_INSTALL` variable to specify
4695 packages for installation. The exception to this is when working with 4695 packages for installation. The exception to this is when working with
4696 the 4696 the
4697 ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__ 4697 ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
@@ -4709,7 +4709,7 @@ system and gives an overview of their function and contents.
4709 4709
4710 PACKAGE_PREPROCESS_FUNCS 4710 PACKAGE_PREPROCESS_FUNCS
4711 Specifies a list of functions run to pre-process the 4711 Specifies a list of functions run to pre-process the
4712 ```PKGD`` <#var-PKGD>`__ directory prior to splitting the files out 4712 :term:`PKGD` directory prior to splitting the files out
4713 to individual packages. 4713 to individual packages.
4714 4714
4715 PACKAGE_WRITE_DEPS 4715 PACKAGE_WRITE_DEPS
@@ -4744,21 +4744,21 @@ system and gives an overview of their function and contents.
4744 order is important and specifies the following: 4744 order is important and specifies the following:
4745 4745
4746 1. Extra arguments that should be added to the configure script 4746 1. Extra arguments that should be added to the configure script
4747 argument list (```EXTRA_OECONF`` <#var-EXTRA_OECONF>`__ or 4747 argument list (:term:`EXTRA_OECONF` or
4748 ```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__) if 4748 :term:`PACKAGECONFIG_CONFARGS`) if
4749 the feature is enabled. 4749 the feature is enabled.
4750 4750
4751 2. Extra arguments that should be added to ``EXTRA_OECONF`` or 4751 2. Extra arguments that should be added to ``EXTRA_OECONF`` or
4752 ``PACKAGECONFIG_CONFARGS`` if the feature is disabled. 4752 ``PACKAGECONFIG_CONFARGS`` if the feature is disabled.
4753 4753
4754 3. Additional build dependencies (```DEPENDS`` <#var-DEPENDS>`__) 4754 3. Additional build dependencies (:term:`DEPENDS`)
4755 that should be added if the feature is enabled. 4755 that should be added if the feature is enabled.
4756 4756
4757 4. Additional runtime dependencies (```RDEPENDS`` <#var-RDEPENDS>`__) 4757 4. Additional runtime dependencies (:term:`RDEPENDS`)
4758 that should be added if the feature is enabled. 4758 that should be added if the feature is enabled.
4759 4759
4760 5. Additional runtime recommendations 4760 5. Additional runtime recommendations
4761 (```RRECOMMENDS`` <#var-RRECOMMENDS>`__) that should be added if 4761 (:term:`RRECOMMENDS`) that should be added if
4762 the feature is enabled. 4762 the feature is enabled.
4763 4763
4764 6. Any conflicting (that is, mutually exclusive) ``PACKAGECONFIG`` 4764 6. Any conflicting (that is, mutually exclusive) ``PACKAGECONFIG``
@@ -4797,10 +4797,10 @@ system and gives an overview of their function and contents.
4797 4797
4798 PACKAGECONFIG_CONFARGS 4798 PACKAGECONFIG_CONFARGS
4799 A space-separated list of configuration options generated from the 4799 A space-separated list of configuration options generated from the
4800 ```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__ setting. 4800 :term:`PACKAGECONFIG` setting.
4801 4801
4802 Classes such as ```autotools`` <#ref-classes-autotools>`__ and 4802 Classes such as :ref:`autotools <ref-classes-autotools>` and
4803 ```cmake`` <#ref-classes-cmake>`__ use ``PACKAGECONFIG_CONFARGS`` to 4803 :ref:`cmake <ref-classes-cmake>` use ``PACKAGECONFIG_CONFARGS`` to
4804 pass ``PACKAGECONFIG`` options to ``configure`` and ``cmake``, 4804 pass ``PACKAGECONFIG`` options to ``configure`` and ``cmake``,
4805 respectively. If you are using ``PACKAGECONFIG`` but not a class that 4805 respectively. If you are using ``PACKAGECONFIG`` but not a class that
4806 handles the ``do_configure`` task, then you need to use 4806 handles the ``do_configure`` task, then you need to use
@@ -4808,7 +4808,7 @@ system and gives an overview of their function and contents.
4808 4808
4809 PACKAGEGROUP_DISABLE_COMPLEMENTARY 4809 PACKAGEGROUP_DISABLE_COMPLEMENTARY
4810 For recipes inheriting the 4810 For recipes inheriting the
4811 ```packagegroup`` <#ref-classes-packagegroup>`__ class, setting 4811 :ref:`packagegroup <ref-classes-packagegroup>` class, setting
4812 ``PACKAGEGROUP_DISABLE_COMPLEMENTARY`` to "1" specifies that the 4812 ``PACKAGEGROUP_DISABLE_COMPLEMENTARY`` to "1" specifies that the
4813 normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth) 4813 normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth)
4814 should not be automatically created by the ``packagegroup`` recipe, 4814 should not be automatically created by the ``packagegroup`` recipe,
@@ -4819,8 +4819,8 @@ system and gives an overview of their function and contents.
4819 following: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale 4819 following: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
4820 ${PACKAGE_BEFORE_PN} ${PN} 4820 ${PACKAGE_BEFORE_PN} ${PN}
4821 4821
4822 During packaging, the ```do_package`` <#ref-tasks-package>`__ task 4822 During packaging, the :ref:`ref-tasks-package` task
4823 goes through ``PACKAGES`` and uses the ```FILES`` <#var-FILES>`__ 4823 goes through ``PACKAGES`` and uses the :term:`FILES`
4824 variable corresponding to each package to assign files to the 4824 variable corresponding to each package to assign files to the
4825 package. If a file matches the ``FILES`` variable for more than one 4825 package. If a file matches the ``FILES`` variable for more than one
4826 package in ``PACKAGES``, it will be assigned to the earliest 4826 package in ``PACKAGES``, it will be assigned to the earliest
@@ -4828,26 +4828,26 @@ system and gives an overview of their function and contents.
4828 4828
4829 Packages in the variable's list that are empty (i.e. where none of 4829 Packages in the variable's list that are empty (i.e. where none of
4830 the patterns in ``FILES_``\ pkg match any files installed by the 4830 the patterns in ``FILES_``\ pkg match any files installed by the
4831 ```do_install`` <#ref-tasks-install>`__ task) are not generated, 4831 :ref:`ref-tasks-install` task) are not generated,
4832 unless generation is forced through the 4832 unless generation is forced through the
4833 ```ALLOW_EMPTY`` <#var-ALLOW_EMPTY>`__ variable. 4833 :term:`ALLOW_EMPTY` variable.
4834 4834
4835 PACKAGES_DYNAMIC 4835 PACKAGES_DYNAMIC
4836 A promise that your recipe satisfies runtime dependencies for 4836 A promise that your recipe satisfies runtime dependencies for
4837 optional modules that are found in other recipes. 4837 optional modules that are found in other recipes.
4838 ``PACKAGES_DYNAMIC`` does not actually satisfy the dependencies, it 4838 ``PACKAGES_DYNAMIC`` does not actually satisfy the dependencies, it
4839 only states that they should be satisfied. For example, if a hard, 4839 only states that they should be satisfied. For example, if a hard,
4840 runtime dependency (```RDEPENDS`` <#var-RDEPENDS>`__) of another 4840 runtime dependency (:term:`RDEPENDS`) of another
4841 package is satisfied at build time through the ``PACKAGES_DYNAMIC`` 4841 package is satisfied at build time through the ``PACKAGES_DYNAMIC``
4842 variable, but a package with the module name is never actually 4842 variable, but a package with the module name is never actually
4843 produced, then the other package will be broken. Thus, if you attempt 4843 produced, then the other package will be broken. Thus, if you attempt
4844 to include that package in an image, you will get a dependency 4844 to include that package in an image, you will get a dependency
4845 failure from the packaging system during the 4845 failure from the packaging system during the
4846 ```do_rootfs`` <#ref-tasks-rootfs>`__ task. 4846 :ref:`ref-tasks-rootfs` task.
4847 4847
4848 Typically, if there is a chance that such a situation can occur and 4848 Typically, if there is a chance that such a situation can occur and
4849 the package that is not created is valid without the dependency being 4849 the package that is not created is valid without the dependency being
4850 satisfied, then you should use ```RRECOMMENDS`` <#var-RRECOMMENDS>`__ 4850 satisfied, then you should use :term:`RRECOMMENDS`
4851 (a soft runtime dependency) instead of ``RDEPENDS``. 4851 (a soft runtime dependency) instead of ``RDEPENDS``.
4852 4852
4853 For an example of how to use the ``PACKAGES_DYNAMIC`` variable when 4853 For an example of how to use the ``PACKAGES_DYNAMIC`` variable when
@@ -4860,14 +4860,14 @@ system and gives an overview of their function and contents.
4860 files into individual packages. Recipes can either prepend to this 4860 files into individual packages. Recipes can either prepend to this
4861 variable or prepend to the ``populate_packages`` function in order to 4861 variable or prepend to the ``populate_packages`` function in order to
4862 perform additional package splitting. In either case, the function 4862 perform additional package splitting. In either case, the function
4863 should set ```PACKAGES`` <#var-PACKAGES>`__, 4863 should set :term:`PACKAGES`,
4864 ```FILES`` <#var-FILES>`__, ```RDEPENDS`` <#var-RDEPENDS>`__ and 4864 :term:`FILES`, :term:`RDEPENDS` and
4865 other packaging variables appropriately in order to perform the 4865 other packaging variables appropriately in order to perform the
4866 desired splitting. 4866 desired splitting.
4867 4867
4868 PARALLEL_MAKE 4868 PARALLEL_MAKE
4869 Extra options passed to the ``make`` command during the 4869 Extra options passed to the ``make`` command during the
4870 ```do_compile`` <#ref-tasks-compile>`__ task in order to specify 4870 :ref:`ref-tasks-compile` task in order to specify
4871 parallel compilation on the local build host. This variable is 4871 parallel compilation on the local build host. This variable is
4872 usually in the form "-j x", where x represents the maximum number of 4872 usually in the form "-j x", where x represents the maximum number of
4873 parallel threads ``make`` can run. 4873 parallel threads ``make`` can run.
@@ -4913,15 +4913,15 @@ system and gives an overview of their function and contents.
4913 4913
4914 PARALLEL_MAKEINST 4914 PARALLEL_MAKEINST
4915 Extra options passed to the ``make install`` command during the 4915 Extra options passed to the ``make install`` command during the
4916 ```do_install`` <#ref-tasks-install>`__ task in order to specify 4916 :ref:`ref-tasks-install` task in order to specify
4917 parallel installation. This variable defaults to the value of 4917 parallel installation. This variable defaults to the value of
4918 ```PARALLEL_MAKE`` <#var-PARALLEL_MAKE>`__. 4918 :term:`PARALLEL_MAKE`.
4919 4919
4920 .. note:: 4920 .. note::
4921 4921
4922 In order for ``PARALLEL_MAKEINST`` to be effective, ``make`` must 4922 In order for ``PARALLEL_MAKEINST`` to be effective, ``make`` must
4923 be called with 4923 be called with
4924 ``${``\ ```EXTRA_OEMAKE`` <#var-EXTRA_OEMAKE>`__\ ``}``. An easy 4924 ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy
4925 way to ensure this is to use the ``oe_runmake`` function. 4925 way to ensure this is to use the ``oe_runmake`` function.
4926 4926
4927 If the software being built experiences dependency issues during 4927 If the software being built experiences dependency issues during
@@ -4946,7 +4946,7 @@ system and gives an overview of their function and contents.
4946 4946
4947 PATCHTOOL 4947 PATCHTOOL
4948 Specifies the utility used to apply patches for a recipe during the 4948 Specifies the utility used to apply patches for a recipe during the
4949 ```do_patch`` <#ref-tasks-patch>`__ task. You can specify one of 4949 :ref:`ref-tasks-patch` task. You can specify one of
4950 three utilities: "patch", "quilt", or "git". The default utility used 4950 three utilities: "patch", "quilt", or "git". The default utility used
4951 is "quilt" except for the quilt-native recipe itself. Because the 4951 is "quilt" except for the quilt-native recipe itself. Because the
4952 quilt tool is not available at the time quilt-native is being 4952 quilt tool is not available at the time quilt-native is being
@@ -4961,20 +4961,20 @@ system and gives an overview of their function and contents.
4961 variable is used to make upgrades possible when the versioning scheme 4961 variable is used to make upgrades possible when the versioning scheme
4962 changes in some backwards incompatible way. 4962 changes in some backwards incompatible way.
4963 4963
4964 ``PE`` is the default value of the ```PKGE`` <#var-PKGE>`__ variable. 4964 ``PE`` is the default value of the :term:`PKGE` variable.
4965 4965
4966 PF 4966 PF
4967 Specifies the recipe or package name and includes all version and 4967 Specifies the recipe or package name and includes all version and
4968 revision numbers (i.e. ``glibc-2.13-r20+svnr15508/`` and 4968 revision numbers (i.e. ``glibc-2.13-r20+svnr15508/`` and
4969 ``bash-4.2-r1/``). This variable is comprised of the following: 4969 ``bash-4.2-r1/``). This variable is comprised of the following:
4970 ${`PN <#var-PN>`__}-${`EXTENDPE <#var-EXTENDPE>`__}${`PV <#var-PV>`__}-${`PR <#var-PR>`__} 4970 ${:term:`PN`}-${:term:`EXTENDPE`}${:term:`PV`}-${:term:`PR`}
4971 4971
4972 PIXBUF_PACKAGES 4972 PIXBUF_PACKAGES
4973 When inheriting the ```pixbufcache`` <#ref-classes-pixbufcache>`__ 4973 When inheriting the :ref:`pixbufcache <ref-classes-pixbufcache>`
4974 class, this variable identifies packages that contain the pixbuf 4974 class, this variable identifies packages that contain the pixbuf
4975 loaders used with ``gdk-pixbuf``. By default, the ``pixbufcache`` 4975 loaders used with ``gdk-pixbuf``. By default, the ``pixbufcache``
4976 class assumes that the loaders are in the recipe's main package (i.e. 4976 class assumes that the loaders are in the recipe's main package (i.e.
4977 ``${``\ ```PN`` <#var-PN>`__\ ``}``). Use this variable if the 4977 ``${``\ :term:`PN`\ ``}``). Use this variable if the
4978 loaders you need are in a package other than that main package. 4978 loaders you need are in a package other than that main package.
4979 4979
4980 PKG 4980 PKG
@@ -4987,7 +4987,7 @@ system and gives an overview of their function and contents.
4987 PKG 4987 PKG
4988 variable, you must use a package name override. 4988 variable, you must use a package name override.
4989 4989
4990 For example, when the ```debian`` <#ref-classes-debian>`__ class 4990 For example, when the :ref:`debian <ref-classes-debian>` class
4991 renames the output package, it does so by setting 4991 renames the output package, it does so by setting
4992 ``PKG_packagename``. 4992 ``PKG_packagename``.
4993 4993
@@ -5005,7 +5005,7 @@ system and gives an overview of their function and contents.
5005 PKGDATA_DIR 5005 PKGDATA_DIR
5006 Points to a shared, global-state directory that holds data generated 5006 Points to a shared, global-state directory that holds data generated
5007 during the packaging process. During the packaging process, the 5007 during the packaging process. During the packaging process, the
5008 ```do_packagedata`` <#ref-tasks-packagedata>`__ task packages data 5008 :ref:`ref-tasks-packagedata` task packages data
5009 for each recipe and installs it into this temporary, shared area. 5009 for each recipe and installs it into this temporary, shared area.
5010 This directory defaults to the following, which you should not 5010 This directory defaults to the following, which you should not
5011 change: ${STAGING_DIR_HOST}/pkgdata For examples of how this data is 5011 change: ${STAGING_DIR_HOST}/pkgdata For examples of how this data is
@@ -5016,7 +5016,7 @@ system and gives an overview of their function and contents.
5016 ``oe-pkgdata-util`` <&YOCTO_DOCS_DEV_URL;#viewing-package-information-with-oe-pkgdata-util>`__" 5016 ``oe-pkgdata-util`` <&YOCTO_DOCS_DEV_URL;#viewing-package-information-with-oe-pkgdata-util>`__"
5017 section in the Yocto Project Development Tasks Manual. For more 5017 section in the Yocto Project Development Tasks Manual. For more
5018 information on the shared, global-state directory, see 5018 information on the shared, global-state directory, see
5019 ```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__. 5019 :term:`STAGING_DIR_HOST`.
5020 5020
5021 PKGDEST 5021 PKGDEST
5022 Points to the parent directory for files to be packaged after they 5022 Points to the parent directory for files to be packaged after they
@@ -5024,30 +5024,30 @@ system and gives an overview of their function and contents.
5024 the following: ${WORKDIR}/packages-split 5024 the following: ${WORKDIR}/packages-split
5025 5025
5026 Under this directory, the build system creates directories for each 5026 Under this directory, the build system creates directories for each
5027 package specified in ```PACKAGES`` <#var-PACKAGES>`__. Do not change 5027 package specified in :term:`PACKAGES`. Do not change
5028 this default. 5028 this default.
5029 5029
5030 PKGDESTWORK 5030 PKGDESTWORK
5031 Points to a temporary work area where the 5031 Points to a temporary work area where the
5032 ```do_package`` <#ref-tasks-package>`__ task saves package metadata. 5032 :ref:`ref-tasks-package` task saves package metadata.
5033 The ``PKGDESTWORK`` location defaults to the following: 5033 The ``PKGDESTWORK`` location defaults to the following:
5034 ${WORKDIR}/pkgdata Do not change this default. 5034 ${WORKDIR}/pkgdata Do not change this default.
5035 5035
5036 The ```do_packagedata`` <#ref-tasks-packagedata>`__ task copies the 5036 The :ref:`ref-tasks-packagedata` task copies the
5037 package metadata from ``PKGDESTWORK`` to 5037 package metadata from ``PKGDESTWORK`` to
5038 ```PKGDATA_DIR`` <#var-PKGDATA_DIR>`__ to make it available globally. 5038 :term:`PKGDATA_DIR` to make it available globally.
5039 5039
5040 PKGE 5040 PKGE
5041 The epoch of the package(s) built by the recipe. By default, ``PKGE`` 5041 The epoch of the package(s) built by the recipe. By default, ``PKGE``
5042 is set to ```PE`` <#var-PE>`__. 5042 is set to :term:`PE`.
5043 5043
5044 PKGR 5044 PKGR
5045 The revision of the package(s) built by the recipe. By default, 5045 The revision of the package(s) built by the recipe. By default,
5046 ``PKGR`` is set to ```PR`` <#var-PR>`__. 5046 ``PKGR`` is set to :term:`PR`.
5047 5047
5048 PKGV 5048 PKGV
5049 The version of the package(s) built by the recipe. By default, 5049 The version of the package(s) built by the recipe. By default,
5050 ``PKGV`` is set to ```PV`` <#var-PV>`__. 5050 ``PKGV`` is set to :term:`PV`.
5051 5051
5052 PN 5052 PN
5053 This variable can have two separate functions depending on the 5053 This variable can have two separate functions depending on the
@@ -5071,7 +5071,7 @@ system and gives an overview of their function and contents.
5071 PNBLACKLIST 5071 PNBLACKLIST
5072 Lists recipes you do not want the OpenEmbedded build system to build. 5072 Lists recipes you do not want the OpenEmbedded build system to build.
5073 This variable works in conjunction with the 5073 This variable works in conjunction with the
5074 ```blacklist`` <#ref-classes-blacklist>`__ class, which is inherited 5074 :ref:`blacklist <ref-classes-blacklist>` class, which is inherited
5075 globally. 5075 globally.
5076 5076
5077 To prevent a recipe from being built, use the ``PNBLACKLIST`` 5077 To prevent a recipe from being built, use the ``PNBLACKLIST``
@@ -5088,7 +5088,7 @@ system and gives an overview of their function and contents.
5088 If you need to pass the SDK path to a command within a function, you 5088 If you need to pass the SDK path to a command within a function, you
5089 can use ``${SDK_DIR}``, which points to the parent directory used by 5089 can use ``${SDK_DIR}``, which points to the parent directory used by
5090 the OpenEmbedded build system when creating SDK output. See the 5090 the OpenEmbedded build system when creating SDK output. See the
5091 ```SDK_DIR`` <#var-SDK_DIR>`__ variable for more information. 5091 :term:`SDK_DIR` variable for more information.
5092 5092
5093 POPULATE_SDK_POST_TARGET_COMMAND 5093 POPULATE_SDK_POST_TARGET_COMMAND
5094 Specifies a list of functions to call once the OpenEmbedded build 5094 Specifies a list of functions to call once the OpenEmbedded build
@@ -5099,12 +5099,12 @@ system and gives an overview of their function and contents.
5099 If you need to pass the SDK path to a command within a function, you 5099 If you need to pass the SDK path to a command within a function, you
5100 can use ``${SDK_DIR}``, which points to the parent directory used by 5100 can use ``${SDK_DIR}``, which points to the parent directory used by
5101 the OpenEmbedded build system when creating SDK output. See the 5101 the OpenEmbedded build system when creating SDK output. See the
5102 ```SDK_DIR`` <#var-SDK_DIR>`__ variable for more information. 5102 :term:`SDK_DIR` variable for more information.
5103 5103
5104 PR 5104 PR
5105 The revision of the recipe. The default value for this variable is 5105 The revision of the recipe. The default value for this variable is
5106 "r0". Subsequent revisions of the recipe conventionally have the 5106 "r0". Subsequent revisions of the recipe conventionally have the
5107 values "r1", "r2", and so forth. When ```PV`` <#var-PV>`__ increases, 5107 values "r1", "r2", and so forth. When :term:`PV` increases,
5108 ``PR`` is conventionally reset to "r0". 5108 ``PR`` is conventionally reset to "r0".
5109 5109
5110 .. note:: 5110 .. note::
@@ -5122,7 +5122,7 @@ system and gives an overview of their function and contents.
5122 The ``PR`` variable primarily becomes significant when a package 5122 The ``PR`` variable primarily becomes significant when a package
5123 manager dynamically installs packages on an already built image. In 5123 manager dynamically installs packages on an already built image. In
5124 this case, ``PR``, which is the default value of 5124 this case, ``PR``, which is the default value of
5125 ```PKGR`` <#var-PKGR>`__, helps the package manager distinguish which 5125 :term:`PKGR`, helps the package manager distinguish which
5126 package is the most recent one in cases where many packages have the 5126 package is the most recent one in cases where many packages have the
5127 same ``PV`` (i.e. ``PKGV``). A component having many packages with 5127 same ``PV`` (i.e. ``PKGV``). A component having many packages with
5128 the same ``PV`` usually means that the packages all install the same 5128 the same ``PV`` usually means that the packages all install the same
@@ -5145,7 +5145,7 @@ system and gives an overview of their function and contents.
5145 which recipe is preferred and thus provides the item (i.e. the 5145 which recipe is preferred and thus provides the item (i.e. the
5146 preferred provider). You should always suffix this variable with the 5146 preferred provider). You should always suffix this variable with the
5147 name of the provided item. And, you should define the variable using 5147 name of the provided item. And, you should define the variable using
5148 the preferred recipe's name (```PN`` <#var-PN>`__). Here is a common 5148 the preferred recipe's name (:term:`PN`). Here is a common
5149 example: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" In the 5149 example: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" In the
5150 previous example, multiple recipes are providing "virtual/kernel". 5150 previous example, multiple recipes are providing "virtual/kernel".
5151 The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of 5151 The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of
@@ -5174,8 +5174,8 @@ system and gives an overview of their function and contents.
5174 PREFERRED_VERSION 5174 PREFERRED_VERSION
5175 If multiple versions of recipes exist, this variable determines which 5175 If multiple versions of recipes exist, this variable determines which
5176 version is given preference. You must always suffix the variable with 5176 version is given preference. You must always suffix the variable with
5177 the ```PN`` <#var-PN>`__ you want to select, and you should set the 5177 the :term:`PN` you want to select, and you should set the
5178 ```PV`` <#var-PV>`__ accordingly for precedence. 5178 :term:`PV` accordingly for precedence.
5179 5179
5180 The ``PREFERRED_VERSION`` variable supports limited wildcard use 5180 The ``PREFERRED_VERSION`` variable supports limited wildcard use
5181 through the "``%``" character. You can use the character to match any 5181 through the "``%``" character. You can use the character to match any
@@ -5192,7 +5192,7 @@ system and gives an overview of their function and contents.
5192 string. You cannot use the wildcard character in any other 5192 string. You cannot use the wildcard character in any other
5193 location of the string. 5193 location of the string.
5194 5194
5195 The specified version is matched against ```PV`` <#var-PV>`__, which 5195 The specified version is matched against :term:`PV`, which
5196 does not necessarily match the version part of the recipe's filename. 5196 does not necessarily match the version part of the recipe's filename.
5197 For example, consider two recipes ``foo_1.2.bb`` and ``foo_git.bb`` 5197 For example, consider two recipes ``foo_1.2.bb`` and ``foo_git.bb``
5198 where ``foo_git.bb`` contains the following assignment: PV = 5198 where ``foo_git.bb`` contains the following assignment: PV =
@@ -5204,7 +5204,7 @@ system and gives an overview of their function and contents.
5204 5204
5205 Sometimes the ``PREFERRED_VERSION`` variable can be set by 5205 Sometimes the ``PREFERRED_VERSION`` variable can be set by
5206 configuration files in a way that is hard to change. You can use 5206 configuration files in a way that is hard to change. You can use
5207 ```OVERRIDES`` <#var-OVERRIDES>`__ to set a machine-specific 5207 :term:`OVERRIDES` to set a machine-specific
5208 override. Here is an example: PREFERRED_VERSION_linux-yocto_qemux86 = 5208 override. Here is an example: PREFERRED_VERSION_linux-yocto_qemux86 =
5209 "5.0%" Although not recommended, worst case, you can also use the 5209 "5.0%" Although not recommended, worst case, you can also use the
5210 "forcevariable" override, which is the strongest override possible. 5210 "forcevariable" override, which is the strongest override possible.
@@ -5226,9 +5226,9 @@ system and gives an overview of their function and contents.
5226 first tries the local download directory. If that location fails, the 5226 first tries the local download directory. If that location fails, the
5227 build system tries locations defined by ``PREMIRRORS``, the upstream 5227 build system tries locations defined by ``PREMIRRORS``, the upstream
5228 source, and then locations specified by 5228 source, and then locations specified by
5229 ```MIRRORS`` <#var-MIRRORS>`__ in that order. 5229 :term:`MIRRORS` in that order.
5230 5230
5231 Assuming your distribution (```DISTRO`` <#var-DISTRO>`__) is "poky", 5231 Assuming your distribution (:term:`DISTRO`) is "poky",
5232 the default value for ``PREMIRRORS`` is defined in the 5232 the default value for ``PREMIRRORS`` is defined in the
5233 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository. 5233 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
5234 5234
@@ -5315,7 +5315,7 @@ system and gives an overview of their function and contents.
5315 "virtual/function" (e.g. "virtual/kernel"). The slash is simply part 5315 "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
5316 of the name and has no syntactical significance. 5316 of the name and has no syntactical significance.
5317 5317
5318 The ```PREFERRED_PROVIDER`` <#var-PREFERRED_PROVIDER>`__ variable is 5318 The :term:`PREFERRED_PROVIDER` variable is
5319 used to select which particular recipe provides a virtual target. 5319 used to select which particular recipe provides a virtual target.
5320 5320
5321 .. note:: 5321 .. note::
@@ -5335,10 +5335,10 @@ system and gives an overview of their function and contents.
5335 5335
5336 5336
5337 PRSERV_HOST 5337 PRSERV_HOST
5338 The network based ```PR`` <#var-PR>`__ service host and port. 5338 The network based :term:`PR` service host and port.
5339 5339
5340 The ``conf/local.conf.sample.extended`` configuration file in the 5340 The ``conf/local.conf.sample.extended`` configuration file in the
5341 `Source Directory <#source-directory>`__ shows how the 5341 :term:`Source Directory` shows how the
5342 ``PRSERV_HOST`` variable is set: PRSERV_HOST = "localhost:0" You must 5342 ``PRSERV_HOST`` variable is set: PRSERV_HOST = "localhost:0" You must
5343 set the variable if you want to automatically start a local `PR 5343 set the variable if you want to automatically start a local `PR
5344 service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__. You can 5344 service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__. You can
@@ -5350,7 +5350,7 @@ system and gives an overview of their function and contents.
5350 functionality is enabled when building a recipe. You should not set 5350 functionality is enabled when building a recipe. You should not set
5351 this variable directly. Enabling and disabling building Package Tests 5351 this variable directly. Enabling and disabling building Package Tests
5352 at build time should be done by adding "ptest" to (or removing it 5352 at build time should be done by adding "ptest" to (or removing it
5353 from) ```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__. 5353 from) :term:`DISTRO_FEATURES`.
5354 5354
5355 PV 5355 PV
5356 The version of the recipe. The version is normally extracted from the 5356 The version of the recipe. The version is normally extracted from the
@@ -5360,14 +5360,14 @@ system and gives an overview of their function and contents.
5360 building an unstable (i.e. development) version from a source code 5360 building an unstable (i.e. development) version from a source code
5361 repository (e.g. Git or Subversion). 5361 repository (e.g. Git or Subversion).
5362 5362
5363 ``PV`` is the default value of the ```PKGV`` <#var-PKGV>`__ variable. 5363 ``PV`` is the default value of the :term:`PKGV` variable.
5364 5364
5365 PYTHON_ABI 5365 PYTHON_ABI
5366 When used by recipes that inherit the 5366 When used by recipes that inherit the
5367 ```distutils3`` <#ref-classes-distutils3>`__, 5367 ```distutils3`` <#ref-classes-distutils3>`__,
5368 ```setuptools3`` <#ref-classes-setuptools3>`__, 5368 ```setuptools3`` <#ref-classes-setuptools3>`__,
5369 ```distutils`` <#ref-classes-distutils>`__, or 5369 :ref:`distutils <ref-classes-distutils>`, or
5370 ```setuptools`` <#ref-classes-setuptools>`__ classes, denotes the 5370 :ref:`setuptools <ref-classes-setuptools>` classes, denotes the
5371 Application Binary Interface (ABI) currently in use for Python. By 5371 Application Binary Interface (ABI) currently in use for Python. By
5372 default, the ABI is "m". You do not have to set this variable as the 5372 default, the ABI is "m". You do not have to set this variable as the
5373 OpenEmbedded build system sets it for you. 5373 OpenEmbedded build system sets it for you.
@@ -5384,8 +5384,8 @@ system and gives an overview of their function and contents.
5384 When used by recipes that inherit the 5384 When used by recipes that inherit the
5385 ```distutils3`` <#ref-classes-distutils3>`__, 5385 ```distutils3`` <#ref-classes-distutils3>`__,
5386 ```setuptools3`` <#ref-classes-setuptools3>`__, 5386 ```setuptools3`` <#ref-classes-setuptools3>`__,
5387 ```distutils`` <#ref-classes-distutils>`__, or 5387 :ref:`distutils <ref-classes-distutils>`, or
5388 ```setuptools`` <#ref-classes-setuptools>`__ classes, specifies the 5388 :ref:`setuptools <ref-classes-setuptools>` classes, specifies the
5389 major Python version being built. For Python 3.x, ``PYTHON_PN`` would 5389 major Python version being built. For Python 3.x, ``PYTHON_PN`` would
5390 be "python3". You do not have to set this variable as the 5390 be "python3". You do not have to set this variable as the
5391 OpenEmbedded build system automatically sets it for you. 5391 OpenEmbedded build system automatically sets it for you.
@@ -5432,15 +5432,15 @@ system and gives an overview of their function and contents.
5432 ```do_package_write_*`` <#ref-tasks-package_write_deb>`__ tasks. 5432 ```do_package_write_*`` <#ref-tasks-package_write_deb>`__ tasks.
5433 Exactly how this is done depends on which package format is used, 5433 Exactly how this is done depends on which package format is used,
5434 which is determined by 5434 which is determined by
5435 ```PACKAGE_CLASSES`` <#var-PACKAGE_CLASSES>`__. When the 5435 :term:`PACKAGE_CLASSES`. When the
5436 corresponding package manager installs the package, it will know to 5436 corresponding package manager installs the package, it will know to
5437 also install the packages on which it depends. 5437 also install the packages on which it depends.
5438 5438
5439 To ensure that the packages ``bar`` and ``baz`` get built, the 5439 To ensure that the packages ``bar`` and ``baz`` get built, the
5440 previous ``RDEPENDS`` assignment also causes a task dependency to be 5440 previous ``RDEPENDS`` assignment also causes a task dependency to be
5441 added. This dependency is from the recipe's 5441 added. This dependency is from the recipe's
5442 ```do_build`` <#ref-tasks-build>`__ (not to be confused with 5442 :ref:`ref-tasks-build` (not to be confused with
5443 ```do_compile`` <#ref-tasks-compile>`__) task to the 5443 :ref:`ref-tasks-compile`) task to the
5444 ``do_package_write_*`` task of the recipes that build ``bar`` and 5444 ``do_package_write_*`` task of the recipes that build ``bar`` and
5445 ``baz``. 5445 ``baz``.
5446 5446
@@ -5449,7 +5449,7 @@ system and gives an overview of their function and contents.
5449 package names and recipe names usually match, the important point 5449 package names and recipe names usually match, the important point
5450 here is that you are providing package names within the ``RDEPENDS`` 5450 here is that you are providing package names within the ``RDEPENDS``
5451 variable. For an example of the default list of packages created from 5451 variable. For an example of the default list of packages created from
5452 a recipe, see the ```PACKAGES`` <#var-PACKAGES>`__ variable. 5452 a recipe, see the :term:`PACKAGES` variable.
5453 5453
5454 Because the ``RDEPENDS`` variable applies to packages being built, 5454 Because the ``RDEPENDS`` variable applies to packages being built,
5455 you should always use the variable in a form with an attached package 5455 you should always use the variable in a form with an attached package
@@ -5478,9 +5478,9 @@ system and gives an overview of their function and contents.
5478 . Use the "+=" operator rather than the "=" operator. 5478 . Use the "+=" operator rather than the "=" operator.
5479 5479
5480 The package names you use with ``RDEPENDS`` must appear as they would 5480 The package names you use with ``RDEPENDS`` must appear as they would
5481 in the ``PACKAGES`` variable. The ```PKG`` <#var-PKG>`__ variable 5481 in the ``PACKAGES`` variable. The :term:`PKG` variable
5482 allows a different name to be used for the final package (e.g. the 5482 allows a different name to be used for the final package (e.g. the
5483 ```debian`` <#ref-classes-debian>`__ class uses this to rename 5483 :ref:`debian <ref-classes-debian>` class uses this to rename
5484 packages), but this final package name cannot be used with 5484 packages), but this final package name cannot be used with
5485 ``RDEPENDS``, which makes sense as ``RDEPENDS`` is meant to be 5485 ``RDEPENDS``, which makes sense as ``RDEPENDS`` is meant to be
5486 independent of the package format used. 5486 independent of the package format used.
@@ -5503,7 +5503,7 @@ system and gives an overview of their function and contents.
5503 greater of the package ``foo``: RDEPENDS_${PN} = "foo (>= 1.2)" 5503 greater of the package ``foo``: RDEPENDS_${PN} = "foo (>= 1.2)"
5504 5504
5505 For information on build-time dependencies, see the 5505 For information on build-time dependencies, see the
5506 ```DEPENDS`` <#var-DEPENDS>`__ variable. You can also see the 5506 :term:`DEPENDS` variable. You can also see the
5507 "`Tasks <&YOCTO_DOCS_BB_URL;#tasks>`__" and 5507 "`Tasks <&YOCTO_DOCS_BB_URL;#tasks>`__" and
5508 "`Dependencies <&YOCTO_DOCS_BB_URL;#dependencies>`__" sections in the 5508 "`Dependencies <&YOCTO_DOCS_BB_URL;#dependencies>`__" sections in the
5509 BitBake User Manual for additional information on tasks and 5509 BitBake User Manual for additional information on tasks and
@@ -5511,7 +5511,7 @@ system and gives an overview of their function and contents.
5511 5511
5512 REQUIRED_DISTRO_FEATURES 5512 REQUIRED_DISTRO_FEATURES
5513 When inheriting the 5513 When inheriting the
5514 ```distro_features_check`` <#ref-classes-distro_features_check>`__ 5514 :ref:`distro_features_check <ref-classes-distro_features_check>`
5515 class, this variable identifies distribution features that must exist 5515 class, this variable identifies distribution features that must exist
5516 in the current configuration in order for the OpenEmbedded build 5516 in the current configuration in order for the OpenEmbedded build
5517 system to build the recipe. In other words, if the 5517 system to build the recipe. In other words, if the
@@ -5546,7 +5546,7 @@ system and gives an overview of their function and contents.
5546 Indicates a filesystem image to include as the root filesystem. 5546 Indicates a filesystem image to include as the root filesystem.
5547 5547
5548 The ``ROOTFS`` variable is an optional variable used with the 5548 The ``ROOTFS`` variable is an optional variable used with the
5549 ```image-live`` <#ref-classes-image-live>`__ class. 5549 :ref:`image-live <ref-classes-image-live>` class.
5550 5550
5551 ROOTFS_POSTINSTALL_COMMAND 5551 ROOTFS_POSTINSTALL_COMMAND
5552 Specifies a list of functions to call after the OpenEmbedded build 5552 Specifies a list of functions to call after the OpenEmbedded build
@@ -5556,7 +5556,7 @@ system and gives an overview of their function and contents.
5556 If you need to pass the root filesystem path to a command within a 5556 If you need to pass the root filesystem path to a command within a
5557 function, you can use ``${IMAGE_ROOTFS}``, which points to the 5557 function, you can use ``${IMAGE_ROOTFS}``, which points to the
5558 directory that becomes the root filesystem image. See the 5558 directory that becomes the root filesystem image. See the
5559 ```IMAGE_ROOTFS`` <#var-IMAGE_ROOTFS>`__ variable for more 5559 :term:`IMAGE_ROOTFS` variable for more
5560 information. 5560 information.
5561 5561
5562 ROOTFS_POSTPROCESS_COMMAND 5562 ROOTFS_POSTPROCESS_COMMAND
@@ -5568,7 +5568,7 @@ system and gives an overview of their function and contents.
5568 If you need to pass the root filesystem path to a command within a 5568 If you need to pass the root filesystem path to a command within a
5569 function, you can use ``${IMAGE_ROOTFS}``, which points to the 5569 function, you can use ``${IMAGE_ROOTFS}``, which points to the
5570 directory that becomes the root filesystem image. See the 5570 directory that becomes the root filesystem image. See the
5571 ```IMAGE_ROOTFS`` <#var-IMAGE_ROOTFS>`__ variable for more 5571 :term:`IMAGE_ROOTFS` variable for more
5572 information. 5572 information.
5573 5573
5574 ROOTFS_POSTUNINSTALL_COMMAND 5574 ROOTFS_POSTUNINSTALL_COMMAND
@@ -5582,7 +5582,7 @@ system and gives an overview of their function and contents.
5582 If you need to pass the root filesystem path to a command within a 5582 If you need to pass the root filesystem path to a command within a
5583 function, you can use ``${IMAGE_ROOTFS}``, which points to the 5583 function, you can use ``${IMAGE_ROOTFS}``, which points to the
5584 directory that becomes the root filesystem image. See the 5584 directory that becomes the root filesystem image. See the
5585 ```IMAGE_ROOTFS`` <#var-IMAGE_ROOTFS>`__ variable for more 5585 :term:`IMAGE_ROOTFS` variable for more
5586 information. 5586 information.
5587 5587
5588 ROOTFS_PREPROCESS_COMMAND 5588 ROOTFS_PREPROCESS_COMMAND
@@ -5594,7 +5594,7 @@ system and gives an overview of their function and contents.
5594 If you need to pass the root filesystem path to a command within a 5594 If you need to pass the root filesystem path to a command within a
5595 function, you can use ``${IMAGE_ROOTFS}``, which points to the 5595 function, you can use ``${IMAGE_ROOTFS}``, which points to the
5596 directory that becomes the root filesystem image. See the 5596 directory that becomes the root filesystem image. See the
5597 ```IMAGE_ROOTFS`` <#var-IMAGE_ROOTFS>`__ variable for more 5597 :term:`IMAGE_ROOTFS` variable for more
5598 information. 5598 information.
5599 5599
5600 RPROVIDES 5600 RPROVIDES
@@ -5623,15 +5623,15 @@ system and gives an overview of their function and contents.
5623 The package manager will automatically install the ``RRECOMMENDS`` 5623 The package manager will automatically install the ``RRECOMMENDS``
5624 list of packages when installing the built package. However, you can 5624 list of packages when installing the built package. However, you can
5625 prevent listed packages from being installed by using the 5625 prevent listed packages from being installed by using the
5626 ```BAD_RECOMMENDATIONS`` <#var-BAD_RECOMMENDATIONS>`__, 5626 :term:`BAD_RECOMMENDATIONS`,
5627 ```NO_RECOMMENDATIONS`` <#var-NO_RECOMMENDATIONS>`__, and 5627 :term:`NO_RECOMMENDATIONS`, and
5628 ```PACKAGE_EXCLUDE`` <#var-PACKAGE_EXCLUDE>`__ variables. 5628 :term:`PACKAGE_EXCLUDE` variables.
5629 5629
5630 Packages specified in ``RRECOMMENDS`` need not actually be produced. 5630 Packages specified in ``RRECOMMENDS`` need not actually be produced.
5631 However, a recipe must exist that provides each package, either 5631 However, a recipe must exist that provides each package, either
5632 through the ```PACKAGES`` <#var-PACKAGES>`__ or 5632 through the :term:`PACKAGES` or
5633 ```PACKAGES_DYNAMIC`` <#var-PACKAGES_DYNAMIC>`__ variables or the 5633 :term:`PACKAGES_DYNAMIC` variables or the
5634 ```RPROVIDES`` <#var-RPROVIDES>`__ variable, or an error will occur 5634 :term:`RPROVIDES` variable, or an error will occur
5635 during the build. If such a recipe does exist and the package is not 5635 during the build. If such a recipe does exist and the package is not
5636 produced, the build continues without error. 5636 produced, the build continues without error.
5637 5637
@@ -5684,9 +5684,9 @@ system and gives an overview of their function and contents.
5684 example: RSUGGESTS_${PN} = "useful_package another_package" 5684 example: RSUGGESTS_${PN} = "useful_package another_package"
5685 5685
5686 S 5686 S
5687 The location in the `Build Directory <#build-directory>`__ where 5687 The location in the :term:`Build Directory` where
5688 unpacked recipe source code resides. By default, this directory is 5688 unpacked recipe source code resides. By default, this directory is
5689 ``${``\ ```WORKDIR`` <#var-WORKDIR>`__\ ``}/${``\ ```BPN`` <#var-BPN>`__\ ``}-${``\ ```PV`` <#var-PV>`__\ ``}``, 5689 ``${``\ :term:`WORKDIR`\ ``}/${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
5690 where ``${BPN}`` is the base recipe name and ``${PV}`` is the recipe 5690 where ``${BPN}`` is the base recipe name and ``${PV}`` is the recipe
5691 version. If the source tarball extracts the code to a directory named 5691 version. If the source tarball extracts the code to a directory named
5692 anything other than ``${BPN}-${PV}``, or if the source code is 5692 anything other than ``${BPN}-${PV}``, or if the source code is
@@ -5694,7 +5694,7 @@ system and gives an overview of their function and contents.
5694 ``S`` in the recipe so that the OpenEmbedded build system knows where 5694 ``S`` in the recipe so that the OpenEmbedded build system knows where
5695 to find the unpacked source. 5695 to find the unpacked source.
5696 5696
5697 As an example, assume a `Source Directory <#source-directory>`__ 5697 As an example, assume a :term:`Source Directory`
5698 top-level folder named ``poky`` and a default Build Directory at 5698 top-level folder named ``poky`` and a default Build Directory at
5699 ``poky/build``. In this case, the work directory the build system 5699 ``poky/build``. In this case, the work directory the build system
5700 uses to keep the unpacked recipe for ``db`` is the following: 5700 uses to keep the unpacked recipe for ``db`` is the following:
@@ -5703,7 +5703,7 @@ system and gives an overview of their function and contents.
5703 5703
5704 This next example assumes a Git repository. By default, Git 5704 This next example assumes a Git repository. By default, Git
5705 repositories are cloned to ``${WORKDIR}/git`` during 5705 repositories are cloned to ``${WORKDIR}/git`` during
5706 ```do_fetch`` <#ref-tasks-fetch>`__. Since this path is different 5706 :ref:`ref-tasks-fetch`. Since this path is different
5707 from the default value of ``S``, you must set it specifically so the 5707 from the default value of ``S``, you must set it specifically so the
5708 source can be located: SRC_URI = "git://path/to/repo.git" S = 5708 source can be located: SRC_URI = "git://path/to/repo.git" S =
5709 "${WORKDIR}/git" 5709 "${WORKDIR}/git"
@@ -5721,13 +5721,13 @@ system and gives an overview of their function and contents.
5721 as read from ``/etc/lsb-release``. Separate the list items with 5721 as read from ``/etc/lsb-release``. Separate the list items with
5722 explicit newline characters (``\n``). If ``SANITY_TESTED_DISTROS`` is 5722 explicit newline characters (``\n``). If ``SANITY_TESTED_DISTROS`` is
5723 not empty and the current value of 5723 not empty and the current value of
5724 ```NATIVELSBSTRING`` <#var-NATIVELSBSTRING>`__ does not appear in the 5724 :term:`NATIVELSBSTRING` does not appear in the
5725 list, then the build system reports a warning that indicates the 5725 list, then the build system reports a warning that indicates the
5726 current host distribution has not been tested as a build host. 5726 current host distribution has not been tested as a build host.
5727 5727
5728 SDK_ARCH 5728 SDK_ARCH
5729 The target architecture for the SDK. Typically, you do not directly 5729 The target architecture for the SDK. Typically, you do not directly
5730 set this variable. Instead, use ```SDKMACHINE`` <#var-SDKMACHINE>`__. 5730 set this variable. Instead, use :term:`SDKMACHINE`.
5731 5731
5732 SDK_DEPLOY 5732 SDK_DEPLOY
5733 The directory set up and used by the 5733 The directory set up and used by the
@@ -5773,8 +5773,8 @@ system and gives an overview of their function and contents.
5773 The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class 5773 The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class
5774 defines the manifest file as follows: SDK_HOST_MANIFEST = 5774 defines the manifest file as follows: SDK_HOST_MANIFEST =
5775 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is 5775 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is
5776 derived using the ```SDK_DEPLOY`` <#var-SDK_DEPLOY>`__ and 5776 derived using the :term:`SDK_DEPLOY` and
5777 ```TOOLCHAIN_OUTPUTNAME`` <#var-TOOLCHAIN_OUTPUTNAME>`__ variables. 5777 :term:`TOOLCHAIN_OUTPUTNAME` variables.
5778 5778
5779 SDK_INCLUDE_PKGDATA 5779 SDK_INCLUDE_PKGDATA
5780 When set to "1", specifies to include the packagedata for all recipes 5780 When set to "1", specifies to include the packagedata for all recipes
@@ -5794,7 +5794,7 @@ system and gives an overview of their function and contents.
5794 SDK_INCLUDE_TOOLCHAIN 5794 SDK_INCLUDE_TOOLCHAIN
5795 When set to "1", specifies to include the toolchain in the extensible 5795 When set to "1", specifies to include the toolchain in the extensible
5796 SDK. Including the toolchain is useful particularly when 5796 SDK. Including the toolchain is useful particularly when
5797 ```SDK_EXT_TYPE`` <#var-SDK_EXT_TYPE>`__ is set to "minimal" to keep 5797 :term:`SDK_EXT_TYPE` is set to "minimal" to keep
5798 the SDK reasonably small but you still want to provide a usable 5798 the SDK reasonably small but you still want to provide a usable
5799 toolchain. For example, suppose you want to use the toolchain from an 5799 toolchain. For example, suppose you want to use the toolchain from an
5800 IDE or from other tools and you do not want to perform additional 5800 IDE or from other tools and you do not want to perform additional
@@ -5805,7 +5805,7 @@ system and gives an overview of their function and contents.
5805 ``SDK_EXT_TYPE`` is set to "full". 5805 ``SDK_EXT_TYPE`` is set to "full".
5806 5806
5807 SDK_INHERIT_BLACKLIST 5807 SDK_INHERIT_BLACKLIST
5808 A list of classes to remove from the ```INHERIT`` <#var-INHERIT>`__ 5808 A list of classes to remove from the :term:`INHERIT`
5809 value globally within the extensible SDK configuration. The 5809 value globally within the extensible SDK configuration. The
5810 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class sets the 5810 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class sets the
5811 default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" 5811 default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
@@ -5829,14 +5829,14 @@ system and gives an overview of their function and contents.
5829 By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the 5829 By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the
5830 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class and 5830 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class and
5831 excludes the following variables: 5831 excludes the following variables:
5832 `CONF_VERSION <#var-CONF_VERSION>`__ 5832 :term:`CONF_VERSION`
5833 `BB_NUMBER_THREADS <#var-BB_NUMBER_THREADS>`__ 5833 :term:`BB_NUMBER_THREADS`
5834 `BB_NUMBER_PARSE_THREADS <&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS>`__ 5834 `BB_NUMBER_PARSE_THREADS <&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS>`__
5835 `PARALLEL_MAKE <#var-PARALLEL_MAKE>`__ 5835 :term:`PARALLEL_MAKE`
5836 `PRSERV_HOST <#var-PRSERV_HOST>`__ 5836 :term:`PRSERV_HOST`
5837 `SSTATE_MIRRORS <#var-SSTATE_MIRRORS>`__ `DL_DIR <#var-DL_DIR>`__ 5837 :term:`SSTATE_MIRRORS` :term:`DL_DIR`
5838 `SSTATE_DIR <#var-SSTATE_DIR>`__ `TMPDIR <#var-TMPDIR>`__ 5838 :term:`SSTATE_DIR` :term:`TMPDIR`
5839 `BB_SERVER_TIMEOUT <#var-BB_SERVER_TIMEOUT>`__ 5839 :term:`BB_SERVER_TIMEOUT`
5840 5840
5841 For additional information on how to customize the extensible SDK's 5841 For additional information on how to customize the extensible SDK's
5842 configuration, see the "`Configuring the Extensible 5842 configuration, see the "`Configuring the Extensible
@@ -5851,7 +5851,7 @@ system and gives an overview of their function and contents.
5851 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class. 5851 ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class.
5852 5852
5853 This list overrides the variables specified using the 5853 This list overrides the variables specified using the
5854 ```SDK_LOCAL_CONF_BLACKLIST`` <#var-SDK_LOCAL_CONF_BLACKLIST>`__ 5854 :term:`SDK_LOCAL_CONF_BLACKLIST`
5855 variable as well as any variables identified by automatic 5855 variable as well as any variables identified by automatic
5856 blacklisting due to the "/" character being found at the start of the 5856 blacklisting due to the "/" character being found at the start of the
5857 value, which is usually indicative of being a path and thus might not 5857 value, which is usually indicative of being a path and thus might not
@@ -5865,15 +5865,15 @@ system and gives an overview of their function and contents.
5865 5865
5866 SDK_NAME 5866 SDK_NAME
5867 The base name for SDK output files. The name is derived from the 5867 The base name for SDK output files. The name is derived from the
5868 ```DISTRO`` <#var-DISTRO>`__, ```TCLIBC`` <#var-TCLIBC>`__, 5868 :term:`DISTRO`, :term:`TCLIBC`,
5869 ```SDK_ARCH`` <#var-SDK_ARCH>`__, 5869 :term:`SDK_ARCH`,
5870 ```IMAGE_BASENAME`` <#var-IMAGE_BASENAME>`__, and 5870 :term:`IMAGE_BASENAME`, and
5871 ```TUNE_PKGARCH`` <#var-TUNE_PKGARCH>`__ variables: SDK_NAME = 5871 :term:`TUNE_PKGARCH` variables: SDK_NAME =
5872 "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}" 5872 "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
5873 5873
5874 SDK_OS 5874 SDK_OS
5875 Specifies the operating system for which the SDK will be built. The 5875 Specifies the operating system for which the SDK will be built. The
5876 default value is the value of ```BUILD_OS`` <#var-BUILD_OS>`__. 5876 default value is the value of :term:`BUILD_OS`.
5877 5877
5878 SDK_OUTPUT 5878 SDK_OUTPUT
5879 The location used by the OpenEmbedded build system when creating SDK 5879 The location used by the OpenEmbedded build system when creating SDK
@@ -5908,12 +5908,12 @@ system and gives an overview of their function and contents.
5908 If you need to pass an SDK path to a command within a function, you 5908 If you need to pass an SDK path to a command within a function, you
5909 can use ``${SDK_DIR}``, which points to the parent directory used by 5909 can use ``${SDK_DIR}``, which points to the parent directory used by
5910 the OpenEmbedded build system when creating SDK output. See the 5910 the OpenEmbedded build system when creating SDK output. See the
5911 ```SDK_DIR`` <#var-SDK_DIR>`__ variable for more information. 5911 :term:`SDK_DIR` variable for more information.
5912 5912
5913 SDK_PREFIX 5913 SDK_PREFIX
5914 The toolchain binary prefix used for ``nativesdk`` recipes. The 5914 The toolchain binary prefix used for ``nativesdk`` recipes. The
5915 OpenEmbedded build system uses the ``SDK_PREFIX`` value to set the 5915 OpenEmbedded build system uses the ``SDK_PREFIX`` value to set the
5916 ```TARGET_PREFIX`` <#var-TARGET_PREFIX>`__ when building 5916 :term:`TARGET_PREFIX` when building
5917 ``nativesdk`` recipes. The default value is "${SDK_SYS}-". 5917 ``nativesdk`` recipes. The default value is "${SDK_SYS}-".
5918 5918
5919 SDK_RECRDEP_TASKS 5919 SDK_RECRDEP_TASKS
@@ -5924,16 +5924,16 @@ system and gives an overview of their function and contents.
5924 to the SDK. To specify tasks beyond these four, you need to use the 5924 to the SDK. To specify tasks beyond these four, you need to use the
5925 ``SDK_RECRDEP_TASKS`` variable (e.g. you are defining additional 5925 ``SDK_RECRDEP_TASKS`` variable (e.g. you are defining additional
5926 tasks that are needed in order to build 5926 tasks that are needed in order to build
5927 ```SDK_TARGETS`` <#var-SDK_TARGETS>`__). 5927 :term:`SDK_TARGETS`).
5928 5928
5929 SDK_SYS 5929 SDK_SYS
5930 Specifies the system, including the architecture and the operating 5930 Specifies the system, including the architecture and the operating
5931 system, for which the SDK will be built. 5931 system, for which the SDK will be built.
5932 5932
5933 The OpenEmbedded build system automatically sets this variable based 5933 The OpenEmbedded build system automatically sets this variable based
5934 on ```SDK_ARCH`` <#var-SDK_ARCH>`__, 5934 on :term:`SDK_ARCH`,
5935 ```SDK_VENDOR`` <#var-SDK_VENDOR>`__, and 5935 :term:`SDK_VENDOR`, and
5936 ```SDK_OS`` <#var-SDK_OS>`__. You do not need to set the ``SDK_SYS`` 5936 :term:`SDK_OS`. You do not need to set the ``SDK_SYS``
5937 variable yourself. 5937 variable yourself.
5938 5938
5939 SDK_TARGET_MANIFEST 5939 SDK_TARGET_MANIFEST
@@ -5945,8 +5945,8 @@ system and gives an overview of their function and contents.
5945 The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class 5945 The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class
5946 defines the manifest file as follows: SDK_TARGET_MANIFEST = 5946 defines the manifest file as follows: SDK_TARGET_MANIFEST =
5947 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location 5947 "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location
5948 is derived using the ```SDK_DEPLOY`` <#var-SDK_DEPLOY>`__ and 5948 is derived using the :term:`SDK_DEPLOY` and
5949 ```TOOLCHAIN_OUTPUTNAME`` <#var-TOOLCHAIN_OUTPUTNAME>`__ variables. 5949 :term:`TOOLCHAIN_OUTPUTNAME` variables.
5950 5950
5951 SDK_TARGETS 5951 SDK_TARGETS
5952 A list of targets to install from shared state as part of the 5952 A list of targets to install from shared state as part of the
@@ -5958,8 +5958,8 @@ system and gives an overview of their function and contents.
5958 5958
5959 SDK_TITLE 5959 SDK_TITLE
5960 The title to be printed when running the SDK installer. By default, 5960 The title to be printed when running the SDK installer. By default,
5961 this title is based on the ```DISTRO_NAME`` <#var-DISTRO_NAME>`__ or 5961 this title is based on the :term:`DISTRO_NAME` or
5962 ```DISTRO`` <#var-DISTRO>`__ variable and is set in the 5962 :term:`DISTRO` variable and is set in the
5963 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as 5963 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as
5964 follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or 5964 follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
5965 d.getVar('DISTRO')} SDK" For the default distribution "poky", 5965 d.getVar('DISTRO')} SDK" For the default distribution "poky",
@@ -5986,12 +5986,12 @@ system and gives an overview of their function and contents.
5986 "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}" 5986 "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
5987 5987
5988 For additional information, see the 5988 For additional information, see the
5989 ```DISTRO_VERSION`` <#var-DISTRO_VERSION>`__ and 5989 :term:`DISTRO_VERSION` and
5990 ```DATE`` <#var-DATE>`__ variables. 5990 :term:`DATE` variables.
5991 5991
5992 SDKEXTPATH 5992 SDKEXTPATH
5993 The default installation directory for the Extensible SDK. By 5993 The default installation directory for the Extensible SDK. By
5994 default, this directory is based on the ```DISTRO`` <#var-DISTRO>`__ 5994 default, this directory is based on the :term:`DISTRO`
5995 variable and is set in the 5995 variable and is set in the
5996 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as 5996 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as
5997 follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the 5997 follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the
@@ -6035,7 +6035,7 @@ system and gives an overview of their function and contents.
6035 SDKTARGETSYSROOT 6035 SDKTARGETSYSROOT
6036 The full path to the sysroot used for cross-compilation within an SDK 6036 The full path to the sysroot used for cross-compilation within an SDK
6037 as it will be when installed into the default 6037 as it will be when installed into the default
6038 ```SDKPATH`` <#var-SDKPATH>`__. 6038 :term:`SDKPATH`.
6039 6039
6040 SECTION 6040 SECTION
6041 The section in which packages should be categorized. Package 6041 The section in which packages should be categorized. Package
@@ -6044,7 +6044,7 @@ system and gives an overview of their function and contents.
6044 SELECTED_OPTIMIZATION 6044 SELECTED_OPTIMIZATION
6045 Specifies the optimization flags passed to the C compiler when 6045 Specifies the optimization flags passed to the C compiler when
6046 building for the target. The flags are passed through the default 6046 building for the target. The flags are passed through the default
6047 value of the ```TARGET_CFLAGS`` <#var-TARGET_CFLAGS>`__ variable. 6047 value of the :term:`TARGET_CFLAGS` variable.
6048 6048
6049 The ``SELECTED_OPTIMIZATION`` variable takes the value of 6049 The ``SELECTED_OPTIMIZATION`` variable takes the value of
6050 ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the 6050 ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the
@@ -6074,7 +6074,7 @@ system and gives an overview of their function and contents.
6074 6074
6075 SERIAL_CONSOLES_CHECK 6075 SERIAL_CONSOLES_CHECK
6076 Specifies serial consoles, which must be listed in 6076 Specifies serial consoles, which must be listed in
6077 ```SERIAL_CONSOLES`` <#var-SERIAL_CONSOLES>`__, to check against 6077 :term:`SERIAL_CONSOLES`, to check against
6078 ``/proc/console`` before enabling them using getty. This variable 6078 ``/proc/console`` before enabling them using getty. This variable
6079 allows aliasing in the format: <device>:<alias>. If a device was 6079 allows aliasing in the format: <device>:<alias>. If a device was
6080 listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in 6080 listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in
@@ -6175,8 +6175,8 @@ system and gives an overview of their function and contents.
6175 recipes are fetched regardless of whether or not a recipe is 6175 recipes are fetched regardless of whether or not a recipe is
6176 compatible with the configuration. A recipe is considered 6176 compatible with the configuration. A recipe is considered
6177 incompatible with the currently configured machine when either or 6177 incompatible with the currently configured machine when either or
6178 both the ```COMPATIBLE_MACHINE`` <#var-COMPATIBLE_MACHINE>`__ 6178 both the :term:`COMPATIBLE_MACHINE`
6179 variable and ```COMPATIBLE_HOST`` <#var-COMPATIBLE_HOST>`__ variables 6179 variable and :term:`COMPATIBLE_HOST` variables
6180 specify compatibility with a machine other than that of the current 6180 specify compatibility with a machine other than that of the current
6181 machine or host. 6181 machine or host.
6182 6182
@@ -6188,12 +6188,12 @@ system and gives an overview of their function and contents.
6188 do not set the variable during a normal build. 6188 do not set the variable during a normal build.
6189 6189
6190 SOURCE_MIRROR_URL 6190 SOURCE_MIRROR_URL
6191 Defines your own ```PREMIRRORS`` <#var-PREMIRRORS>`__ from which to 6191 Defines your own :term:`PREMIRRORS` from which to
6192 first fetch source before attempting to fetch from the upstream 6192 first fetch source before attempting to fetch from the upstream
6193 specified in ```SRC_URI`` <#var-SRC_URI>`__. 6193 specified in :term:`SRC_URI`.
6194 6194
6195 To use this variable, you must globally inherit the 6195 To use this variable, you must globally inherit the
6196 ```own-mirrors`` <#ref-classes-own-mirrors>`__ class and then provide 6196 :ref:`own-mirrors <ref-classes-own-mirrors>` class and then provide
6197 the URL to your mirrors. Here is the general syntax: INHERIT += 6197 the URL to your mirrors. Here is the general syntax: INHERIT +=
6198 "own-mirrors" SOURCE_MIRROR_URL = 6198 "own-mirrors" SOURCE_MIRROR_URL =
6199 "http://example.com/my_source_mirror" 6199 "http://example.com/my_source_mirror"
@@ -6209,14 +6209,14 @@ system and gives an overview of their function and contents.
6209 ``meta/files/common-licenses/``. For the default ``SPDXLICENSEMAP`` 6209 ``meta/files/common-licenses/``. For the default ``SPDXLICENSEMAP``
6210 mappings, see the ``meta/conf/licenses.conf`` file. 6210 mappings, see the ``meta/conf/licenses.conf`` file.
6211 6211
6212 For additional information, see the ```LICENSE`` <#var-LICENSE>`__ 6212 For additional information, see the :term:`LICENSE`
6213 variable. 6213 variable.
6214 6214
6215 SPECIAL_PKGSUFFIX 6215 SPECIAL_PKGSUFFIX
6216 A list of prefixes for ```PN`` <#var-PN>`__ used by the OpenEmbedded 6216 A list of prefixes for :term:`PN` used by the OpenEmbedded
6217 build system to create variants of recipes or packages. The list 6217 build system to create variants of recipes or packages. The list
6218 specifies the prefixes to strip off during certain circumstances such 6218 specifies the prefixes to strip off during certain circumstances such
6219 as the generation of the ```BPN`` <#var-BPN>`__ variable. 6219 as the generation of the :term:`BPN` variable.
6220 6220
6221 SPL_BINARY 6221 SPL_BINARY
6222 The file type for the Secondary Program Loader (SPL). Some devices 6222 The file type for the Secondary Program Loader (SPL). Some devices
@@ -6260,9 +6260,9 @@ system and gives an overview of their function and contents.
6260 BitBake User Manual. 6260 BitBake User Manual.
6261 6261
6262 - *``file://`` -* Fetches files, which are usually files shipped 6262 - *``file://`` -* Fetches files, which are usually files shipped
6263 with the `Metadata <#metadata>`__, from the local machine (e.g. 6263 with the :term:`Metadata`, from the local machine (e.g.
6264 `patch <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__ files). 6264 `patch <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__ files).
6265 The path is relative to the ```FILESPATH`` <#var-FILESPATH>`__ 6265 The path is relative to the :term:`FILESPATH`
6266 variable. Thus, the build system searches, in order, from the 6266 variable. Thus, the build system searches, in order, from the
6267 following directories, which are assumed to be a subdirectories of 6267 following directories, which are assumed to be a subdirectories of
6268 the directory in which the recipe file (``.bb``) or append file 6268 the directory in which the recipe file (``.bb``) or append file
@@ -6334,13 +6334,13 @@ system and gives an overview of their function and contents.
6334 patch. The default level is 1. 6334 patch. The default level is 1.
6335 6335
6336 - *``patchdir`` -* Specifies the directory in which the patch should 6336 - *``patchdir`` -* Specifies the directory in which the patch should
6337 be applied. The default is ``${``\ ```S`` <#var-S>`__\ ``}``. 6337 be applied. The default is ``${``\ :term:`S`\ ``}``.
6338 6338
6339 Here are options specific to recipes building code from a revision 6339 Here are options specific to recipes building code from a revision
6340 control system: 6340 control system:
6341 6341
6342 - *``mindate`` -* Apply the patch only if 6342 - *``mindate`` -* Apply the patch only if
6343 ```SRCDATE`` <#var-SRCDATE>`__ is equal to or greater than 6343 :term:`SRCDATE` is equal to or greater than
6344 ``mindate``. 6344 ``mindate``.
6345 6345
6346 - *``maxdate`` -* Apply the patch only if ``SRCDATE`` is not later 6346 - *``maxdate`` -* Apply the patch only if ``SRCDATE`` is not later
@@ -6364,7 +6364,7 @@ system and gives an overview of their function and contents.
6364 an archive. The default action is to unpack the file. 6364 an archive. The default action is to unpack the file.
6365 6365
6366 - *``destsuffix`` -* Places the file (or extracts its contents) into 6366 - *``destsuffix`` -* Places the file (or extracts its contents) into
6367 the specified subdirectory of ```WORKDIR`` <#var-WORKDIR>`__ when 6367 the specified subdirectory of :term:`WORKDIR` when
6368 the Git fetcher is used. 6368 the Git fetcher is used.
6369 6369
6370 - *``subdir`` -* Places the file (or extracts its contents) into the 6370 - *``subdir`` -* Places the file (or extracts its contents) into the
@@ -6398,10 +6398,10 @@ system and gives an overview of their function and contents.
6398 6398
6399 SRCPV 6399 SRCPV
6400 Returns the version string of the current package. This string is 6400 Returns the version string of the current package. This string is
6401 used to help define the value of ```PV`` <#var-PV>`__. 6401 used to help define the value of :term:`PV`.
6402 6402
6403 The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf`` 6403 The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf``
6404 configuration file in the `Source Directory <#source-directory>`__ as 6404 configuration file in the :term:`Source Directory` as
6405 follows: SRCPV = "${@bb.fetch2.get_srcrev(d)}" 6405 follows: SRCPV = "${@bb.fetch2.get_srcrev(d)}"
6406 6406
6407 Recipes that need to define ``PV`` do so with the help of the 6407 Recipes that need to define ``PV`` do so with the help of the
@@ -6433,7 +6433,7 @@ system and gives an overview of their function and contents.
6433 6433
6434 SSTATE_MIRROR_ALLOW_NETWORK 6434 SSTATE_MIRROR_ALLOW_NETWORK
6435 If set to "1", allows fetches from mirrors that are specified in 6435 If set to "1", allows fetches from mirrors that are specified in
6436 ```SSTATE_MIRRORS`` <#var-SSTATE_MIRRORS>`__ to work even when 6436 :term:`SSTATE_MIRRORS` to work even when
6437 fetching from the network is disabled by setting ``BB_NO_NETWORK`` to 6437 fetching from the network is disabled by setting ``BB_NO_NETWORK`` to
6438 "1". Using the ``SSTATE_MIRROR_ALLOW_NETWORK`` variable is useful if 6438 "1". Using the ``SSTATE_MIRROR_ALLOW_NETWORK`` variable is useful if
6439 you have set ``SSTATE_MIRRORS`` to point to an internal server for 6439 you have set ``SSTATE_MIRRORS`` to point to an internal server for
@@ -6443,8 +6443,8 @@ system and gives an overview of their function and contents.
6443 SSTATE_MIRRORS 6443 SSTATE_MIRRORS
6444 Configures the OpenEmbedded build system to search other mirror 6444 Configures the OpenEmbedded build system to search other mirror
6445 locations for prebuilt cache data objects before building out the 6445 locations for prebuilt cache data objects before building out the
6446 data. This variable works like fetcher ```MIRRORS`` <#var-MIRRORS>`__ 6446 data. This variable works like fetcher :term:`MIRRORS`
6447 and ```PREMIRRORS`` <#var-PREMIRRORS>`__ and points to the cache 6447 and :term:`PREMIRRORS` and points to the cache
6448 locations to check for the shared state (sstate) objects. 6448 locations to check for the shared state (sstate) objects.
6449 6449
6450 You can specify a filesystem directory or a remote URL such as HTTP 6450 You can specify a filesystem directory or a remote URL such as HTTP
@@ -6456,15 +6456,15 @@ system and gives an overview of their function and contents.
6456 a different GCC version for native builds, you must configure 6456 a different GCC version for native builds, you must configure
6457 ``SSTATE_MIRRORS`` with a regular expression that maps local search 6457 ``SSTATE_MIRRORS`` with a regular expression that maps local search
6458 paths to server paths. The paths need to take into account 6458 paths to server paths. The paths need to take into account
6459 ```NATIVELSBSTRING`` <#var-NATIVELSBSTRING>`__ set by the 6459 :term:`NATIVELSBSTRING` set by the
6460 ```uninative`` <#ref-classes-uninative>`__ class. For example, the 6460 :ref:`uninative <ref-classes-uninative>` class. For example, the
6461 following maps the local search path ``universal-4.9`` to the 6461 following maps the local search path ``universal-4.9`` to the
6462 server-provided path server_url_sstate_path: SSTATE_MIRRORS ?= 6462 server-provided path server_url_sstate_path: SSTATE_MIRRORS ?=
6463 file://universal-4.9/(.*) 6463 file://universal-4.9/(.*)
6464 http://server_url_sstate_path/universal-4.8/\1 \\n 6464 http://server_url_sstate_path/universal-4.8/\1 \\n
6465 6465
6466 If a mirror uses the same structure as 6466 If a mirror uses the same structure as
6467 ```SSTATE_DIR`` <#var-SSTATE_DIR>`__, you need to add "PATH" at the 6467 :term:`SSTATE_DIR`, you need to add "PATH" at the
6468 end as shown in the examples below. The build system substitutes the 6468 end as shown in the examples below. The build system substitutes the
6469 correct path within the directory structure. SSTATE_MIRRORS ?= "\\ 6469 correct path within the directory structure. SSTATE_MIRRORS ?= "\\
6470 file://.\* 6470 file://.\*
@@ -6484,11 +6484,11 @@ system and gives an overview of their function and contents.
6484 by the ``SSTATE_SCAN_FILES`` variable. Typically, recipes add files 6484 by the ``SSTATE_SCAN_FILES`` variable. Typically, recipes add files
6485 they want to be scanned to the value of ``SSTATE_SCAN_FILES`` rather 6485 they want to be scanned to the value of ``SSTATE_SCAN_FILES`` rather
6486 than the variable being comprehensively set. The 6486 than the variable being comprehensively set. The
6487 ```sstate`` <#ref-classes-sstate>`__ class specifies the default list 6487 :ref:`sstate <ref-classes-sstate>` class specifies the default list
6488 of files. 6488 of files.
6489 6489
6490 For details on the process, see the 6490 For details on the process, see the
6491 ```staging`` <#ref-classes-staging>`__ class. 6491 :ref:`staging <ref-classes-staging>` class.
6492 6492
6493 STAGING_BASE_LIBDIR_NATIVE 6493 STAGING_BASE_LIBDIR_NATIVE
6494 Specifies the path to the ``/lib`` subdirectory of the sysroot 6494 Specifies the path to the ``/lib`` subdirectory of the sysroot
@@ -6497,12 +6497,12 @@ system and gives an overview of their function and contents.
6497 STAGING_BASELIBDIR 6497 STAGING_BASELIBDIR
6498 Specifies the path to the ``/lib`` subdirectory of the sysroot 6498 Specifies the path to the ``/lib`` subdirectory of the sysroot
6499 directory for the target for which the current recipe is being built 6499 directory for the target for which the current recipe is being built
6500 (```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__). 6500 (:term:`STAGING_DIR_HOST`).
6501 6501
6502 STAGING_BINDIR 6502 STAGING_BINDIR
6503 Specifies the path to the ``/usr/bin`` subdirectory of the sysroot 6503 Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
6504 directory for the target for which the current recipe is being built 6504 directory for the target for which the current recipe is being built
6505 (```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__). 6505 (:term:`STAGING_DIR_HOST`).
6506 6506
6507 STAGING_BINDIR_CROSS 6507 STAGING_BINDIR_CROSS
6508 Specifies the path to the directory containing binary configuration 6508 Specifies the path to the directory containing binary configuration
@@ -6528,7 +6528,7 @@ system and gives an overview of their function and contents.
6528 STAGING_DATADIR 6528 STAGING_DATADIR
6529 Specifies the path to the ``/usr/share`` subdirectory of the sysroot 6529 Specifies the path to the ``/usr/share`` subdirectory of the sysroot
6530 directory for the target for which the current recipe is being built 6530 directory for the target for which the current recipe is being built
6531 (```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__). 6531 (:term:`STAGING_DIR_HOST`).
6532 6532
6533 STAGING_DATADIR_NATIVE 6533 STAGING_DATADIR_NATIVE
6534 Specifies the path to the ``/usr/share`` subdirectory of the sysroot 6534 Specifies the path to the ``/usr/share`` subdirectory of the sysroot
@@ -6539,14 +6539,14 @@ system and gives an overview of their function and contents.
6539 during packaging. 6539 during packaging.
6540 6540
6541 For information on how staging for recipe-specific sysroots occurs, 6541 For information on how staging for recipe-specific sysroots occurs,
6542 see the ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ 6542 see the :ref:`ref-tasks-populate_sysroot`
6543 task, the "`Sharing Files Between 6543 task, the "`Sharing Files Between
6544 Recipes <&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes>`__" 6544 Recipes <&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes>`__"
6545 section in the Yocto Project Development Tasks Manual, the 6545 section in the Yocto Project Development Tasks Manual, the
6546 "`Configuration, Compilation, and 6546 "`Configuration, Compilation, and
6547 Staging <&YOCTO_DOCS_OM_URL;#configuration-compilation-and-staging-dev-environment>`__" 6547 Staging <&YOCTO_DOCS_OM_URL;#configuration-compilation-and-staging-dev-environment>`__"
6548 section in the Yocto Project Overview and Concepts Manual, and the 6548 section in the Yocto Project Overview and Concepts Manual, and the
6549 ```SYSROOT_DIRS`` <#var-SYSROOT_DIRS>`__ variable. 6549 :term:`SYSROOT_DIRS` variable.
6550 6550
6551 .. note:: 6551 .. note::
6552 6552
@@ -6566,15 +6566,15 @@ system and gives an overview of their function and contents.
6566 Specifies the path to the sysroot directory for the system on which 6566 Specifies the path to the sysroot directory for the system on which
6567 the component is built to run (the system that hosts the component). 6567 the component is built to run (the system that hosts the component).
6568 For most recipes, this sysroot is the one in which that recipe's 6568 For most recipes, this sysroot is the one in which that recipe's
6569 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task copies 6569 :ref:`ref-tasks-populate_sysroot` task copies
6570 files. Exceptions include ``-native`` recipes, where the 6570 files. Exceptions include ``-native`` recipes, where the
6571 ``do_populate_sysroot`` task instead uses 6571 ``do_populate_sysroot`` task instead uses
6572 ```STAGING_DIR_NATIVE`` <#var-STAGING_DIR_NATIVE>`__. Depending on 6572 :term:`STAGING_DIR_NATIVE`. Depending on
6573 the type of recipe and the build target, ``STAGING_DIR_HOST`` can 6573 the type of recipe and the build target, ``STAGING_DIR_HOST`` can
6574 have the following values: 6574 have the following values:
6575 6575
6576 - For recipes building for the target machine, the value is 6576 - For recipes building for the target machine, the value is
6577 "${`STAGING_DIR <#var-STAGING_DIR>`__}/${`MACHINE <#var-MACHINE>`__}". 6577 "${:term:`STAGING_DIR`}/${:term:`MACHINE`}".
6578 6578
6579 - For native recipes building for the build host, the value is empty 6579 - For native recipes building for the build host, the value is empty
6580 given the assumption that when building for the build host, the 6580 given the assumption that when building for the build host, the
@@ -6586,16 +6586,16 @@ system and gives an overview of their function and contents.
6586 as ``/usr``. Rather, these recipes are installed into 6586 as ``/usr``. Rather, these recipes are installed into
6587 ``STAGING_DIR_NATIVE``. When compiling ``-native`` recipes, 6587 ``STAGING_DIR_NATIVE``. When compiling ``-native`` recipes,
6588 standard build environment variables such as 6588 standard build environment variables such as
6589 ```CPPFLAGS`` <#var-CPPFLAGS>`__ and 6589 :term:`CPPFLAGS` and
6590 ```CFLAGS`` <#var-CFLAGS>`__ are set up so that both host paths 6590 :term:`CFLAGS` are set up so that both host paths
6591 and ``STAGING_DIR_NATIVE`` are searched for libraries and 6591 and ``STAGING_DIR_NATIVE`` are searched for libraries and
6592 headers using, for example, GCC's ``-isystem`` option. 6592 headers using, for example, GCC's ``-isystem`` option.
6593 6593
6594 Thus, the emphasis is that the ``STAGING_DIR*`` variables 6594 Thus, the emphasis is that the ``STAGING_DIR*`` variables
6595 should be viewed as input variables by tasks such as 6595 should be viewed as input variables by tasks such as
6596 ```do_configure`` <#ref-tasks-configure>`__, 6596 :ref:`ref-tasks-configure`,
6597 ```do_compile`` <#ref-tasks-compile>`__, and 6597 :ref:`ref-tasks-compile`, and
6598 ```do_install`` <#ref-tasks-install>`__. Having the real system 6598 :ref:`ref-tasks-install`. Having the real system
6599 root correspond to ``STAGING_DIR_HOST`` makes conceptual sense 6599 root correspond to ``STAGING_DIR_HOST`` makes conceptual sense
6600 for ``-native`` recipes, as they make use of host headers and 6600 for ``-native`` recipes, as they make use of host headers and
6601 libraries. 6601 libraries.
@@ -6608,7 +6608,7 @@ system and gives an overview of their function and contents.
6608 Specifies the path to the sysroot used for the system for which the 6608 Specifies the path to the sysroot used for the system for which the
6609 component generates code. For components that do not generate code, 6609 component generates code. For components that do not generate code,
6610 which is the majority, ``STAGING_DIR_TARGET`` is set to match 6610 which is the majority, ``STAGING_DIR_TARGET`` is set to match
6611 ```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__. 6611 :term:`STAGING_DIR_HOST`.
6612 6612
6613 Some recipes build binaries that can run on the target system but 6613 Some recipes build binaries that can run on the target system but
6614 those binaries in turn generate code for another different system 6614 those binaries in turn generate code for another different system
@@ -6627,12 +6627,12 @@ system and gives an overview of their function and contents.
6627 STAGING_EXECPREFIXDIR 6627 STAGING_EXECPREFIXDIR
6628 Specifies the path to the ``/usr`` subdirectory of the sysroot 6628 Specifies the path to the ``/usr`` subdirectory of the sysroot
6629 directory for the target for which the current recipe is being built 6629 directory for the target for which the current recipe is being built
6630 (```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__). 6630 (:term:`STAGING_DIR_HOST`).
6631 6631
6632 STAGING_INCDIR 6632 STAGING_INCDIR
6633 Specifies the path to the ``/usr/include`` subdirectory of the 6633 Specifies the path to the ``/usr/include`` subdirectory of the
6634 sysroot directory for the target for which the current recipe being 6634 sysroot directory for the target for which the current recipe being
6635 built (```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__). 6635 built (:term:`STAGING_DIR_HOST`).
6636 6636
6637 STAGING_INCDIR_NATIVE 6637 STAGING_INCDIR_NATIVE
6638 Specifies the path to the ``/usr/include`` subdirectory of the 6638 Specifies the path to the ``/usr/include`` subdirectory of the
@@ -6652,7 +6652,7 @@ system and gives an overview of their function and contents.
6652 STAGING_LIBDIR 6652 STAGING_LIBDIR
6653 Specifies the path to the ``/usr/lib`` subdirectory of the sysroot 6653 Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
6654 directory for the target for which the current recipe is being built 6654 directory for the target for which the current recipe is being built
6655 (```STAGING_DIR_HOST`` <#var-STAGING_DIR_HOST>`__). 6655 (:term:`STAGING_DIR_HOST`).
6656 6656
6657 STAGING_LIBDIR_NATIVE 6657 STAGING_LIBDIR_NATIVE
6658 Specifies the path to the ``/usr/lib`` subdirectory of the sysroot 6658 Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
@@ -6671,10 +6671,10 @@ system and gives an overview of their function and contents.
6671 Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__" 6671 Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__"
6672 section in the Yocto Project Overview and Concepts Manual. 6672 section in the Yocto Project Overview and Concepts Manual.
6673 6673
6674 See ```STAMPS_DIR`` <#var-STAMPS_DIR>`__, 6674 See :term:`STAMPS_DIR`,
6675 ```MULTIMACH_TARGET_SYS`` <#var-MULTIMACH_TARGET_SYS>`__, 6675 :term:`MULTIMACH_TARGET_SYS`,
6676 ```PN`` <#var-PN>`__, ```EXTENDPE`` <#var-EXTENDPE>`__, 6676 :term:`PN`, :term:`EXTENDPE`,
6677 ```PV`` <#var-PV>`__, and ```PR`` <#var-PR>`__ for related variable 6677 :term:`PV`, and :term:`PR` for related variable
6678 information. 6678 information.
6679 6679
6680 STAMPS_DIR 6680 STAMPS_DIR
@@ -6689,7 +6689,7 @@ system and gives an overview of their function and contents.
6689 The short (72 characters or less) summary of the binary package for 6689 The short (72 characters or less) summary of the binary package for
6690 packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default, 6690 packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default,
6691 ``SUMMARY`` is used to define the 6691 ``SUMMARY`` is used to define the
6692 ```DESCRIPTION`` <#var-DESCRIPTION>`__ variable if ``DESCRIPTION`` is 6692 :term:`DESCRIPTION` variable if ``DESCRIPTION`` is
6693 not set in the recipe. 6693 not set in the recipe.
6694 6694
6695 SVNDIR 6695 SVNDIR
@@ -6702,7 +6702,7 @@ system and gives an overview of their function and contents.
6702 follows where "X" is the console number you want to use: 6702 follows where "X" is the console number you want to use:
6703 SYSLINUX_DEFAULT_CONSOLE = "console=ttyX" 6703 SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
6704 6704
6705 The ```syslinux`` <#ref-classes-syslinux>`__ class initially sets 6705 The :ref:`syslinux <ref-classes-syslinux>` class initially sets
6706 this variable to null but then checks for a value later. 6706 this variable to null but then checks for a value later.
6707 6707
6708 SYSLINUX_OPTS 6708 SYSLINUX_OPTS
@@ -6710,14 +6710,14 @@ system and gives an overview of their function and contents.
6710 this variable in your recipe. If you want to list multiple options, 6710 this variable in your recipe. If you want to list multiple options,
6711 separate the options with a semicolon character (``;``). 6711 separate the options with a semicolon character (``;``).
6712 6712
6713 The ```syslinux`` <#ref-classes-syslinux>`__ class uses this variable 6713 The :ref:`syslinux <ref-classes-syslinux>` class uses this variable
6714 to create a set of options. 6714 to create a set of options.
6715 6715
6716 SYSLINUX_SERIAL 6716 SYSLINUX_SERIAL
6717 Specifies the alternate serial port or turns it off. To turn off 6717 Specifies the alternate serial port or turns it off. To turn off
6718 serial, set this variable to an empty string in your recipe. The 6718 serial, set this variable to an empty string in your recipe. The
6719 variable's default value is set in the 6719 variable's default value is set in the
6720 ```syslinux`` <#ref-classes-syslinux>`__ class as follows: 6720 :ref:`syslinux <ref-classes-syslinux>` class as follows:
6721 SYSLINUX_SERIAL ?= "0 115200" 6721 SYSLINUX_SERIAL ?= "0 115200"
6722 6722
6723 The class checks for and uses the variable as needed. 6723 The class checks for and uses the variable as needed.
@@ -6726,36 +6726,36 @@ system and gives an overview of their function and contents.
6726 An ``.LSS`` file used as the background for the VGA boot menu when 6726 An ``.LSS`` file used as the background for the VGA boot menu when
6727 you use the boot menu. You need to set this variable in your recipe. 6727 you use the boot menu. You need to set this variable in your recipe.
6728 6728
6729 The ```syslinux`` <#ref-classes-syslinux>`__ class checks for this 6729 The :ref:`syslinux <ref-classes-syslinux>` class checks for this
6730 variable and if found, the OpenEmbedded build system installs the 6730 variable and if found, the OpenEmbedded build system installs the
6731 splash screen. 6731 splash screen.
6732 6732
6733 SYSLINUX_SERIAL_TTY 6733 SYSLINUX_SERIAL_TTY
6734 Specifies the alternate console=tty... kernel boot argument. The 6734 Specifies the alternate console=tty... kernel boot argument. The
6735 variable's default value is set in the 6735 variable's default value is set in the
6736 ```syslinux`` <#ref-classes-syslinux>`__ class as follows: 6736 :ref:`syslinux <ref-classes-syslinux>` class as follows:
6737 SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200" 6737 SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
6738 6738
6739 The class checks for and uses the variable as needed. 6739 The class checks for and uses the variable as needed.
6740 6740
6741 SYSROOT_DESTDIR 6741 SYSROOT_DESTDIR
6742 Points to the temporary directory under the work directory (default 6742 Points to the temporary directory under the work directory (default
6743 "``${``\ ```WORKDIR`` <#var-WORKDIR>`__\ ``}/sysroot-destdir``") 6743 "``${``\ :term:`WORKDIR`\ ``}/sysroot-destdir``")
6744 where the files populated into the sysroot are assembled during the 6744 where the files populated into the sysroot are assembled during the
6745 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task. 6745 :ref:`ref-tasks-populate_sysroot` task.
6746 6746
6747 SYSROOT_DIRS 6747 SYSROOT_DIRS
6748 Directories that are staged into the sysroot by the 6748 Directories that are staged into the sysroot by the
6749 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task. By 6749 :ref:`ref-tasks-populate_sysroot` task. By
6750 default, the following directories are staged: SYSROOT_DIRS = " \\ 6750 default, the following directories are staged: SYSROOT_DIRS = " \\
6751 ${includedir} \\ ${libdir} \\ ${base_libdir} \\ 6751 ${includedir} \\ ${libdir} \\ ${base_libdir} \\
6752 ${nonarch_base_libdir} \\ ${datadir} \\ " 6752 ${nonarch_base_libdir} \\ ${datadir} \\ "
6753 6753
6754 SYSROOT_DIRS_BLACKLIST 6754 SYSROOT_DIRS_BLACKLIST
6755 Directories that are not staged into the sysroot by the 6755 Directories that are not staged into the sysroot by the
6756 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task. You 6756 :ref:`ref-tasks-populate_sysroot` task. You
6757 can use this variable to exclude certain subdirectories of 6757 can use this variable to exclude certain subdirectories of
6758 directories listed in ```SYSROOT_DIRS`` <#var-SYSROOT_DIRS>`__ from 6758 directories listed in :term:`SYSROOT_DIRS` from
6759 staging. By default, the following directories are not staged: 6759 staging. By default, the following directories are not staged:
6760 SYSROOT_DIRS_BLACKLIST = " \\ ${mandir} \\ ${docdir} \\ ${infodir} \\ 6760 SYSROOT_DIRS_BLACKLIST = " \\ ${mandir} \\ ${docdir} \\ ${infodir} \\
6761 ${datadir}/locale \\ ${datadir}/applications \\ ${datadir}/fonts \\ 6761 ${datadir}/locale \\ ${datadir}/applications \\ ${datadir}/fonts \\
@@ -6763,9 +6763,9 @@ system and gives an overview of their function and contents.
6763 6763
6764 SYSROOT_DIRS_NATIVE 6764 SYSROOT_DIRS_NATIVE
6765 Extra directories staged into the sysroot by the 6765 Extra directories staged into the sysroot by the
6766 ```do_populate_sysroot`` <#ref-tasks-populate_sysroot>`__ task for 6766 :ref:`ref-tasks-populate_sysroot` task for
6767 ``-native`` recipes, in addition to those specified in 6767 ``-native`` recipes, in addition to those specified in
6768 ```SYSROOT_DIRS`` <#var-SYSROOT_DIRS>`__. By default, the following 6768 :term:`SYSROOT_DIRS`. By default, the following
6769 extra directories are staged: SYSROOT_DIRS_NATIVE = " \\ ${bindir} \\ 6769 extra directories are staged: SYSROOT_DIRS_NATIVE = " \\ ${bindir} \\
6770 ${sbindir} \\ ${base_bindir} \\ ${base_sbindir} \\ ${libexecdir} \\ 6770 ${sbindir} \\ ${base_bindir} \\ ${base_sbindir} \\ ${libexecdir} \\
6771 ${sysconfdir} \\ ${localstatedir} \\ " 6771 ${sysconfdir} \\ ${localstatedir} \\ "
@@ -6785,50 +6785,50 @@ system and gives an overview of their function and contents.
6785 processing on the staged files, or to stage additional files. 6785 processing on the staged files, or to stage additional files.
6786 6786
6787 SYSTEMD_AUTO_ENABLE 6787 SYSTEMD_AUTO_ENABLE
6788 When inheriting the ```systemd`` <#ref-classes-systemd>`__ class, 6788 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
6789 this variable specifies whether the specified service in 6789 this variable specifies whether the specified service in
6790 ```SYSTEMD_SERVICE`` <#var-SYSTEMD_SERVICE>`__ should start 6790 :term:`SYSTEMD_SERVICE` should start
6791 automatically or not. By default, the service is enabled to 6791 automatically or not. By default, the service is enabled to
6792 automatically start at boot time. The default setting is in the 6792 automatically start at boot time. The default setting is in the
6793 ```systemd`` <#ref-classes-systemd>`__ class as follows: 6793 :ref:`systemd <ref-classes-systemd>` class as follows:
6794 SYSTEMD_AUTO_ENABLE ??= "enable" 6794 SYSTEMD_AUTO_ENABLE ??= "enable"
6795 6795
6796 You can disable the service by setting the variable to "disable". 6796 You can disable the service by setting the variable to "disable".
6797 6797
6798 SYSTEMD_BOOT_CFG 6798 SYSTEMD_BOOT_CFG
6799 When ```EFI_PROVIDER`` <#var-EFI_PROVIDER>`__ is set to 6799 When :term:`EFI_PROVIDER` is set to
6800 "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the 6800 "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the
6801 configuration file that should be used. By default, the 6801 configuration file that should be used. By default, the
6802 ```systemd-boot`` <#ref-classes-systemd-boot>`__ class sets the 6802 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
6803 ``SYSTEMD_BOOT_CFG`` as follows: SYSTEMD_BOOT_CFG ?= 6803 ``SYSTEMD_BOOT_CFG`` as follows: SYSTEMD_BOOT_CFG ?=
6804 "${`S <#var-S>`__}/loader.conf" 6804 "${:term:`S`}/loader.conf"
6805 6805
6806 For information on Systemd-boot, see the `Systemd-boot 6806 For information on Systemd-boot, see the `Systemd-boot
6807 documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. 6807 documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
6808 6808
6809 SYSTEMD_BOOT_ENTRIES 6809 SYSTEMD_BOOT_ENTRIES
6810 When ```EFI_PROVIDER`` <#var-EFI_PROVIDER>`__ is set to 6810 When :term:`EFI_PROVIDER` is set to
6811 "systemd-boot", the ``SYSTEMD_BOOT_ENTRIES`` variable specifies a 6811 "systemd-boot", the ``SYSTEMD_BOOT_ENTRIES`` variable specifies a
6812 list of entry files (``*.conf``) to install that contain one boot 6812 list of entry files (``*.conf``) to install that contain one boot
6813 entry per file. By default, the 6813 entry per file. By default, the
6814 ```systemd-boot`` <#ref-classes-systemd-boot>`__ class sets the 6814 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
6815 ``SYSTEMD_BOOT_ENTRIES`` as follows: SYSTEMD_BOOT_ENTRIES ?= "" 6815 ``SYSTEMD_BOOT_ENTRIES`` as follows: SYSTEMD_BOOT_ENTRIES ?= ""
6816 6816
6817 For information on Systemd-boot, see the `Systemd-boot 6817 For information on Systemd-boot, see the `Systemd-boot
6818 documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. 6818 documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
6819 6819
6820 SYSTEMD_BOOT_TIMEOUT 6820 SYSTEMD_BOOT_TIMEOUT
6821 When ```EFI_PROVIDER`` <#var-EFI_PROVIDER>`__ is set to 6821 When :term:`EFI_PROVIDER` is set to
6822 "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the 6822 "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the
6823 boot menu timeout in seconds. By default, the 6823 boot menu timeout in seconds. By default, the
6824 ```systemd-boot`` <#ref-classes-systemd-boot>`__ class sets the 6824 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
6825 ``SYSTEMD_BOOT_TIMEOUT`` as follows: SYSTEMD_BOOT_TIMEOUT ?= "10" 6825 ``SYSTEMD_BOOT_TIMEOUT`` as follows: SYSTEMD_BOOT_TIMEOUT ?= "10"
6826 6826
6827 For information on Systemd-boot, see the `Systemd-boot 6827 For information on Systemd-boot, see the `Systemd-boot
6828 documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__. 6828 documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
6829 6829
6830 SYSTEMD_PACKAGES 6830 SYSTEMD_PACKAGES
6831 When inheriting the ```systemd`` <#ref-classes-systemd>`__ class, 6831 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
6832 this variable locates the systemd unit files when they are not found 6832 this variable locates the systemd unit files when they are not found
6833 in the main recipe's package. By default, the ``SYSTEMD_PACKAGES`` 6833 in the main recipe's package. By default, the ``SYSTEMD_PACKAGES``
6834 variable is set such that the systemd unit files are assumed to 6834 variable is set such that the systemd unit files are assumed to
@@ -6839,7 +6839,7 @@ system and gives an overview of their function and contents.
6839 the build system can find the systemd unit files. 6839 the build system can find the systemd unit files.
6840 6840
6841 SYSTEMD_SERVICE 6841 SYSTEMD_SERVICE
6842 When inheriting the ```systemd`` <#ref-classes-systemd>`__ class, 6842 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
6843 this variable specifies the systemd service name for a package. 6843 this variable specifies the systemd service name for a package.
6844 6844
6845 When you specify this file in your recipe, use a package name 6845 When you specify this file in your recipe, use a package name
@@ -6852,7 +6852,7 @@ system and gives an overview of their function and contents.
6852 `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__, 6852 `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__,
6853 specifies a space-separated list of the virtual terminals that should 6853 specifies a space-separated list of the virtual terminals that should
6854 run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ 6854 run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
6855 (allowing login), assuming ```USE_VT`` <#var-USE_VT>`__ is not set to 6855 (allowing login), assuming :term:`USE_VT` is not set to
6856 "0". 6856 "0".
6857 6857
6858 The default value for ``SYSVINIT_ENABLED_GETTYS`` is "1" (i.e. only 6858 The default value for ``SYSVINIT_ENABLED_GETTYS`` is "1" (i.e. only
@@ -6864,12 +6864,12 @@ system and gives an overview of their function and contents.
6864 particular recipe. The variable is typically set as follows: T = 6864 particular recipe. The variable is typically set as follows: T =
6865 "${WORKDIR}/temp" 6865 "${WORKDIR}/temp"
6866 6866
6867 The ```WORKDIR`` <#var-WORKDIR>`__ is the directory into which 6867 The :term:`WORKDIR` is the directory into which
6868 BitBake unpacks and builds the recipe. The default ``bitbake.conf`` 6868 BitBake unpacks and builds the recipe. The default ``bitbake.conf``
6869 file sets this variable. 6869 file sets this variable.
6870 6870
6871 The ``T`` variable is not to be confused with the 6871 The ``T`` variable is not to be confused with the
6872 ```TMPDIR`` <#var-TMPDIR>`__ variable, which points to the root of 6872 :term:`TMPDIR` variable, which points to the root of
6873 the directory tree where BitBake places the output of an entire 6873 the directory tree where BitBake places the output of an entire
6874 build. 6874 build.
6875 6875
@@ -6880,19 +6880,19 @@ system and gives an overview of their function and contents.
6880 configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel 6880 configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel
6881 6881
6882 For additional information on machine architectures, see the 6882 For additional information on machine architectures, see the
6883 ```TUNE_ARCH`` <#var-TUNE_ARCH>`__ variable. 6883 :term:`TUNE_ARCH` variable.
6884 6884
6885 TARGET_AS_ARCH 6885 TARGET_AS_ARCH
6886 Specifies architecture-specific assembler flags for the target 6886 Specifies architecture-specific assembler flags for the target
6887 system. ``TARGET_AS_ARCH`` is initialized from 6887 system. ``TARGET_AS_ARCH`` is initialized from
6888 ```TUNE_ASARGS`` <#var-TUNE_ASARGS>`__ by default in the BitBake 6888 :term:`TUNE_ASARGS` by default in the BitBake
6889 configuration file (``meta/conf/bitbake.conf``): TARGET_AS_ARCH = 6889 configuration file (``meta/conf/bitbake.conf``): TARGET_AS_ARCH =
6890 "${TUNE_ASARGS}" 6890 "${TUNE_ASARGS}"
6891 6891
6892 TARGET_CC_ARCH 6892 TARGET_CC_ARCH
6893 Specifies architecture-specific C compiler flags for the target 6893 Specifies architecture-specific C compiler flags for the target
6894 system. ``TARGET_CC_ARCH`` is initialized from 6894 system. ``TARGET_CC_ARCH`` is initialized from
6895 ```TUNE_CCARGS`` <#var-TUNE_CCARGS>`__ by default. 6895 :term:`TUNE_CCARGS` by default.
6896 6896
6897 .. note:: 6897 .. note::
6898 6898
@@ -6908,17 +6908,17 @@ system and gives an overview of their function and contents.
6908 TARGET_CC_KERNEL_ARCH 6908 TARGET_CC_KERNEL_ARCH
6909 This is a specific kernel compiler flag for a CPU or Application 6909 This is a specific kernel compiler flag for a CPU or Application
6910 Binary Interface (ABI) tune. The flag is used rarely and only for 6910 Binary Interface (ABI) tune. The flag is used rarely and only for
6911 cases where a userspace ```TUNE_CCARGS`` <#var-TUNE_CCARGS>`__ is not 6911 cases where a userspace :term:`TUNE_CCARGS` is not
6912 compatible with the kernel compilation. The ``TARGET_CC_KERNEL_ARCH`` 6912 compatible with the kernel compilation. The ``TARGET_CC_KERNEL_ARCH``
6913 variable allows the kernel (and associated modules) to use a 6913 variable allows the kernel (and associated modules) to use a
6914 different configuration. See the 6914 different configuration. See the
6915 ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the 6915 ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the
6916 `Source Directory <#source-directory>`__ for an example. 6916 :term:`Source Directory` for an example.
6917 6917
6918 TARGET_CFLAGS 6918 TARGET_CFLAGS
6919 Specifies the flags to pass to the C compiler when building for the 6919 Specifies the flags to pass to the C compiler when building for the
6920 target. When building in the target context, 6920 target. When building in the target context,
6921 ```CFLAGS`` <#var-CFLAGS>`__ is set to the value of this variable by 6921 :term:`CFLAGS` is set to the value of this variable by
6922 default. 6922 default.
6923 6923
6924 Additionally, the SDK's environment setup script sets the ``CFLAGS`` 6924 Additionally, the SDK's environment setup script sets the ``CFLAGS``
@@ -6928,7 +6928,7 @@ system and gives an overview of their function and contents.
6928 TARGET_CPPFLAGS 6928 TARGET_CPPFLAGS
6929 Specifies the flags to pass to the C pre-processor (i.e. to both the 6929 Specifies the flags to pass to the C pre-processor (i.e. to both the
6930 C and the C++ compilers) when building for the target. When building 6930 C and the C++ compilers) when building for the target. When building
6931 in the target context, ```CPPFLAGS`` <#var-CPPFLAGS>`__ is set to the 6931 in the target context, :term:`CPPFLAGS` is set to the
6932 value of this variable by default. 6932 value of this variable by default.
6933 6933
6934 Additionally, the SDK's environment setup script sets the 6934 Additionally, the SDK's environment setup script sets the
@@ -6939,7 +6939,7 @@ system and gives an overview of their function and contents.
6939 TARGET_CXXFLAGS 6939 TARGET_CXXFLAGS
6940 Specifies the flags to pass to the C++ compiler when building for the 6940 Specifies the flags to pass to the C++ compiler when building for the
6941 target. When building in the target context, 6941 target. When building in the target context,
6942 ```CXXFLAGS`` <#var-CXXFLAGS>`__ is set to the value of this variable 6942 :term:`CXXFLAGS` is set to the value of this variable
6943 by default. 6943 by default.
6944 6944
6945 Additionally, the SDK's environment setup script sets the 6945 Additionally, the SDK's environment setup script sets the
@@ -6956,18 +6956,18 @@ system and gives an overview of their function and contents.
6956 TARGET_LD_ARCH 6956 TARGET_LD_ARCH
6957 Specifies architecture-specific linker flags for the target system. 6957 Specifies architecture-specific linker flags for the target system.
6958 ``TARGET_LD_ARCH`` is initialized from 6958 ``TARGET_LD_ARCH`` is initialized from
6959 ```TUNE_LDARGS`` <#var-TUNE_LDARGS>`__ by default in the BitBake 6959 :term:`TUNE_LDARGS` by default in the BitBake
6960 configuration file (``meta/conf/bitbake.conf``): TARGET_LD_ARCH = 6960 configuration file (``meta/conf/bitbake.conf``): TARGET_LD_ARCH =
6961 "${TUNE_LDARGS}" 6961 "${TUNE_LDARGS}"
6962 6962
6963 TARGET_LDFLAGS 6963 TARGET_LDFLAGS
6964 Specifies the flags to pass to the linker when building for the 6964 Specifies the flags to pass to the linker when building for the
6965 target. When building in the target context, 6965 target. When building in the target context,
6966 ```LDFLAGS`` <#var-LDFLAGS>`__ is set to the value of this variable 6966 :term:`LDFLAGS` is set to the value of this variable
6967 by default. 6967 by default.
6968 6968
6969 Additionally, the SDK's environment setup script sets the 6969 Additionally, the SDK's environment setup script sets the
6970 ```LDFLAGS`` <#var-LDFLAGS>`__ variable in the environment to the 6970 :term:`LDFLAGS` variable in the environment to the
6971 ``TARGET_LDFLAGS`` value so that executables built using the SDK also 6971 ``TARGET_LDFLAGS`` value so that executables built using the SDK also
6972 have the flags applied. 6972 have the flags applied.
6973 6973
@@ -6984,7 +6984,7 @@ system and gives an overview of their function and contents.
6984 ``TARGET_PREFIX`` is set as follows: 6984 ``TARGET_PREFIX`` is set as follows:
6985 6985
6986 - For recipes building for the target machine, the value is 6986 - For recipes building for the target machine, the value is
6987 "${`TARGET_SYS <#var-TARGET_SYS>`__}-". 6987 "${:term:`TARGET_SYS`}-".
6988 6988
6989 - For native recipes, the build system sets the variable to the 6989 - For native recipes, the build system sets the variable to the
6990 value of ``BUILD_PREFIX``. 6990 value of ``BUILD_PREFIX``.
@@ -6998,9 +6998,9 @@ system and gives an overview of their function and contents.
6998 current recipe. 6998 current recipe.
6999 6999
7000 The OpenEmbedded build system automatically sets this variable based 7000 The OpenEmbedded build system automatically sets this variable based
7001 on ```TARGET_ARCH`` <#var-TARGET_ARCH>`__, 7001 on :term:`TARGET_ARCH`,
7002 ```TARGET_VENDOR`` <#var-TARGET_VENDOR>`__, and 7002 :term:`TARGET_VENDOR`, and
7003 ```TARGET_OS`` <#var-TARGET_OS>`__ variables. 7003 :term:`TARGET_OS` variables.
7004 7004
7005 .. note:: 7005 .. note::
7006 7006
@@ -7028,9 +7028,9 @@ system and gives an overview of their function and contents.
7028 7028
7029 TCLIBCAPPEND 7029 TCLIBCAPPEND
7030 Specifies a suffix to be appended onto the 7030 Specifies a suffix to be appended onto the
7031 ```TMPDIR`` <#var-TMPDIR>`__ value. The suffix identifies the 7031 :term:`TMPDIR` value. The suffix identifies the
7032 ``libc`` variant for building. When you are building for multiple 7032 ``libc`` variant for building. When you are building for multiple
7033 variants with the same `Build Directory <#build-directory>`__, this 7033 variants with the same :term:`Build Directory`, this
7034 mechanism ensures that output for different ``libc`` variants is kept 7034 mechanism ensures that output for different ``libc`` variants is kept
7035 separate to avoid potential conflicts. 7035 separate to avoid potential conflicts.
7036 7036
@@ -7063,7 +7063,7 @@ system and gives an overview of their function and contents.
7063 page on the Yocto Project website and click on the "RELEASE 7063 page on the Yocto Project website and click on the "RELEASE
7064 INFORMATION" link for the appropriate release. 7064 INFORMATION" link for the appropriate release.
7065 7065
7066 The ``TCMODE`` variable is similar to ```TCLIBC`` <#var-TCLIBC>`__, 7066 The ``TCMODE`` variable is similar to :term:`TCLIBC`,
7067 which controls the variant of the GNU standard C library (``libc``) 7067 which controls the variant of the GNU standard C library (``libc``)
7068 used during the build process: ``glibc`` or ``musl``. 7068 used during the build process: ``glibc`` or ``musl``.
7069 7069
@@ -7086,7 +7086,7 @@ system and gives an overview of their function and contents.
7086 7086
7087 TEST_EXPORT_DIR 7087 TEST_EXPORT_DIR
7088 The location the OpenEmbedded build system uses to export tests when 7088 The location the OpenEmbedded build system uses to export tests when
7089 the ```TEST_EXPORT_ONLY`` <#var-TEST_EXPORT_ONLY>`__ variable is set 7089 the :term:`TEST_EXPORT_ONLY` variable is set
7090 to "1". 7090 to "1".
7091 7091
7092 The ``TEST_EXPORT_DIR`` variable defaults to 7092 The ``TEST_EXPORT_DIR`` variable defaults to
@@ -7121,7 +7121,7 @@ system and gives an overview of their function and contents.
7121 TEST_POWERCONTROL_EXTRA_ARGS 7121 TEST_POWERCONTROL_EXTRA_ARGS
7122 For automated hardware testing, specifies additional arguments to 7122 For automated hardware testing, specifies additional arguments to
7123 pass through to the command specified in 7123 pass through to the command specified in
7124 ```TEST_POWERCONTROL_CMD`` <#var-TEST_POWERCONTROL_CMD>`__. Setting 7124 :term:`TEST_POWERCONTROL_CMD`. Setting
7125 ``TEST_POWERCONTROL_EXTRA_ARGS`` is optional. You can use it if you 7125 ``TEST_POWERCONTROL_EXTRA_ARGS`` is optional. You can use it if you
7126 wish, for example, to separate the machine-specific and 7126 wish, for example, to separate the machine-specific and
7127 non-machine-specific parts of the arguments. 7127 non-machine-specific parts of the arguments.
@@ -7152,7 +7152,7 @@ system and gives an overview of their function and contents.
7152 TEST_SERIALCONTROL_EXTRA_ARGS 7152 TEST_SERIALCONTROL_EXTRA_ARGS
7153 For automated hardware testing, specifies additional arguments to 7153 For automated hardware testing, specifies additional arguments to
7154 pass through to the command specified in 7154 pass through to the command specified in
7155 ```TEST_SERIALCONTROL_CMD`` <#var-TEST_SERIALCONTROL_CMD>`__. Setting 7155 :term:`TEST_SERIALCONTROL_CMD`. Setting
7156 ``TEST_SERIALCONTROL_EXTRA_ARGS`` is optional. You can use it if you 7156 ``TEST_SERIALCONTROL_EXTRA_ARGS`` is optional. You can use it if you
7157 wish, for example, to separate the machine-specific and 7157 wish, for example, to separate the machine-specific and
7158 non-machine-specific parts of the command. 7158 non-machine-specific parts of the command.
@@ -7195,7 +7195,7 @@ system and gives an overview of their function and contents.
7195 - *"simpleremote":* Runs the tests on target hardware that is 7195 - *"simpleremote":* Runs the tests on target hardware that is
7196 already up and running. The hardware can be on the network or it 7196 already up and running. The hardware can be on the network or it
7197 can be a device running an image on QEMU. You must also set 7197 can be a device running an image on QEMU. You must also set
7198 ```TEST_TARGET_IP`` <#var-TEST_TARGET_IP>`__ when you use 7198 :term:`TEST_TARGET_IP` when you use
7199 "simpleremote". 7199 "simpleremote".
7200 7200
7201 .. note:: 7201 .. note::
@@ -7211,7 +7211,7 @@ system and gives an overview of their function and contents.
7211 7211
7212 TEST_TARGET_IP 7212 TEST_TARGET_IP
7213 The IP address of your hardware under test. The ``TEST_TARGET_IP`` 7213 The IP address of your hardware under test. The ``TEST_TARGET_IP``
7214 variable has no effect when ```TEST_TARGET`` <#var-TEST_TARGET>`__ is 7214 variable has no effect when :term:`TEST_TARGET` is
7215 set to "qemu". 7215 set to "qemu".
7216 7216
7217 When you specify the IP address, you can also include a port. Here is 7217 When you specify the IP address, you can also include a port. Here is
@@ -7263,14 +7263,14 @@ system and gives an overview of their function and contents.
7263 These tests are written in Python making use of the ``unittest`` 7263 These tests are written in Python making use of the ``unittest``
7264 module, and the majority of them run commands on the target system 7264 module, and the majority of them run commands on the target system
7265 over ``ssh``. You can set this variable to "1" in your ``local.conf`` 7265 over ``ssh``. You can set this variable to "1" in your ``local.conf``
7266 file in the `Build Directory <#build-directory>`__ to have the 7266 file in the :term:`Build Directory` to have the
7267 OpenEmbedded build system automatically run these tests after an 7267 OpenEmbedded build system automatically run these tests after an
7268 image successfully builds: TESTIMAGE_AUTO = "1" For more information 7268 image successfully builds: TESTIMAGE_AUTO = "1" For more information
7269 on enabling, running, and writing these tests, see the "`Performing 7269 on enabling, running, and writing these tests, see the "`Performing
7270 Automated Runtime 7270 Automated Runtime
7271 Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" 7271 Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
7272 section in the Yocto Project Development Tasks Manual and the 7272 section in the Yocto Project Development Tasks Manual and the
7273 "```testimage*.bbclass`` <#ref-classes-testimage*>`__" section. 7273 ":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
7274 7274
7275 THISDIR 7275 THISDIR
7276 The directory in which the file BitBake is currently parsing is 7276 The directory in which the file BitBake is currently parsing is
@@ -7285,7 +7285,7 @@ system and gives an overview of their function and contents.
7285 This variable is the base directory the OpenEmbedded build system 7285 This variable is the base directory the OpenEmbedded build system
7286 uses for all build output and intermediate files (other than the 7286 uses for all build output and intermediate files (other than the
7287 shared state cache). By default, the ``TMPDIR`` variable points to 7287 shared state cache). By default, the ``TMPDIR`` variable points to
7288 ``tmp`` within the `Build Directory <#build-directory>`__. 7288 ``tmp`` within the :term:`Build Directory`.
7289 7289
7290 If you want to establish this directory in a location other than the 7290 If you want to establish this directory in a location other than the
7291 default, you can uncomment and edit the following statement in the 7291 default, you can uncomment and edit the following statement in the
@@ -7304,7 +7304,7 @@ system and gives an overview of their function and contents.
7304 This variable lists packages the OpenEmbedded build system uses when 7304 This variable lists packages the OpenEmbedded build system uses when
7305 building an SDK, which contains a cross-development environment. The 7305 building an SDK, which contains a cross-development environment. The
7306 packages specified by this variable are part of the toolchain set 7306 packages specified by this variable are part of the toolchain set
7307 that runs on the ```SDKMACHINE`` <#var-SDKMACHINE>`__, and each 7307 that runs on the :term:`SDKMACHINE`, and each
7308 package should usually have the prefix ``nativesdk-``. For example, 7308 package should usually have the prefix ``nativesdk-``. For example,
7309 consider the following command when building an SDK: $ bitbake -c 7309 consider the following command when building an SDK: $ bitbake -c
7310 populate_sdk imagename In this case, a default list of packages is 7310 populate_sdk imagename In this case, a default list of packages is
@@ -7328,8 +7328,8 @@ system and gives an overview of their function and contents.
7328 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class sets 7328 ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class sets
7329 the ``TOOLCHAIN_OUTPUTNAME`` variable as follows: 7329 the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:
7330 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See 7330 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See
7331 the ```SDK_NAME`` <#var-SDK_NAME>`__ and 7331 the :term:`SDK_NAME` and
7332 ```SDK_VERSION`` <#var-SDK_VERSION>`__ variables for additional 7332 :term:`SDK_VERSION` variables for additional
7333 information. 7333 information.
7334 7334
7335 TOOLCHAIN_TARGET_TASK 7335 TOOLCHAIN_TARGET_TASK
@@ -7352,12 +7352,12 @@ system and gives an overview of their function and contents.
7352 Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. 7352 Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
7353 7353
7354 TOPDIR 7354 TOPDIR
7355 The top-level `Build Directory <#build-directory>`__. BitBake 7355 The top-level :term:`Build Directory`. BitBake
7356 automatically sets this variable when you initialize your build 7356 automatically sets this variable when you initialize your build
7357 environment using ````` <#structure-core-script>`__. 7357 environment using ````` <#structure-core-script>`__.
7358 7358
7359 TRANSLATED_TARGET_ARCH 7359 TRANSLATED_TARGET_ARCH
7360 A sanitized version of ```TARGET_ARCH`` <#var-TARGET_ARCH>`__. This 7360 A sanitized version of :term:`TARGET_ARCH`. This
7361 variable is used where the architecture is needed in a value where 7361 variable is used where the architecture is needed in a value where
7362 underscores are not allowed, for example within package filenames. In 7362 underscores are not allowed, for example within package filenames. In
7363 this case, dash characters replace any underscore characters used in 7363 this case, dash characters replace any underscore characters used in
@@ -7379,7 +7379,7 @@ system and gives an overview of their function and contents.
7379 ``TUNE_ARCH`` specific to the ``mips`` architecture. 7379 ``TUNE_ARCH`` specific to the ``mips`` architecture.
7380 7380
7381 ``TUNE_ARCH`` is tied closely to 7381 ``TUNE_ARCH`` is tied closely to
7382 ```TARGET_ARCH`` <#var-TARGET_ARCH>`__, which defines the target 7382 :term:`TARGET_ARCH`, which defines the target
7383 machine's architecture. The BitBake configuration file 7383 machine's architecture. The BitBake configuration file
7384 (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows: 7384 (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows:
7385 TARGET_ARCH = "${TUNE_ARCH}" 7385 TARGET_ARCH = "${TUNE_ARCH}"
@@ -7393,7 +7393,7 @@ system and gives an overview of their function and contents.
7393 system. The set of flags is based on the selected tune features. 7393 system. The set of flags is based on the selected tune features.
7394 ``TUNE_ASARGS`` is set using the tune include files, which are 7394 ``TUNE_ASARGS`` is set using the tune include files, which are
7395 typically under ``meta/conf/machine/include/`` and are influenced 7395 typically under ``meta/conf/machine/include/`` and are influenced
7396 through ```TUNE_FEATURES`` <#var-TUNE_FEATURES>`__. For example, the 7396 through :term:`TUNE_FEATURES`. For example, the
7397 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags 7397 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
7398 for the x86 architecture as follows: TUNE_ASARGS += 7398 for the x86 architecture as follows: TUNE_ASARGS +=
7399 "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}" 7399 "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
@@ -7409,7 +7409,7 @@ system and gives an overview of their function and contents.
7409 system. The set of flags is based on the selected tune features. 7409 system. The set of flags is based on the selected tune features.
7410 ``TUNE_CCARGS`` is set using the tune include files, which are 7410 ``TUNE_CCARGS`` is set using the tune include files, which are
7411 typically under ``meta/conf/machine/include/`` and are influenced 7411 typically under ``meta/conf/machine/include/`` and are influenced
7412 through ```TUNE_FEATURES`` <#var-TUNE_FEATURES>`__. 7412 through :term:`TUNE_FEATURES`.
7413 7413
7414 .. note:: 7414 .. note::
7415 7415
@@ -7422,7 +7422,7 @@ system and gives an overview of their function and contents.
7422 The set of flags is based on the selected tune features. 7422 The set of flags is based on the selected tune features.
7423 ``TUNE_LDARGS`` is set using the tune include files, which are 7423 ``TUNE_LDARGS`` is set using the tune include files, which are
7424 typically under ``meta/conf/machine/include/`` and are influenced 7424 typically under ``meta/conf/machine/include/`` and are influenced
7425 through ```TUNE_FEATURES`` <#var-TUNE_FEATURES>`__. For example, the 7425 through :term:`TUNE_FEATURES`. For example, the
7426 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags 7426 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
7427 for the x86 architecture as follows: TUNE_LDARGS += 7427 for the x86 architecture as follows: TUNE_LDARGS +=
7428 "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", 7428 "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "",
@@ -7446,7 +7446,7 @@ system and gives an overview of their function and contents.
7446 The BitBake configuration file (``meta/conf/bitbake.conf``) defines 7446 The BitBake configuration file (``meta/conf/bitbake.conf``) defines
7447 ``TUNE_FEATURES`` as follows: TUNE_FEATURES ??= 7447 ``TUNE_FEATURES`` as follows: TUNE_FEATURES ??=
7448 "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" See the 7448 "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" See the
7449 ```DEFAULTTUNE`` <#var-DEFAULTTUNE>`__ variable for more information. 7449 :term:`DEFAULTTUNE` variable for more information.
7450 7450
7451 TUNE_PKGARCH 7451 TUNE_PKGARCH
7452 The package architecture understood by the packaging system to define 7452 The package architecture understood by the packaging system to define
@@ -7463,34 +7463,34 @@ system and gives an overview of their function and contents.
7463 An underlying Application Binary Interface (ABI) used by a particular 7463 An underlying Application Binary Interface (ABI) used by a particular
7464 tuning in a given toolchain layer. Providers that use prebuilt 7464 tuning in a given toolchain layer. Providers that use prebuilt
7465 libraries can use the ``TUNEABI``, 7465 libraries can use the ``TUNEABI``,
7466 ```TUNEABI_OVERRIDE`` <#var-TUNEABI_OVERRIDE>`__, and 7466 :term:`TUNEABI_OVERRIDE`, and
7467 ```TUNEABI_WHITELIST`` <#var-TUNEABI_WHITELIST>`__ variables to check 7467 :term:`TUNEABI_WHITELIST` variables to check
7468 compatibility of tunings against their selection of libraries. 7468 compatibility of tunings against their selection of libraries.
7469 7469
7470 If ``TUNEABI`` is undefined, then every tuning is allowed. See the 7470 If ``TUNEABI`` is undefined, then every tuning is allowed. See the
7471 ```sanity`` <#ref-classes-sanity>`__ class to see how the variable is 7471 :ref:`sanity <ref-classes-sanity>` class to see how the variable is
7472 used. 7472 used.
7473 7473
7474 TUNEABI_OVERRIDE 7474 TUNEABI_OVERRIDE
7475 If set, the OpenEmbedded system ignores the 7475 If set, the OpenEmbedded system ignores the
7476 ```TUNEABI_WHITELIST`` <#var-TUNEABI_WHITELIST>`__ variable. 7476 :term:`TUNEABI_WHITELIST` variable.
7477 Providers that use prebuilt libraries can use the 7477 Providers that use prebuilt libraries can use the
7478 ``TUNEABI_OVERRIDE``, ``TUNEABI_WHITELIST``, and 7478 ``TUNEABI_OVERRIDE``, ``TUNEABI_WHITELIST``, and
7479 ```TUNEABI`` <#var-TUNEABI>`__ variables to check compatibility of a 7479 :term:`TUNEABI` variables to check compatibility of a
7480 tuning against their selection of libraries. 7480 tuning against their selection of libraries.
7481 7481
7482 See the ```sanity`` <#ref-classes-sanity>`__ class to see how the 7482 See the :ref:`sanity <ref-classes-sanity>` class to see how the
7483 variable is used. 7483 variable is used.
7484 7484
7485 TUNEABI_WHITELIST 7485 TUNEABI_WHITELIST
7486 A whitelist of permissible ```TUNEABI`` <#var-TUNEABI>`__ values. If 7486 A whitelist of permissible :term:`TUNEABI` values. If
7487 ``TUNEABI_WHITELIST`` is not set, all tunes are allowed. Providers 7487 ``TUNEABI_WHITELIST`` is not set, all tunes are allowed. Providers
7488 that use prebuilt libraries can use the ``TUNEABI_WHITELIST``, 7488 that use prebuilt libraries can use the ``TUNEABI_WHITELIST``,
7489 ```TUNEABI_OVERRIDE`` <#var-TUNEABI_OVERRIDE>`__, and ``TUNEABI`` 7489 :term:`TUNEABI_OVERRIDE`, and ``TUNEABI``
7490 variables to check compatibility of a tuning against their selection 7490 variables to check compatibility of a tuning against their selection
7491 of libraries. 7491 of libraries.
7492 7492
7493 See the ```sanity`` <#ref-classes-sanity>`__ class to see how the 7493 See the :ref:`sanity <ref-classes-sanity>` class to see how the
7494 variable is used. 7494 variable is used.
7495 7495
7496 TUNECONFLICTS[feature] 7496 TUNECONFLICTS[feature]
@@ -7498,7 +7498,7 @@ system and gives an overview of their function and contents.
7498 that conflict with feature. 7498 that conflict with feature.
7499 7499
7500 Known tuning conflicts are specified in the machine include files in 7500 Known tuning conflicts are specified in the machine include files in
7501 the `Source Directory <#source-directory>`__. Here is an example from 7501 the :term:`Source Directory`. Here is an example from
7502 the ``meta/conf/machine/include/mips/arch-mips.inc`` include file 7502 the ``meta/conf/machine/include/mips/arch-mips.inc`` include file
7503 that lists the "o32" and "n64" features as conflicting with the "n32" 7503 that lists the "o32" and "n64" features as conflicting with the "n32"
7504 feature: TUNECONFLICTS[n32] = "o32 n64" 7504 feature: TUNECONFLICTS[n32] = "o32 n64"
@@ -7514,8 +7514,8 @@ system and gives an overview of their function and contents.
7514 Directory <#source-directory>`__ for these features. 7514 Directory <#source-directory>`__ for these features.
7515 7515
7516 UBOOT_CONFIG 7516 UBOOT_CONFIG
7517 Configures the ```UBOOT_MACHINE`` <#var-UBOOT_MACHINE>`__ and can 7517 Configures the :term:`UBOOT_MACHINE` and can
7518 also define ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ for individual 7518 also define :term:`IMAGE_FSTYPES` for individual
7519 cases. 7519 cases.
7520 7520
7521 Following is an example from the ``meta-fsl-arm`` layer. UBOOT_CONFIG 7521 Following is an example from the ``meta-fsl-arm`` layer. UBOOT_CONFIG
@@ -7611,10 +7611,10 @@ system and gives an overview of their function and contents.
7611 UNKNOWN_CONFIGURE_WHITELIST 7611 UNKNOWN_CONFIGURE_WHITELIST
7612 Specifies a list of options that, if reported by the configure script 7612 Specifies a list of options that, if reported by the configure script
7613 as being invalid, should not generate a warning during the 7613 as being invalid, should not generate a warning during the
7614 ```do_configure`` <#ref-tasks-configure>`__ task. Normally, invalid 7614 :ref:`ref-tasks-configure` task. Normally, invalid
7615 configure options are simply not passed to the configure script (e.g. 7615 configure options are simply not passed to the configure script (e.g.
7616 should be removed from ```EXTRA_OECONF`` <#var-EXTRA_OECONF>`__ or 7616 should be removed from :term:`EXTRA_OECONF` or
7617 ```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__). 7617 :term:`PACKAGECONFIG_CONFARGS`).
7618 However, common options, for example, exist that are passed to all 7618 However, common options, for example, exist that are passed to all
7619 configure scripts at a class level that might not be valid for some 7619 configure scripts at a class level that might not be valid for some
7620 configure scripts. It follows that no benefit exists in seeing a 7620 configure scripts. It follows that no benefit exists in seeing a
@@ -7623,12 +7623,12 @@ system and gives an overview of their function and contents.
7623 7623
7624 The configure arguments check that uses 7624 The configure arguments check that uses
7625 ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the 7625 ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the
7626 ```insane`` <#ref-classes-insane>`__ class and is only enabled if the 7626 :ref:`insane <ref-classes-insane>` class and is only enabled if the
7627 recipe inherits the ```autotools`` <#ref-classes-autotools>`__ class. 7627 recipe inherits the :ref:`autotools <ref-classes-autotools>` class.
7628 7628
7629 UPDATERCPN 7629 UPDATERCPN
7630 For recipes inheriting the 7630 For recipes inheriting the
7631 ```update-rc.d`` <#ref-classes-update-rc.d>`__ class, ``UPDATERCPN`` 7631 :ref:`update-rc.d <ref-classes-update-rc.d>` class, ``UPDATERCPN``
7632 specifies the package that contains the initscript that is enabled. 7632 specifies the package that contains the initscript that is enabled.
7633 7633
7634 The default value is "${PN}". Given that almost all recipes that 7634 The default value is "${PN}". Given that almost all recipes that
@@ -7651,7 +7651,7 @@ system and gives an overview of their function and contents.
7651 Use the ``UPSTREAM_CHECK_REGEX`` variable to specify a different 7651 Use the ``UPSTREAM_CHECK_REGEX`` variable to specify a different
7652 regular expression instead of the default one when the package 7652 regular expression instead of the default one when the package
7653 checking system is parsing the page found using 7653 checking system is parsing the page found using
7654 ```UPSTREAM_CHECK_URI`` <#var-UPSTREAM_CHECK_URI>`__. 7654 :term:`UPSTREAM_CHECK_URI`.
7655 UPSTREAM_CHECK_REGEX = "package_regex" 7655 UPSTREAM_CHECK_REGEX = "package_regex"
7656 7656
7657 UPSTREAM_CHECK_URI 7657 UPSTREAM_CHECK_URI
@@ -7703,8 +7703,8 @@ system and gives an overview of their function and contents.
7703 If set to ``error``, forces the OpenEmbedded build system to produce 7703 If set to ``error``, forces the OpenEmbedded build system to produce
7704 an error if the user identification (``uid``) and group 7704 an error if the user identification (``uid``) and group
7705 identification (``gid``) values are not defined in any of the files 7705 identification (``gid``) values are not defined in any of the files
7706 listed in ```USERADD_UID_TABLES`` <#var-USERADD_UID_TABLES>`__ and 7706 listed in :term:`USERADD_UID_TABLES` and
7707 ```USERADD_GID_TABLES`` <#var-USERADD_GID_TABLES>`__. If set to 7707 :term:`USERADD_GID_TABLES`. If set to
7708 ``warn``, a warning will be issued instead. 7708 ``warn``, a warning will be issued instead.
7709 7709
7710 The default behavior for the build system is to dynamically apply 7710 The default behavior for the build system is to dynamically apply
@@ -7715,9 +7715,9 @@ system and gives an overview of their function and contents.
7715 file as follows: USERADD_ERROR_DYNAMIC = "error" Overriding the 7715 file as follows: USERADD_ERROR_DYNAMIC = "error" Overriding the
7716 default behavior implies you are going to also take steps to set 7716 default behavior implies you are going to also take steps to set
7717 static ``uid`` and ``gid`` values through use of the 7717 static ``uid`` and ``gid`` values through use of the
7718 ```USERADDEXTENSION`` <#var-USERADDEXTENSION>`__, 7718 :term:`USERADDEXTENSION`,
7719 ```USERADD_UID_TABLES`` <#var-USERADD_UID_TABLES>`__, and 7719 :term:`USERADD_UID_TABLES`, and
7720 ```USERADD_GID_TABLES`` <#var-USERADD_GID_TABLES>`__ variables. 7720 :term:`USERADD_GID_TABLES` variables.
7721 7721
7722 .. note:: 7722 .. note::
7723 7723
@@ -7745,7 +7745,7 @@ system and gives an overview of their function and contents.
7745 adds a group to the system during package installation. 7745 adds a group to the system during package installation.
7746 7746
7747 When applying static group identification (``gid``) values, the 7747 When applying static group identification (``gid``) values, the
7748 OpenEmbedded build system looks in ```BBPATH`` <#var-BBPATH>`__ for a 7748 OpenEmbedded build system looks in :term:`BBPATH` for a
7749 ``files/group`` file and then applies those ``uid`` values. Set the 7749 ``files/group`` file and then applies those ``uid`` values. Set the
7750 variable as follows in your ``local.conf`` file: USERADD_GID_TABLES = 7750 variable as follows in your ``local.conf`` file: USERADD_GID_TABLES =
7751 "files/group" 7751 "files/group"
@@ -7760,7 +7760,7 @@ system and gives an overview of their function and contents.
7760 values. 7760 values.
7761 7761
7762 USERADD_PACKAGES 7762 USERADD_PACKAGES
7763 When inheriting the ```useradd`` <#ref-classes-useradd>`__ class, 7763 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
7764 this variable specifies the individual packages within the recipe 7764 this variable specifies the individual packages within the recipe
7765 that require users and/or groups to be added. 7765 that require users and/or groups to be added.
7766 7766
@@ -7781,7 +7781,7 @@ system and gives an overview of their function and contents.
7781 variables. 7781 variables.
7782 7782
7783 USERADD_PARAM 7783 USERADD_PARAM
7784 When inheriting the ```useradd`` <#ref-classes-useradd>`__ class, 7784 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
7785 this variable specifies for a package what parameters should pass to 7785 this variable specifies for a package what parameters should pass to
7786 the ``useradd`` command if you add a user to the system when the 7786 the ``useradd`` command if you add a user to the system when the
7787 package is installed. 7787 package is installed.
@@ -7798,7 +7798,7 @@ system and gives an overview of their function and contents.
7798 adds a user to the system during package installation. 7798 adds a user to the system during package installation.
7799 7799
7800 When applying static user identification (``uid``) values, the 7800 When applying static user identification (``uid``) values, the
7801 OpenEmbedded build system looks in ```BBPATH`` <#var-BBPATH>`__ for a 7801 OpenEmbedded build system looks in :term:`BBPATH` for a
7802 ``files/passwd`` file and then applies those ``uid`` values. Set the 7802 ``files/passwd`` file and then applies those ``uid`` values. Set the
7803 variable as follows in your ``local.conf`` file: USERADD_UID_TABLES = 7803 variable as follows in your ``local.conf`` file: USERADD_UID_TABLES =
7804 "files/passwd" 7804 "files/passwd"
@@ -7815,7 +7815,7 @@ system and gives an overview of their function and contents.
7815 USERADDEXTENSION 7815 USERADDEXTENSION
7816 When set to "useradd-staticids", causes the OpenEmbedded build system 7816 When set to "useradd-staticids", causes the OpenEmbedded build system
7817 to base all user and group additions on a static ``passwd`` and 7817 to base all user and group additions on a static ``passwd`` and
7818 ``group`` files found in ```BBPATH`` <#var-BBPATH>`__. 7818 ``group`` files found in :term:`BBPATH`.
7819 7819
7820 To use static user identification (``uid``) and group identification 7820 To use static user identification (``uid``) and group identification
7821 (``gid``) values, set the variable as follows in your ``local.conf`` 7821 (``gid``) values, set the variable as follows in your ``local.conf``
@@ -7833,10 +7833,10 @@ system and gives an overview of their function and contents.
7833 7833
7834 If you use static ``uid`` and ``gid`` information, you must also 7834 If you use static ``uid`` and ``gid`` information, you must also
7835 specify the ``files/passwd`` and ``files/group`` files by setting the 7835 specify the ``files/passwd`` and ``files/group`` files by setting the
7836 ```USERADD_UID_TABLES`` <#var-USERADD_UID_TABLES>`__ and 7836 :term:`USERADD_UID_TABLES` and
7837 ```USERADD_GID_TABLES`` <#var-USERADD_GID_TABLES>`__ variables. 7837 :term:`USERADD_GID_TABLES` variables.
7838 Additionally, you should also set the 7838 Additionally, you should also set the
7839 ```USERADD_ERROR_DYNAMIC`` <#var-USERADD_ERROR_DYNAMIC>`__ variable. 7839 :term:`USERADD_ERROR_DYNAMIC` variable.
7840 7840
7841 VOLATILE_LOG_DIR 7841 VOLATILE_LOG_DIR
7842 Specifies the persistence of the target's ``/var/log`` directory, 7842 Specifies the persistence of the target's ``/var/log`` directory,
@@ -7851,18 +7851,18 @@ system and gives an overview of their function and contents.
7851 warnings by the OpenEmbedded build system. You set this variable in 7851 warnings by the OpenEmbedded build system. You set this variable in
7852 your distribution configuration file. For a list of the checks you 7852 your distribution configuration file. For a list of the checks you
7853 can control with this variable, see the 7853 can control with this variable, see the
7854 "```insane.bbclass`` <#ref-classes-insane>`__" section. 7854 ":ref:`insane.bbclass <ref-classes-insane>`" section.
7855 7855
7856 WKS_FILE_DEPENDS 7856 WKS_FILE_DEPENDS
7857 When placed in the recipe that builds your image, this variable lists 7857 When placed in the recipe that builds your image, this variable lists
7858 build-time dependencies. The ``WKS_FILE_DEPENDS`` variable is only 7858 build-time dependencies. The ``WKS_FILE_DEPENDS`` variable is only
7859 applicable when Wic images are active (i.e. when 7859 applicable when Wic images are active (i.e. when
7860 ```IMAGE_FSTYPES`` <#var-IMAGE_FSTYPES>`__ contains entries related 7860 :term:`IMAGE_FSTYPES` contains entries related
7861 to Wic). If your recipe does not create Wic images, the variable has 7861 to Wic). If your recipe does not create Wic images, the variable has
7862 no effect. 7862 no effect.
7863 7863
7864 The ``WKS_FILE_DEPENDS`` variable is similar to the 7864 The ``WKS_FILE_DEPENDS`` variable is similar to the
7865 ```DEPENDS`` <#var-DEPENDS>`__ variable. When you use the variable in 7865 :term:`DEPENDS` variable. When you use the variable in
7866 your recipe that builds the Wic image, dependencies you list in the 7866 your recipe that builds the Wic image, dependencies you list in the
7867 ``WIC_FILE_DEPENDS`` variable are added to the ``DEPENDS`` variable. 7867 ``WIC_FILE_DEPENDS`` variable are added to the ``DEPENDS`` variable.
7868 7868
@@ -7886,7 +7886,7 @@ system and gives an overview of their function and contents.
7886 WORKDIR 7886 WORKDIR
7887 The pathname of the work directory in which the OpenEmbedded build 7887 The pathname of the work directory in which the OpenEmbedded build
7888 system builds a recipe. This directory is located within the 7888 system builds a recipe. This directory is located within the
7889 ```TMPDIR`` <#var-TMPDIR>`__ directory structure and is specific to 7889 :term:`TMPDIR` directory structure and is specific to
7890 the recipe being built and the system for which it is being built. 7890 the recipe being built and the system for which it is being built.
7891 7891
7892 The ``WORKDIR`` directory is defined as follows: 7892 The ``WORKDIR`` directory is defined as follows:
@@ -7922,7 +7922,7 @@ system and gives an overview of their function and contents.
7922 server and drivers for the current machine, assuming your image 7922 server and drivers for the current machine, assuming your image
7923 directly includes ``packagegroup-core-x11-xserver`` or, perhaps 7923 directly includes ``packagegroup-core-x11-xserver`` or, perhaps
7924 indirectly, includes "x11-base" in 7924 indirectly, includes "x11-base" in
7925 ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__. 7925 :term:`IMAGE_FEATURES`.
7926 7926
7927 The default value of ``XSERVER``, if not specified in the machine 7927 The default value of ``XSERVER``, if not specified in the machine
7928 configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev". 7928 configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev".
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst
index 0a8811d95d..50f2afae03 100644
--- a/documentation/ref-manual/resources.rst
+++ b/documentation/ref-manual/resources.rst
@@ -79,7 +79,7 @@ instructions:
79 mailing list about OpenEmbedded. 79 mailing list about OpenEmbedded.
80 80
81- ` <&OE_LISTS_URL;/listinfo/bitbake-devel>`__ - Discussion mailing 81- ` <&OE_LISTS_URL;/listinfo/bitbake-devel>`__ - Discussion mailing
82 list about the `BitBake <#bitbake-term>`__ build tool. 82 list about the :term:`BitBake` build tool.
83 83
84- ` <&YOCTO_LISTS_URL;/listinfo/poky>`__ - Discussion mailing list 84- ` <&YOCTO_LISTS_URL;/listinfo/poky>`__ - Discussion mailing list
85 about `Poky <#poky>`__. 85 about `Poky <#poky>`__.
@@ -179,7 +179,7 @@ Here is a list of resources you might find helpful:
179- `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__\ *:* This manual 179- `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__\ *:* This manual
180 introduces and describes how to set up and use Toaster. Toaster is an 180 introduces and describes how to set up and use Toaster. Toaster is an
181 Application Programming Interface (API) and web-based interface to 181 Application Programming Interface (API) and web-based interface to
182 the `OpenEmbedded Build System <#build-system-term>`__, which uses 182 the :term:`OpenEmbedded Build System`, which uses
183 BitBake, that reports build information. 183 BitBake, that reports build information.
184 184
185- `FAQ <&YOCTO_WIKI_URL;/wiki/FAQ>`__\ *:* A list of commonly asked 185- `FAQ <&YOCTO_WIKI_URL;/wiki/FAQ>`__\ *:* A list of commonly asked
diff --git a/documentation/sdk-manual/sdk-appendix-customizing-standard.rst b/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
index 02f7d764ca..f6f2b6640f 100644
--- a/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
+++ b/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
@@ -11,9 +11,9 @@ Adding Individual Packages to the Standard SDK
11 11
12When you build a standard SDK using the ``bitbake -c populate_sdk``, a 12When you build a standard SDK using the ``bitbake -c populate_sdk``, a
13default set of packages is included in the resulting SDK. The 13default set of packages is included in the resulting SDK. The
14```TOOLCHAIN_HOST_TASK`` <&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_HOST_TASK>`__ 14:term:`TOOLCHAIN_HOST_TASK`
15and 15and
16```TOOLCHAIN_TARGET_TASK`` <&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK>`__ 16:term:`TOOLCHAIN_TARGET_TASK`
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
@@ -28,7 +28,7 @@ Adding API Documentation to the Standard SDK
28You can include API documentation as well as any other documentation 28You can include API documentation as well as any other documentation
29provided by recipes with the standard SDK by adding "api-documentation" 29provided by recipes with the standard SDK by adding "api-documentation"
30to the 30to the
31```DISTRO_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES>`__ 31:term:`DISTRO_FEATURES`
32variable: DISTRO_FEATURES_append = " api-documentation" Setting this 32variable: DISTRO_FEATURES_append = " api-documentation" Setting this
33variable as shown here causes the OpenEmbedded build system to build the 33variable as shown here causes the OpenEmbedded build system to build the
34documentation and then include it in the standard SDK. 34documentation and then include it in the standard SDK.
diff --git a/documentation/sdk-manual/sdk-appendix-customizing.rst b/documentation/sdk-manual/sdk-appendix-customizing.rst
index 522b41033d..8169f2bed8 100644
--- a/documentation/sdk-manual/sdk-appendix-customizing.rst
+++ b/documentation/sdk-manual/sdk-appendix-customizing.rst
@@ -22,7 +22,7 @@ build system applies them against ``local.conf`` and ``auto.conf``:
22 host <&YOCTO_DOCS_REF_URL;#hardware-build-system-term>`__. 22 host <&YOCTO_DOCS_REF_URL;#hardware-build-system-term>`__.
23 23
24- Variables listed in 24- Variables listed in
25 ```SDK_LOCAL_CONF_BLACKLIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST>`__ 25 :term:`SDK_LOCAL_CONF_BLACKLIST`
26 are excluded. These variables are not allowed through from the 26 are excluded. These variables are not allowed through from the
27 OpenEmbedded build system configuration into the extensible SDK 27 OpenEmbedded build system configuration into the extensible SDK
28 configuration. Typically, these variables are specific to the machine 28 configuration. Typically, these variables are specific to the machine
@@ -30,23 +30,23 @@ build system applies them against ``local.conf`` and ``auto.conf``:
30 of the extensible SDK configuration. 30 of the extensible SDK configuration.
31 31
32 For a list of the variables excluded by default, see the 32 For a list of the variables excluded by default, see the
33 ```SDK_LOCAL_CONF_BLACKLIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST>`__ 33 :term:`SDK_LOCAL_CONF_BLACKLIST`
34 in the glossary of the Yocto Project Reference Manual. 34 in the glossary of the Yocto Project Reference Manual.
35 35
36- Variables listed in 36- Variables listed in
37 ```SDK_LOCAL_CONF_WHITELIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_WHITELIST>`__ 37 :term:`SDK_LOCAL_CONF_WHITELIST`
38 are included. Including a variable in the value of 38 are included. Including a variable in the value of
39 ``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two 39 ``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two
40 filters. The default value is blank. 40 filters. The default value is blank.
41 41
42- Classes inherited globally with 42- Classes inherited globally with
43 ```INHERIT`` <&YOCTO_DOCS_REF_URL;#var-INHERIT>`__ that are listed in 43 :term:`INHERIT` that are listed in
44 ```SDK_INHERIT_BLACKLIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST>`__ 44 :term:`SDK_INHERIT_BLACKLIST`
45 are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these 45 are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these
46 classes is the typical method to disable classes that are problematic 46 classes is the typical method to disable classes that are problematic
47 or unnecessary in the SDK context. The default value blacklists the 47 or unnecessary in the SDK context. The default value blacklists the
48 ```buildhistory`` <&YOCTO_DOCS_REF_URL;#ref-classes-buildhistory>`__ 48 :ref:`buildhistory <ref-classes-buildhistory>`
49 and ```icecc`` <&YOCTO_DOCS_REF_URL;#ref-classes-icecc>`__ classes. 49 and :ref:`icecc <ref-classes-icecc>` classes.
50 50
51Additionally, the contents of ``conf/sdk-extra.conf``, when present, are 51Additionally, the contents of ``conf/sdk-extra.conf``, when present, are
52appended to the end of ``conf/local.conf`` within the produced SDK, 52appended to the end of ``conf/local.conf`` within the produced SDK,
@@ -63,10 +63,10 @@ However, some cases exist for which you might consider making
63adjustments: 63adjustments:
64 64
65- If your SDK configuration inherits additional classes using the 65- If your SDK configuration inherits additional classes using the
66 ```INHERIT`` <&YOCTO_DOCS_REF_URL;#var-INHERIT>`__ variable and you 66 :term:`INHERIT` variable and you
67 do not need or want those classes enabled in the SDK, you can 67 do not need or want those classes enabled in the SDK, you can
68 blacklist them by adding them to the 68 blacklist them by adding them to the
69 ```SDK_INHERIT_BLACKLIST`` <&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST>`__ 69 :term:`SDK_INHERIT_BLACKLIST`
70 variable as described in the fourth bullet of the previous section. 70 variable as described in the fourth bullet of the previous section.
71 71
72 .. note:: 72 .. note::
@@ -93,7 +93,7 @@ adjustments:
93 state cache) or ensuring the tasks are able to be produced quickly 93 state cache) or ensuring the tasks are able to be produced quickly
94 from a task that is a shared state task, add the task name to the 94 from a task that is a shared state task, add the task name to the
95 value of 95 value of
96 ```SDK_RECRDEP_TASKS`` <&YOCTO_DOCS_REF_URL;#var-SDK_RECRDEP_TASKS>`__. 96 :term:`SDK_RECRDEP_TASKS`.
97 97
98 - Disable the tasks if they are added by a class and you do not need 98 - Disable the tasks if they are added by a class and you do not need
99 the functionality the class provides in the extensible SDK. To 99 the functionality the class provides in the extensible SDK. To
@@ -109,24 +109,24 @@ adjustments:
109 109
110- If you want users of the SDK to be able to easily update the SDK, you 110- If you want users of the SDK to be able to easily update the SDK, you
111 need to set the 111 need to set the
112 ```SDK_UPDATE_URL`` <&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL>`__ 112 :term:`SDK_UPDATE_URL`
113 variable. For more information, see the "`Providing Updates to the 113 variable. For more information, see the "`Providing Updates to the
114 Extensible SDK After 114 Extensible SDK After
115 Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" 115 Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__"
116 section. 116 section.
117 117
118- If you have adjusted the list of files and directories that appear in 118- If you have adjusted the list of files and directories that appear in
119 ```COREBASE`` <&YOCTO_DOCS_REF_URL;#var-COREBASE>`__ (other than 119 :term:`COREBASE` (other than
120 layers that are enabled through ``bblayers.conf``), then you must 120 layers that are enabled through ``bblayers.conf``), then you must
121 list these files in 121 list these files in
122 ```COREBASE_FILES`` <&YOCTO_DOCS_REF_URL;#var-COREBASE_FILES>`__ so 122 :term:`COREBASE_FILES` so
123 that the files are copied into the SDK. 123 that the files are copied into the SDK.
124 124
125- If your OpenEmbedded build system setup uses a different environment 125- If your OpenEmbedded build system setup uses a different environment
126 setup script other than 126 setup script other than
127 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, then you must 127 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, then you must
128 set 128 set
129 ```OE_INIT_ENV_SCRIPT`` <&YOCTO_DOCS_REF_URL;#var-OE_INIT_ENV_SCRIPT>`__ 129 :term:`OE_INIT_ENV_SCRIPT`
130 to point to the environment setup script you use. 130 to point to the environment setup script you use.
131 131
132 .. note:: 132 .. note::
@@ -139,15 +139,15 @@ Changing the Extensible SDK Installer Title
139=========================================== 139===========================================
140 140
141You can change the displayed title for the SDK installer by setting the 141You can change the displayed title for the SDK installer by setting the
142```SDK_TITLE`` <&YOCTO_DOCS_REF_URL;#var-SDK_TITLE>`__ variable and then 142:term:`SDK_TITLE` variable and then
143rebuilding the the SDK installer. For information on how to build an SDK 143rebuilding the the SDK installer. For information on how to build an SDK
144installer, see the "`Building an SDK 144installer, see the "`Building an SDK
145Installer <#sdk-building-an-sdk-installer>`__" section. 145Installer <#sdk-building-an-sdk-installer>`__" section.
146 146
147By default, this title is derived from 147By default, this title is derived from
148```DISTRO_NAME`` <&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME>`__ when it is 148:term:`DISTRO_NAME` when it is
149set. If the ``DISTRO_NAME`` variable is not set, the title is derived 149set. If the ``DISTRO_NAME`` variable is not set, the title is derived
150from the ```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__ variable. 150from the :term:`DISTRO` variable.
151 151
152The 152The
153```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__ 153```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__
@@ -181,7 +181,7 @@ the installed SDKs to update the installed SDKs by using the
181 to host the directory. This directory must contain the published SDK. 181 to host the directory. This directory must contain the published SDK.
182 182
1832. Set the 1832. Set the
184 ```SDK_UPDATE_URL`` <&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL>`__ 184 :term:`SDK_UPDATE_URL`
185 variable to point to the corresponding HTTP or HTTPS URL. Setting 185 variable to point to the corresponding HTTP or HTTPS URL. Setting
186 this variable causes any SDK built to default to that URL and thus, 186 this variable causes any SDK built to default to that URL and thus,
187 the user does not have to pass the URL to the ``devtool sdk-update`` 187 the user does not have to pass the URL to the ``devtool sdk-update``
@@ -209,8 +209,8 @@ Changing the Default SDK Installation Directory
209 209
210When you build the installer for the Extensible SDK, the default 210When you build the installer for the Extensible SDK, the default
211installation directory for the SDK is based on the 211installation directory for the SDK is based on the
212```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__ and 212:term:`DISTRO` and
213```SDKEXTPATH`` <&YOCTO_DOCS_REF_URL;#var-SDKEXTPATH>`__ variables from 213:term:`SDKEXTPATH` variables from
214within the 214within the
215```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__ 215```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__
216class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can 216class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can
@@ -248,7 +248,7 @@ source, you need to do a number of things:
248 - Build the "world" target and set 248 - Build the "world" target and set
249 ``EXCLUDE_FROM_WORLD_pn-``\ recipename for the recipes you do not 249 ``EXCLUDE_FROM_WORLD_pn-``\ recipename for the recipes you do not
250 want built. See the 250 want built. See the
251 ```EXCLUDE_FROM_WORLD`` <&YOCTO_DOCS_REF_URL;#var-EXCLUDE_FROM_WORLD>`__ 251 :term:`EXCLUDE_FROM_WORLD`
252 variable for additional information. 252 variable for additional information.
253 253
2542. Expose the ``sstate-cache`` directory produced by the build. 2542. Expose the ``sstate-cache`` directory produced by the build.
@@ -259,7 +259,7 @@ source, you need to do a number of things:
259 259
2603. Set the appropriate configuration so that the produced SDK knows how 2603. Set the appropriate configuration so that the produced SDK knows how
261 to find the configuration. The variable you need to set is 261 to find the configuration. The variable you need to set is
262 ```SSTATE_MIRRORS`` <&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS>`__: 262 :term:`SSTATE_MIRRORS`:
263 SSTATE_MIRRORS = "file://.\* 263 SSTATE_MIRRORS = "file://.\*
264 http://example.com/some_path/sstate-cache/PATH" You can set the 264 http://example.com/some_path/sstate-cache/PATH" You can set the
265 ``SSTATE_MIRRORS`` variable in two different places: 265 ``SSTATE_MIRRORS`` variable in two different places:
@@ -297,7 +297,7 @@ more in size. If the size of this file causes a problem, you can build
297an SDK that has just enough in it to install and provide access to the 297an SDK that has just enough in it to install and provide access to the
298``devtool command`` by setting the following in your configuration: 298``devtool command`` by setting the following in your configuration:
299SDK_EXT_TYPE = "minimal" Setting 299SDK_EXT_TYPE = "minimal" Setting
300```SDK_EXT_TYPE`` <&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE>`__ to 300:term:`SDK_EXT_TYPE` to
301"minimal" produces an SDK installer that is around 35 Mbytes in size, 301"minimal" produces an SDK installer that is around 35 Mbytes in size,
302which downloads and installs quickly. You need to realize, though, that 302which downloads and installs quickly. You need to realize, though, that
303the minimal installer does not install any libraries or tools out of the 303the minimal installer does not install any libraries or tools out of the
@@ -315,7 +315,7 @@ results.
315 315
316To facilitate this wider range of information, you would need to set the 316To facilitate this wider range of information, you would need to set the
317following: SDK_INCLUDE_PKGDATA = "1" See the 317following: SDK_INCLUDE_PKGDATA = "1" See the
318```SDK_INCLUDE_PKGDATA`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_PKGDATA>`__ 318:term:`SDK_INCLUDE_PKGDATA`
319variable for additional information. 319variable for additional information.
320 320
321Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world" 321Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world"
@@ -341,7 +341,7 @@ in most cases.
341 341
342You can explicitly control whether or not to include the toolchain when 342You can explicitly control whether or not to include the toolchain when
343you build an SDK by setting the 343you build an SDK by setting the
344```SDK_INCLUDE_TOOLCHAIN`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN>`__ 344:term:`SDK_INCLUDE_TOOLCHAIN`
345variable to "1". In particular, it is useful to include the toolchain 345variable to "1". In particular, it is useful to include the toolchain
346when you have set ``SDK_EXT_TYPE`` to "minimal", which by default, 346when you have set ``SDK_EXT_TYPE`` to "minimal", which by default,
347excludes the toolchain. Also, it is helpful if you are building a small 347excludes the toolchain. Also, it is helpful if you are building a small
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.rst b/documentation/sdk-manual/sdk-appendix-obtain.rst
index 1c69b3254d..c6efdf674c 100644
--- a/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/documentation/sdk-manual/sdk-appendix-obtain.rst
@@ -95,14 +95,14 @@ build the SDK installer. Follow these steps:
95 95
964. *Make Sure You Are Building an Installer for the Correct Machine:* 964. *Make Sure You Are Building an Installer for the Correct Machine:*
97 Check to be sure that your 97 Check to be sure that your
98 ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable in the 98 :term:`MACHINE` variable in the
99 ``local.conf`` file in your Build Directory matches the architecture 99 ``local.conf`` file in your Build Directory matches the architecture
100 for which you are building. 100 for which you are building.
101 101
1025. *Make Sure Your SDK Machine is Correctly Set:* If you are building a 1025. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
103 toolchain designed to run on an architecture that differs from your 103 toolchain designed to run on an architecture that differs from your
104 current development host machine (i.e. the build host), be sure that 104 current development host machine (i.e. the build host), be sure that
105 the ```SDKMACHINE`` <&YOCTO_DOCS_REF_URL;#var-SDKMACHINE>`__ variable 105 the :term:`SDKMACHINE` variable
106 in the ``local.conf`` file in your Build Directory is correctly set. 106 in the ``local.conf`` file in your Build Directory is correctly set.
107 107
108 .. note:: 108 .. note::
@@ -138,7 +138,7 @@ build the SDK installer. Follow these steps:
138 binaries. If you want to use the toolchain to build these types 138 binaries. If you want to use the toolchain to build these types
139 of libraries, you need to be sure your SDK has the appropriate 139 of libraries, you need to be sure your SDK has the appropriate
140 static development libraries. Use the 140 static development libraries. Use the
141 ```TOOLCHAIN_TARGET_TASK`` <&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK>`__ 141 :term:`TOOLCHAIN_TARGET_TASK`
142 variable inside your ``local.conf`` file before building the 142 variable inside your ``local.conf`` file before building the
143 SDK installer. Doing so ensures that the eventual SDK 143 SDK installer. Doing so ensures that the eventual SDK
144 installation process installs the appropriate library packages 144 installation process installs the appropriate library packages
@@ -189,7 +189,7 @@ Follow these steps to extract the root filesystem:
189 filesystem image's profile: lsb, lsb-dev, lsb-sdk, minimal, 189 filesystem image's profile: lsb, lsb-dev, lsb-sdk, minimal,
190 minimal-dev, minimal-initramfs, sato, sato-dev, sato-sdk, 190 minimal-dev, minimal-initramfs, sato, sato-dev, sato-sdk,
191 sato-sdk-ptest. For information on these types of image profiles, see 191 sato-sdk-ptest. For information on these types of image profiles, see
192 the "`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the 192 the ":ref:`ref-manual/ref-images:Images`" chapter in the
193 Yocto Project Reference Manual. arch is a string representing the 193 Yocto Project Reference Manual. arch is a string representing the
194 target architecture: beaglebone-yocto, beaglebone-yocto-lsb, 194 target architecture: beaglebone-yocto, beaglebone-yocto-lsb,
195 edgerouter, edgerouter-lsb, genericx86, genericx86-64, 195 edgerouter, edgerouter-lsb, genericx86, genericx86-64,
diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/sdk-extensible.rst
index cccc857d46..17cd08a25c 100644
--- a/documentation/sdk-manual/sdk-extensible.rst
+++ b/documentation/sdk-manual/sdk-extensible.rst
@@ -148,8 +148,8 @@ SDK environment now set up; additionally you may now run devtool to
148perform development tasks. Run devtool --help for further details. 148perform development tasks. Run devtool --help for further details.
149Running the setup script defines many environment variables needed in 149Running the setup script defines many environment variables needed in
150order to use the SDK (e.g. ``PATH``, 150order to use the SDK (e.g. ``PATH``,
151```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__, 151:term:`CC`,
152```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__, and so forth). If you want to 152:term:`LD`, and so forth). If you want to
153see all the environment variables the script exports, examine the 153see all the environment variables the script exports, examine the
154installation file itself. 154installation file itself.
155 155
@@ -215,7 +215,7 @@ Use ``devtool add`` to Add an Application
215 215
216The ``devtool add`` command generates a new recipe based on existing 216The ``devtool add`` command generates a new recipe based on existing
217source code. This command takes advantage of the 217source code. This command takes advantage of the
218`workspace <&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure>`__ 218:ref:`devtool-the-workspace-layer-structure`
219layer that many ``devtool`` commands use. The command is flexible enough 219layer that many ``devtool`` commands use. The command is flexible enough
220to allow you to extract source code into both the workspace or a 220to allow you to extract source code into both the workspace or a
221separate local Git repository and to use existing code that does not 221separate local Git repository and to use existing code that does not
@@ -397,7 +397,7 @@ command:
397 The following command identifies the recipe and, by default, 397 The following command identifies the recipe and, by default,
398 extracts the source files: $ devtool modify recipe Once 398 extracts the source files: $ devtool modify recipe Once
399 ``devtool``\ locates the recipe, ``devtool`` uses the recipe's 399 ``devtool``\ locates the recipe, ``devtool`` uses the recipe's
400 ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements to 400 :term:`SRC_URI` statements to
401 locate the source code and any local patch files from other 401 locate the source code and any local patch files from other
402 developers. 402 developers.
403 403
@@ -569,7 +569,7 @@ counterparts.
569The ``devtool upgrade`` command is flexible enough to allow you to 569The ``devtool upgrade`` command is flexible enough to allow you to
570specify source code revision and versioning schemes, extract code into 570specify source code revision and versioning schemes, extract code into
571or out of the ``devtool`` 571or out of the ``devtool``
572`workspace <&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure>`__, 572:ref:`devtool-the-workspace-layer-structure`,
573and work with any source file forms that the 573and work with any source file forms that the
574`fetchers <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ support. 574`fetchers <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ support.
575 575
@@ -584,7 +584,7 @@ The following diagram shows the common development flow used with the
584 workspace. 584 workspace.
585 585
586 - The source files for the new release exist in the same location 586 - The source files for the new release exist in the same location
587 pointed to by ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ 587 pointed to by :term:`SRC_URI`
588 in the recipe (e.g. a tarball with the new version number in the 588 in the recipe (e.g. a tarball with the new version number in the
589 name, or as a different revision in the upstream Git repository). 589 name, or as a different revision in the upstream Git repository).
590 590
@@ -594,7 +594,7 @@ The following diagram shows the common development flow used with the
594 use the newer version of the software: $ devtool upgrade -V version 594 use the newer version of the software: $ devtool upgrade -V version
595 recipe By default, the ``devtool upgrade`` command extracts source 595 recipe By default, the ``devtool upgrade`` command extracts source
596 code into the ``sources`` directory in the 596 code into the ``sources`` directory in the
597 `workspace <&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure>`__. 597 :ref:`devtool-the-workspace-layer-structure`.
598 If you want the code extracted to any other location, you need to 598 If you want the code extracted to any other location, you need to
599 provide the srctree positional argument with the command as follows: 599 provide the srctree positional argument with the command as follows:
600 $ devtool upgrade -V version recipe srctree 600 $ devtool upgrade -V version recipe srctree
@@ -773,7 +773,7 @@ Dependency Detection and Mapping
773The ``devtool add`` command attempts to detect build-time dependencies 773The ``devtool add`` command attempts to detect build-time dependencies
774and map them to other recipes in the system. During this mapping, the 774and map them to other recipes in the system. During this mapping, the
775command fills in the names of those recipes as part of the 775command fills in the names of those recipes as part of the
776```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ variable within the 776:term:`DEPENDS` variable within the
777recipe. If a dependency cannot be mapped, ``devtool`` places a comment 777recipe. If a dependency cannot be mapped, ``devtool`` places a comment
778in the recipe indicating such. The inability to map a dependency can 778in the recipe indicating such. The inability to map a dependency can
779result from naming not being recognized or because the dependency simply 779result from naming not being recognized or because the dependency simply
@@ -807,13 +807,13 @@ License Detection
807The ``devtool add`` command attempts to determine if the software you 807The ``devtool add`` command attempts to determine if the software you
808are adding is able to be distributed under a common, open-source 808are adding is able to be distributed under a common, open-source
809license. If so, the command sets the 809license. If so, the command sets the
810```LICENSE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ value accordingly. 810:term:`LICENSE` value accordingly.
811You should double-check the value added by the command against the 811You should double-check the value added by the command against the
812documentation or source files for the software you are building and, if 812documentation or source files for the software you are building and, if
813necessary, update that ``LICENSE`` value. 813necessary, update that ``LICENSE`` value.
814 814
815The ``devtool add`` command also sets the 815The ``devtool add`` command also sets the
816```LIC_FILES_CHKSUM`` <&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM>`__ 816:term:`LIC_FILES_CHKSUM`
817value to point to all files that appear to be license-related. Realize 817value to point to all files that appear to be license-related. Realize
818that license statements often appear in comments at the top of source 818that license statements often appear in comments at the top of source
819files or within the documentation. In such cases, the command does not 819files or within the documentation. In such cases, the command does not
@@ -842,7 +842,7 @@ open-source software. Unfortunately, Makefiles are often not written
842with cross-compilation in mind. Thus, ``devtool add`` often cannot do 842with cross-compilation in mind. Thus, ``devtool add`` often cannot do
843very much to ensure that these Makefiles build correctly. It is very 843very much to ensure that these Makefiles build correctly. It is very
844common, for example, to explicitly call ``gcc`` instead of using the 844common, for example, to explicitly call ``gcc`` instead of using the
845```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ variable. Usually, in a 845:term:`CC` variable. Usually, in a
846cross-compilation environment, ``gcc`` is the compiler for the build 846cross-compilation environment, ``gcc`` is the compiler for the build
847host and the cross-compiler is named something similar to 847host and the cross-compiler is named something similar to
848``arm-poky-linux-gnueabi-gcc`` and might require arguments (e.g. to 848``arm-poky-linux-gnueabi-gcc`` and might require arguments (e.g. to
@@ -869,8 +869,8 @@ mind:
869 sets the default using the "?=" operator, or you can alternatively 869 sets the default using the "?=" operator, or you can alternatively
870 force the value on the ``make`` command line. To force the value on 870 force the value on the ``make`` command line. To force the value on
871 the command line, add the variable setting to 871 the command line, add the variable setting to
872 ```EXTRA_OEMAKE`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OEMAKE>`__ or 872 :term:`EXTRA_OEMAKE` or
873 ```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ 873 :term:`PACKAGECONFIG_CONFARGS`
874 within the recipe. Here is an example using ``EXTRA_OEMAKE``: 874 within the recipe. Here is an example using ``EXTRA_OEMAKE``:
875 EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" In the above example, 875 EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" In the above example,
876 single quotes are used around the variable settings as the values are 876 single quotes are used around the variable settings as the values are
@@ -951,7 +951,7 @@ repository or local source tree. To add modules this way, use
951https://github.com/diversario/node-ssdp In this example, ``devtool`` 951https://github.com/diversario/node-ssdp In this example, ``devtool``
952fetches the specified Git repository, detects the code as Node.js code, 952fetches the specified Git repository, detects the code as Node.js code,
953fetches dependencies using ``npm``, and sets 953fetches dependencies using ``npm``, and sets
954```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ accordingly. 954:term:`SRC_URI` accordingly.
955 955
956.. _sdk-working-with-recipes: 956.. _sdk-working-with-recipes:
957 957
@@ -976,8 +976,8 @@ build progresses as follows:
976For recipes in the workspace, fetching and unpacking is disabled as the 976For recipes in the workspace, fetching and unpacking is disabled as the
977source tree has already been prepared and is persistent. Each of these 977source tree has already been prepared and is persistent. Each of these
978build steps is defined as a function (task), usually with a "do_" prefix 978build steps is defined as a function (task), usually with a "do_" prefix
979(e.g. ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__, 979(e.g. :ref:`ref-tasks-fetch`,
980```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__, and so 980:ref:`ref-tasks-unpack`, and so
981forth). These functions are typically shell scripts but can instead be 981forth). These functions are typically shell scripts but can instead be
982written in Python. 982written in Python.
983 983
@@ -986,7 +986,7 @@ does not include complete instructions for building the software.
986Instead, common functionality is encapsulated in classes inherited with 986Instead, common functionality is encapsulated in classes inherited with
987the ``inherit`` directive. This technique leaves the recipe to describe 987the ``inherit`` directive. This technique leaves the recipe to describe
988just the things that are specific to the software being built. A 988just the things that are specific to the software being built. A
989```base`` <&YOCTO_DOCS_REF_URL;#ref-classes-base>`__ class exists that 989:ref:`base <ref-classes-base>` class exists that
990is implicitly inherited by all recipes and provides the functionality 990is implicitly inherited by all recipes and provides the functionality
991that most recipes typically need. 991that most recipes typically need.
992 992
@@ -1011,9 +1011,9 @@ links created within the source tree:
1011 useful: 1011 useful:
1012 1012
1013 - ``image/``: Contains all of the files installed during the 1013 - ``image/``: Contains all of the files installed during the
1014 ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ stage. 1014 :ref:`ref-tasks-install` stage.
1015 Within a recipe, this directory is referred to by the expression 1015 Within a recipe, this directory is referred to by the expression
1016 ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}``. 1016 ``${``\ :term:`D`\ ``}``.
1017 1017
1018 - ``sysroot-destdir/``: Contains a subset of files installed within 1018 - ``sysroot-destdir/``: Contains a subset of files installed within
1019 ``do_install`` that have been put into the shared sysroot. For 1019 ``do_install`` that have been put into the shared sysroot. For
@@ -1035,16 +1035,16 @@ Setting Configure Arguments
1035If the software your recipe is building uses GNU autoconf, then a fixed 1035If the software your recipe is building uses GNU autoconf, then a fixed
1036set of arguments is passed to it to enable cross-compilation plus any 1036set of arguments is passed to it to enable cross-compilation plus any
1037extras specified by 1037extras specified by
1038```EXTRA_OECONF`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF>`__ or 1038:term:`EXTRA_OECONF` or
1039```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ 1039:term:`PACKAGECONFIG_CONFARGS`
1040set within the recipe. If you wish to pass additional options, add them 1040set within the recipe. If you wish to pass additional options, add them
1041to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build 1041to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build
1042tools have similar variables (e.g. 1042tools have similar variables (e.g.
1043```EXTRA_OECMAKE`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE>`__ for 1043:term:`EXTRA_OECMAKE` for
1044CMake, ```EXTRA_OESCONS`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OESCONS>`__ 1044CMake, :term:`EXTRA_OESCONS`
1045for Scons, and so forth). If you need to pass anything on the ``make`` 1045for Scons, and so forth). If you need to pass anything on the ``make``
1046command line, you can use ``EXTRA_OEMAKE`` or the 1046command line, you can use ``EXTRA_OEMAKE`` or the
1047```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ 1047:term:`PACKAGECONFIG_CONFARGS`
1048variables to do so. 1048variables to do so.
1049 1049
1050You can use the ``devtool configure-help`` command to help you set the 1050You can use the ``devtool configure-help`` command to help you set the
@@ -1071,8 +1071,8 @@ the build host.
1071 1071
1072Recipes should never write files directly into the sysroot. Instead, 1072Recipes should never write files directly into the sysroot. Instead,
1073files should be installed into standard locations during the 1073files should be installed into standard locations during the
1074```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task within 1074:ref:`ref-tasks-install` task within
1075the ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}`` directory. A 1075the ``${``\ :term:`D`\ ``}`` directory. A
1076subset of these files automatically goes into the sysroot. The reason 1076subset of these files automatically goes into the sysroot. The reason
1077for this limitation is that almost all files that go into the sysroot 1077for this limitation is that almost all files that go into the sysroot
1078are cataloged in manifests in order to ensure they can be removed later 1078are cataloged in manifests in order to ensure they can be removed later
@@ -1090,9 +1090,9 @@ the target device, it is important to understand packaging because the
1090contents of the image are expressed in terms of packages and not 1090contents of the image are expressed in terms of packages and not
1091recipes. 1091recipes.
1092 1092
1093During the ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ 1093During the :ref:`ref-tasks-package`
1094task, files installed during the 1094task, files installed during the
1095```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task are 1095:ref:`ref-tasks-install` task are
1096split into one main package, which is almost always named the same as 1096split into one main package, which is almost always named the same as
1097the recipe, and into several other packages. This separation exists 1097the recipe, and into several other packages. This separation exists
1098because not all of those installed files are useful in every image. For 1098because not all of those installed files are useful in every image. For
@@ -1105,14 +1105,14 @@ package splitting as well.
1105After building a recipe, you can see where files have gone by looking in 1105After building a recipe, you can see where files have gone by looking in
1106the ``oe-workdir/packages-split`` directory, which contains a 1106the ``oe-workdir/packages-split`` directory, which contains a
1107subdirectory for each package. Apart from some advanced cases, the 1107subdirectory for each package. Apart from some advanced cases, the
1108```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__ and 1108:term:`PACKAGES` and
1109```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ variables controls 1109:term:`FILES` variables controls
1110splitting. The ``PACKAGES`` variable lists all of the packages to be 1110splitting. The ``PACKAGES`` variable lists all of the packages to be
1111produced, while the ``FILES`` variable specifies which files to include 1111produced, while the ``FILES`` variable specifies which files to include
1112in each package by using an override to specify the package. For 1112in each package by using an override to specify the package. For
1113example, ``FILES_${PN}`` specifies the files to go into the main package 1113example, ``FILES_${PN}`` specifies the files to go into the main package
1114(i.e. the main package has the same name as the recipe and 1114(i.e. the main package has the same name as the recipe and
1115``${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}`` evaluates to the 1115``${``\ :term:`PN`\ ``}`` evaluates to the
1116recipe name). The order of the ``PACKAGES`` value is significant. For 1116recipe name). The order of the ``PACKAGES`` value is significant. For
1117each installed file, the first package whose ``FILES`` value matches the 1117each installed file, the first package whose ``FILES`` value matches the
1118file is the package into which the file goes. Defaults exist for both 1118file is the package into which the file goes. Defaults exist for both
@@ -1190,7 +1190,7 @@ manually "pull down" the updates into the installed SDK.
1190To update your installed SDK, use ``devtool`` as follows: $ devtool 1190To update your installed SDK, use ``devtool`` as follows: $ devtool
1191sdk-update The previous command assumes your SDK provider has set the 1191sdk-update The previous command assumes your SDK provider has set the
1192default update URL for you through the 1192default update URL for you through the
1193```SDK_UPDATE_URL`` <&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL>`__ 1193:term:`SDK_UPDATE_URL`
1194variable as described in the "`Providing Updates to the Extensible SDK 1194variable as described in the "`Providing Updates to the Extensible SDK
1195After 1195After
1196Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" 1196Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__"
diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
index 1a07a9e7a9..fcb15a8592 100644
--- a/documentation/sdk-manual/sdk-intro.rst
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -56,8 +56,8 @@ toolchain binaries are produced for any given architecture. This feature
56takes advantage of the fact that the target hardware can be passed to 56takes advantage of the fact that the target hardware can be passed to
57``gcc`` as a set of compiler options. Those options are set up by the 57``gcc`` as a set of compiler options. Those options are set up by the
58environment script and contained in variables such as 58environment script and contained in variables such as
59```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ and 59:term:`CC` and
60```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__. This reduces the space needed 60:term:`LD`. This reduces the space needed
61for the tools. Understand, however, that every target still needs a 61for the tools. Understand, however, that every target still needs a
62sysroot because those binaries are target-specific. 62sysroot because those binaries are target-specific.
63 63
@@ -66,7 +66,7 @@ The SDK development environment consists of the following:
66- The self-contained SDK, which is an architecture-specific 66- The self-contained SDK, which is an architecture-specific
67 cross-toolchain and matching sysroots (target and native) all built 67 cross-toolchain and matching sysroots (target and native) all built
68 by the OpenEmbedded build system (e.g. the SDK). The toolchain and 68 by the OpenEmbedded build system (e.g. the SDK). The toolchain and
69 sysroots are based on a `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ 69 sysroots are based on a :term:`Metadata`
70 configuration and extensions, which allows you to cross-develop on 70 configuration and extensions, which allows you to cross-develop on
71 the host machine for the target hardware. Additionally, the 71 the host machine for the target hardware. Additionally, the
72 extensible SDK contains the ``devtool`` functionality. 72 extensible SDK contains the ``devtool`` functionality.
@@ -107,9 +107,9 @@ when considering which to build:
107+-----------------------+-----------------------+-----------------------+ 107+-----------------------+-----------------------+-----------------------+
108 108
109\* Extensible SDK contains the toolchain and debugger if 109\* Extensible SDK contains the toolchain and debugger if
110```SDK_EXT_TYPE`` <&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE>`__ is "full" 110:term:`SDK_EXT_TYPE` is "full"
111or 111or
112```SDK_INCLUDE_TOOLCHAIN`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN>`__ 112:term:`SDK_INCLUDE_TOOLCHAIN`
113is "1", which is the default. \*\* Sysroot is managed through the use of 113is "1", which is the default. \*\* Sysroot is managed through the use of
114``devtool``. Thus, it is less likely that you will corrupt your SDK 114``devtool``. Thus, it is less likely that you will corrupt your SDK
115sysroot when you try to add additional libraries. \**\* You can add 115sysroot when you try to add additional libraries. \**\* You can add
diff --git a/documentation/sdk-manual/sdk-working-projects.rst b/documentation/sdk-manual/sdk-working-projects.rst
index 1d001d1099..63f61de66d 100644
--- a/documentation/sdk-manual/sdk-working-projects.rst
+++ b/documentation/sdk-manual/sdk-working-projects.rst
@@ -79,7 +79,7 @@ project:
79 79
804. *Cross-Compile the Project:* This command compiles the project using 804. *Cross-Compile the Project:* This command compiles the project using
81 the cross-compiler. The 81 the cross-compiler. The
82 ```CONFIGURE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS>`__ 82 :term:`CONFIGURE_FLAGS`
83 environment variable provides the minimal arguments for GNU 83 environment variable provides the minimal arguments for GNU
84 configure: $ ./configure ${CONFIGURE_FLAGS} For an Autotools-based 84 configure: $ ./configure ${CONFIGURE_FLAGS} For an Autotools-based
85 project, you can use the cross-toolchain by just passing the 85 project, you can use the cross-toolchain by just passing the
@@ -167,7 +167,7 @@ demonstrates these variable behaviors.
167In a new shell environment variables are not established for the SDK 167In a new shell environment variables are not established for the SDK
168until you run the setup script. For example, the following commands show 168until you run the setup script. For example, the following commands show
169a null value for the compiler variable (i.e. 169a null value for the compiler variable (i.e.
170```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__). $ echo ${CC} $ Running the 170:term:`CC`). $ echo ${CC} $ Running the
171SDK setup script for a 64-bit build host and an i586-tuned target 171SDK setup script for a 64-bit build host and an i586-tuned target
172architecture for a ``core-image-sato`` image using the current DISTRO 172architecture for a ``core-image-sato`` image using the current DISTRO
173Yocto Project release and then echoing that variable shows the value 173Yocto Project release and then echoing that variable shows the value
diff --git a/documentation/test-manual/test-manual-intro.rst b/documentation/test-manual/test-manual-intro.rst
index a7f91e06ac..80e57b134c 100644
--- a/documentation/test-manual/test-manual-intro.rst
+++ b/documentation/test-manual/test-manual-intro.rst
@@ -95,8 +95,8 @@ The Autobuilder tests different elements of the project by using
95thefollowing types of tests: 95thefollowing types of tests:
96 96
97- *Build Testing:* Tests whether specific configurations build by 97- *Build Testing:* Tests whether specific configurations build by
98 varying ```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__, 98 varying :term:`MACHINE`,
99 ```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__, other configuration 99 :term:`DISTRO`, other configuration
100 options, and the specific target images being built (or world). Used 100 options, and the specific target images being built (or world). Used
101 to trigger builds of all the different test configurations on the 101 to trigger builds of all the different test configurations on the
102 Autobuilder. Builds usually cover many different targets for 102 Autobuilder. Builds usually cover many different targets for
@@ -105,7 +105,7 @@ thefollowing types of tests:
105 Autobuilder tests literally hundreds of configurations and targets. 105 Autobuilder tests literally hundreds of configurations and targets.
106 106
107 - *Sanity Checks During the Build Process:* Tests initiated through 107 - *Sanity Checks During the Build Process:* Tests initiated through
108 the ```insane`` <&YOCTO_DOCS_REF_URL;#ref-classes-insane>`__ 108 the :ref:`insane <ref-classes-insane>`
109 class. These checks ensure the output of the builds are correct. 109 class. These checks ensure the output of the builds are correct.
110 For example, does the ELF architecture in the generated binaries 110 For example, does the ELF architecture in the generated binaries
111 match the target system? ARM binaries would not work in a MIPS 111 match the target system? ARM binaries would not work in a MIPS
@@ -133,9 +133,9 @@ thefollowing types of tests:
133 133
134- *Image Testing:* Image tests initiated through the following command: 134- *Image Testing:* Image tests initiated through the following command:
135 $ bitbake image -c testimage The tests utilize the 135 $ bitbake image -c testimage The tests utilize the
136 ```testimage*`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ 136 :ref:`testimage* <ref-classes-testimage*>`
137 classes and the 137 classes and the
138 ```do_testimage`` <&YOCTO_DOCS_REF_URL;#ref-tasks-testimage>`__ task. 138 :ref:`ref-tasks-testimage` task.
139 139
140- *Layer Testing:* The Autobuilder has the possibility to test whether 140- *Layer Testing:* The Autobuilder has the possibility to test whether
141 specific layers work with the test of the system. The layers tested 141 specific layers work with the test of the system. The layers tested
@@ -152,7 +152,7 @@ thefollowing types of tests:
152 152
153- *SDK Testing:* Image tests initiated through the following command: $ 153- *SDK Testing:* Image tests initiated through the following command: $
154 bitbake image -c testsdk The tests utilize the 154 bitbake image -c testsdk The tests utilize the
155 ```testsdk`` <&YOCTO_DOCS_REF_URL;#ref-classes-testsdk>`__ class and 155 :ref:`testsdk <ref-classes-testsdk>` class and
156 the ``do_testsdk`` task. 156 the ``do_testsdk`` task.
157 157
158- *Unit Testing:* Unit tests on various components of the system run 158- *Unit Testing:* Unit tests on various components of the system run
@@ -236,7 +236,7 @@ Tests map into the codebase as follows:
236 ``meta/lib/oeqa/runtime/cases/``. 236 ``meta/lib/oeqa/runtime/cases/``.
237 237
238 - You need to set the 238 - You need to set the
239 ```IMAGE_CLASSES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_CLASSES>`__ 239 :term:`IMAGE_CLASSES`
240 variable as follows: IMAGE_CLASSES += "testimage" 240 variable as follows: IMAGE_CLASSES += "testimage"
241 241
242 - Run the tests using the following command form: $ bitbake image -c 242 - Run the tests using the following command form: $ bitbake image -c
diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst
index 47d08a157e..c98a27eeb8 100644
--- a/documentation/toaster-manual/toaster-manual-reference.rst
+++ b/documentation/toaster-manual/toaster-manual-reference.rst
@@ -244,7 +244,7 @@ Defining the Default Distro and Other Values
244This section defines the default distro value for new projects. By 244This section defines the default distro value for new projects. By
245default, it reserves the first Toaster Setting record "1". The following 245default, it reserves the first Toaster Setting record "1". The following
246demonstrates how to set the project default value for 246demonstrates how to set the project default value for
247```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__: <!-- Set the project 247:term:`DISTRO`: <!-- Set the project
248default value for DISTRO --> <object model="orm.toastersetting" pk="1"> 248default value for DISTRO --> <object model="orm.toastersetting" pk="1">
249<field type="CharField" name="name">DEFCONF_DISTRO</field> <field 249<field type="CharField" name="name">DEFCONF_DISTRO</field> <field
250type="CharField" name="value">poky</field> </object> You can override 250type="CharField" name="value">poky</field> </object> You can override
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
index d621e241e9..7e715403d0 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
@@ -132,7 +132,7 @@ superuser by following these steps:
132 command: $ export PATH=$PATH:$HOME/.local/bin 132 command: $ export PATH=$PATH:$HOME/.local/bin
133 133
1342. From the directory containing the Toaster database, which by default 1342. From the directory containing the Toaster database, which by default
135 is the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, 135 is the :term:`Build Directory`,
136 invoke the ``createsuperuser`` command from ``manage.py``: $ cd 136 invoke the ``createsuperuser`` command from ``manage.py``: $ cd
137 ~/poky/build $ ../bitbake/lib/toaster/manage.py createsuperuser 137 ~/poky/build $ ../bitbake/lib/toaster/manage.py createsuperuser
138 138
@@ -482,7 +482,7 @@ For the ``bash`` case, version 4.3.30-r0 is built by default.
482Unfortunately, Toaster as it exists, is not able to override the default 482Unfortunately, Toaster as it exists, is not able to override the default
483recipe version. If you would like to build bash 3.2.48, you need to set 483recipe version. If you would like to build bash 3.2.48, you need to set
484the 484the
485```PREFERRED_VERSION`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION>`__ 485:term:`PREFERRED_VERSION`
486variable. You can do so from Toaster, using the "Add variable" form, 486variable. You can do so from Toaster, using the "Add variable" form,
487which is available in the "BitBake variables" page of the project 487which is available in the "BitBake variables" page of the project
488configuration section as shown in the following screen: 488configuration section as shown in the following screen: