1 files changed, 3292 insertions, 2329 deletions

diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 54a892576b..625a37c158 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -21,74 +21,86 @@ system and gives an overview of their function and contents.
    ABIEXTENSION
       Extension to the Application Binary Interface (ABI) field of the GNU
       canonical architecture name (e.g. "eabi").
-   
+
       ABI extensions are set in the machine include files. For example, the
       ``meta/conf/machine/include/arm/arch-arm.inc`` file sets the
-      following extension: ABIEXTENSION = "eabi"
-   
+      following extension:
+      ::
+
+         ABIEXTENSION = "eabi"
+
    ALLOW_EMPTY
       Specifies whether to produce an output package even if it is empty.
       By default, BitBake does not produce empty packages. This default
       behavior can cause issues when there is an
       :term:`RDEPENDS` or some other hard runtime
       requirement on the existence of the package.
-   
+
       Like all package-controlling variables, you must always use them in
-      conjunction with a package name override, as in: ALLOW_EMPTY_${PN} =
-      "1" ALLOW_EMPTY_${PN}-dev = "1" ALLOW_EMPTY_${PN}-staticdev = "1"
-   
+      conjunction with a package name override, as in:
+      ::
+
+         ALLOW_EMPTY_${PN} = "1"
+         ALLOW_EMPTY_${PN}-dev = "1"
+         ALLOW_EMPTY_${PN}-staticdev = "1"
+
    ALTERNATIVE
       Lists commands in a package that need an alternative binary naming
       scheme. Sometimes the same command is provided in multiple packages.
       When this occurs, the OpenEmbedded build system needs to use the
       alternatives system to create a different binary naming scheme so the
       commands can co-exist.
-   
+
       To use the variable, list out the package's commands that also exist
       as part of another package. For example, if the ``busybox`` package
       has four commands that also exist as part of another package, you
-      identify them as follows: ALTERNATIVE_busybox = "sh sed test bracket"
+      identify them as follows:
+      ::
+
+         ALTERNATIVE_busybox = "sh sed test bracket"
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    ALTERNATIVE_LINK_NAME
       Used by the alternatives system to map duplicated commands to actual
       locations. For example, if the ``bracket`` command provided by the
       ``busybox`` package is duplicated through another package, you must
       use the ``ALTERNATIVE_LINK_NAME`` variable to specify the actual
-      location: ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
-   
+      location:
+      ::
+
+         ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
+
       In this example, the binary for the ``bracket`` command (i.e. ``[``)
       from the ``busybox`` package resides in ``/usr/bin/``.
-   
+
       .. note::
-   
-         If
-         ALTERNATIVE_LINK_NAME
-         is not defined, it defaults to
-         ${bindir}/
-         name
-         .
-   
+
+         If ALTERNATIVE_LINK_NAME is not defined, it defaults to ${bindir}/ name.
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    ALTERNATIVE_PRIORITY
       Used by the alternatives system to create default priorities for
       duplicated commands. You can use the variable to create a single
       default regardless of the command name or package, a default for
       specific duplicated commands regardless of the package, or a default
       for specific commands tied to particular packages. Here are the
-      available syntax forms: ALTERNATIVE_PRIORITY = "priority"
-      ALTERNATIVE_PRIORITY[name] = "priority"
-      ALTERNATIVE_PRIORITY_pkg[name] = "priority"
-   
+      available syntax forms:
+      ::
+
+         ALTERNATIVE_PRIORITY = "priority"
+         ALTERNATIVE_PRIORITY[name] = "priority"
+         ALTERNATIVE_PRIORITY_pkg[name] = "priority"
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    ALTERNATIVE_TARGET
       Used by the alternatives system to create default link locations for
       duplicated commands. You can use the variable to create a single
@@ -96,105 +108,115 @@ system and gives an overview of their function and contents.
       command name or package, a default for specific duplicated commands
       regardless of the package, or a default for specific commands tied to
       particular packages. Here are the available syntax forms:
-      ALTERNATIVE_TARGET = "target" ALTERNATIVE_TARGET[name] = "target"
-      ALTERNATIVE_TARGET_pkg[name] = "target"
-   
+      ::
+
+         ALTERNATIVE_TARGET = "target"
+         ALTERNATIVE_TARGET[name] = "target"
+         ALTERNATIVE_TARGET_pkg[name] = "target"
+
       .. note::
-   
+
          If ``ALTERNATIVE_TARGET`` is not defined, it inherits the value
-         from the
-         :term:`ALTERNATIVE_LINK_NAME`
-         variable.
-   
+         from the :term:`ALTERNATIVE_LINK_NAME` variable.
+
          If ``ALTERNATIVE_LINK_NAME`` and ``ALTERNATIVE_TARGET`` are the
          same, the target for ``ALTERNATIVE_TARGET`` has "``.{BPN}``"
          appended to it.
-   
+
          Finally, if the file referenced has not been renamed, the
          alternatives system will rename it to avoid the need to rename
          alternative files in the :ref:`ref-tasks-install`
          task while retaining support for the command if necessary.
-   
+
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
-   
+
    APPEND
       An override list of append strings for each target specified with
       :term:`LABELS`.
-   
+
       See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
       information on how this variable is used.
-   
+
    AR
       The minimal command and arguments used to run ``ar``.
-   
+
    ARCHIVER_MODE
       When used with the :ref:`archiver <ref-classes-archiver>` class,
       determines the type of information used to create a released archive.
       You can use this variable to create archives of patched source,
       original source, configured source, and so forth by employing the
-      following variable flags (varflags): ARCHIVER_MODE[src] = "original"
-      # Uses original (unpacked) source # files. ARCHIVER_MODE[src] =
-      "patched" # Uses patched source files. This is # the default.
-      ARCHIVER_MODE[src] = "configured" # Uses configured source files.
-      ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and #
-      do_patch. ARCHIVER_MODE[diff-exclude] ?= "file file ..." # Lists
-      files and directories to # exclude from diff. ARCHIVER_MODE[dumpdata]
-      = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses
-      recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM
-      package files. For information on how the variable works, see the
+      following variable flags (varflags):
+      ::
+
+         ARCHIVER_MODE[src] = "original"                   # Uses original (unpacked) source files.
+         ARCHIVER_MODE[src] = "patched"                    # Uses patched source files. This is the default.
+         ARCHIVER_MODE[src] = "configured"                 # Uses configured source files.
+         ARCHIVER_MODE[diff] = "1"                         # Uses patches between do_unpack and do_patch.
+         ARCHIVER_MODE[diff-exclude] ?= "file file ..."    # Lists files and directories to exclude from diff.
+         ARCHIVER_MODE[dumpdata] = "1"                     # Uses environment data.
+         ARCHIVER_MODE[recipe] = "1"                       # Uses recipe and include files.
+         ARCHIVER_MODE[srpm] = "1"                         # Uses RPM package files.
+
+      For information on how the variable works, see the
       ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
-   
+
    AS
       Minimal command and arguments needed to run the assembler.
-   
+
    ASSUME_PROVIDED
       Lists recipe names (:term:`PN` values) BitBake does not
       attempt to build. Instead, BitBake assumes these recipes have already
       been built.
-   
+
       In OpenEmbedded-Core, ``ASSUME_PROVIDED`` mostly specifies native
       tools that should not be built. An example is ``git-native``, which
       when specified, allows for the Git binary from the host to be used
       rather than building ``git-native``.
-   
+
    ASSUME_SHLIBS
       Provides additional ``shlibs`` provider mapping information, which
       adds to or overwrites the information provided automatically by the
       system. Separate multiple entries using spaces.
-   
+
       As an example, use the following form to add an ``shlib`` provider of
       shlibname in packagename with the optional version:
-      shlibname:packagename[_version]
-   
+      ::
+
+         shlibname:packagename[_version]
+
       Here is an example that adds a shared library named ``libEGL.so.1``
       as being provided by the ``libegl-implementation`` package:
-      ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
-   
+      ::
+
+         ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
+
    AUTHOR
       The email address used to contact the original author or authors in
       order to send patches and forward bugs.
-   
+
    AUTO_LIBNAME_PKGS
       When the :ref:`debian <ref-classes-debian>` class is inherited,
       which is the default behavior, ``AUTO_LIBNAME_PKGS`` specifies which
       packages should be checked for libraries and renamed according to
       Debian library package naming.
-   
+
       The default value is "${PACKAGES}", which causes the debian class to
       act on all packages that are explicitly generated by the recipe.
-   
+
    AUTO_SYSLINUXMENU
       Enables creating an automatic menu for the syslinux bootloader. You
       must set this variable in your recipe. The
       :ref:`syslinux <ref-classes-syslinux>` class checks this variable.
-   
+
    AUTOREV
       When ``SRCREV`` is set to the value of this variable, it specifies to
       use the latest source revision in the repository. Here is an example:
-      SRCREV = "${AUTOREV}"
-   
+      ::
+
+         SRCREV = "${AUTOREV}"
+
       If you use the previous statement to retrieve the latest version of
       software, you need to be sure :term:`PV` contains
       ``${``\ :term:`SRCPV`\ ``}``. For example, suppose you
@@ -203,19 +225,18 @@ system and gives an overview of their function and contents.
       statement. In this example, ``${SRCPV}`` does not automatically get
       into ``PV``. Consequently, you need to change ``PV`` in your recipe
       so that it does contain ``${SRCPV}``.
-   
-      For more information see the "`Automatically Incrementing a Binary
-      Package Revision
-      Number <&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number>`__"
+
+      For more information see the
+      ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    AVAILABLE_LICENSES
       List of licenses found in the directories specified by
       :term:`COMMON_LICENSE_DIR` and
       :term:`LICENSE_PATH`.
-   
+
       .. note::
-   
+
          It is assumed that all changes to
          COMMON_LICENSE_DIR
          and
@@ -225,106 +246,113 @@ system and gives an overview of their function and contents.
          is defined (in
          license.bbclass
          ).
-   
+
    AVAILTUNES
       The list of defined CPU and Application Binary Interface (ABI)
       tunings (i.e. "tunes") available for use by the OpenEmbedded build
       system.
-   
+
       The list simply presents the tunes that are available. Not all tunes
       may be compatible with a particular machine configuration, or with
       each other in a
-      `Multilib <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__
+      :ref:`Multilib <dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image>`
       configuration.
-   
+
       To add a tune to the list, be sure to append it with spaces using the
       "+=" BitBake operator. Do not simply replace the list by using the
       "=" operator. See the
       ":ref:`Basic Syntax <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax>`" section in the BitBake
       User Manual for more information.
-   
+
    B
       The directory within the :term:`Build Directory` in
       which the OpenEmbedded build system places generated objects during a
       recipe's build process. By default, this directory is the same as the
-      :term:`S` directory, which is defined as: S =
-      "${WORKDIR}/${BP}"
-   
+      :term:`S` directory, which is defined as:
+      ::
+
+         S = "${WORKDIR}/${BP}"
+
       You can separate the (``S``) directory and the directory pointed to
       by the ``B`` variable. Most Autotools-based recipes support
       separating these directories. The build system defaults to using
       separate directories for ``gcc`` and some kernel recipes.
-   
+
    BAD_RECOMMENDATIONS
       Lists "recommended-only" packages to not install. Recommended-only
       packages are packages installed only through the
       :term:`RRECOMMENDS` variable. You can prevent any
       of these "recommended" packages from being installed by listing them
-      with the ``BAD_RECOMMENDATIONS`` variable: BAD_RECOMMENDATIONS =
-      "package_name package_name package_name ..."
-   
+      with the ``BAD_RECOMMENDATIONS`` variable:
+      ::
+
+         BAD_RECOMMENDATIONS = "package_name package_name package_name ..."
+
       You can set this variable globally in your ``local.conf`` file or you
       can attach it to a specific image recipe by using the recipe name
-      override: BAD_RECOMMENDATIONS_pn-target_image = "package_name"
-   
+      override:
+      ::
+
+         BAD_RECOMMENDATIONS_pn-target_image = "package_name"
+
       It is important to realize that if you choose to not install packages
       using this variable and some other packages are dependent on them
       (i.e. listed in a recipe's :term:`RDEPENDS`
       variable), the OpenEmbedded build system ignores your request and
       will install the packages to avoid dependency errors.
-   
+
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
-   
+
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`PACKAGE_EXCLUDE` variables for related
       information.
-   
+
    BASE_LIB
       The library directory name for the CPU or Application Binary
       Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib
-      context. See the "`Combining Multiple Versions of Library Files into
-      One
-      Image <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__"
+      context. See the ":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`"
       section in the Yocto Project Development Tasks Manual for information
       on Multilib.
-   
+
       The ``BASE_LIB`` variable is defined in the machine include files in
       the :term:`Source Directory`. If Multilib is not
       being used, the value defaults to "lib".
-   
+
    BASE_WORKDIR
       Points to the base of the work directory for all recipes. The default
       value is "${TMPDIR}/work".
-   
+
    BB_ALLOWED_NETWORKS
       Specifies a space-delimited list of hosts that the fetcher is allowed
       to use to obtain the required source code. Following are
       considerations surrounding this variable:
-   
+
       -  This host list is only used if ``BB_NO_NETWORK`` is either not set
          or set to "0".
-   
+
       -  Limited support for wildcard matching against the beginning of
          host names exists. For example, the following setting matches
          ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``.
-         BB_ALLOWED_NETWORKS = "*.gnu.org"
-   
+         ::
+
+            BB_ALLOWED_NETWORKS = "*.gnu.org"
+
          .. note::
-   
+
             The use of the "``*``" character only works at the beginning of
             a host name and it must be isolated from the remainder of the
             host name. You cannot use the wildcard character in any other
             location of the name or combined with the front part of the
             name.
-   
+
             For example, ``*.foo.bar`` is supported, while ``*aa.foo.bar``
             is not.
-   
+
       -  Mirrors not in the host list are skipped and logged in debug.
-   
+
       -  Attempts to access networks not in the host list cause a failure.
-   
+
       Using ``BB_ALLOWED_NETWORKS`` in conjunction with
       :term:`PREMIRRORS` is very useful. Adding the host
       you want to use to ``PREMIRRORS`` results in the source code being
@@ -333,7 +361,7 @@ system and gives an overview of their function and contents.
       statement. This is because the fetcher does not attempt to use the
       host listed in ``SRC_URI`` after a successful fetch from the
       ``PREMIRRORS`` occurs.
-   
+
    BB_DANGLINGAPPENDS_WARNONLY
       Defines how BitBake handles situations where an append file
       (``.bbappend``) has no corresponding recipe file (``.bb``). This
@@ -341,42 +369,69 @@ system and gives an overview of their function and contents.
       bumps a recipe version and the old recipe no longer exists and the
       other layer has not been updated to the new version of the recipe
       yet).
-   
+
       The default fatal behavior is safest because it is the sane reaction
       given something is out of sync. It is important to realize when your
       changes are no longer being applied.
-   
+
       You can change the default behavior by setting this variable to "1",
       "yes", or "true" in your ``local.conf`` file, which is located in the
       :term:`Build Directory`: Here is an example:
-      BB_DANGLINGAPPENDS_WARNONLY = "1"
-   
+      ::
+
+         BB_DANGLINGAPPENDS_WARNONLY = "1"
+
    BB_DISKMON_DIRS
       Monitors disk space and available inodes during the build and allows
       you to control the build based on these parameters.
-   
+
       Disk space monitoring is disabled by default. To enable monitoring,
       add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file
       found in the :term:`Build Directory`. Use the
-      following form: BB_DISKMON_DIRS = "action,dir,threshold [...]" where:
-      action is: ABORT: Immediately abort the build when a threshold is
-      broken. STOPTASKS: Stop the build after the currently executing tasks
-      have finished when a threshold is broken. WARN: Issue a warning but
-      continue the build when a threshold is broken. Subsequent warnings
-      are issued as defined by the BB_DISKMON_WARNINTERVAL variable, which
-      must be defined in the conf/local.conf file. dir is: Any directory
-      you choose. You can specify one or more directories to monitor by
-      separating the groupings with a space. If two directories are on the
-      same device, only the first directory is monitored. threshold is:
-      Either the minimum available disk space, the minimum number of free
-      inodes, or both. You must specify at least one. To omit one or the
-      other, simply omit the value. Specify the threshold using G, M, K for
-      Gbytes, Mbytes, and Kbytes, respectively. If you do not specify G, M,
-      or K, Kbytes is assumed by default. Do not use GB, MB, or KB.
-   
-      Here are some examples: BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K
-      WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS =
-      "STOPTASKS,${TMPDIR},1G" BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+      following form:
+      ::
+
+         BB_DISKMON_DIRS = "action,dir,threshold [...]"
+
+         where:
+
+            action is:
+               ABORT:     Immediately abort the build when
+                          a threshold is broken.
+               STOPTASKS: Stop the build after the currently
+                          executing tasks have finished when
+                          a threshold is broken.
+               WARN:      Issue a warning but continue the
+                          build when a threshold is broken.
+                          Subsequent warnings are issued as
+                          defined by the BB_DISKMON_WARNINTERVAL
+                          variable, which must be defined in
+                          the conf/local.conf file.
+
+            dir is:
+               Any directory you choose. You can specify one or
+               more directories to monitor by separating the
+               groupings with a space.  If two directories are
+               on the same device, only the first directory
+               is monitored.
+
+            threshold is:
+               Either the minimum available disk space,
+               the minimum number of free inodes, or
+               both.  You must specify at least one.  To
+               omit one or the other, simply omit the value.
+               Specify the threshold using G, M, K for Gbytes,
+               Mbytes, and Kbytes, respectively. If you do
+               not specify G, M, or K, Kbytes is assumed by
+               default.  Do not use GB, MB, or KB.
+
+      Here are some examples:
+      ::
+
+         BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
+         BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
+         BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+
       The first example works only if you also provide the
       :term:`BB_DISKMON_WARNINTERVAL`
       variable in the ``conf/local.conf``. This example causes the build
@@ -388,64 +443,85 @@ system and gives an overview of their function and contents.
       of free inodes drops below 100 Kbytes. Subsequent warnings are issued
       during intervals as defined by the ``BB_DISKMON_WARNINTERVAL``
       variable.
-   
+
       The second example stops the build after all currently executing
       tasks complete when the minimum disk space in the ``${TMPDIR}``
       directory drops below 1 Gbyte. No disk monitoring occurs for the free
       inodes in this case.
-   
+
       The final example immediately aborts the build when the number of
       free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
       disk space monitoring for the directory itself occurs in this case.
-   
+
    BB_DISKMON_WARNINTERVAL
       Defines the disk space and free inode warning intervals. To set these
       intervals, define the variable in your ``conf/local.conf`` file in
       the :term:`Build Directory`.
-   
+
       If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you
       must also use the :term:`BB_DISKMON_DIRS`
       variable and define its action as "WARN". During the build,
       subsequent warnings are issued each time disk space or number of free
       inodes further reduces by the respective interval.
-   
+
       If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you
       do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk
       monitoring interval defaults to the following:
-      BB_DISKMON_WARNINTERVAL = "50M,5K"
-   
+      ::
+
+         BB_DISKMON_WARNINTERVAL = "50M,5K"
+
       When specifying the variable in your configuration file, use the
-      following form: BB_DISKMON_WARNINTERVAL =
-      "disk_space_interval,disk_inode_interval" where: disk_space_interval
-      is: An interval of memory expressed in either G, M, or K for Gbytes,
-      Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB.
-      disk_inode_interval is: An interval of free inodes expressed in
-      either G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You
-      cannot use GB, MB, or KB.
-   
-      Here is an example: BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
-      BB_DISKMON_WARNINTERVAL = "50M,5K" These variables cause the
+      following form:
+      ::
+
+         BB_DISKMON_WARNINTERVAL = "disk_space_interval,disk_inode_interval"
+
+         where:
+
+            disk_space_interval is:
+               An interval of memory expressed in either
+               G, M, or K for Gbytes, Mbytes, or Kbytes,
+               respectively. You cannot use GB, MB, or KB.
+
+            disk_inode_interval is:
+               An interval of free inodes expressed in either
+               G, M, or K for Gbytes, Mbytes, or Kbytes,
+               respectively. You cannot use GB, MB, or KB.
+
+      Here is an example:
+      ::
+
+         BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
+         BB_DISKMON_WARNINTERVAL = "50M,5K"
+
+      These variables cause the
       OpenEmbedded build system to issue subsequent warnings each time the
       available disk space further reduces by 50 Mbytes or the number of
       free inodes further reduces by 5 Kbytes in the ``${SSTATE_DIR}``
       directory. Subsequent warnings based on the interval occur each time
       a respective interval is reached beyond the initial warning (i.e. 1
       Gbytes and 100 Kbytes).
-   
+
    BB_GENERATE_MIRROR_TARBALLS
       Causes tarballs of the source control repositories (e.g. Git
       repositories), including metadata, to be placed in the
       :term:`DL_DIR` directory.
-   
+
       For performance reasons, creating and placing tarballs of these
       repositories is not the default action by the OpenEmbedded build
-      system. BB_GENERATE_MIRROR_TARBALLS = "1" Set this variable in your
+      system.
+      ::
+
+         BB_GENERATE_MIRROR_TARBALLS = "1"
+
+      Set this variable in your
       ``local.conf`` file in the :term:`Build Directory`.
-   
+
       Once you have the tarballs containing your source files, you can
       clean up your ``DL_DIR`` directory by deleting any Git or other
       source control work directories.
-   
+
    BB_NUMBER_THREADS
       The maximum number of tasks BitBake should run in parallel at any one
       time. The OpenEmbedded build system automatically configures this
@@ -453,27 +529,31 @@ system and gives an overview of their function and contents.
       example, a system with a dual core processor that also uses
       hyper-threading causes the ``BB_NUMBER_THREADS`` variable to default
       to "4".
-   
+
       For single socket systems (i.e. one CPU), you should not have to
       override this variable to gain optimal parallelism during builds.
       However, if you have very large systems that employ multiple physical
       CPUs, you might want to make sure the ``BB_NUMBER_THREADS`` variable
       is not set higher than "20".
-   
-      For more information on speeding up builds, see the "`Speeding Up a
-      Build <&YOCTO_DOCS_DEV_URL;#speeding-up-a-build>`__" section in the
-      Yocto Project Development Tasks Manual.
-   
+
+      For more information on speeding up builds, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+      section in the Yocto Project Development Tasks Manual.
+
    BB_SERVER_TIMEOUT
       Specifies the time (in seconds) after which to unload the BitBake
       server due to inactivity. Set ``BB_SERVER_TIMEOUT`` to determine how
       long the BitBake server stays resident between invocations.
-   
+
       For example, the following statement in your ``local.conf`` file
       instructs the server to be unloaded after 20 seconds of inactivity:
-      BB_SERVER_TIMEOUT = "20" If you want the server to never be unloaded,
+      ::
+
+         BB_SERVER_TIMEOUT = "20"
+
+      If you want the server to never be unloaded,
       set ``BB_SERVER_TIMEOUT`` to "-1".
-   
+
    BBCLASSEXTEND
       Allows you to extend a recipe so that it builds variants of the
       software. Common variants for recipes exist such as "natives" like
@@ -483,40 +563,42 @@ system and gives an overview of their function and contents.
       :term:`MACHINE`; "nativesdk", which targets the SDK
       machine instead of ``MACHINE``; and "mulitlibs" in the form
       "``multilib:``\ multilib_name".
-   
+
       To build a different variant of the recipe with a minimal amount of
       code, it usually is as simple as adding the following to your recipe:
-      BBCLASSEXTEND =+ "native nativesdk" BBCLASSEXTEND =+
-      "multilib:multilib_name"
-   
+      ::
+
+         BBCLASSEXTEND =+ "native nativesdk"
+         BBCLASSEXTEND =+ "multilib:multilib_name"
+
       .. note::
-   
+
          Internally, the ``BBCLASSEXTEND`` mechanism generates recipe
          variants by rewriting variable values and applying overrides such
          as ``_class-native``. For example, to generate a native version of
          a recipe, a :term:`DEPENDS` on "foo" is rewritten
          to a ``DEPENDS`` on "foo-native".
-   
+
          Even when using ``BBCLASSEXTEND``, the recipe is only parsed once.
          Parsing once adds some limitations. For example, it is not
          possible to include a different file depending on the variant,
          since ``include`` statements are processed when the recipe is
          parsed.
-   
+
    BBFILE_COLLECTIONS
       Lists the names of configured layers. These names are used to find
       the other ``BBFILE_*`` variables. Typically, each layer will append
       its name to this variable in its ``conf/layer.conf`` file.
-   
+
    BBFILE_PATTERN
       Variable that expands to match files from
       :term:`BBFILES` in a particular layer. This variable
       is used in the ``conf/layer.conf`` file and must be suffixed with the
       name of the specific layer (e.g. ``BBFILE_PATTERN_emenlow``).
-   
+
    BBFILE_PRIORITY
       Assigns the priority for recipe files in each layer.
-   
+
       This variable is useful in situations where the same recipe appears
       in more than one layer. Setting this variable allows you to
       prioritize a layer against other layers that contain the same recipe
@@ -526,7 +608,7 @@ system and gives an overview of their function and contents.
       example, a layer that has a recipe with a higher ``PV`` value but for
       which the ``BBFILE_PRIORITY`` is set to have a lower precedence still
       has a lower precedence.
-   
+
       A larger value for the ``BBFILE_PRIORITY`` variable results in a
       higher precedence. For example, the value 6 has a higher precedence
       than the value 5. If not specified, the ``BBFILE_PRIORITY`` variable
@@ -534,116 +616,136 @@ system and gives an overview of their function and contents.
       for more information. The default priority, if unspecified for a
       layer with no dependencies, is the lowest defined priority + 1 (or 1
       if no priorities are defined).
-   
+
       .. tip::
-   
+
          You can use the command
          bitbake-layers show-layers
          to list all configured layers along with their priorities.
-   
+
    BBFILES
       A space-separated list of recipe files BitBake uses to build
       software.
-   
+
       When specifying recipe files, you can pattern match using Python's
-      ```glob`https://docs.python.org/3/library/glob.html syntax.
+      `glob <https://docs.python.org/3/library/glob.html>`_ syntax.
       For details on the syntax, see the documentation by following the
       previous link.
-   
+
    BBFILES_DYNAMIC
       Activates content when identified layers are present. You identify
       the layers by the collections that the layers define.
-   
+
       Use the ``BBFILES_DYNAMIC`` variable to avoid ``.bbappend`` files
       whose corresponding ``.bb`` file is in a layer that attempts to
       modify other layers through ``.bbappend`` but does not want to
       introduce a hard dependency on those other layers.
-   
+
       Use the following form for ``BBFILES_DYNAMIC``:
       collection_name:filename_pattern The following example identifies two
-      collection names and two filename patterns: BBFILES_DYNAMIC += " \\
-      clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \\
-      core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \\ "
+      collection names and two filename patterns:
+      ::
+
+         BBFILES_DYNAMIC += " \
+            clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
+            core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
+            "
+
       This next example shows an error message that occurs because invalid
-      entries are found, which cause parsing to abort: ERROR:
-      BBFILES_DYNAMIC entries must be of the form <collection
-      name>:<filename pattern>, not:
-      /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
-      /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
-   
+      entries are found, which cause parsing to abort:
+      ::
+
+         ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
+             /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
+             /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
+
    BBINCLUDELOGS
       Variable that controls how BitBake displays logs on build failure.
-   
+
    BBINCLUDELOGS_LINES
       If :term:`BBINCLUDELOGS` is set, specifies the
       maximum number of lines from the task log file to print when
       reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``,
       the entire log is printed.
-   
+
    BBLAYERS
       Lists the layers to enable during the build. This variable is defined
       in the ``bblayers.conf`` configuration file in the :term:`Build Directory`.
-      Here is an example: BBLAYERS = " \\
-      /home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\
-      /home/scottrif/poky/meta-yocto-bsp \\
-      /home/scottrif/poky/meta-mykernel \\ "
-   
+      Here is an example:
+      ::
+
+         BBLAYERS = " \
+             /home/scottrif/poky/meta \ /home/scottrif/poky/meta-poky \
+             /home/scottrif/poky/meta-yocto-bsp \
+             /home/scottrif/poky/meta-mykernel \
+             "
+
       This example enables four layers, one of which is a custom,
       user-defined layer named ``meta-mykernel``.
-   
+
    BBMASK
       Prevents BitBake from processing recipes and recipe append files.
-   
+
       You can use the ``BBMASK`` variable to "hide" these ``.bb`` and
       ``.bbappend`` files. BitBake ignores any recipe or recipe append
       files that match any of the expressions. It is as if BitBake does not
       see them at all. Consequently, matching files are not parsed or
       otherwise used by BitBake.
-   
+
       The values you provide are passed to Python's regular expression
       compiler. Consequently, the syntax follows Python's Regular
       Expression (re) syntax. The expressions are compared against the full
       paths to the files. For complete syntax information, see Python's
       documentation at http://docs.python.org/3/library/re.html#re.
-   
+
       The following example uses a complete regular expression to tell
       BitBake to ignore all recipe and recipe append files in the
-      ``meta-ti/recipes-misc/`` directory: BBMASK = "meta-ti/recipes-misc/"
+      ``meta-ti/recipes-misc/`` directory:
+      ::
+
+         BBMASK = "meta-ti/recipes-misc/"
+
       If you want to mask out multiple directories or recipes, you can
       specify multiple regular expression fragments. This next example
-      masks out multiple directories and individual recipes: BBMASK +=
-      "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" BBMASK +=
-      "/meta-oe/recipes-support/" BBMASK += "/meta-foo/.*/openldap" BBMASK
-      += "opencv.*\.bbappend" BBMASK += "lzma"
-   
+      masks out multiple directories and individual recipes: ::
+
+         BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
+         BBMASK += "/meta-oe/recipes-support/"
+         BBMASK += "/meta-foo/.*/openldap"
+         BBMASK += "opencv.*\.bbappend"
+         BBMASK += "lzma"
+
       .. note::
-   
+
          When specifying a directory name, use the trailing slash character
          to ensure you match just that directory name.
-   
+
    BBMULTICONFIG
       Specifies each additional separate configuration when you are
       building targets with multiple configurations. Use this variable in
       your ``conf/local.conf`` configuration file. Specify a
       multiconfigname for each configuration file you are using. For
       example, the following line specifies three configuration files:
-      BBMULTICONFIG = "configA configB configC" Each configuration file you
+      ::
+
+         BBMULTICONFIG = "configA configB configC"
+
+      Each configuration file you
       use must reside in the :term:`Build Directory`
       ``conf/multiconfig`` directory (e.g.
       build_directory\ ``/conf/multiconfig/configA.conf``).
-   
+
       For information on how to use ``BBMULTICONFIG`` in an environment
       that supports building targets with multiple configurations, see the
-      "`Building Images for Multiple Targets Using Multiple
-      Configurations <&YOCTO_DOCS_DEV_URL;#dev-building-images-for-multiple-targets-using-multiple-configurations>`__"
+      ":ref:`dev-building-images-for-multiple-targets-using-multiple-configurations`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    BBPATH
       Used by BitBake to locate ``.bbclass`` and configuration files. This
       variable is analogous to the ``PATH`` variable.
-   
+
       .. note::
-   
+
          If you run BitBake from a directory outside of the
          Build Directory
          , you must be sure to set
@@ -651,24 +753,27 @@ system and gives an overview of their function and contents.
          to point to the Build Directory. Set the variable as you would any
          environment variable and then run BitBake:
          ::
-   
+
                  $ BBPATH = "build_directory"
                  $ export BBPATH
                  $ bitbake target
-                                    
-   
+
+
    BBSERVER
       If defined in the BitBake environment, ``BBSERVER`` points to the
       BitBake remote server.
-   
+
       Use the following format to export the variable to the BitBake
-      environment: export BBSERVER=localhost:$port
-   
+      environment:
+      ::
+
+         export BBSERVER=localhost:$port
+
       By default, ``BBSERVER`` also appears in
       :term:`bitbake:BB_HASHBASE_WHITELIST`.
       Consequently, ``BBSERVER`` is excluded from checksum and dependency
       data.
-   
+
    BINCONFIG
       When inheriting the
       :ref:`binconfig-disabled <ref-classes-binconfig-disabled>` class,
@@ -677,11 +782,13 @@ system and gives an overview of their function and contents.
       ``binconfig-disabled`` class will modify the specified scripts to
       return an error so that calls to them can be easily found and
       replaced.
-   
+
       To add multiple scripts, separate them by spaces. Here is an example
-      from the ``libpng`` recipe: BINCONFIG = "${bindir}/libpng-config
-      ${bindir}/libpng16-config"
-   
+      from the ``libpng`` recipe:
+      ::
+
+         BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"
+
    BINCONFIG_GLOB
       When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
       this variable specifies a wildcard for configuration scripts that
@@ -689,9 +796,9 @@ system and gives an overview of their function and contents.
       been set up during compilation so that they are correct for use when
       installed into the sysroot and called by the build processes of other
       recipes.
-   
+
       .. note::
-   
+
          The
          BINCONFIG_GLOB
          variable uses
@@ -702,18 +809,21 @@ system and gives an overview of their function and contents.
          and
          glob
          .
-   
+
       For more information on how this variable works, see
       ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
       You can also find general
       information on the class in the
       ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
-   
+
    BP
       The base recipe name and version but without any special recipe name
       suffix (i.e. ``-native``, ``lib64-``, and so forth). ``BP`` is
-      comprised of the following: ${BPN}-${PV}
-   
+      comprised of the following:
+      ::
+
+         ${BPN}-${PV}
+
    BPN
       This variable is a version of the :term:`PN` variable with
       common prefixes and suffixes removed, such as ``nativesdk-``,
@@ -722,115 +832,115 @@ system and gives an overview of their function and contents.
       :term:`MLPREFIX` and
       :term:`SPECIAL_PKGSUFFIX` variables,
       respectively.
-   
+
    BUGTRACKER
       Specifies a URL for an upstream bug tracking website for a recipe.
       The OpenEmbedded build system does not use this variable. Rather, the
       variable is a useful pointer in case a bug in the software being
       built needs to be manually reported.
-   
+
    BUILD_ARCH
       Specifies the architecture of the build host (e.g. ``i686``). The
       OpenEmbedded build system sets the value of ``BUILD_ARCH`` from the
       machine name reported by the ``uname`` command.
-   
+
    BUILD_AS_ARCH
       Specifies the architecture-specific assembler flags for the build
       host. By default, the value of ``BUILD_AS_ARCH`` is empty.
-   
+
    BUILD_CC_ARCH
       Specifies the architecture-specific C compiler flags for the build
       host. By default, the value of ``BUILD_CC_ARCH`` is empty.
-   
+
    BUILD_CCLD
       Specifies the linker command to be used for the build host when the C
       compiler is being used as the linker. By default, ``BUILD_CCLD``
       points to GCC and passes as arguments the value of
       :term:`BUILD_CC_ARCH`, assuming
       ``BUILD_CC_ARCH`` is set.
-   
+
    BUILD_CFLAGS
       Specifies the flags to pass to the C compiler when building for the
       build host. When building in the ``-native`` context,
       :term:`CFLAGS` is set to the value of this variable by
       default.
-   
+
    BUILD_CPPFLAGS
       Specifies the flags to pass to the C preprocessor (i.e. to both the C
       and the C++ compilers) when building for the build host. When
       building in the ``-native`` context, :term:`CPPFLAGS`
       is set to the value of this variable by default.
-   
+
    BUILD_CXXFLAGS
       Specifies the flags to pass to the C++ compiler when building for the
       build host. When building in the ``-native`` context,
       :term:`CXXFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILD_FC
       Specifies the Fortran compiler command for the build host. By
       default, ``BUILD_FC`` points to Gfortran and passes as arguments the
       value of :term:`BUILD_CC_ARCH`, assuming
       ``BUILD_CC_ARCH`` is set.
-   
+
    BUILD_LD
       Specifies the linker command for the build host. By default,
       ``BUILD_LD`` points to the GNU linker (ld) and passes as arguments
       the value of :term:`BUILD_LD_ARCH`, assuming
       ``BUILD_LD_ARCH`` is set.
-   
+
    BUILD_LD_ARCH
       Specifies architecture-specific linker flags for the build host. By
       default, the value of ``BUILD_LD_ARCH`` is empty.
-   
+
    BUILD_LDFLAGS
       Specifies the flags to pass to the linker when building for the build
       host. When building in the ``-native`` context,
       :term:`LDFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILD_OPTIMIZATION
       Specifies the optimization flags passed to the C compiler when
       building for the build host or the SDK. The flags are passed through
       the :term:`BUILD_CFLAGS` and
       :term:`BUILDSDK_CFLAGS` default values.
-   
+
       The default value of the ``BUILD_OPTIMIZATION`` variable is "-O2
       -pipe".
-   
+
    BUILD_OS
       Specifies the operating system in use on the build host (e.g.
       "linux"). The OpenEmbedded build system sets the value of
       ``BUILD_OS`` from the OS reported by the ``uname`` command - the
       first word, converted to lower-case characters.
-   
+
    BUILD_PREFIX
       The toolchain binary prefix used for native recipes. The OpenEmbedded
       build system uses the ``BUILD_PREFIX`` value to set the
       :term:`TARGET_PREFIX` when building for
       ``native`` recipes.
-   
+
    BUILD_STRIP
       Specifies the command to be used to strip debugging symbols from
       binaries produced for the build host. By default, ``BUILD_STRIP``
       points to
       ``${``\ :term:`BUILD_PREFIX`\ ``}strip``.
-   
+
    BUILD_SYS
       Specifies the system, including the architecture and the operating
       system, to use when building for the build host (i.e. when building
       ``native`` recipes).
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`BUILD_ARCH`,
       :term:`BUILD_VENDOR`, and
       :term:`BUILD_OS`. You do not need to set the
       ``BUILD_SYS`` variable yourself.
-   
+
    BUILD_VENDOR
       Specifies the vendor name to use when building for the build host.
       The default value is an empty string ("").
-   
+
    BUILDDIR
       Points to the location of the :term:`Build Directory`.
       You can define this directory indirectly through the
@@ -838,7 +948,7 @@ system and gives an overview of their function and contents.
       Directory path when you run the script. If you run the script and do
       not provide a Build Directory path, the ``BUILDDIR`` defaults to
       ``build`` in the current directory.
-   
+
    BUILDHISTORY_COMMIT
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies whether or not to commit the build
@@ -848,60 +958,70 @@ system and gives an overview of their function and contents.
       top-level subdirectory of the build history output (images, packages,
       and sdk). If you want to track changes to build history over time,
       you should set this value to "1".
-   
+
       By default, the ``buildhistory`` class does not commit the build
-      history output in a local Git repository: BUILDHISTORY_COMMIT ?= "0"
-   
+      history output in a local Git repository:
+      ::
+
+         BUILDHISTORY_COMMIT ?= "0"
+
    BUILDHISTORY_COMMIT_AUTHOR
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the author to use for each Git commit.
       In order for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable to work, the
       :term:`BUILDHISTORY_COMMIT` variable must
       be set to "1".
-   
+
       Git requires that the value you provide for the
       ``BUILDHISTORY_COMMIT_AUTHOR`` variable takes the form of "name
       email@host". Providing an email address or host that is not valid
       does not produce an error.
-   
+
       By default, the ``buildhistory`` class sets the variable as follows:
-      BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
-   
+      ::
+
+         BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
+
    BUILDHISTORY_DIR
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the directory in which build history
       information is kept. For more information on how the variable works,
       see the ``buildhistory.class``.
-   
+
       By default, the ``buildhistory`` class sets the directory as follows:
-      BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
-   
+      ::
+
+         BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
+
    BUILDHISTORY_FEATURES
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies the build history features to be
       enabled. For more information on how build history works, see the
-      "`Maintaining Build Output
-      Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
       section in the Yocto Project Development Tasks Manual.
-   
+
       You can specify these features in the form of a space-separated list:
-   
+
       -  *image:* Analysis of the contents of images, which includes the
          list of installed packages among other things.
-   
+
       -  *package:* Analysis of the contents of individual packages.
-   
+
       -  *sdk:* Analysis of the contents of the software development kit
          (SDK).
-   
-      -  *task:* Save output file signatures for `shared
-         state <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__ (sstate) tasks.
+
+      -  *task:* Save output file signatures for
+         :ref:`shared state <overview-manual/overview-manual-concepts:shared state cache>`
+         (sstate) tasks.
          This saves one file per task and lists the SHA-256 checksums for
          each file staged (i.e. the output of the task).
-   
+
       By default, the ``buildhistory`` class enables the following
-      features: BUILDHISTORY_FEATURES ?= "image package sdk"
-   
+      features:
+      ::
+
+         BUILDHISTORY_FEATURES ?= "image package sdk"
+
    BUILDHISTORY_IMAGE_FILES
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable specifies a list of paths to files copied from
@@ -912,10 +1032,13 @@ system and gives an overview of their function and contents.
       changes in user and group entries. You can modify the list to include
       any file. Specifying an invalid path does not produce an error.
       Consequently, you can include files that might not always be present.
-   
+
       By default, the ``buildhistory`` class provides paths to the
-      following files: BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
-   
+      following files:
+      ::
+
+         BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
+
    BUILDHISTORY_PUSH_REPO
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
       class, this variable optionally specifies a remote repository to
@@ -923,81 +1046,83 @@ system and gives an overview of their function and contents.
       ``BUILDHISTORY_PUSH_REPO`` to work,
       :term:`BUILDHISTORY_COMMIT` must be set to
       "1".
-   
+
       The repository should correspond to a remote address that specifies a
       repository as understood by Git, or alternatively to a remote name
       that you have set up manually using ``git remote`` within the local
       repository.
-   
+
       By default, the ``buildhistory`` class sets the variable as follows:
-      BUILDHISTORY_PUSH_REPO ?= ""
-   
+      ::
+
+         BUILDHISTORY_PUSH_REPO ?= ""
+
    BUILDSDK_CFLAGS
       Specifies the flags to pass to the C compiler when building for the
       SDK. When building in the ``nativesdk-`` context,
       :term:`CFLAGS` is set to the value of this variable by
       default.
-   
+
    BUILDSDK_CPPFLAGS
       Specifies the flags to pass to the C pre-processor (i.e. to both the
       C and the C++ compilers) when building for the SDK. When building in
       the ``nativesdk-`` context, :term:`CPPFLAGS` is set
       to the value of this variable by default.
-   
+
    BUILDSDK_CXXFLAGS
       Specifies the flags to pass to the C++ compiler when building for the
       SDK. When building in the ``nativesdk-`` context,
       :term:`CXXFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILDSDK_LDFLAGS
       Specifies the flags to pass to the linker when building for the SDK.
       When building in the ``nativesdk-`` context,
       :term:`LDFLAGS` is set to the value of this variable
       by default.
-   
+
    BUILDSTATS_BASE
       Points to the location of the directory that holds build statistics
       when you use and enable the
       :ref:`buildstats <ref-classes-buildstats>` class. The
       ``BUILDSTATS_BASE`` directory defaults to
       ``${``\ :term:`TMPDIR`\ ``}/buildstats/``.
-   
+
    BUSYBOX_SPLIT_SUID
       For the BusyBox recipe, specifies whether to split the output
       executable file into two parts: one for features that require
       ``setuid root``, and one for the remaining features (i.e. those that
       do not require ``setuid root``).
-   
+
       The ``BUSYBOX_SPLIT_SUID`` variable defaults to "1", which results in
       splitting the output executable file. Set the variable to "0" to get
       a single output executable file.
-   
+
    CACHE
       Specifies the directory BitBake uses to store a cache of the
       :term:`Metadata` so it does not need to be parsed every time
       BitBake is started.
-   
+
    CC
       The minimal command and arguments used to run the C compiler.
-   
+
    CFLAGS
       Specifies the flags to pass to the C compiler. This variable is
       exported to an environment variable and thus made visible to the
       software being built during the compilation step.
-   
+
       Default initialization for ``CFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_CFLAGS` when building for the
          target
-   
+
       -  :term:`BUILD_CFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_CFLAGS` when building for
          an SDK (i.e. ``nativesdk-``)
-   
+
    CLASSOVERRIDE
       An internal variable specifying the special class override that
       should currently apply (e.g. "class-target", "class-native", and so
@@ -1005,31 +1130,41 @@ system and gives an overview of their function and contents.
       :ref:`native <ref-classes-native>`,
       :ref:`nativesdk <ref-classes-nativesdk>`, and so forth) set the
       variable to appropriate values.
-   
+
       .. note::
-   
+
          CLASSOVERRIDE
          gets its default "class-target" value from the
          bitbake.conf
          file.
-   
+
       As an example, the following override allows you to install extra
       files, but only when building for the target:
-      do_install_append_class-target() { install my-extra-file
-      ${D}${sysconfdir} } Here is an example where ``FOO`` is set to
+      ::
+
+         do_install_append_class-target() {
+             install my-extra-file ${D}${sysconfdir}
+         }
+
+      Here is an example where ``FOO`` is set to
       "native" when building for the build host, and to "other" when not
-      building for the build host: FOO_class-native = "native" FOO =
-      "other" The underlying mechanism behind ``CLASSOVERRIDE`` is simply
+      building for the build host:
+      ::
+
+         FOO_class-native = "native"
+         FOO = "other"
+
+      The underlying mechanism behind ``CLASSOVERRIDE`` is simply
       that it is included in the default value of
       :term:`OVERRIDES`.
-   
+
    CLEANBROKEN
       If set to "1" within a recipe, ``CLEANBROKEN`` specifies that the
       ``make clean`` command does not work for the software being built.
       Consequently, the OpenEmbedded build system will not try to run
       ``make clean`` during the :ref:`ref-tasks-configure`
       task, which is the default behavior.
-   
+
    COMBINED_FEATURES
       Provides a list of hardware features that are enabled in both
       :term:`MACHINE_FEATURES` and
@@ -1039,12 +1174,12 @@ system and gives an overview of their function and contents.
       "bluetooth" feature requires hardware support but should also be
       optional at the distribution level, in case the hardware supports
       Bluetooth but you do not ever intend to use it.
-   
+
    COMMON_LICENSE_DIR
       Points to ``meta/files/common-licenses`` in the
       :term:`Source Directory`, which is where generic license
       files reside.
-   
+
    COMPATIBLE_HOST
       A regular expression that resolves to one or more hosts (when the
       recipe is native) or one or more targets (when the recipe is
@@ -1055,7 +1190,7 @@ system and gives an overview of their function and contents.
       particularly useful with kernels. The variable also helps to increase
       parsing speed since the build system skips parsing recipes not
       compatible with the current system.
-   
+
    COMPATIBLE_MACHINE
       A regular expression that resolves to one or more target machines
       with which a recipe is compatible. The regular expression is matched
@@ -1065,14 +1200,14 @@ system and gives an overview of their function and contents.
       useful with kernels. The variable also helps to increase parsing
       speed since the build system skips parsing recipes not compatible
       with the current machine.
-   
+
    COMPLEMENTARY_GLOB
       Defines wildcards to match when installing a list of complementary
       packages for all the packages explicitly (or implicitly) installed in
       an image.
-   
+
       .. note::
-   
+
          The
          COMPLEMENTARY_GLOB
          variable uses Unix filename pattern matching (
@@ -1080,33 +1215,36 @@ system and gives an overview of their function and contents.
          ), which is similar to the Unix style pathname pattern expansion (
          glob
          ).
-   
+
       The resulting list of complementary packages is associated with an
       item that can be added to
       :term:`IMAGE_FEATURES`. An example usage of
       this is the "dev-pkgs" item that when added to ``IMAGE_FEATURES``
       will install -dev packages (containing headers and other development
       files) for every package in the image.
-   
+
       To add a new feature item pointing to a wildcard, use a variable flag
       to specify the feature item name and use the value to specify the
-      wildcard. Here is an example: COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
-   
+      wildcard. Here is an example:
+      ::
+
+         COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
+
    COMPONENTS_DIR
       Stores sysroot components for each recipe. The OpenEmbedded build
       system uses ``COMPONENTS_DIR`` when constructing recipe-specific
       sysroots for other recipes.
-   
+
       The default is
       "``${``\ :term:`STAGING_DIR`\ ``}-components``."
       (i.e.
       "``${``\ :term:`TMPDIR`\ ``}/sysroots-components``").
-   
+
    CONF_VERSION
       Tracks the version of the local configuration file (i.e.
       ``local.conf``). The value for ``CONF_VERSION`` increments each time
       ``build/conf/`` compatibility changes.
-   
+
    CONFFILES
       Identifies editable or configurable files that are part of a package.
       If the Package Management System (PMS) is being used to update
@@ -1117,12 +1255,15 @@ system and gives an overview of their function and contents.
       as part of the package update process. You can use the ``CONFFILES``
       variable to list the files in the package that you wish to prevent
       the PMS from overwriting during this update process.
-   
+
       To use the ``CONFFILES`` variable, provide a package name override
       that identifies the resulting package. Then, provide a
-      space-separated list of files. Here is an example: CONFFILES_${PN} +=
-      "${sysconfdir}/file1 \\ ${sysconfdir}/file2 ${sysconfdir}/file3"
-   
+      space-separated list of files. Here is an example:
+      ::
+
+         CONFFILES_${PN} += "${sysconfdir}/file1 \
+             ${sysconfdir}/file2 ${sysconfdir}/file3"
+
       A relationship exists between the ``CONFFILES`` and ``FILES``
       variables. The files listed within ``CONFFILES`` must be a subset of
       the files listed within ``FILES``. Because the configuration files
@@ -1130,9 +1271,9 @@ system and gives an overview of their function and contents.
       the PMS will not overwrite them, it makes sense that the files must
       already be included as part of the package through the ``FILES``
       variable.
-   
+
       .. note::
-   
+
          When specifying paths as part of the
          CONFFILES
          variable, it is good practice to use appropriate path variables.
@@ -1149,13 +1290,13 @@ system and gives an overview of their function and contents.
          file in the
          Source Directory
          .
-   
+
    CONFIG_INITRAMFS_SOURCE
       Identifies the initial RAM filesystem (initramfs) source files. The
       OpenEmbedded build system receives and uses this kernel Kconfig
       variable as an environment variable. By default, the variable is set
       to null ("").
-   
+
       The ``CONFIG_INITRAMFS_SOURCE`` can be either a single cpio archive
       with a ``.cpio`` suffix or a space-separated list of directories and
       files for building the initramfs image. A cpio archive should contain
@@ -1163,23 +1304,22 @@ system and gives an overview of their function and contents.
       should contain a filesystem layout to be included in the initramfs
       image. Files should contain entries according to the format described
       by the ``usr/gen_init_cpio`` program in the kernel tree.
-   
+
       If you specify multiple directories and files, the initramfs image
       will be the aggregate of all of them.
-   
-      For information on creating an initramfs, see the "`Building an
-      Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+
+      For information on creating an initramfs, see the
+      ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    CONFIG_SITE
       A list of files that contains ``autoconf`` test results relevant to
       the current build. This variable is used by the Autotools utilities
       when running ``configure``.
-   
+
    CONFIGURE_FLAGS
       The minimal arguments for GNU configure.
-   
+
    CONFLICT_DISTRO_FEATURES
       When inheriting the
       :ref:`distro_features_check <ref-classes-distro_features_check>`
@@ -1188,7 +1328,7 @@ system and gives an overview of their function and contents.
       ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also
       appears in ``DISTRO_FEATURES`` within the current configuration, an
       error occurs and the build stops.
-   
+
    COPYLEFT_LICENSE_EXCLUDE
       A space-separated list of licenses to exclude from the source
       archived by the :ref:`archiver <ref-classes-archiver>` class. In
@@ -1196,32 +1336,32 @@ system and gives an overview of their function and contents.
       :term:`LICENSE` value is in the value of
       ``COPYLEFT_LICENSE_EXCLUDE``, then its source is not archived by the
       class.
-   
+
       .. note::
-   
+
          The
          COPYLEFT_LICENSE_EXCLUDE
          variable takes precedence over the
          COPYLEFT_LICENSE_INCLUDE
          variable.
-   
+
       The default value, which is "CLOSED Proprietary", for
       ``COPYLEFT_LICENSE_EXCLUDE`` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class.
-   
+
    COPYLEFT_LICENSE_INCLUDE
       A space-separated list of licenses to include in the source archived
       by the :ref:`archiver <ref-classes-archiver>` class. In other
       words, if a license in a recipe's :term:`LICENSE`
       value is in the value of ``COPYLEFT_LICENSE_INCLUDE``, then its
       source is archived by the class.
-   
+
       The default value is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class. The default value includes
       "GPL*", "LGPL*", and "AGPL*".
-   
+
    COPYLEFT_PN_EXCLUDE
       A list of recipes to exclude in the source archived by the
       :ref:`archiver <ref-classes-archiver>` class. The
@@ -1230,12 +1370,12 @@ system and gives an overview of their function and contents.
       :term:`COPYLEFT_LICENSE_INCLUDE` and
       :term:`COPYLEFT_LICENSE_EXCLUDE`
       variables, respectively.
-   
+
       The default value, which is "" indicating to not explicitly exclude
       any recipes by name, for ``COPYLEFT_PN_EXCLUDE`` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class.
-   
+
    COPYLEFT_PN_INCLUDE
       A list of recipes to include in the source archived by the
       :ref:`archiver <ref-classes-archiver>` class. The
@@ -1244,22 +1384,22 @@ system and gives an overview of their function and contents.
       :term:`COPYLEFT_LICENSE_INCLUDE` and
       :term:`COPYLEFT_LICENSE_EXCLUDE`
       variables, respectively.
-   
+
       The default value, which is "" indicating to not explicitly include
       any recipes by name, for ``COPYLEFT_PN_INCLUDE`` is set by the
       :ref:`copyleft_filter <ref-classes-copyleft_filter>` class, which
       is inherited by the ``archiver`` class.
-   
+
    COPYLEFT_RECIPE_TYPES
       A space-separated list of recipe types to include in the source
       archived by the :ref:`archiver <ref-classes-archiver>` class.
       Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``,
       ``crosssdk``, and ``cross-canadian``.
-   
+
       The default value, which is "target*", for ``COPYLEFT_RECIPE_TYPES``
       is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
       class, which is inherited by the ``archiver`` class.
-   
+
    COPY_LIC_DIRS
       If set to "1" along with the
       :term:`COPY_LIC_MANIFEST` variable, the
@@ -1267,9 +1407,9 @@ system and gives an overview of their function and contents.
       which are located in ``/usr/share/common-licenses``, for each
       package. The license files are placed in directories within the image
       itself during build time.
-   
+
       .. note::
-   
+
          The
          COPY_LIC_DIRS
          does not offer a path for adding licenses for newly installed
@@ -1280,15 +1420,15 @@ system and gives an overview of their function and contents.
          Providing License Text
          " section in the Yocto Project Development Tasks Manual for
          information on providing license text.
-   
+
    COPY_LIC_MANIFEST
       If set to "1", the OpenEmbedded build system copies the license
       manifest for the image to
       ``/usr/share/common-licenses/license.manifest`` within the image
       itself during build time.
-   
+
       .. note::
-   
+
          The
          COPY_LIC_MANIFEST
          does not offer a path for adding licenses for newly installed
@@ -1299,177 +1439,190 @@ system and gives an overview of their function and contents.
          Providing License Text
          " section in the Yocto Project Development Tasks Manual for
          information on providing license text.
-   
+
    CORE_IMAGE_EXTRA_INSTALL
       Specifies the list of packages to be added to the image. You should
       only set this variable in the ``local.conf`` configuration file found
       in the :term:`Build Directory`.
-   
+
       This variable replaces ``POKY_EXTRA_INSTALL``, which is no longer
       supported.
-   
+
    COREBASE
       Specifies the parent directory of the OpenEmbedded-Core Metadata
       layer (i.e. ``meta``).
-   
+
       It is an important distinction that ``COREBASE`` points to the parent
       of this layer and not the layer itself. Consider an example where you
       have cloned the Poky Git repository and retained the ``poky`` name
       for your local copy of the repository. In this case, ``COREBASE``
       points to the ``poky`` folder because it is the parent directory of
       the ``poky/meta`` layer.
-   
+
    COREBASE_FILES
       Lists files from the :term:`COREBASE` directory that
       should be copied other than the layers listed in the
       ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for
       the purpose of copying metadata from the OpenEmbedded build system
       into the extensible SDK.
-   
+
       Explicitly listing files in ``COREBASE`` is needed because it
       typically contains build directories and other files that should not
       normally be copied into the extensible SDK. Consequently, the value
       of ``COREBASE_FILES`` is used in order to only copy the files that
       are actually needed.
-   
+
    CPP
       The minimal command and arguments used to run the C preprocessor.
-   
+
    CPPFLAGS
       Specifies the flags to pass to the C pre-processor (i.e. to both the
       C and the C++ compilers). This variable is exported to an environment
       variable and thus made visible to the software being built during the
       compilation step.
-   
+
       Default initialization for ``CPPFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_CPPFLAGS` when building for
          the target
-   
+
       -  :term:`BUILD_CPPFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_CPPFLAGS` when building
          for an SDK (i.e. ``nativesdk-``)
-   
+
    CROSS_COMPILE
       The toolchain binary prefix for the target tools. The
       ``CROSS_COMPILE`` variable is the same as the
       :term:`TARGET_PREFIX` variable.
-   
+
       .. note::
-   
+
          The OpenEmbedded build system sets the
          CROSS_COMPILE
          variable only in certain contexts (e.g. when building for kernel
          and kernel module recipes).
-   
+
    CVSDIR
       The directory in which files checked out under the CVS system are
       stored.
-   
+
    CXX
       The minimal command and arguments used to run the C++ compiler.
-   
+
    CXXFLAGS
       Specifies the flags to pass to the C++ compiler. This variable is
       exported to an environment variable and thus made visible to the
       software being built during the compilation step.
-   
+
       Default initialization for ``CXXFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_CXXFLAGS` when building for
          the target
-   
+
       -  :term:`BUILD_CXXFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_CXXFLAGS` when building
          for an SDK (i.e. ``nativesdk-``)
-   
+
    D
       The destination directory. The location in the :term:`Build Directory`
       where components are installed by the
       :ref:`ref-tasks-install` task. This location defaults
-      to: ${WORKDIR}/image
-   
+      to:
+      ::
+
+         ${WORKDIR}/image
+
       .. note::
-   
+
          Tasks that read from or write to this directory should run under
          fakeroot
          .
-   
+
    DATE
       The date the build was started. Dates appear using the year, month,
       and day (YMD) format (e.g. "20150209" for February 9th, 2015).
-   
+
    DATETIME
       The date and time on which the current build started. The format is
       suitable for timestamps.
-   
+
    DEBIAN_NOAUTONAME
       When the :ref:`debian <ref-classes-debian>` class is inherited,
       which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a
       particular package should not be renamed according to Debian library
       package naming. You must use the package name as an override when you
       set this variable. Here is an example from the ``fontconfig`` recipe:
-      DEBIAN_NOAUTONAME_fontconfig-utils = "1"
-   
+      ::
+
+         DEBIAN_NOAUTONAME_fontconfig-utils = "1"
+
    DEBIANNAME
       When the :ref:`debian <ref-classes-debian>` class is inherited,
       which is the default behavior, ``DEBIANNAME`` allows you to override
       the library name for an individual package. Overriding the library
       name in these cases is rare. You must use the package name as an
       override when you set this variable. Here is an example from the
-      ``dbus`` recipe: DEBIANNAME_${PN} = "dbus-1"
-   
+      ``dbus`` recipe:
+      ::
+
+         DEBIANNAME_${PN} = "dbus-1"
+
    DEBUG_BUILD
       Specifies to build packages with debugging information. This
       influences the value of the ``SELECTED_OPTIMIZATION`` variable.
-   
+
    DEBUG_OPTIMIZATION
       The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
       compiling a system for debugging. This variable defaults to "-O
       -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
-   
+
    DEFAULT_PREFERENCE
       Specifies a weak bias for recipe selection priority.
-   
+
       The most common usage of this is variable is to set it to "-1" within
       a recipe for a development version of a piece of software. Using the
       variable in this way causes the stable version of the recipe to build
       by default in the absence of ``PREFERRED_VERSION`` being used to
       build the development version.
-   
+
       .. note::
-   
+
          The bias provided by
          DEFAULT_PREFERENCE
          is weak and is overridden by
          BBFILE_PRIORITY
          if that variable is different between two layers that contain
          different versions of the same recipe.
-   
+
    DEFAULTTUNE
       The default CPU and Application Binary Interface (ABI) tunings (i.e.
       the "tune") used by the OpenEmbedded build system. The
       ``DEFAULTTUNE`` helps define
       :term:`TUNE_FEATURES`.
-   
+
       The default tune is either implicitly or explicitly set by the
       machine (:term:`MACHINE`). However, you can override
       the setting using available tunes as defined with
       :term:`AVAILTUNES`.
-   
+
    DEPENDS
       Lists a recipe's build-time dependencies. These are dependencies on
       other recipes whose contents (e.g. headers and shared libraries) are
       needed by the recipe at build time.
-   
+
       As an example, consider a recipe ``foo`` that contains the following
-      assignment: DEPENDS = "bar" The practical effect of the previous
+      assignment:
+      ::
+
+          DEPENDS = "bar"
+
+      The practical effect of the previous
       assignment is that all files installed by bar will be available in
       the appropriate staging sysroot, given by the
       :term:`STAGING_DIR* <STAGING_DIR>` variables, by the time the
@@ -1479,23 +1632,28 @@ system and gives an overview of their function and contents.
       each recipe listed in ``DEPENDS``, through a
       ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
       declaration in the :ref:`base <ref-classes-base>` class.
-   
+
       .. note::
-   
+
          It seldom is necessary to reference, for example,
          STAGING_DIR_HOST
          explicitly. The standard classes and build-related variables are
          configured to automatically use the appropriate staging sysroots.
-   
+
       As another example, ``DEPENDS`` can also be used to add utilities
       that run on the build machine during the build. For example, a recipe
       that makes use of a code generator built by the recipe ``codegen``
-      might have the following: DEPENDS = "codegen-native" For more
+      might have the following:
+      ::
+
+         DEPENDS = "codegen-native"
+
+      For more
       information, see the :ref:`native <ref-classes-native>` class and
       the :term:`EXTRANATIVEPATH` variable.
-   
+
       .. note::
-   
+
          -  ``DEPENDS`` is a list of recipe names. Or, to be more precise,
             it is a list of :term:`PROVIDES` names, which
             usually match recipe names. Putting a package name such as
@@ -1503,16 +1661,15 @@ system and gives an overview of their function and contents.
             instead, as this will put files from all the packages that make
             up ``foo``, which includes those from ``foo-dev``, into the
             sysroot.
-   
+
          -  One recipe having another recipe in ``DEPENDS`` does not by
             itself add any runtime dependencies between the packages
             produced by the two recipes. However, as explained in the
-            "`Automatically Added Runtime
-            Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+            ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
             section in the Yocto Project Overview and Concepts Manual,
             runtime dependencies will often be added automatically, meaning
             ``DEPENDS`` alone is sufficient for most recipes.
-   
+
          -  Counterintuitively, ``DEPENDS`` is often necessary even for
             recipes that install precompiled components. For example, if
             ``libfoo`` is a precompiled library that links against
@@ -1521,50 +1678,51 @@ system and gives an overview of their function and contents.
             Without a ``DEPENDS`` from the recipe that installs ``libfoo``
             to the recipe that installs ``libbar``, other recipes might
             fail to link against ``libfoo``.
-   
+
       For information on runtime dependencies, see the
       :term:`RDEPENDS` variable. You can also see the
       ":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and
       ":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the
       BitBake User Manual for additional information on tasks and
       dependencies.
-   
+
    DEPLOY_DIR
       Points to the general area that the OpenEmbedded build system uses to
       place images, packages, SDKs, and other output files that are ready
       to be used outside of the build system. By default, this directory
       resides within the :term:`Build Directory` as
       ``${TMPDIR}/deploy``.
-   
+
       For more information on the structure of the Build Directory, see
-      "`The Build Directory - ``build/`` <#structure-build>`__" section.
+      ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
-      "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__", "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__", and
-      "`Application Development
-      SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections all in the
+      ":ref:`Images <images-dev-environment>`", ":ref:`Package
+      Feeds <package-feeds-dev-environment>`", and
+      ":ref:`sdk-dev-environment`" sections all in the
       Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_DEB
       Points to the area that the OpenEmbedded build system uses to place
       Debian packages that are ready to be used outside of the build
       system. This variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_deb".
-   
+
       The BitBake configuration file initially defines the
       ``DEPLOY_DIR_DEB`` variable as a sub-folder of
-      :term:`DEPLOY_DIR`: DEPLOY_DIR_DEB =
-      "${DEPLOY_DIR}/deb"
-   
+      :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
+
       The :ref:`package_deb <ref-classes-package_deb>` class uses the
       ``DEPLOY_DIR_DEB`` variable to make sure the
       :ref:`ref-tasks-package_write_deb` task
       writes Debian packages into the appropriate folder. For more
-      information on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      information on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_IMAGE
       Points to the area that the OpenEmbedded build system uses to place
       images and other associated output files that are ready to be
@@ -1572,120 +1730,130 @@ system and gives an overview of their function and contents.
       as it contains the ``${MACHINE}`` name. By default, this directory
       resides within the :term:`Build Directory` as
       ``${DEPLOY_DIR}/images/${MACHINE}/``.
-   
+
       For more information on the structure of the Build Directory, see
-      "`The Build Directory - ``build/`` <#structure-build>`__" section.
+      ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
-      "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and
-      "`Application Development
-      SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections both in
+      ":ref:`Images <images-dev-environment>`" and
+      ":ref:`sdk-dev-environment`" sections both in
       the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_IPK
       Points to the area that the OpenEmbedded build system uses to place
       IPK packages that are ready to be used outside of the build system.
       This variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_ipk".
-   
+
       The BitBake configuration file initially defines this variable as a
-      sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_IPK =
-      "${DEPLOY_DIR}/ipk"
-   
+      sub-folder of :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
+
       The :ref:`package_ipk <ref-classes-package_ipk>` class uses the
       ``DEPLOY_DIR_IPK`` variable to make sure the
       :ref:`ref-tasks-package_write_ipk` task
       writes IPK packages into the appropriate folder. For more information
-      on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_RPM
       Points to the area that the OpenEmbedded build system uses to place
       RPM packages that are ready to be used outside of the build system.
       This variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_rpm".
-   
+
       The BitBake configuration file initially defines this variable as a
-      sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_RPM =
-      "${DEPLOY_DIR}/rpm"
-   
+      sub-folder of :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
+
       The :ref:`package_rpm <ref-classes-package_rpm>` class uses the
       ``DEPLOY_DIR_RPM`` variable to make sure the
       :ref:`ref-tasks-package_write_rpm` task
       writes RPM packages into the appropriate folder. For more information
-      on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOY_DIR_TAR
       Points to the area that the OpenEmbedded build system uses to place
       tarballs that are ready to be used outside of the build system. This
       variable applies only when
       :term:`PACKAGE_CLASSES` contains
       "package_tar".
-   
+
       The BitBake configuration file initially defines this variable as a
-      sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_TAR =
-      "${DEPLOY_DIR}/tar"
-   
+      sub-folder of :term:`DEPLOY_DIR`:
+      ::
+
+         DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
+
       The :ref:`package_tar <ref-classes-package_tar>` class uses the
       ``DEPLOY_DIR_TAR`` variable to make sure the
       :ref:`ref-tasks-package_write_tar` task
       writes TAR packages into the appropriate folder. For more information
-      on how packaging works, see the "`Package
-      Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section
+      on how packaging works, see the ":ref:`Package
+      Feeds <package-feeds-dev-environment>`" section
       in the Yocto Project Overview and Concepts Manual.
-   
+
    DEPLOYDIR
       When inheriting the :ref:`deploy <ref-classes-deploy>` class, the
       ``DEPLOYDIR`` points to a temporary work area for deployed files that
-      is set in the ``deploy`` class as follows: DEPLOYDIR =
-      "${WORKDIR}/deploy-${:term:`PN`}"
-   
+      is set in the ``deploy`` class as follows:
+      ::
+
+         DEPLOYDIR = "${WORKDIR}/deploy-${:term:`PN`}"
+
       Recipes inheriting the ``deploy`` class should copy files to be
       deployed into ``DEPLOYDIR``, and the class will take care of copying
       them into :term:`DEPLOY_DIR_IMAGE`
       afterwards.
-   
+
    DESCRIPTION
       The package description used by package managers. If not set,
       ``DESCRIPTION`` takes the value of the :term:`SUMMARY`
       variable.
-   
+
    DISTRO
       The short name of the distribution. For information on the long name
       of the distribution, see the :term:`DISTRO_NAME`
       variable.
-   
+
       The ``DISTRO`` variable corresponds to a distribution configuration
       file whose root name is the same as the variable's argument and whose
       filename extension is ``.conf``. For example, the distribution
       configuration file for the Poky distribution is named ``poky.conf``
       and resides in the ``meta-poky/conf/distro`` directory of the
       :term:`Source Directory`.
-   
+
       Within that ``poky.conf`` file, the ``DISTRO`` variable is set as
-      follows: DISTRO = "poky"
-   
+      follows:
+      ::
+
+         DISTRO = "poky"
+
       Distribution configuration files are located in a ``conf/distro``
       directory within the :term:`Metadata` that contains the
       distribution configuration. The value for ``DISTRO`` must not contain
       spaces, and is typically all lower-case.
-   
+
       .. note::
-   
+
          If the
          DISTRO
          variable is blank, a set of default configurations are used, which
          are specified within
          meta/conf/distro/defaultsetup.conf
          also in the Source Directory.
-   
+
    DISTRO_CODENAME
       Specifies a codename for the distribution being built.
-   
+
    DISTRO_EXTRA_RDEPENDS
       Specifies a list of distro-specific packages to add to all images.
       This variable takes affect through ``packagegroup-base`` so the
@@ -1693,18 +1861,18 @@ system and gives an overview of their function and contents.
       include ``packagegroup-base``. You can use this variable to keep
       distro policy out of generic images. As with all other distro
       variables, you set this variable in the distro ``.conf`` file.
-   
+
    DISTRO_EXTRA_RRECOMMENDS
       Specifies a list of distro-specific packages to add to all images if
       the packages exist. The packages might not exist or be empty (e.g.
       kernel modules). The list of packages are automatically installed but
       you can remove them.
-   
+
    DISTRO_FEATURES
       The software support you want in your distribution for various
       features. You define your distribution features in the distribution
       configuration file.
-   
+
       In most cases, the presence or absence of a feature in
       ``DISTRO_FEATURES`` is translated to the appropriate option supplied
       to the configure script during the
@@ -1713,41 +1881,43 @@ system and gives an overview of their function and contents.
       ``DISTRO_FEATURES``, causes every piece of software built for the
       target that can optionally support X11 to have its X11 support
       enabled.
-   
+
       Two more examples are Bluetooth and NFS support. For a more complete
       list of features that ships with the Yocto Project and that you can
       provide with this variable, see the "`Distro
       Features <#ref-features-distro>`__" section.
-   
+
    DISTRO_FEATURES_BACKFILL
       Features to be added to ``DISTRO_FEATURES`` if not also present in
       ``DISTRO_FEATURES_BACKFILL_CONSIDERED``.
-   
+
       This variable is set in the ``meta/conf/bitbake.conf`` file. It is
       not intended to be user-configurable. It is best to just reference
       the variable to see which distro features are being backfilled for
       all distro configurations. See the "`Feature
       Backfilling <#ref-features-backfill>`__" section for more
       information.
-   
+
    DISTRO_FEATURES_BACKFILL_CONSIDERED
       Features from ``DISTRO_FEATURES_BACKFILL`` that should not be
       backfilled (i.e. added to ``DISTRO_FEATURES``) during the build. See
       the "`Feature Backfilling <#ref-features-backfill>`__" section for
       more information.
-   
+
    DISTRO_FEATURES_DEFAULT
       A convenience variable that gives you the default list of distro
       features with the exception of any features specific to the C library
       (``libc``).
-   
+
       When creating a custom distribution, you might find it useful to be
       able to reuse the default
       :term:`DISTRO_FEATURES` options without the
       need to write out the full set. Here is an example that uses
       ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file:
-      DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
-   
+      ::
+
+         DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
+
    DISTRO_FEATURES_FILTER_NATIVE
       Specifies a list of features that if present in the target
       :term:`DISTRO_FEATURES` value should be
@@ -1755,7 +1925,7 @@ system and gives an overview of their function and contents.
       variable is used in addition to the features filtered using the
       :term:`DISTRO_FEATURES_NATIVE`
       variable.
-   
+
    DISTRO_FEATURES_FILTER_NATIVESDK
       Specifies a list of features that if present in the target
       :term:`DISTRO_FEATURES` value should be
@@ -1763,7 +1933,7 @@ system and gives an overview of their function and contents.
       variable is used in addition to the features filtered using the
       :term:`DISTRO_FEATURES_NATIVESDK`
       variable.
-   
+
    DISTRO_FEATURES_NATIVE
       Specifies a list of features that should be included in
       :term:`DISTRO_FEATURES` when building native
@@ -1771,7 +1941,7 @@ system and gives an overview of their function and contents.
       using the
       :term:`DISTRO_FEATURES_FILTER_NATIVE`
       variable.
-   
+
    DISTRO_FEATURES_NATIVESDK
       Specifies a list of features that should be included in
       :term:`DISTRO_FEATURES` when building
@@ -1779,49 +1949,52 @@ system and gives an overview of their function and contents.
       filtered using the
       :term:`DISTRO_FEATURES_FILTER_NATIVESDK`
       variable.
-   
+
    DISTRO_NAME
       The long name of the distribution. For information on the short name
       of the distribution, see the :term:`DISTRO` variable.
-   
+
       The ``DISTRO_NAME`` variable corresponds to a distribution
       configuration file whose root name is the same as the variable's
       argument and whose filename extension is ``.conf``. For example, the
       distribution configuration file for the Poky distribution is named
       ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory
       of the :term:`Source Directory`.
-   
+
       Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set
-      as follows: DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-   
+      as follows:
+      ::
+
+         DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
+
       Distribution configuration files are located in a ``conf/distro``
       directory within the :term:`Metadata` that contains the
       distribution configuration.
-   
+
       .. note::
-   
+
          If the
          DISTRO_NAME
          variable is blank, a set of default configurations are used, which
          are specified within
          meta/conf/distro/defaultsetup.conf
          also in the Source Directory.
-   
+
    DISTRO_VERSION
       The version of the distribution.
-   
+
    DISTROOVERRIDES
       A colon-separated list of overrides specific to the current
       distribution. By default, this list includes the value of
       :term:`DISTRO`.
-   
+
       You can extend ``DISTROOVERRIDES`` to add extra overrides that should
       apply to the distribution.
-   
+
       The underlying mechanism behind ``DISTROOVERRIDES`` is simply that it
       is included in the default value of
       :term:`OVERRIDES`.
-   
+
    DL_DIR
       The central download directory used by the build process to store
       downloads. By default, ``DL_DIR`` gets files suitable for mirroring
@@ -1829,25 +2002,29 @@ system and gives an overview of their function and contents.
       repositories, use the
       :term:`BB_GENERATE_MIRROR_TARBALLS`
       variable.
-   
+
       You can set this directory by defining the ``DL_DIR`` variable in the
       ``conf/local.conf`` file. This directory is self-maintaining and you
       should not have to touch it. By default, the directory is
-      ``downloads`` in the :term:`Build Directory`. #DL_DIR
-      ?= "${TOPDIR}/downloads" To specify a different download directory,
+      ``downloads`` in the :term:`Build Directory`.
+      ::
+
+         #DL_DIR ?= "${TOPDIR}/downloads"
+
+      To specify a different download directory,
       simply remove the comment from the line and provide your directory.
-   
+
       During a first build, the system downloads many different source code
       tarballs from various upstream projects. Downloading can take a
       while, particularly if your network connection is slow. Tarballs are
       all stored in the directory defined by ``DL_DIR`` and the build
       system looks there first to find source tarballs.
-   
+
       .. note::
-   
+
          When wiping and rebuilding, you can preserve this directory to
          speed up this part of subsequent builds.
-   
+
       You can safely share this directory between multiple builds on the
       same development machine. For additional information on how the build
       process gets source files when working behind a firewall or proxy
@@ -1856,58 +2033,61 @@ system and gives an overview of their function and contents.
       chapter. You can also refer to the
       ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
       Wiki page.
-   
+
    DOC_COMPRESS
       When inheriting the :ref:`compress_doc <ref-classes-compress_doc>`
       class, this variable sets the compression policy used when the
       OpenEmbedded build system compresses man pages and info pages. By
       default, the compression method used is gz (gzip). Other policies
       available are xz and bz2.
-   
+
       For information on policies and on how to use this variable, see the
       comments in the ``meta/classes/compress_doc.bbclass`` file.
-   
+
    EFI_PROVIDER
       When building bootable images (i.e. where ``hddimg``, ``iso``, or
       ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the
       ``EFI_PROVIDER`` variable specifies the EFI bootloader to use. The
       default is "grub-efi", but "systemd-boot" can be used instead.
-   
+
       See the :ref:`systemd-boot <ref-classes-systemd-boot>` and
       :ref:`image-live <ref-classes-image-live>` classes for more
       information.
-   
+
    ENABLE_BINARY_LOCALE_GENERATION
       Variable that controls which locales for ``glibc`` are generated
       during the build (useful if the target device has 64Mbytes of RAM or
       less).
-   
+
    ERR_REPORT_DIR
       When used with the :ref:`report-error <ref-classes-report-error>`
       class, specifies the path used for storing the debug files created by
-      the `error reporting
-      tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which
+      the :ref:`error reporting
+      tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`, which
       allows you to submit build errors you encounter to a central
       database. By default, the value of this variable is
       ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
-   
+
       You can set ``ERR_REPORT_DIR`` to the path you want the error
       reporting tool to store the debug files as follows in your
-      ``local.conf`` file: ERR_REPORT_DIR = "path"
-   
+      ``local.conf`` file:
+      ::
+
+         ERR_REPORT_DIR = "path"
+
    ERROR_QA
       Specifies the quality assurance checks whose failures are reported as
       errors by the OpenEmbedded build system. You set this variable in
       your distribution configuration file. For a list of the checks you
       can control with this variable, see the
       ":ref:`insane.bbclass <ref-classes-insane>`" section.
-   
+
    EXCLUDE_FROM_SHLIBS
       Triggers the OpenEmbedded build system's shared libraries resolver to
       exclude an entire package when scanning for shared libraries.
-   
+
       .. note::
-   
+
          The shared libraries resolver's functionality results in part from
          the internal function
          package_do_shlibs
@@ -1915,25 +2095,28 @@ system and gives an overview of their function and contents.
          do_package
          task. You should be aware that the shared libraries resolver might
          implicitly define some dependencies between packages.
-   
+
       The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the
       :term:`PRIVATE_LIBS` variable, which excludes a
       package's particular libraries only and not the whole package.
-   
+
       Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a
-      particular package: EXCLUDE_FROM_SHLIBS = "1"
-   
+      particular package:
+      ::
+
+         EXCLUDE_FROM_SHLIBS = "1"
+
    EXCLUDE_FROM_WORLD
       Directs BitBake to exclude a recipe from world builds (i.e.
       ``bitbake world``). During world builds, BitBake locates, parses and
       builds all recipes found in every layer exposed in the
       ``bblayers.conf`` configuration file.
-   
+
       To exclude a recipe from a world build using this variable, set the
       variable to "1" in the recipe.
-   
+
       .. note::
-   
+
          Recipes added to
          EXCLUDE_FROM_WORLD
          may still be built during a world build in order to satisfy
@@ -1941,52 +2124,53 @@ system and gives an overview of their function and contents.
          EXCLUDE_FROM_WORLD
          only ensures that the recipe is not explicitly added to the list
          of build targets in a world build.
-   
+
    EXTENDPE
       Used with file and pathnames to create a prefix for a recipe's
       version based on the recipe's :term:`PE` value. If ``PE``
       is set and greater than zero for a recipe, ``EXTENDPE`` becomes that
-      value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1_").
+      value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1").
       If a recipe's ``PE`` is not set (the default) or is equal to zero,
       ``EXTENDPE`` becomes "".
-   
+
       See the :term:`STAMP` variable for an example.
-   
+
    EXTENDPKGV
       The full package version specification as it appears on the final
       packages produced by a recipe. The variable's value is normally used
       to fix a runtime dependency to the exact same version of another
-      package in the same recipe: RDEPENDS_${PN}-additional-module = "${PN}
-      (= ${EXTENDPKGV})"
-   
+      package in the same recipe:
+      ::
+
+         RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
+
       The dependency relationships are intended to force the package
       manager to upgrade these types of packages in lock-step.
-   
+
    EXTERNAL_KERNEL_TOOLS
       When set, the ``EXTERNAL_KERNEL_TOOLS`` variable indicates that these
       tools are not in the source tree.
-   
+
       When kernel tools are available in the tree, they are preferred over
       any externally installed tools. Setting the ``EXTERNAL_KERNEL_TOOLS``
       variable tells the OpenEmbedded build system to prefer the installed
       external tools. See the
       :ref:`kernel-yocto <ref-classes-kernel-yocto>` class in
       ``meta/classes`` to see how the variable is used.
-   
+
    EXTERNALSRC
       When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
       class, this variable points to the source tree, which is outside of
       the OpenEmbedded build system. When set, this variable sets the
       :term:`S` variable, which is what the OpenEmbedded build
       system uses to locate unpacked recipe source code.
-   
+
       For more information on ``externalsrc.bbclass``, see the
       ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
       can also find information on how to use this variable in the
-      "`Building Software from an External
-      Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    EXTERNALSRC_BUILD
       When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
       class, this variable points to the directory in which the recipe's
@@ -1994,121 +2178,124 @@ system and gives an overview of their function and contents.
       system. When set, this variable sets the :term:`B` variable,
       which is what the OpenEmbedded build system uses to locate the Build
       Directory.
-   
+
       For more information on ``externalsrc.bbclass``, see the
       ":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
       can also find information on how to use this variable in the
-      "`Building Software from an External
-      Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    EXTRA_AUTORECONF
       For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
       class, you can use ``EXTRA_AUTORECONF`` to specify extra options to
       pass to the ``autoreconf`` command that is executed during the
       :ref:`ref-tasks-configure` task.
-   
+
       The default value is "--exclude=autopoint".
-   
+
    EXTRA_IMAGE_FEATURES
       A list of additional features to include in an image. When listing
       more than one feature, separate them with a space.
-   
+
       Typically, you configure this variable in your ``local.conf`` file,
       which is found in the :term:`Build Directory`.
       Although you can use this variable from within a recipe, best
       practices dictate that you do not.
-   
+
       .. note::
-   
+
          To enable primary features from within the image recipe, use the
          IMAGE_FEATURES
          variable.
-   
-      Here are some examples of features you can add: "dbg-pkgs" - Adds
-      -dbg packages for all installed packages including symbol information
-      for debugging and profiling. "debug-tweaks" - Makes an image suitable
-      for debugging. For example, allows root logins without passwords and
-      enables post-installation logging. See the 'allow-empty-password' and
-      'post-install-logging' features in the "`Image
-      Features <#ref-features-image>`__" section for more information.
-      "dev-pkgs" - Adds -dev packages for all installed packages. This is
-      useful if you want to develop against the libraries in the image.
-      "read-only-rootfs" - Creates an image whose root filesystem is
-      read-only. See the "`Creating a Read-Only Root
-      Filesystem <&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem>`__"
-      section in the Yocto Project Development Tasks Manual for more
-      information "tools-debug" - Adds debugging tools such as gdb and
-      strace. "tools-sdk" - Adds development tools such as gcc, make,
-      pkgconfig and so forth. "tools-testapps" - Adds useful testing tools
-      such as ts_print, aplay, arecord and so forth.
-   
+
+      Here are some examples of features you can add:
+
+        - "dbg-pkgs" - Adds -dbg packages for all installed packages including
+          symbol information for debugging and profiling.
+
+        - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and
+          enables post-installation logging. See the 'allow-empty-password' and
+          'post-install-logging' features in the "`Image
+          Features <#ref-features-image>`__" section for more information.
+        - "dev-pkgs" - Adds -dev packages for all installed packages. This is
+          useful if you want to develop against the libraries in the image.
+        - "read-only-rootfs" - Creates an image whose root filesystem is
+          read-only. See the
+          ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+          section in the Yocto Project Development Tasks Manual for more
+          information
+        - "tools-debug" - Adds debugging tools such as gdb and strace.
+        - "tools-sdk" - Adds development tools such as gcc, make,
+          pkgconfig and so forth.
+        - "tools-testapps" - Adds useful testing tools
+          such as ts_print, aplay, arecord and so forth.
+
       For a complete list of image features that ships with the Yocto
       Project, see the "`Image Features <#ref-features-image>`__" section.
-   
+
       For an example that shows how to customize your image by using this
-      variable, see the "`Customizing Images Using Custom
-      ``IMAGE_FEATURES`` and
-      ``EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures>`__"
+      variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    EXTRA_IMAGECMD
       Specifies additional options for the image creation command that has
       been specified in :term:`IMAGE_CMD`. When setting
       this variable, use an override for the associated image type. Here is
-      an example: EXTRA_IMAGECMD_ext3 ?= "-i 4096"
-   
+      an example:
+      ::
+
+         EXTRA_IMAGECMD_ext3 ?= "-i 4096"
+
    EXTRA_IMAGEDEPENDS
       A list of recipes to build that do not provide packages for
       installing into the root filesystem.
-   
+
       Sometimes a recipe is required to build the final image but is not
       needed in the root filesystem. You can use the ``EXTRA_IMAGEDEPENDS``
       variable to list these recipes and thus specify the dependencies. A
       typical example is a required bootloader in a machine configuration.
-   
+
       .. note::
-   
+
          To add packages to the root filesystem, see the various
-         \*
-         RDEPENDS
-         and
-         \*
-         RRECOMMENDS
+         \*RDEPENDS and \*RRECOMMENDS
          variables.
-   
+
    EXTRANATIVEPATH
       A list of subdirectories of
       ``${``\ :term:`STAGING_BINDIR_NATIVE`\ ``}``
       added to the beginning of the environment variable ``PATH``. As an
       example, the following prepends
       "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to
-      ``PATH``: EXTRANATIVEPATH = "foo bar"
-   
+      ``PATH``:
+      ::
+
+         EXTRANATIVEPATH = "foo bar"
+
    EXTRA_OECMAKE
       Additional `CMake <https://cmake.org/overview/>`__ options. See the
       :ref:`cmake <ref-classes-cmake>` class for additional information.
-   
+
    EXTRA_OECONF
       Additional ``configure`` script options. See
       :term:`PACKAGECONFIG_CONFARGS` for
       additional information on passing configure script options.
-   
+
    EXTRA_OEMAKE
       Additional GNU ``make`` options.
-   
+
       Because the ``EXTRA_OEMAKE`` defaults to "", you need to set the
       variable to specify any required GNU options.
-   
+
       :term:`PARALLEL_MAKE` and
       :term:`PARALLEL_MAKEINST` also make use of
       ``EXTRA_OEMAKE`` to pass the required flags.
-   
+
    EXTRA_OESCONS
       When inheriting the :ref:`scons <ref-classes-scons>` class, this
       variable specifies additional configuration options you want to pass
       to the ``scons`` command line.
-   
+
    EXTRA_USERS_PARAMS
       When inheriting the :ref:`extrausers <ref-classes-extrausers>`
       class, this variable provides image level user and group operations.
@@ -2116,26 +2303,35 @@ system and gives an overview of their function and contents.
       configuration as compared to using the
       :ref:`useradd <ref-classes-useradd>` class, which ties user and
       group configurations to a specific recipe.
-   
+
       The set list of commands you can configure using the
       ``EXTRA_USERS_PARAMS`` is shown in the ``extrausers`` class. These
-      commands map to the normal Unix commands of the same names: #
-      EXTRA_USERS_PARAMS = "\\ # useradd -p '' tester; \\ # groupadd
-      developers; \\ # userdel nobody; \\ # groupdel -g video; \\ #
-      groupmod -g 1020 developers; \\ # usermod -s /bin/sh tester; \\ # "
-   
+      commands map to the normal Unix commands of the same names:
+      ::
+
+         # EXTRA_USERS_PARAMS = "\
+         # useradd -p '' tester; \
+         # groupadd developers; \
+         # userdel nobody; \
+         # groupdel -g video; \
+         # groupmod -g 1020 developers; \
+         # usermod -s /bin/sh tester; \
+         # "
+
    FEATURE_PACKAGES
       Defines one or more packages to include in an image when a specific
       item is included in :term:`IMAGE_FEATURES`.
       When setting the value, ``FEATURE_PACKAGES`` should have the name of
       the feature item as an override. Here is an example:
-      FEATURE_PACKAGES_widget = "package1 package2"
-   
+      ::
+
+         FEATURE_PACKAGES_widget = "package1 package2"
+
       In this example, if "widget" were added to ``IMAGE_FEATURES``,
       package1 and package2 would be included in the image.
-   
+
       .. note::
-   
+
          Packages installed by features defined through
          FEATURE_PACKAGES
          are often package groups. While similarly named, you should not
@@ -2143,40 +2339,46 @@ system and gives an overview of their function and contents.
          FEATURE_PACKAGES
          variable with package groups, which are discussed elsewhere in the
          documentation.
-   
+
    FEED_DEPLOYDIR_BASE_URI
       Points to the base URL of the server and location within the
       document-root that provides the metadata and packages required by
       OPKG to support runtime package management of IPK packages. You set
       this variable in your ``local.conf`` file.
-   
-      Consider the following example: FEED_DEPLOYDIR_BASE_URI =
-      "http://192.168.7.1/BOARD-dir" This example assumes you are serving
+
+      Consider the following example:
+      ::
+
+         FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir"
+
+      This example assumes you are serving
       your packages over HTTP and your databases are located in a directory
       named ``BOARD-dir``, which is underneath your HTTP server's
       document-root. In this case, the OpenEmbedded build system generates
       a set of configuration files for you in your target that work with
       the feed.
-   
+
    FILES
       The list of files and directories that are placed in a package. The
       :term:`PACKAGES` variable lists the packages
       generated by a recipe.
-   
+
       To use the ``FILES`` variable, provide a package name override that
       identifies the resulting package. Then, provide a space-separated
       list of files or paths that identify the files you want included as
-      part of the resulting package. Here is an example: FILES_${PN} +=
-      "${bindir}/mydir1 ${bindir}/mydir2/myfile"
-   
+      part of the resulting package. Here is an example:
+      ::
+
+         FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
+
       .. note::
-   
+
          -  When specifying files or paths, you can pattern match using
             Python's
-            ```glob`https://docs.python.org/2/library/glob.html
+            `glob <https://docs.python.org/3/library/glob.html>`_
             syntax. For details on the syntax, see the documentation by
             following the previous link.
-   
+
          -  When specifying paths as part of the ``FILES`` variable, it is
             good practice to use appropriate path variables. For example,
             use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}``
@@ -2185,24 +2387,26 @@ system and gives an overview of their function and contents.
             the :term:`Source Directory`. You will also
             find the default values of the various ``FILES_*`` variables in
             this file.
-   
+
       If some of the files you provide with the ``FILES`` variable are
       editable and you know they should not be overwritten during the
       package update process by the Package Management System (PMS), you
       can identify these files so that the PMS will not overwrite them. See
       the :term:`CONFFILES` variable for information on
       how to identify these files to the PMS.
-   
+
    FILES_SOLIBSDEV
       Defines the file specification to match
       :term:`SOLIBSDEV`. In other words,
       ``FILES_SOLIBSDEV`` defines the full path name of the development
       symbolic link (symlink) for shared libraries on the target platform.
-   
+
       The following statement from the ``bitbake.conf`` shows how it is
-      set: FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV}
-      ${libdir}/lib*${SOLIBSDEV}"
-   
+      set:
+      ::
+
+         FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
+
    FILESEXTRAPATHS
       Extends the search path the OpenEmbedded build system uses when
       looking for files and patches as it processes recipes and append
@@ -2210,58 +2414,71 @@ system and gives an overview of their function and contents.
       are initially defined by the :term:`FILESPATH`
       variable. You can extend ``FILESPATH`` variable by using
       ``FILESEXTRAPATHS``.
-   
+
       Best practices dictate that you accomplish this by using
       ``FILESEXTRAPATHS`` from within a ``.bbappend`` file and that you
-      prepend paths as follows: FILESEXTRAPATHS_prepend :=
-      "${THISDIR}/${PN}:" In the above example, the build system first
+      prepend paths as follows:
+      ::
+
+         FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+      In the above example, the build system first
       looks for files in a directory that has the same name as the
       corresponding append file.
-   
+
       .. note::
-   
+
          When extending ``FILESEXTRAPATHS``, be sure to use the immediate
          expansion (``:=``) operator. Immediate expansion makes sure that
          BitBake evaluates :term:`THISDIR` at the time the
          directive is encountered rather than at some later time when
          expansion might result in a directory that does not contain the
          files you need.
-   
+
          Also, include the trailing separating colon character if you are
          prepending. The trailing colon character is necessary because you
          are directing BitBake to extend the path by prepending directories
          to the search path.
-   
-      Here is another common use: FILESEXTRAPATHS_prepend :=
-      "${THISDIR}/files:" In this example, the build system extends the
+
+      Here is another common use:
+      ::
+
+         FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+      In this example, the build system extends the
       ``FILESPATH`` variable to include a directory named ``files`` that is
       in the same directory as the corresponding append file.
-   
+
       This next example specifically adds three paths:
-      FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
-   
+      ::
+
+         FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+
       A final example shows how you can extend the search path and include
       a :term:`MACHINE`-specific override, which is useful
-      in a BSP layer: FILESEXTRAPATHS_prepend_intel-x86-common :=
-      "${THISDIR}/${PN}:" The previous statement appears in the
-      ``linux-yocto-dev.bbappend`` file, which is found in the Yocto
-      Project `Source
-      Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ in
+      in a BSP layer:
+      ::
+
+          FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:"
+
+      The previous statement appears in the
+      ``linux-yocto-dev.bbappend`` file, which is found in the
+      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in
       ``meta-intel/common/recipes-kernel/linux``. Here, the machine
       override is a special :term:`PACKAGE_ARCH`
       definition for multiple ``meta-intel`` machines.
-   
+
       .. note::
-   
+
          For a layer that supports a single BSP, the override could just be
          the value of
          MACHINE
          .
-   
+
       By prepending paths in ``.bbappend`` files, you allow multiple append
       files that reside in different layers but are used for the same
       recipe to correctly extend the path.
-   
+
    FILESOVERRIDES
       A subset of :term:`OVERRIDES` used by the
       OpenEmbedded build system for creating
@@ -2273,53 +2490,63 @@ system and gives an overview of their function and contents.
       are handled in the
       ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
       section of the BitBake User Manual.
-   
+
       By default, the ``FILESOVERRIDES`` variable is defined as:
-      FILESOVERRIDES =
-      "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
-   
+      ::
+
+         FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
+
       .. note::
-   
+
          Do not hand-edit the
          FILESOVERRIDES
          variable. The values match up with expected overrides and are used
          in an expected manner by the build system.
-   
+
    FILESPATH
       The default set of directories the OpenEmbedded build system uses
       when searching for patches and files.
-   
+
       During the build process, BitBake searches each directory in
       ``FILESPATH`` in the specified order when looking for files and
       patches specified by each ``file://`` URI in a recipe's
       :term:`SRC_URI` statements.
-   
+
       The default value for the ``FILESPATH`` variable is defined in the
       ``base.bbclass`` class found in ``meta/classes`` in the
-      :term:`Source Directory`: FILESPATH =
-      "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\
-      "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The
+      :term:`Source Directory`:
+      ::
+
+         FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
+             "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
+
+      The
       ``FILESPATH`` variable is automatically extended using the overrides
       from the :term:`FILESOVERRIDES` variable.
-   
+
       .. note::
-   
+
          -  Do not hand-edit the ``FILESPATH`` variable. If you want the
             build system to look in directories other than the defaults,
             extend the ``FILESPATH`` variable by using the
             :term:`FILESEXTRAPATHS` variable.
-   
+
          -  Be aware that the default ``FILESPATH`` directories do not map
             to directories in custom layers where append files
             (``.bbappend``) are used. If you want the build system to find
             patches or files that reside with your append files, you need
             to extend the ``FILESPATH`` variable by using the
             ``FILESEXTRAPATHS`` variable.
-   
+
       You can take advantage of this searching behavior in useful ways. For
       example, consider a case where the following directory structure
       exists for general and machine-specific configurations:
-      files/defconfig files/MACHINEA/defconfig files/MACHINEB/defconfig
+      ::
+
+         files/defconfig
+         files/MACHINEA/defconfig
+         files/MACHINEB/defconfig
+
       Also in the example, the ``SRC_URI`` statement contains
       "file://defconfig". Given this scenario, you can set
       :term:`MACHINE` to "MACHINEA" and cause the build
@@ -2327,37 +2554,37 @@ system and gives an overview of their function and contents.
       "MACHINEB" and the build system uses files from ``files/MACHINEB``.
       Finally, for any machine other than "MACHINEA" and "MACHINEB", the
       build system uses files from ``files/defconfig``.
-   
+
       You can find out more about the patching process in the
-      "`Patching <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__" section
-      in the Yocto Project Overview and Concepts Manual and the "`Patching
-      Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in
+      ":ref:`patching-dev-environment`" section
+      in the Yocto Project Overview and Concepts Manual and the
+      ":ref:`new-recipe-patching-code`" section in
       the Yocto Project Development Tasks Manual. See the
       :ref:`ref-tasks-patch` task as well.
-   
+
    FILESYSTEM_PERMS_TABLES
       Allows you to define your own file permissions settings table as part
       of your configuration for the packaging process. For example, suppose
       you need a consistent set of custom permissions for a set of groups
       and users across an entire work project. It is best to do this in the
       packages themselves but this is not always possible.
-   
+
       By default, the OpenEmbedded build system uses the ``fs-perms.txt``,
       which is located in the ``meta/files`` folder in the :term:`Source Directory`.
       If you create your own file
       permissions setting table, you should place it in your layer or the
       distro's layer.
-   
+
       You define the ``FILESYSTEM_PERMS_TABLES`` variable in the
       ``conf/local.conf`` file, which is found in the :term:`Build Directory`,
       to point to your custom
       ``fs-perms.txt``. You can specify more than a single file permissions
       setting table. The paths you specify to these files must be defined
       within the :term:`BBPATH` variable.
-   
+
       For guidance on how to create your own file permissions settings
       table file, examine the existing ``fs-perms.txt``.
-   
+
    FIT_HASH_ALG
       Specifies the hash algorithm used in creating the FIT Image. For e.g. sha256.
 
@@ -2369,7 +2596,7 @@ system and gives an overview of their function and contents.
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable specifies the runtime dependencies for font packages.
       By default, the ``FONT_EXTRA_RDEPENDS`` is set to "fontconfig-utils".
-   
+
    FONT_PACKAGES
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable identifies packages containing font files that need to
@@ -2377,168 +2604,189 @@ system and gives an overview of their function and contents.
       that fonts are in the recipe's main package (i.e.
       ``${``\ :term:`PN`\ ``}``). Use this variable if fonts you
       need are in a package other than that main package.
-   
+
    FORCE_RO_REMOVE
       Forces the removal of the packages listed in ``ROOTFS_RO_UNNEEDED``
       during the generation of the root filesystem.
-   
+
       Set the variable to "1" to force the removal of these packages.
-   
+
    FULL_OPTIMIZATION
       The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
       compiling an optimized system. This variable defaults to "-O2 -pipe
       ${DEBUG_FLAGS}".
-   
+
    GCCPIE
       Enables Position Independent Executables (PIE) within the GNU C
       Compiler (GCC). Enabling PIE in the GCC makes Return Oriented
       Programming (ROP) attacks much more difficult to execute.
-   
+
       By default the ``security_flags.inc`` file enables PIE by setting the
-      variable as follows: GCCPIE ?= "--enable-default-pie"
-   
+      variable as follows:
+      ::
+
+         GCCPIE ?= "--enable-default-pie"
+
    GCCVERSION
       Specifies the default version of the GNU C Compiler (GCC) used for
       compilation. By default, ``GCCVERSION`` is set to "8.x" in the
       ``meta/conf/distro/include/tcmode-default.inc`` include file:
-      GCCVERSION ?= "8.%" You can override this value by setting it in a
+      ::
+
+         GCCVERSION ?= "8.%"
+
+      You can override this value by setting it in a
       configuration file such as the ``local.conf``.
-   
+
    GDB
       The minimal command and arguments to run the GNU Debugger.
-   
+
    GITDIR
       The directory in which a local copy of a Git repository is stored
       when it is cloned.
-   
+
    GLIBC_GENERATE_LOCALES
       Specifies the list of GLIBC locales to generate should you not wish
       to generate all LIBC locals, which can be time consuming.
-   
+
       .. note::
-   
+
          If you specifically remove the locale
          en_US.UTF-8
          , you must set
          IMAGE_LINGUAS
          appropriately.
-   
+
       You can set ``GLIBC_GENERATE_LOCALES`` in your ``local.conf`` file.
-      By default, all locales are generated. GLIBC_GENERATE_LOCALES =
-      "en_GB.UTF-8 en_US.UTF-8"
-   
+      By default, all locales are generated.
+      ::
+
+         GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8"
+
    GROUPADD_PARAM
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies for a package what parameters should be
       passed to the ``groupadd`` command if you wish to add a group to the
       system when the package is installed.
-   
-      Here is an example from the ``dbus`` recipe: GROUPADD_PARAM_${PN} =
-      "-r netdev" For information on the standard Linux shell command
+
+      Here is an example from the ``dbus`` recipe:
+      ::
+
+         GROUPADD_PARAM_${PN} = "-r netdev"
+
+      For information on the standard Linux shell command
       ``groupadd``, see http://linux.die.net/man/8/groupadd.
-   
+
    GROUPMEMS_PARAM
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies for a package what parameters should be
       passed to the ``groupmems`` command if you wish to modify the members
       of a group when the package is installed.
-   
+
       For information on the standard Linux shell command ``groupmems``,
       see http://linux.die.net/man/8/groupmems.
-   
+
    GRUB_GFXSERIAL
       Configures the GNU GRand Unified Bootloader (GRUB) to have graphics
       and serial in the boot menu. Set this variable to "1" in your
       ``local.conf`` or distribution configuration file to enable graphics
       and serial in the menu.
-   
+
       See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
       information on how this variable is used.
-   
+
    GRUB_OPTS
       Additional options to add to the GNU GRand Unified Bootloader (GRUB)
       configuration. Use a semi-colon character (``;``) to separate
       multiple options.
-   
+
       The ``GRUB_OPTS`` variable is optional. See the
       :ref:`grub-efi <ref-classes-grub-efi>` class for more information
       on how this variable is used.
-   
+
    GRUB_TIMEOUT
       Specifies the timeout before executing the default ``LABEL`` in the
       GNU GRand Unified Bootloader (GRUB).
-   
+
       The ``GRUB_TIMEOUT`` variable is optional. See the
       :ref:`grub-efi <ref-classes-grub-efi>` class for more information
       on how this variable is used.
-   
+
    GTKIMMODULES_PACKAGES
       When inheriting the
       :ref:`gtk-immodules-cache <ref-classes-gtk-immodules-cache>` class,
       this variable specifies the packages that contain the GTK+ input
       method modules being installed when the modules are in packages other
       than the main package.
-   
+
    HOMEPAGE
       Website where more information about the software the recipe is
       building can be found.
-   
+
    HOST_ARCH
       The name of the target architecture, which is normally the same as
       :term:`TARGET_ARCH`. The OpenEmbedded build system
       supports many architectures. Here is an example list of architectures
       supported. This list is by no means complete as the architecture is
-      configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel
-   
+      configurable:
+
+      - arm
+      - i586
+      - x86_64
+      - powerpc
+      - powerpc64
+      - mips
+      - mipsel
+
    HOST_CC_ARCH
       Specifies architecture-specific compiler flags that are passed to the
       C compiler.
-   
+
       Default initialization for ``HOST_CC_ARCH`` varies depending on what
       is being built:
-   
+
       -  :term:`TARGET_CC_ARCH` when building for the
          target
-   
+
       -  ``BUILD_CC_ARCH`` when building for the build host (i.e.
          ``-native``)
-   
+
       -  ``BUILDSDK_CC_ARCH`` when building for an SDK (i.e.
          ``nativesdk-``)
-   
+
    HOST_OS
       Specifies the name of the target operating system, which is normally
       the same as the :term:`TARGET_OS`. The variable can
       be set to "linux" for ``glibc``-based systems and to "linux-musl" for
       ``musl``. For ARM/EABI targets, there are also "linux-gnueabi" and
       "linux-musleabi" values possible.
-   
+
    HOST_PREFIX
       Specifies the prefix for the cross-compile toolchain. ``HOST_PREFIX``
       is normally the same as :term:`TARGET_PREFIX`.
-   
+
    HOST_SYS
       Specifies the system, including the architecture and the operating
       system, for which the build is occurring in the context of the
       current recipe.
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`HOST_ARCH`,
       :term:`HOST_VENDOR`, and
       :term:`HOST_OS` variables.
-   
+
       .. note::
-   
+
          You do not need to set the variable yourself.
-   
+
       Consider these two examples:
-   
+
       -  Given a native recipe on a 32-bit x86 machine running Linux, the
          value is "i686-linux".
-   
+
       -  Given a recipe being built for a little-endian MIPS target running
          Linux, the value might be "mipsel-linux".
-   
+
    HOSTTOOLS
       A space-separated list (filter) of tools on the build host that
       should be allowed to be called from within build tasks. Using this
@@ -2546,10 +2794,10 @@ system and gives an overview of their function and contents.
       specified in the value of ``HOSTTOOLS`` is not found on the build
       host, the OpenEmbedded build system produces an error and the build
       is not started.
-   
+
       For additional information, see
       :term:`HOSTTOOLS_NONFATAL`.
-   
+
    HOSTTOOLS_NONFATAL
       A space-separated list (filter) of tools on the build host that
       should be allowed to be called from within build tasks. Using this
@@ -2558,44 +2806,51 @@ system and gives an overview of their function and contents.
       does not produce an error if a tool specified in the value of
       ``HOSTTOOLS_NONFATAL`` is not found on the build host. Thus, you can
       use ``HOSTTOOLS_NONFATAL`` to filter optional host tools.
-   
+
    HOST_VENDOR
       Specifies the name of the vendor. ``HOST_VENDOR`` is normally the
       same as :term:`TARGET_VENDOR`.
-   
+
    ICECC_DISABLED
       Disables or enables the ``icecc`` (Icecream) function. For more
       information on this function and best practices for using this
       variable, see the ":ref:`icecc.bbclass <ref-classes-icecc>`"
       section.
-   
+
       Setting this variable to "1" in your ``local.conf`` disables the
-      function: ICECC_DISABLED ??= "1" To enable the function, set the
-      variable as follows: ICECC_DISABLED = ""
-   
+      function:
+      ::
+
+         ICECC_DISABLED ??= "1"
+
+      To enable the function, set the variable as follows:
+      ::
+
+         ICECC_DISABLED = ""
+
    ICECC_ENV_EXEC
       Points to the ``icecc-create-env`` script that you provide. This
       variable is used by the :ref:`icecc <ref-classes-icecc>` class. You
       set this variable in your ``local.conf`` file.
-   
+
       If you do not point to a script that you provide, the OpenEmbedded
       build system uses the default script provided by the
       ``icecc-create-env.bb`` recipe, which is a modified version and not
       the one that comes with ``icecc``.
-   
+
    ICECC_PARALLEL_MAKE
       Extra options passed to the ``make`` command during the
       :ref:`ref-tasks-compile` task that specify parallel
       compilation. This variable usually takes the form of "-j x", where x
       represents the maximum number of parallel threads ``make`` can run.
-   
+
       .. note::
-   
+
          The options passed affect builds on all enabled machines on the
          network, which are machines running the
          iceccd
          daemon.
-   
+
       If your enabled machines support multiple cores, coming up with the
       maximum number of parallel threads that gives you the best
       performance could take some experimentation since machine speed,
@@ -2604,37 +2859,37 @@ system and gives an overview of their function and contents.
       :term:`PARALLEL_MAKE` variable, there is no
       rule-of-thumb for setting ``ICECC_PARALLEL_MAKE`` to achieve optimal
       performance.
-   
+
       If you do not set ``ICECC_PARALLEL_MAKE``, the build system does not
       use it (i.e. the system does not detect and assign the number of
       cores as is done with ``PARALLEL_MAKE``).
-   
+
    ICECC_PATH
       The location of the ``icecc`` binary. You can set this variable in
       your ``local.conf`` file. If your ``local.conf`` file does not define
       this variable, the :ref:`icecc <ref-classes-icecc>` class attempts
       to define it by locating ``icecc`` using ``which``.
-   
+
    ICECC_USER_CLASS_BL
       Identifies user classes that you do not want the Icecream distributed
       compile support to consider. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
-   
+
       When you list classes using this variable, you are "blacklisting"
       them from distributed compilation across remote hosts. Any classes
       you list will be distributed and compiled locally.
-   
+
    ICECC_USER_PACKAGE_BL
       Identifies user recipes that you do not want the Icecream distributed
       compile support to consider. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
-   
+
       When you list packages using this variable, you are "blacklisting"
       them from distributed compilation across remote hosts. Any packages
       you list will be distributed and compiled locally.
-   
+
    ICECC_USER_PACKAGE_WL
       Identifies user recipes that use an empty
       :term:`PARALLEL_MAKE` variable that you want to
@@ -2642,67 +2897,76 @@ system and gives an overview of their function and contents.
       distributed compile support. This variable is used by the
       :ref:`icecc <ref-classes-icecc>` class. You set this variable in
       your ``local.conf`` file.
-   
+
    IMAGE_BASENAME
       The base name of image output files. This variable defaults to the
       recipe name (``${``\ :term:`PN`\ ``}``).
-   
+
    IMAGE_BOOT_FILES
       A space-separated list of files installed into the boot partition
       when preparing an image using the Wic tool with the
-      ``bootimg-partition`` or ``bootimg-efi`` source plugin. By default, 
+      ``bootimg-partition`` or ``bootimg-efi`` source plugin. By default,
       the files are
       installed under the same name as the source files. To change the
       installed name, separate it from the original name with a semi-colon
       (;). Source files need to be located in
       :term:`DEPLOY_DIR_IMAGE`. Here are two
-      examples: IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
-      IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
-   
+      examples:
+      ::
+
+         IMAGE_BOOT_FILES = "u-boot.img uImage;kernel"
+         IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}"
+
       Alternatively, source files can be picked up using a glob pattern. In
       this case, the destination file must have the same name as the base
       name of the source file path. To install files into a directory
       within the target location, pass its name after a semi-colon (;).
-      Here are two examples: IMAGE_BOOT_FILES = "bcm2835-bootfiles/*"
-      IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/" The first example
+      Here are two examples:
+      ::
+
+         IMAGE_BOOT_FILES = "bcm2835-bootfiles/*"
+         IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/"
+
+      The first example
       installs all files from ``${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles``
       into the root of the target partition. The second example installs
       the same files into a ``boot`` directory within the target partition.
-   
-      You can find information on how to use the Wic tool in the "`Creating
-      Partitioned Images Using
-      Wic <&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic>`__"
+
+      You can find information on how to use the Wic tool in the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
       section of the Yocto Project Development Tasks Manual. Reference
-      material for Wic is located in the "`OpenEmbedded Kickstart (.wks)
-      Reference <&YOCTO_DOCS_REF_URL;#ref-kickstart>`__" chapter.
-   
+      material for Wic is located in the
+      ":doc:`../ref-manual/ref-kickstart`" chapter.
+
    IMAGE_CLASSES
       A list of classes that all images should inherit. You typically use
       this variable to specify the list of classes that register the
       different types of images the OpenEmbedded build system creates.
-   
+
       The default value for ``IMAGE_CLASSES`` is ``image_types``. You can
       set this variable in your ``local.conf`` or in a distribution
       configuration file.
-   
+
       For more information, see ``meta/classes/image_types.bbclass`` in the
       :term:`Source Directory`.
-   
+
    IMAGE_CMD
       Specifies the command to create the image file for a specific image
       type, which corresponds to the value set set in
       :term:`IMAGE_FSTYPES`, (e.g. ``ext3``,
       ``btrfs``, and so forth). When setting this variable, you should use
       an override for the associated type. Here is an example:
-      IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \\ --faketime
-      --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \\
-      ${EXTRA_IMAGECMD}"
-   
+      ::
+
+         IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \
+             --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
+             ${EXTRA_IMAGECMD}"
+
       You typically do not need to set this variable unless you are adding
       support for a new image type. For more examples on how to set this
       variable, see the :ref:`image_types <ref-classes-image_types>`
       class file, which is ``meta/classes/image_types.bbclass``.
-   
+
    IMAGE_DEVICE_TABLES
       Specifies one or more files that contain custom device tables that
       are passed to the ``makedevs`` command as part of creating an image.
@@ -2712,55 +2976,55 @@ system and gives an overview of their function and contents.
       :term:`BBPATH`. For details on how you should write
       device table files, see ``meta/files/device_table-minimal.txt`` as an
       example.
-   
+
    IMAGE_FEATURES
       The primary list of features to include in an image. Typically, you
       configure this variable in an image recipe. Although you can use this
       variable from your ``local.conf`` file, which is found in the
       :term:`Build Directory`, best practices dictate that you do
       not.
-   
+
       .. note::
-   
+
          To enable extra features from outside the image recipe, use the
          EXTRA_IMAGE_FEATURES
          variable.
-   
+
       For a list of image features that ships with the Yocto Project, see
       the "`Image Features <#ref-features-image>`__" section.
-   
+
       For an example that shows how to customize your image by using this
-      variable, see the "`Customizing Images Using Custom
-      ``IMAGE_FEATURES`` and
-      ``EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures>`__"
+      variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    IMAGE_FSTYPES
       Specifies the formats the OpenEmbedded build system uses during the
       build when creating the root filesystem. For example, setting
       ``IMAGE_FSTYPES`` as follows causes the build system to create root
       filesystems using two formats: ``.ext3`` and ``.tar.bz2``:
-      IMAGE_FSTYPES = "ext3 tar.bz2"
-   
+      ::
+
+         IMAGE_FSTYPES = "ext3 tar.bz2"
+
       For the complete list of supported image formats from which you can
       choose, see :term:`IMAGE_TYPES`.
-   
+
       .. note::
-   
+
          -  If an image recipe uses the "inherit image" line and you are
             setting ``IMAGE_FSTYPES`` inside the recipe, you must set
             ``IMAGE_FSTYPES`` prior to using the "inherit image" line.
-   
+
          -  Due to the way the OpenEmbedded build system processes this
             variable, you cannot update its contents by using ``_append``
             or ``_prepend``. You must use the ``+=`` operator to add one or
             more options to the ``IMAGE_FSTYPES`` variable.
-   
+
    IMAGE_INSTALL
       Used by recipes to specify the packages to install into an image
       through the :ref:`image <ref-classes-image>` class. Use the
       ``IMAGE_INSTALL`` variable with care to avoid ordering issues.
-   
+
       Image recipes set ``IMAGE_INSTALL`` to specify the packages to
       install into an image through ``image.bbclass``. Additionally,
       "helper" classes such as the
@@ -2768,14 +3032,18 @@ system and gives an overview of their function and contents.
       take lists used with ``IMAGE_FEATURES`` and turn them into
       auto-generated entries in ``IMAGE_INSTALL`` in addition to its
       default contents.
-   
+
       When you use this variable, it is best to use it as follows:
-      IMAGE_INSTALL_append = " package-name" Be sure to include the space
+      ::
+
+         IMAGE_INSTALL_append = " package-name"
+
+      Be sure to include the space
       between the quotation character and the start of the package name or
       names.
-   
+
       .. note::
-   
+
          -  When working with a
             ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
             image, do not use the ``IMAGE_INSTALL`` variable to specify
@@ -2783,11 +3051,10 @@ system and gives an overview of their function and contents.
             :term:`PACKAGE_INSTALL` variable, which
             allows the initial RAM filesystem (initramfs) recipe to use a
             fixed set of packages and not be affected by ``IMAGE_INSTALL``.
-            For information on creating an initramfs, see the "`Building an
-            Initial RAM Filesystem (initramfs)
-            Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__"
+            For information on creating an initramfs, see the
+            ":ref:`building-an-initramfs-image`"
             section in the Yocto Project Development Tasks Manual.
-   
+
          -  Using ``IMAGE_INSTALL`` with the
             :ref:`+= <bitbake:appending-and-prepending>`
             BitBake operator within the ``/conf/local.conf`` file or from
@@ -2802,7 +3069,7 @@ system and gives an overview of their function and contents.
             within an image recipe may or may not succeed depending on the
             specific situation. In both these cases, the behavior is
             contrary to how most users expect the ``+=`` operator to work.
-   
+
    IMAGE_LINGUAS
       Specifies the list of locales to install into the image during the
       root filesystem construction process. The OpenEmbedded build system
@@ -2810,39 +3077,50 @@ system and gives an overview of their function and contents.
       into separate packages. Setting the ``IMAGE_LINGUAS`` variable
       ensures that any locale packages that correspond to packages already
       selected for installation into the image are also installed. Here is
-      an example: IMAGE_LINGUAS = "pt-br de-de"
-   
+      an example:
+      ::
+
+         IMAGE_LINGUAS = "pt-br de-de"
+
       In this example, the build system ensures any Brazilian Portuguese
       and German locale files that correspond to packages in the image are
       installed (i.e. ``*-locale-pt-br`` and ``*-locale-de-de`` as well as
       ``*-locale-pt`` and ``*-locale-de``, since some software packages
       only provide locale files by language and not by country-specific
       language).
-   
+
       See the :term:`GLIBC_GENERATE_LOCALES`
       variable for information on generating GLIBC locales.
-   
+
    IMAGE_MANIFEST
       The manifest file for the image. This file lists all the installed
       packages that make up the image. The file contains package
-      information on a line-per-package basis as follows: packagename
-      packagearch version
-   
+      information on a line-per-package basis as follows:
+      ::
+
+          packagename packagearch version
+
       The :ref:`image <ref-classes-image>` class defines the manifest
-      file as follows: IMAGE_MANIFEST =
-      "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" The location is
+      file as follows:
+      ::
+
+         IMAGE_MANIFEST ="${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
+
+      The location is
       derived using the :term:`DEPLOY_DIR_IMAGE`
       and :term:`IMAGE_NAME` variables. You can find
-      information on how the image is created in the "`Image
-      Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__"
+      information on how the image is created in the ":ref:`image-generation-dev-environment`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
    IMAGE_NAME
       The name of the output image files minus the extension. This variable
       is derived using the :term:`IMAGE_BASENAME`,
       :term:`MACHINE`, and :term:`DATETIME`
-      variables: IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
-   
+      variables:
+      ::
+
+         IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
+
    IMAGE_OVERHEAD_FACTOR
       Defines a multiplier that the build system applies to the initial
       image size for cases when the multiplier times the returned disk
@@ -2858,18 +3136,20 @@ system and gives an overview of their function and contents.
       not produce an image with all the theoretical free disk space. See
       ``IMAGE_ROOTFS_SIZE`` for information on how the build system
       determines the overall image size.
-   
+
       The default 30% free disk space typically gives the image enough room
       to boot and allows for basic post installs while still leaving a
       small amount of free disk space. If 30% free space is inadequate, you
       can increase the default value. For example, the following setting
-      gives you 50% free space added to the image: IMAGE_OVERHEAD_FACTOR =
-      "1.5"
-   
+      gives you 50% free space added to the image:
+      ::
+
+         IMAGE_OVERHEAD_FACTOR = "1.5"
+
       Alternatively, you can ensure a specific amount of free disk space is
       added to the image by using the ``IMAGE_ROOTFS_EXTRA_SPACE``
       variable.
-   
+
    IMAGE_PKGTYPE
       Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the
       OpenEmbedded build system. The variable is defined appropriately by
@@ -2877,84 +3157,92 @@ system and gives an overview of their function and contents.
       :ref:`package_rpm <ref-classes-package_rpm>`,
       :ref:`package_ipk <ref-classes-package_ipk>`, or
       :ref:`package_tar <ref-classes-package_tar>` class.
-   
+
       .. note::
-   
+
          The
          package_tar
          class is broken and is not supported. It is recommended that you
          do not use it.
-   
+
       The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
       :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE``
       for packaging up images and SDKs.
-   
+
       You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the
       variable is set indirectly through the appropriate
       :ref:`package_* <ref-classes-package>` class using the
       :term:`PACKAGE_CLASSES` variable. The
       OpenEmbedded build system uses the first package type (e.g. DEB, RPM,
       or IPK) that appears with the variable
-   
+
       .. note::
-   
+
          Files using the
          .tar
          format are never used as a substitute packaging format for DEB,
          RPM, and IPK formatted files for your image or SDK.
-   
+
    IMAGE_POSTPROCESS_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system creates the final image output files. You can specify
-      functions separated by semicolons: IMAGE_POSTPROCESS_COMMAND +=
-      "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+         IMAGE_POSTPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within the
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    IMAGE_PREPROCESS_COMMAND
       Specifies a list of functions to call before the OpenEmbedded build
       system creates the final image output files. You can specify
-      functions separated by semicolons: IMAGE_PREPROCESS_COMMAND +=
-      "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+         IMAGE_PREPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within the
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    IMAGE_ROOTFS
       The location of the root filesystem while it is under construction
       (i.e. during the :ref:`ref-tasks-rootfs` task). This
       variable is not configurable. Do not change it.
-   
+
    IMAGE_ROOTFS_ALIGNMENT
       Specifies the alignment for the output image file in Kbytes. If the
       size of the image is not a multiple of this value, then the size is
       rounded up to the nearest multiple of the value. The default value is
       "1". See :term:`IMAGE_ROOTFS_SIZE` for
       additional information.
-   
+
    IMAGE_ROOTFS_EXTRA_SPACE
       Defines additional free disk space created in the image in Kbytes. By
       default, this variable is set to "0". This free disk space is added
       to the image after the build system determines the image size as
       described in ``IMAGE_ROOTFS_SIZE``.
-   
+
       This variable is particularly useful when you want to ensure that a
       specific amount of free disk space is available on a device after an
       image is installed and running. For example, to be sure 5 Gbytes of
       free disk space is available, set the variable as follows:
-      IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
-   
+      ::
+
+         IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
+
       For example, the Yocto Project Build Appliance specifically requests
-      40 Gbytes of extra space with the line: IMAGE_ROOTFS_EXTRA_SPACE =
-      "41943040"
-   
+      40 Gbytes of extra space with the line:
+      ::
+
+         IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
+
    IMAGE_ROOTFS_SIZE
       Defines the size in Kbytes for the generated image. The OpenEmbedded
       build system determines the final size for the generated image using
@@ -2962,45 +3250,87 @@ system and gives an overview of their function and contents.
       the generated image, a requested size for the image, and requested
       additional free disk space to be added to the image. Programatically,
       the build system determines the final size of the generated image as
-      follows: if (image-du \* overhead) < rootfs-size:
-      internal-rootfs-size = rootfs-size + xspace else:
-      internal-rootfs-size = (image-du \* overhead) + xspace where:
-      image-du = Returned value of the du command on the image. overhead =
-      IMAGE_OVERHEAD_FACTOR rootfs-size = IMAGE_ROOTFS_SIZE
-      internal-rootfs-size = Initial root filesystem size before any
-      modifications. xspace = IMAGE_ROOTFS_EXTRA_SPACE
-   
+      follows:
+      ::
+
+         if (image-du * overhead) < rootfs-size:
+             internal-rootfs-size = rootfs-size + xspace
+         else:
+             internal-rootfs-size = (image-du * overhead) + xspace
+         where:
+             image-du = Returned value of the du command on the image.
+             overhead = IMAGE_OVERHEAD_FACTOR
+             rootfs-size = IMAGE_ROOTFS_SIZE
+             internal-rootfs-size = Initial root filesystem size before any modifications.
+             xspace = IMAGE_ROOTFS_EXTRA_SPACE
+
       See the :term:`IMAGE_OVERHEAD_FACTOR`
       and :term:`IMAGE_ROOTFS_EXTRA_SPACE`
       variables for related information.
-   
+
    IMAGE_TYPEDEP
       Specifies a dependency from one image type on another. Here is an
       example from the :ref:`image-live <ref-classes-image-live>` class:
-      IMAGE_TYPEDEP_live = "ext3"
-   
+      ::
+
+         IMAGE_TYPEDEP_live = "ext3"
+
       In the previous example, the variable ensures that when "live" is
       listed with the :term:`IMAGE_FSTYPES` variable,
       the OpenEmbedded build system produces an ``ext3`` image first since
       one of the components of the live image is an ``ext3`` formatted
       partition containing the root filesystem.
-   
+
    IMAGE_TYPES
       Specifies the complete list of supported image types by default:
-      btrfs container cpio cpio.gz cpio.lz4 cpio.lzma cpio.xz cramfs ext2
-      ext2.bz2 ext2.gz ext2.lzma ext3 ext3.gz ext4 ext4.gz f2fs hddimg iso
-      jffs2 jffs2.sum multiubi squashfs squashfs-lz4 squashfs-lzo
-      squashfs-xz tar tar.bz2 tar.gz tar.lz4 tar.xz tar.zst ubi ubifs wic
-      wic.bz2 wic.gz wic.lzma
-   
+
+      - btrfs
+      - container
+      - cpio
+      - cpio.gz
+      - cpio.lz4
+      - cpio.lzma
+      - cpio.xz
+      - cramfs
+      - ext2
+      - ext2.bz2
+      - ext2.gz
+      - ext2.lzma
+      - ext3
+      - ext3.gz
+      - ext4
+      - ext4.gz
+      - f2fs
+      - hddimg
+      - iso
+      - jffs2
+      - jffs2.sum
+      - multiubi
+      - squashfs
+      - squashfs-lz4
+      - squashfs-lzo
+      - squashfs-xz
+      - tar
+      - tar.bz2
+      - tar.gz
+      - tar.lz4
+      - tar.xz
+      - tar.zst
+      - ubi
+      - ubifs
+      - wic
+      - wic.bz2
+      - wic.gz
+      - wic.lzma
+
       For more information about these types of images, see
       ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
-   
+
    INC_PR
       Helps define the recipe revision for recipes that share a common
       ``include`` file. You can think of this variable as part of the
       recipe revision as set from within an include file.
-   
+
       Suppose, for example, you have a set of recipes that are used across
       several projects. And, within each of those recipes the revision (its
       :term:`PR` value) is set accordingly. In this case, when
@@ -3009,49 +3339,53 @@ system and gives an overview of their function and contents.
       updated version of the recipe. In this scenario, it can get
       complicated when recipes that are used in many places and provide
       common functionality are upgraded to a new revision.
-   
+
       A more efficient way of dealing with this situation is to set the
       ``INC_PR`` variable inside the ``include`` files that the recipes
       share and then expand the ``INC_PR`` variable within the recipes to
       help define the recipe revision.
-   
+
       The following provides an example that shows how to use the
       ``INC_PR`` variable given a common ``include`` file that defines the
       variable. Once the variable is defined in the ``include`` file, you
       can use the variable to set the ``PR`` values in each recipe. You
       will notice that when you set a recipe's ``PR`` you can provide more
       granular revisioning by appending values to the ``INC_PR`` variable:
-      recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
-      recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
-      recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
-      recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The
+      ::
+
+         recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
+         recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
+         recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
+         recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
+
+      The
       first line of the example establishes the baseline revision to be
       used for all recipes that use the ``include`` file. The remaining
       lines in the example are from individual recipes and show how the
       ``PR`` value is set.
-   
+
    INCOMPATIBLE_LICENSE
       Specifies a space-separated list of license names (as they would
       appear in :term:`LICENSE`) that should be excluded
       from the build. Recipes that provide no alternatives to listed
       incompatible licenses are not built. Packages that are individually
       licensed with the specified incompatible licenses will be deleted.
-   
+
       .. note::
-   
+
          This functionality is only regularly tested using the following
          setting:
          ::
-   
+
                  INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0"
-                                
-   
+
+
          Although you can use other settings, you might be required to
          remove dependencies on or provide alternatives to components that
          are required to produce a functional system image.
-   
+
       .. note::
-   
+
          It is possible to define a list of licenses that are allowed to be
          used instead of the licenses that are excluded. To do this, define
          a variable
@@ -3060,10 +3394,10 @@ system and gives an overview of their function and contents.
          INCOMPATIBLE_LICENSE
          as:
          ::
-   
+
                  INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}"
-                                
-   
+
+
          This will result in
          INCOMPATIBLE_LICENSE
          containing the names of all licences from
@@ -3071,34 +3405,36 @@ system and gives an overview of their function and contents.
          except the ones specified in
          COMPATIBLE_LICENSES
          , thus only allowing the latter licences to be used.
-   
+
    INHERIT
       Causes the named class or classes to be inherited globally. Anonymous
       functions in the class or classes are not executed for the base
       configuration and in each individual recipe. The OpenEmbedded build
       system ignores changes to ``INHERIT`` in individual recipes.
-   
+
       For more information on ``INHERIT``, see the
       :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
       section in the Bitbake User Manual.
-   
+
    INHERIT_DISTRO
       Lists classes that will be inherited at the distribution level. It is
       unlikely that you want to edit this variable.
-   
+
       The default value of the variable is set as follows in the
-      ``meta/conf/distro/defaultsetup.conf`` file: INHERIT_DISTRO ?=
-      "debian devshell sstate license"
-   
+      ``meta/conf/distro/defaultsetup.conf`` file:
+      ::
+
+         INHERIT_DISTRO ?= "debian devshell sstate license"
+
    INHIBIT_DEFAULT_DEPS
       Prevents the default dependencies, namely the C compiler and standard
       C library (libc), from being added to :term:`DEPENDS`.
       This variable is usually used within recipes that do not require any
       compilation using the C compiler.
-   
+
       Set the variable to "1" to prevent the default dependencies from
       being added.
-   
+
    INHIBIT_PACKAGE_DEBUG_SPLIT
       Prevents the OpenEmbedded build system from splitting out debug
       information during packaging. By default, the build system splits out
@@ -3107,37 +3443,40 @@ system and gives an overview of their function and contents.
       how debug information is split out, see the
       :term:`PACKAGE_DEBUG_SPLIT_STYLE`
       variable.
-   
+
       To prevent the build system from splitting out debug information
       during packaging, set the ``INHIBIT_PACKAGE_DEBUG_SPLIT`` variable as
-      follows: INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
-   
+      follows:
+      ::
+
+         INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+
    INHIBIT_PACKAGE_STRIP
       If set to "1", causes the build to not strip binaries in resulting
       packages and prevents the ``-dbg`` package from containing the source
       files.
-   
+
       By default, the OpenEmbedded build system strips binaries and puts
       the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``.
       Consequently, you should not set ``INHIBIT_PACKAGE_STRIP`` when you
       plan to debug in general.
-   
+
    INHIBIT_SYSROOT_STRIP
       If set to "1", causes the build to not strip binaries in the
       resulting sysroot.
-   
+
       By default, the OpenEmbedded build system strips binaries in the
       resulting sysroot. When you specifically set the
       ``INHIBIT_SYSROOT_STRIP`` variable to "1" in your recipe, you inhibit
       this stripping.
-   
+
       If you want to use this variable, include the
       :ref:`staging <ref-classes-staging>` class. This class uses a
       ``sys_strip()`` function to test for the variable and acts
       accordingly.
-   
+
       .. note::
-   
+
          Use of the
          INHIBIT_SYSROOT_STRIP
          variable occurs in rare and special circumstances. For example,
@@ -3145,20 +3484,20 @@ system and gives an overview of their function and contents.
          GCC toolchain. Furthermore, even if the toolchain's binaries are
          strippable, other files exist that are needed for the build that
          are not strippable.
-   
+
    INITRAMFS_FSTYPES
       Defines the format for the output image of an initial RAM filesystem
       (initramfs), which is used during boot. Supported formats are the
       same as those supported by the
       :term:`IMAGE_FSTYPES` variable.
-   
+
       The default value of this variable, which is set in the
       ``meta/conf/bitbake.conf`` configuration file in the
       :term:`Source Directory`, is "cpio.gz". The Linux kernel's
       initramfs mechanism, as opposed to the initial RAM filesystem
       `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
       an optionally compressed cpio archive.
-   
+
    INITRAMFS_IMAGE
       Specifies the :term:`PROVIDES` name of an image
       recipe that is used to build an initial RAM filesystem (initramfs)
@@ -3168,13 +3507,13 @@ system and gives an overview of their function and contents.
       initramfs image recipe you provide should set
       :term:`IMAGE_FSTYPES` to
       :term:`INITRAMFS_FSTYPES`.
-   
+
       An initramfs image provides a temporary root filesystem used for
       early system initialization (e.g. loading of modules needed to locate
       and mount the "real" root filesystem).
-   
+
       .. note::
-   
+
          See the
          meta/recipes-core/images/core-image-minimal-initramfs.bb
          recipe in the
@@ -3183,24 +3522,23 @@ system and gives an overview of their function and contents.
          the one built to provide the initramfs image, set
          INITRAMFS_IMAGE
          to "core-image-minimal-initramfs".
-   
+
       You can also find more information by referencing the
       ``meta-poky/conf/local.conf.sample.extended`` configuration file in
       the Source Directory, the :ref:`image <ref-classes-image>` class,
       and the :ref:`kernel <ref-classes-kernel>` class to see how to use
       the ``INITRAMFS_IMAGE`` variable.
-   
+
       If ``INITRAMFS_IMAGE`` is empty, which is the default, then no
       initramfs image is built.
-   
+
       For more information, you can also see the
       :term:`INITRAMFS_IMAGE_BUNDLE`
       variable, which allows the generated image to be bundled inside the
       kernel image. Additionally, for information on creating an initramfs
-      image, see the "`Building an Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+      image, see the ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    INITRAMFS_IMAGE_BUNDLE
       Controls whether or not the image recipe specified by
       :term:`INITRAMFS_IMAGE` is run through an
@@ -3211,152 +3549,181 @@ system and gives an overview of their function and contents.
       image. This makes use of the
       :term:`CONFIG_INITRAMFS_SOURCE` kernel
       feature.
-   
+
       .. note::
-   
+
          Using an extra compilation pass to bundle the initramfs avoids a
          circular dependency between the kernel recipe and the initramfs
          recipe should the initramfs include kernel modules. Should that be
          the case, the initramfs recipe depends on the kernel for the
          kernel modules, and the kernel depends on the initramfs recipe
          since the initramfs is bundled inside the kernel image.
-   
+
       The combined binary is deposited into the ``tmp/deploy`` directory,
       which is part of the :term:`Build Directory`.
-   
+
       Setting the variable to "1" in a configuration file causes the
       OpenEmbedded build system to generate a kernel image with the
       initramfs specified in ``INITRAMFS_IMAGE`` bundled within:
-      INITRAMFS_IMAGE_BUNDLE = "1" By default, the
+      ::
+
+         INITRAMFS_IMAGE_BUNDLE = "1"
+
+      By default, the
       :ref:`kernel <ref-classes-kernel>` class sets this variable to a
-      null string as follows: INITRAMFS_IMAGE_BUNDLE ?= ""
-   
+      null string as follows:
+      ::
+
+         INITRAMFS_IMAGE_BUNDLE ?= ""
+
       .. note::
-   
+
          You must set the
          INITRAMFS_IMAGE_BUNDLE
          variable in a configuration file. You cannot set the variable in a
          recipe file.
-   
+
       See the
       :yocto_git:`local.conf.sample.extended </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended>`
       file for additional information. Also, for information on creating an
-      initramfs, see the "`Building an Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+      initramfs, see the ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    INITRAMFS_LINK_NAME
       The link name of the initial RAM filesystem image. This variable is
       set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: INITRAMFS_LINK_NAME ?=
-      "initramfs-${KERNEL_ARTIFACT_LINK_NAME}" The value of the
+      follows:
+      ::
+
+         INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value of the
       ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
-      file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    INITRAMFS_NAME
       The base name of the initial RAM filesystem image. This variable is
       set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" The
-      value of the :term:`KERNEL_ARTIFACT_NAME`
+      follows:
+      ::
+
+         INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME`
       variable, which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    INITRD
       Indicates list of filesystem images to concatenate and use as an
       initial RAM disk (``initrd``).
-   
+
       The ``INITRD`` variable is an optional variable used with the
       :ref:`image-live <ref-classes-image-live>` class.
-   
+
    INITRD_IMAGE
       When building a "live" bootable image (i.e. when
       :term:`IMAGE_FSTYPES` contains "live"),
       ``INITRD_IMAGE`` specifies the image recipe that should be built to
       provide the initial RAM disk image. The default value is
       "core-image-minimal-initramfs".
-   
+
       See the :ref:`image-live <ref-classes-image-live>` class for more
       information.
-   
+
    INITSCRIPT_NAME
       The filename of the initialization script as installed to
       ``${sysconfdir}/init.d``.
-   
+
       This variable is used in recipes when using ``update-rc.d.bbclass``.
       The variable is mandatory.
-   
+
    INITSCRIPT_PACKAGES
       A list of the packages that contain initscripts. If multiple packages
       are specified, you need to append the package name to the other
       ``INITSCRIPT_*`` as an override.
-   
+
       This variable is used in recipes when using ``update-rc.d.bbclass``.
       The variable is optional and defaults to the :term:`PN`
       variable.
-   
+
    INITSCRIPT_PARAMS
       Specifies the options to pass to ``update-rc.d``. Here is an example:
-      INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
-   
+      ::
+
+         INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
+
       In this example, the script has a runlevel of 99, starts the script
       in initlevels 2 and 5, and stops the script in levels 0, 1 and 6.
-   
+
       The variable's default value is "defaults", which is set in the
       :ref:`update-rc.d <ref-classes-update-rc.d>` class.
-   
+
       The value in ``INITSCRIPT_PARAMS`` is passed through to the
       ``update-rc.d`` command. For more information on valid parameters,
       please see the ``update-rc.d`` manual page at
       http://www.tin.org/bin/man.cgi?section=8&topic=update-rc.d.
-   
+
    INSANE_SKIP
       Specifies the QA checks to skip for a specific package within a
       recipe. For example, to skip the check for symbolic link ``.so``
       files in the main package of a recipe, add the following to the
       recipe. The package name override must be used, which in this example
-      is ``${PN}``: INSANE_SKIP_${PN} += "dev-so"
-   
+      is ``${PN}``:
+      ::
+
+         INSANE_SKIP_${PN} += "dev-so"
+
       See the ":ref:`insane.bbclass <ref-classes-insane>`" section for a
       list of the valid QA checks you can specify using this variable.
-   
+
    INSTALL_TIMEZONE_FILE
       By default, the ``tzdata`` recipe packages an ``/etc/timezone`` file.
       Set the ``INSTALL_TIMEZONE_FILE`` variable to "0" at the
       configuration level to disable this behavior.
-   
+
    IPK_FEED_URIS
       When the IPK backend is in use and package management is enabled on
       the target, you can use this variable to set up ``opkg`` in the
       target image to point to package feeds on a nominated server. Once
       the feed is established, you can perform installations or upgrades
       using the package manager at runtime.
-   
+
    KARCH
       Defines the kernel architecture used when assembling the
-      configuration. Architectures supported for this release are: powerpc
-      i386 x86_64 arm qemu mips
-   
-      You define the ``KARCH`` variable in the `BSP
-      Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__.
-   
+      configuration. Architectures supported for this release are:
+
+      - powerpc
+      - i386
+      - x86_64
+      - arm
+      - qemu
+      - mips
+
+      You define the ``KARCH`` variable in the :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`.
+
    KBRANCH
       A regular expression used by the build process to explicitly identify
       the kernel branch that is validated, patched, and configured during a
       build. You must set this variable to ensure the exact kernel branch
       you want is being used by the build process.
-   
+
       Values for this variable are set in the kernel's recipe file and the
       kernel's append file. For example, if you are using the
       ``linux-yocto_4.12`` kernel, the kernel recipe file is the
       ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` file. ``KBRANCH``
-      is set as follows in that kernel recipe file: KBRANCH ?=
-      "standard/base"
-   
+      is set as follows in that kernel recipe file:
+      ::
+
+         KBRANCH ?= "standard/base"
+
       This variable is also used from the kernel's append file to identify
       the kernel branch specific to a particular machine or target
       hardware. Continuing with the previous kernel example, the kernel's
@@ -3366,17 +3733,22 @@ system and gives an overview of their function and contents.
       machines (``meta-yocto-bsp``) is named
       ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``.
       Here are the related statements from that append file:
-      KBRANCH_genericx86 = "standard/base" KBRANCH_genericx86-64 =
-      "standard/base" KBRANCH_edgerouter = "standard/edgerouter"
-      KBRANCH_beaglebone = "standard/beaglebone" The ``KBRANCH`` statements
+      ::
+
+         KBRANCH_genericx86 = "standard/base"
+         KBRANCH_genericx86-64 = "standard/base"
+         KBRANCH_edgerouter = "standard/edgerouter"
+         KBRANCH_beaglebone = "standard/beaglebone"
+
+      The ``KBRANCH`` statements
       identify the kernel branch to use when building for each supported
       BSP.
-   
+
    KBUILD_DEFCONFIG
       When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
       class, specifies an "in-tree" kernel configuration file for use
       during a kernel build.
-   
+
       Typically, when using a ``defconfig`` to configure a kernel during a
       build, you place the file in your layer in the same manner as you
       would place patch files and configuration fragment files (i.e.
@@ -3385,46 +3757,53 @@ system and gives an overview of their function and contents.
       ``KBUILD_DEFCONFIG`` variable and append the
       :term:`KMACHINE` variable to point to the
       ``defconfig`` file.
-   
+
       To use the variable, set it in the append file for your kernel recipe
-      using the following form: KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
+      using the following form:
+      ::
+
+         KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
+
       Here is an example from a "raspberrypi2" ``KMACHINE`` build that uses
       a ``defconfig`` file named "bcm2709_defconfig":
-      KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig" As an
-      alternative, you can use the following within your append file:
-      KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file For more
+      ::
+
+         KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
+
+      As an alternative, you can use the following within your append file:
+      ::
+
+         KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file
+
+      For more
       information on how to use the ``KBUILD_DEFCONFIG`` variable, see the
-      "`Using an "In-Tree" ``defconfig``
-      File <&YOCTO_DOCS_KERNEL_DEV_URL;#using-an-in-tree-defconfig-file>`__"
+      ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`"
       section in the Yocto Project Linux Kernel Development Manual.
-   
+
    KERNEL_ALT_IMAGETYPE
       Specifies an alternate kernel image type for creation in addition to
       the kernel image type specified using the
       :term:`KERNEL_IMAGETYPE` variable.
-   
+
    KERNEL_ARTIFACT_NAME
       Specifies the name of all of the build artifacts. You can change the
       name of the artifacts by changing the ``KERNEL_ARTIFACT_NAME``
       variable.
-   
+
       The value of ``KERNEL_ARTIFACT_NAME``, which is set in the
       ``meta/classes/kernel-artifact-names.bbclass`` file, has the
-      following default value: KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
-      See the :term:`PKGE`, :term:`PKGV`,
-      :term:`PKGR`, and :term:`MACHINE`
+      following default value:
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
+      See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, and :term:`MACHINE`
       variables for additional information.
-   
+
       .. note::
-   
-         The
-         IMAGE_VERSION_SUFFIX
-         variable is set to
-         DATETIME
-         .
-   
+
+         The IMAGE_VERSION_SUFFIX variable is set to DATETIME.
+
    KERNEL_CLASSES
       A list of classes defining kernel image types that the
       :ref:`kernel <ref-classes-kernel>` class should inherit. You
@@ -3433,46 +3812,56 @@ system and gives an overview of their function and contents.
       resides in ``meta/classes/kernel-fitimage.bbclass``. You can register
       custom kernel image types with the ``kernel`` class using this
       variable.
-   
+
    KERNEL_DEVICETREE
       Specifies the name of the generated Linux kernel device tree (i.e.
       the ``.dtb``) file.
-   
+
       .. note::
-   
+
          Legacy support exists for specifying the full path to the device
-         tree. However, providing just the
-         .dtb
-         file is preferred.
-   
+         tree. However, providing just the .dtb file is preferred.
+
       In order to use this variable, the
       :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class must
       be inherited.
-   
+
    KERNEL_DTB_LINK_NAME
       The link name of the kernel device tree binary (DTB). This variable
       is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The
+      follows:
+      ::
+
+         KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The
       value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in
-      the same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      the same file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    KERNEL_DTB_NAME
       The base name of the kernel device tree binary (DTB). This variable
       is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
-      follows: KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of
-      the :term:`KERNEL_ARTIFACT_NAME`
+      follows:
+      ::
+
+         KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME`
       variable, which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    KERNEL_EXTRA_ARGS
       Specifies additional ``make`` command-line arguments the OpenEmbedded
       build system passes on when compiling the kernel.
-   
+
    KERNEL_FEATURES
       Includes additional kernel metadata. In the OpenEmbedded build
       system, the default Board Support Packages (BSPs)
@@ -3481,158 +3870,184 @@ system and gives an overview of their function and contents.
       variables. You can use the ``KERNEL_FEATURES`` variable from within
       the kernel recipe or kernel append file to further add metadata for
       all BSPs or specific BSPs.
-   
+
       The metadata you add through this variable includes config fragments
       and features descriptions, which usually includes patches as well as
       config fragments. You typically override the ``KERNEL_FEATURES``
       variable for a specific machine. In this way, you can provide
       validated, but optional, sets of kernel configurations and features.
-   
+
       For example, the following example from the ``linux-yocto-rt_4.12``
       kernel recipe adds "netfilter" and "taskstats" features to all BSPs
       as well as "virtio" configurations to all QEMU machines. The last two
       statements add specific configurations to targeted machine types:
-      KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
-      features/taskstats/taskstats.scc" KERNEL_FEATURES_append = "
-      ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall = "
-      cfg/virtio.scc" KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc
-      cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64 = "
-      cfg/sound.scc"
-   
+      ::
+
+         KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
+         KERNEL_FEATURES_append = "${KERNEL_EXTRA_FEATURES}"
+         KERNEL_FEATURES_append_qemuall = "cfg/virtio.scc"
+         KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+         KERNEL_FEATURES_append_qemux86-64 = "cfg/sound.scc"
+
    KERNEL_FIT_LINK_NAME
       The link name of the kernel flattened image tree (FIT) image. This
       variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
-      file as follows: KERNEL_FIT_LINK_NAME ?=
-      "${KERNEL_ARTIFACT_LINK_NAME}" The value of the
+      file as follows:
+      ::
+
+         KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value of the
       ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
-      file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    KERNEL_FIT_NAME
       The base name of the kernel flattened image tree (FIT) image. This
       variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
-      file as follows: KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" The
-      value of the :term:`KERNEL_ARTIFACT_NAME`
+      file as follows:
+      ::
+
+         KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME`
       variable, which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    KERNEL_IMAGE_LINK_NAME
       The link name for the kernel image. This variable is set in the
       ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of
+      ::
+
+         KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value of
       the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
-      file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
+      file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
       See the :term:`MACHINE` variable for additional
       information.
-   
+
    KERNEL_IMAGE_MAXSIZE
       Specifies the maximum size of the kernel image file in kilobytes. If
       ``KERNEL_IMAGE_MAXSIZE`` is set, the size of the kernel image file is
       checked against the set value during the
       :ref:`ref-tasks-sizecheck` task. The task fails if
       the kernel image file is larger than the setting.
-   
+
       ``KERNEL_IMAGE_MAXSIZE`` is useful for target devices that have a
       limited amount of space in which the kernel image must be stored.
-   
+
       By default, this variable is not set, which means the size of the
       kernel image is not checked.
-   
+
    KERNEL_IMAGE_NAME
       The base name of the kernel image. This variable is set in the
       ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the
+      ::
+
+         KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the
       :term:`KERNEL_ARTIFACT_NAME` variable,
       which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    KERNEL_IMAGETYPE
       The type of kernel to build for a device, usually set by the machine
       configuration files and defaults to "zImage". This variable is used
       when building the kernel and is passed to ``make`` as the target to
       build.
-   
+
       If you want to build an alternate kernel image type, use the
       :term:`KERNEL_ALT_IMAGETYPE` variable.
-   
+
    KERNEL_MODULE_AUTOLOAD
       Lists kernel modules that need to be auto-loaded during boot.
-   
+
       .. note::
-   
+
          This variable replaces the deprecated
          module_autoload
          variable.
-   
+
       You can use the ``KERNEL_MODULE_AUTOLOAD`` variable anywhere that it
       can be recognized by the kernel recipe or by an out-of-tree kernel
       module recipe (e.g. a machine configuration file, a distribution
       configuration file, an append file for the recipe, or the recipe
       itself).
-   
-      Specify it as follows: KERNEL_MODULE_AUTOLOAD += "module_name1
-      module_name2 module_name3"
-   
+
+      Specify it as follows:
+      ::
+
+         KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3"
+
       Including ``KERNEL_MODULE_AUTOLOAD`` causes the OpenEmbedded build
       system to populate the ``/etc/modules-load.d/modname.conf`` file with
       the list of modules to be auto-loaded on boot. The modules appear
       one-per-line in the file. Here is an example of the most common use
-      case: KERNEL_MODULE_AUTOLOAD += "module_name"
-   
+      case:
+      ::
+
+         KERNEL_MODULE_AUTOLOAD += "module_name"
+
       For information on how to populate the ``modname.conf`` file with
-      ``modprobe.d`` syntax lines, see the
-      :term:`KERNEL_MODULE_PROBECONF`
-      variable.
-   
+      ``modprobe.d`` syntax lines, see the :term:`KERNEL_MODULE_PROBECONF` variable.
+
    KERNEL_MODULE_PROBECONF
       Provides a list of modules for which the OpenEmbedded build system
       expects to find ``module_conf_``\ modname values that specify
       configuration for each of the modules. For information on how to
       provide those module configurations, see the
       :term:`module_conf_* <module_conf>` variable.
-   
+
    KERNEL_PATH
       The location of the kernel sources. This variable is set to the value
       of the :term:`STAGING_KERNEL_DIR` within
       the :ref:`module <ref-classes-module>` class. For information on
-      how this variable is used, see the "`Incorporating Out-of-Tree
-      Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
+      how this variable is used, see the
+      ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
       section in the Yocto Project Linux Kernel Development Manual.
-   
+
       To help maximize compatibility with out-of-tree drivers used to build
       modules, the OpenEmbedded build system also recognizes and uses the
       :term:`KERNEL_SRC` variable, which is identical to
       the ``KERNEL_PATH`` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
-   
+
    KERNEL_SRC
       The location of the kernel sources. This variable is set to the value
       of the :term:`STAGING_KERNEL_DIR` within
       the :ref:`module <ref-classes-module>` class. For information on
-      how this variable is used, see the "`Incorporating Out-of-Tree
-      Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__"
+      how this variable is used, see the
+      ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
       section in the Yocto Project Linux Kernel Development Manual.
-   
+
       To help maximize compatibility with out-of-tree drivers used to build
       modules, the OpenEmbedded build system also recognizes and uses the
       :term:`KERNEL_PATH` variable, which is identical
       to the ``KERNEL_SRC`` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
-   
+
    KERNEL_VERSION
       Specifies the version of the kernel as extracted from ``version.h``
       or ``utsrelease.h`` within the kernel sources. Effects of setting
       this variable do not take affect until the kernel has been
       configured. Consequently, attempting to refer to this variable in
       contexts prior to configuration will not work.
-   
+
    KERNELDEPMODDEPEND
       Specifies whether the data referenced through
       :term:`PKGDATA_DIR` is needed or not. The
@@ -3641,14 +4056,16 @@ system and gives an overview of their function and contents.
       use the data, set the ``KERNELDEPMODDEPEND`` variable in your
       ``initramfs`` recipe. Setting the variable there when the data is not
       needed avoids a potential dependency loop.
-   
+
    KFEATURE_DESCRIPTION
       Provides a short description of a configuration fragment. You use
       this variable in the ``.scc`` file that describes a configuration
       fragment file. Here is the variable used in a file named ``smp.scc``
-      to describe SMP being enabled: define KFEATURE_DESCRIPTION "Enable
-      SMP"
-   
+      to describe SMP being enabled:
+      ::
+
+          define KFEATURE_DESCRIPTION "Enable SMP"
+
    KMACHINE
       The machine as known by the kernel. Sometimes the machine name used
       by the kernel does not match the machine name used by the
@@ -3658,77 +4075,86 @@ system and gives an overview of their function and contents.
       understands that machine as ``intel-core2-32``. For cases like these,
       the ``KMACHINE`` variable maps the kernel machine name to the
       OpenEmbedded build system machine name.
-   
+
       These mappings between different names occur in the Yocto Linux
       Kernel's ``meta`` branch. As an example take a look in the
       ``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file:
-      LINUX_VERSION_core2-32-intel-common = "3.19.0"
-      COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
-      SRCREV_meta_core2-32-intel-common =
-      "8897ef68b30e7426bc1d39895e71fb155d694974"
-      SRCREV_machine_core2-32-intel-common =
-      "43b9eced9ba8a57add36af07736344dcc383f711"
-      KMACHINE_core2-32-intel-common = "intel-core2-32"
-      KBRANCH_core2-32-intel-common = "standard/base"
-      KERNEL_FEATURES_append_core2-32-intel-common =
-      "${KERNEL_FEATURES_INTEL_COMMON}" The ``KMACHINE`` statement says
+      ::
+
+         LINUX_VERSION_core2-32-intel-common = "3.19.0"
+         COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+         SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
+         SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
+         KMACHINE_core2-32-intel-common = "intel-core2-32"
+         KBRANCH_core2-32-intel-common = "standard/base"
+         KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
+
+      The ``KMACHINE`` statement says
       that the kernel understands the machine name as "intel-core2-32".
       However, the OpenEmbedded build system understands the machine as
       "core2-32-intel-common".
-   
+
    KTYPE
       Defines the kernel type to be used in assembling the configuration.
       The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
-      kernel types. See the "`Kernel
-      Types <&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types>`__" section in the
+      kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+      section in the
       Yocto Project Linux Kernel Development Manual for more information on
       kernel types.
-   
-      You define the ``KTYPE`` variable in the `BSP
-      Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__. The
+
+      You define the ``KTYPE`` variable in the
+      :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. The
       value you use must match the value used for the
       :term:`LINUX_KERNEL_TYPE` value used by the
       kernel recipe.
-   
+
    LABELS
       Provides a list of targets for automatic configuration.
-   
+
       See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
       information on how this variable is used.
-   
+
    LAYERDEPENDS
       Lists the layers, separated by spaces, on which this recipe depends.
       Optionally, you can specify a specific layer version for a dependency
       by adding it to the end of the layer name. Here is an example:
-      LAYERDEPENDS_mylayer = "anotherlayer (=3)" In this previous example,
+      ::
+
+         LAYERDEPENDS_mylayer = "anotherlayer (=3)"
+
+      In this previous example,
       version 3 of "anotherlayer" is compared against
       :term:`LAYERVERSION`\ ``_anotherlayer``.
-   
+
       An error is produced if any dependency is missing or the version
       numbers (if specified) do not match exactly. This variable is used in
       the ``conf/layer.conf`` file and must be suffixed with the name of
       the specific layer (e.g. ``LAYERDEPENDS_mylayer``).
-   
+
    LAYERDIR
       When used inside the ``layer.conf`` configuration file, this variable
       provides the path of the current layer. This variable is not
       available outside of ``layer.conf`` and references are expanded
       immediately when parsing of the file completes.
-   
+
    LAYERRECOMMENDS
       Lists the layers, separated by spaces, recommended for use with this
       layer.
-   
+
       Optionally, you can specify a specific layer version for a
       recommendation by adding the version to the end of the layer name.
-      Here is an example: LAYERRECOMMENDS_mylayer = "anotherlayer (=3)" In
-      this previous example, version 3 of "anotherlayer" is compared
+      Here is an example:
+      ::
+
+         LAYERRECOMMENDS_mylayer = "anotherlayer (=3)"
+
+      In this previous example, version 3 of "anotherlayer" is compared
       against ``LAYERVERSION_anotherlayer``.
-   
+
       This variable is used in the ``conf/layer.conf`` file and must be
       suffixed with the name of the specific layer (e.g.
       ``LAYERRECOMMENDS_mylayer``).
-   
+
    LAYERSERIES_COMPAT
       Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which
       a layer is compatible. Using the ``LAYERSERIES_COMPAT`` variable
@@ -3736,27 +4162,28 @@ system and gives an overview of their function and contents.
       layer and OE-Core can be expected to work. The variable gives the
       system a way to detect when a layer has not been tested with new
       releases of OE-Core (e.g. the layer is not maintained).
-   
+
       To specify the OE-Core versions for which a layer is compatible, use
       this variable in your layer's ``conf/layer.conf`` configuration file.
       For the list, use the Yocto Project
       :yocto_wiki:`Release Name </wiki/Releases>` (e.g.
       DISTRO_NAME_NO_CAP). To specify multiple OE-Core versions for the
-      layer, use a space-separated list: LAYERSERIES_COMPAT_layer_root_name
-      = "DISTRO_NAME_NO_CAP DISTRO_NAME_NO_CAP_MINUS_ONE"
-   
+      layer, use a space-separated list:
+      ::
+
+         LAYERSERIES_COMPAT_layer_root_name = "DISTRO_NAME_NO_CAP DISTRO_NAME_NO_CAP_MINUS_ONE"
+
       .. note::
-   
+
          Setting
          LAYERSERIES_COMPAT
          is required by the Yocto Project Compatible version 2 standard.
          The OpenEmbedded build system produces a warning if the variable
          is not set for any given layer.
-   
-      See the "`Creating Your Own
-      Layer <&YOCTO_DOCS_DEV_URL;#creating-your-own-layer>`__" section in
-      the Yocto Project Development Tasks Manual.
-   
+
+      See the ":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+      section in the Yocto Project Development Tasks Manual.
+
    LAYERVERSION
       Optionally specifies the version of a layer as a single number. You
       can use this within :term:`LAYERDEPENDS` for
@@ -3764,90 +4191,98 @@ system and gives an overview of their function and contents.
       This variable is used in the ``conf/layer.conf`` file and must be
       suffixed with the name of the specific layer (e.g.
       ``LAYERVERSION_mylayer``).
-   
+
    LD
       The minimal command and arguments used to run the linker.
-   
+
    LDFLAGS
       Specifies the flags to pass to the linker. This variable is exported
       to an environment variable and thus made visible to the software
       being built during the compilation step.
-   
+
       Default initialization for ``LDFLAGS`` varies depending on what is
       being built:
-   
+
       -  :term:`TARGET_LDFLAGS` when building for the
          target
-   
+
       -  :term:`BUILD_LDFLAGS` when building for the
          build host (i.e. ``-native``)
-   
+
       -  :term:`BUILDSDK_LDFLAGS` when building for
          an SDK (i.e. ``nativesdk-``)
-   
+
    LEAD_SONAME
       Specifies the lead (or primary) compiled library file (i.e. ``.so``)
       that the :ref:`debian <ref-classes-debian>` class applies its
       naming policy to given a recipe that packages multiple libraries.
-   
+
       This variable works in conjunction with the ``debian`` class.
-   
+
    LIC_FILES_CHKSUM
       Checksums of the license text in the recipe source code.
-   
+
       This variable tracks changes in license text of the source code
       files. If the license text is changed, it will trigger a build
       failure, which gives the developer an opportunity to review any
       license change.
-   
+
       This variable must be defined for all recipes (unless
       :term:`LICENSE` is set to "CLOSED").
-   
-      For more information, see the "`Tracking License
-      Changes <&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-LIC_FILES_CHKSUM>`__"
+
+      For more information, see the ":ref:`usingpoky-configuring-lic_files_chksum`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    LICENSE
       The list of source licenses for the recipe. Follow these rules:
-   
+
       -  Do not use spaces within individual license names.
-   
+
       -  Separate license names using \| (pipe) when there is a choice
          between licenses.
-   
+
       -  Separate license names using & (ampersand) when multiple licenses
          exist that cover different parts of the source.
-   
+
       -  You can use spaces between license names.
-   
+
       -  For standard licenses, use the names of the files in
          ``meta/files/common-licenses/`` or the
          :term:`SPDXLICENSEMAP` flag names defined in
          ``meta/conf/licenses.conf``.
-   
-      Here are some examples: LICENSE = "LGPLv2.1 \| GPLv3" LICENSE =
-      "MPL-1 & LGPLv2.1" LICENSE = "GPLv2+" The first example is from the
+
+      Here are some examples:
+      ::
+
+         LICENSE = "LGPLv2.1 | GPLv3"
+         LICENSE = "MPL-1 & LGPLv2.1"
+         LICENSE = "GPLv2+"
+
+      The first example is from the
       recipes for Qt, which the user may choose to distribute under either
       the LGPL version 2.1 or GPL version 3. The second example is from
       Cairo where two licenses cover different parts of the source code.
       The final example is from ``sysstat``, which presents a single
       license.
-   
+
       You can also specify licenses on a per-package basis to handle
       situations where components of the output have different licenses.
       For example, a piece of software whose code is licensed under GPLv2
       but has accompanying documentation licensed under the GNU Free
-      Documentation License 1.2 could be specified as follows: LICENSE =
-      "GFDL-1.2 & GPLv2" LICENSE_${PN} = "GPLv2" LICENSE_${PN}-doc =
-      "GFDL-1.2"
-   
+      Documentation License 1.2 could be specified as follows:
+      ::
+
+         LICENSE = "GFDL-1.2 & GPLv2"
+         LICENSE_${PN} = "GPLv2"
+         LICENSE_${PN}-doc = "GFDL-1.2"
+
    LICENSE_CREATE_PACKAGE
       Setting ``LICENSE_CREATE_PACKAGE`` to "1" causes the OpenEmbedded
       build system to create an extra package (i.e.
       ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add
       those packages to the
       :term:`RRECOMMENDS`\ ``_${PN}``.
-   
+
       The ``${PN}-lic`` package installs a directory in
       ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base
       name, and installs files in that directory that contain license and
@@ -3857,124 +4292,149 @@ system and gives an overview of their function and contents.
       and copies of files marked in
       :term:`LIC_FILES_CHKSUM` as containing
       license text).
-   
+
       For related information on providing license text, see the
       :term:`COPY_LIC_DIRS` variable, the
       :term:`COPY_LIC_MANIFEST` variable, and the
-      "`Providing License
-      Text <&YOCTO_DOCS_DEV_URL;#providing-license-text>`__" section in the
-      Yocto Project Development Tasks Manual.
-   
+      ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+      section in the Yocto Project Development Tasks Manual.
+
    LICENSE_FLAGS
       Specifies additional flags for a recipe you must whitelist through
       :term:`LICENSE_FLAGS_WHITELIST` in
       order to allow the recipe to be built. When providing multiple flags,
       separate them with spaces.
-   
+
       This value is independent of :term:`LICENSE` and is
       typically used to mark recipes that might require additional licenses
       in order to be used in a commercial product. For more information,
-      see the "`Enabling Commercially Licensed
-      Recipes <&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes>`__"
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    LICENSE_FLAGS_WHITELIST
       Lists license flags that when specified in
       :term:`LICENSE_FLAGS` within a recipe should not
       prevent that recipe from being built. This practice is otherwise
       known as "whitelisting" license flags. For more information, see the
-      "`Enabling Commercially Licensed
-      Recipes <&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    LICENSE_PATH
       Path to additional licenses used during the build. By default, the
       OpenEmbedded build system uses ``COMMON_LICENSE_DIR`` to define the
       directory that holds common license text used during the build. The
       ``LICENSE_PATH`` variable allows you to extend that location to other
-      areas that have additional licenses: LICENSE_PATH +=
-      "path-to-additional-common-licenses"
-   
+      areas that have additional licenses:
+      ::
+
+         LICENSE_PATH += "path-to-additional-common-licenses"
+
    LINUX_KERNEL_TYPE
       Defines the kernel type to be used in assembling the configuration.
       The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
-      kernel types. See the "`Kernel
-      Types <&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types>`__" section in the
+      kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+      section in the
       Yocto Project Linux Kernel Development Manual for more information on
       kernel types.
-   
+
       If you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to
       "standard". Together with :term:`KMACHINE`, the
       ``LINUX_KERNEL_TYPE`` variable defines the search arguments used by
       the kernel tools to find the appropriate description within the
       kernel :term:`Metadata` with which to build out the sources
       and configuration.
-   
+
    LINUX_VERSION
       The Linux version from ``kernel.org`` on which the Linux kernel image
       being built using the OpenEmbedded build system is based. You define
       this variable in the kernel recipe. For example, the
       ``linux-yocto-3.4.bb`` kernel recipe found in
       ``meta/recipes-kernel/linux`` defines the variables as follows:
-      LINUX_VERSION ?= "3.4.24"
-   
+      ::
+
+         LINUX_VERSION ?= "3.4.24"
+
       The ``LINUX_VERSION`` variable is used to define :term:`PV`
-      for the recipe: PV = "${LINUX_VERSION}+git${SRCPV}"
-   
+      for the recipe:
+      ::
+
+         PV = "${LINUX_VERSION}+git${SRCPV}"
+
    LINUX_VERSION_EXTENSION
       A string extension compiled into the version string of the Linux
       kernel built with the OpenEmbedded build system. You define this
       variable in the kernel recipe. For example, the linux-yocto kernel
-      recipes all define the variable as follows: LINUX_VERSION_EXTENSION
-      ?= "-yocto-${:term:`LINUX_KERNEL_TYPE`}"
-   
+      recipes all define the variable as follows:
+      ::
+
+         LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
+
       Defining this variable essentially sets the Linux kernel
       configuration item ``CONFIG_LOCALVERSION``, which is visible through
       the ``uname`` command. Here is an example that shows the extension
-      assuming it was set as previously shown: $ uname -r 3.7.0-rc8-custom
-   
+      assuming it was set as previously shown:
+      ::
+
+         $ uname -r
+         3.7.0-rc8-custom
+
    LOG_DIR
       Specifies the directory to which the OpenEmbedded build system writes
       overall log files. The default directory is ``${TMPDIR}/log``.
-   
+
       For the directory containing logs specific to each task, see the
       :term:`T` variable.
-   
+
    MACHINE
       Specifies the target device for which the image is built. You define
       ``MACHINE`` in the ``local.conf`` file found in the
       :term:`Build Directory`. By default, ``MACHINE`` is set to
       "qemux86", which is an x86-based architecture machine to be emulated
-      using QEMU: MACHINE ?= "qemux86"
-   
+      using QEMU:
+      ::
+
+         MACHINE ?= "qemux86"
+
       The variable corresponds to a machine configuration file of the same
       name, through which machine-specific configurations are set. Thus,
       when ``MACHINE`` is set to "qemux86" there exists the corresponding
       ``qemux86.conf`` machine configuration file, which can be found in
       the :term:`Source Directory` in
       ``meta/conf/machine``.
-   
+
       The list of machines supported by the Yocto Project as shipped
-      include the following: MACHINE ?= "qemuarm" MACHINE ?= "qemuarm64"
-      MACHINE ?= "qemumips" MACHINE ?= "qemumips64" MACHINE ?= "qemuppc"
-      MACHINE ?= "qemux86" MACHINE ?= "qemux86-64" MACHINE ?= "genericx86"
-      MACHINE ?= "genericx86-64" MACHINE ?= "beaglebone" MACHINE ?=
-      "edgerouter" The last five are Yocto Project reference hardware
+      include the following:
+      ::
+
+         MACHINE ?= "qemuarm"
+         MACHINE ?= "qemuarm64"
+         MACHINE ?= "qemumips"
+         MACHINE ?= "qemumips64"
+         MACHINE ?= "qemuppc"
+         MACHINE ?= "qemux86"
+         MACHINE ?= "qemux86-64"
+         MACHINE ?= "genericx86"
+         MACHINE ?= "genericx86-64"
+         MACHINE ?= "beaglebone"
+         MACHINE ?= "edgerouter"
+
+      The last five are Yocto Project reference hardware
       boards, which are provided in the ``meta-yocto-bsp`` layer.
-   
+
       .. note::
-   
+
          Adding additional Board Support Package (BSP) layers to your
          configuration adds new possible settings for
          MACHINE
          .
-   
+
    MACHINE_ARCH
       Specifies the name of the machine-specific architecture. This
       variable is set automatically from :term:`MACHINE` or
       :term:`TUNE_PKGARCH`. You should not hand-edit
       the ``MACHINE_ARCH`` variable.
-   
+
    MACHINE_ESSENTIAL_EXTRA_RDEPENDS
       A list of required machine-specific packages to install as part of
       the image being built. The build process depends on these packages
@@ -3983,19 +4443,21 @@ system and gives an overview of their function and contents.
       The impact of this variable affects images based on
       ``packagegroup-core-boot``, including the ``core-image-minimal``
       image.
-   
+
       This variable is similar to the
       ``MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` variable with the exception
       that the image being built has a build dependency on the variable's
       list of packages. In other words, the image will not build if a file
       in this list is not found.
-   
+
       As an example, suppose the machine for which you are building
       requires ``example-init`` to be run during boot to initialize the
       hardware. In this case, you would use the following in the machine's
-      ``.conf`` configuration file: MACHINE_ESSENTIAL_EXTRA_RDEPENDS +=
-      "example-init"
-   
+      ``.conf`` configuration file:
+      ::
+
+         MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
+
    MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
       A list of recommended machine-specific packages to install as part of
       the image being built. The build process does not depend on these
@@ -4004,7 +4466,7 @@ system and gives an overview of their function and contents.
       the machine to boot. The impact of this variable affects images based
       on ``packagegroup-core-boot``, including the ``core-image-minimal``
       image.
-   
+
       This variable is similar to the ``MACHINE_ESSENTIAL_EXTRA_RDEPENDS``
       variable with the exception that the image being built does not have
       a build dependency on the variable's list of packages. In other
@@ -4013,7 +4475,7 @@ system and gives an overview of their function and contents.
       modules, whose functionality may be selected to be built into the
       kernel rather than as a module, in which case a package will not be
       produced.
-   
+
       Consider an example where you have a custom kernel where a specific
       touchscreen driver is required for the machine to be usable. However,
       the driver can be built as a module or into the kernel depending on
@@ -4024,10 +4486,12 @@ system and gives an overview of their function and contents.
       not fail due to the missing package. To accomplish this, assuming the
       package for the module was called ``kernel-module-ab123``, you would
       use the following in the machine's ``.conf`` configuration file:
-      MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
-   
+      ::
+
+         MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
+
       .. note::
-   
+
          In this example, the
          kernel-module-ab123
          recipe needs to explicitly set its
@@ -4035,25 +4499,25 @@ system and gives an overview of their function and contents.
          variable to ensure that BitBake does not use the kernel recipe's
          PACKAGES_DYNAMIC
          variable to satisfy the dependency.
-   
+
       Some examples of these machine essentials are flash, screen,
       keyboard, mouse, or touchscreen drivers (depending on the machine).
-   
+
    MACHINE_EXTRA_RDEPENDS
       A list of machine-specific packages to install as part of the image
       being built that are not essential for the machine to boot. However,
       the build process for more fully-featured images depends on the
       packages being present.
-   
+
       This variable affects all images based on ``packagegroup-base``,
       which does not include the ``core-image-minimal`` or
       ``core-image-full-cmdline`` images.
-   
+
       The variable is similar to the ``MACHINE_EXTRA_RRECOMMENDS`` variable
       with the exception that the image being built has a build dependency
       on the variable's list of packages. In other words, the image will
       not build if a file in this list is not found.
-   
+
       An example is a machine that has WiFi capability but is not essential
       for the machine to boot the image. However, if you are building a
       more fully-featured image, you want to enable the WiFi. The package
@@ -4062,22 +4526,24 @@ system and gives an overview of their function and contents.
       finding the package. In this case, assuming the package for the
       firmware was called ``wifidriver-firmware``, you would use the
       following in the ``.conf`` file for the machine:
-      MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
-   
+      ::
+
+         MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
+
    MACHINE_EXTRA_RRECOMMENDS
       A list of machine-specific packages to install as part of the image
       being built that are not essential for booting the machine. The image
       being built has no build dependency on this list of packages.
-   
+
       This variable affects only images based on ``packagegroup-base``,
       which does not include the ``core-image-minimal`` or
       ``core-image-full-cmdline`` images.
-   
+
       This variable is similar to the ``MACHINE_EXTRA_RDEPENDS`` variable
       with the exception that the image being built does not have a build
       dependency on the variable's list of packages. In other words, the
       image will build if a file in this list is not found.
-   
+
       An example is a machine that has WiFi capability but is not essential
       For the machine to boot the image. However, if you are building a
       more fully-featured image, you want to enable WiFi. In this case, the
@@ -4087,8 +4553,10 @@ system and gives an overview of their function and contents.
       not being found. To accomplish this, assuming the package for the
       module was called ``kernel-module-examplewifi``, you would use the
       following in the ``.conf`` file for the machine:
-      MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
-   
+      ::
+
+         MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
+
    MACHINE_FEATURES
       Specifies the list of hardware features the
       :term:`MACHINE` is capable of supporting. For related
@@ -4096,48 +4564,59 @@ system and gives an overview of their function and contents.
       :term:`DISTRO_FEATURES`,
       :term:`COMBINED_FEATURES`, and
       :term:`IMAGE_FEATURES` variables.
-   
+
       For a list of hardware features supported by the Yocto Project as
       shipped, see the "`Machine Features <#ref-features-machine>`__"
       section.
-   
+
    MACHINE_FEATURES_BACKFILL
       Features to be added to ``MACHINE_FEATURES`` if not also present in
       ``MACHINE_FEATURES_BACKFILL_CONSIDERED``.
-   
+
       This variable is set in the ``meta/conf/bitbake.conf`` file. It is
       not intended to be user-configurable. It is best to just reference
       the variable to see which machine features are being backfilled for
       all machine configurations. See the "`Feature
       Backfilling <#ref-features-backfill>`__" section for more
       information.
-   
+
    MACHINE_FEATURES_BACKFILL_CONSIDERED
       Features from ``MACHINE_FEATURES_BACKFILL`` that should not be
       backfilled (i.e. added to ``MACHINE_FEATURES``) during the build. See
       the "`Feature Backfilling <#ref-features-backfill>`__" section for
       more information.
-   
+
    MACHINEOVERRIDES
       A colon-separated list of overrides that apply to the current
       machine. By default, this list includes the value of
       :term:`MACHINE`.
-   
+
       You can extend ``MACHINEOVERRIDES`` to add extra overrides that
       should apply to a machine. For example, all machines emulated in QEMU
       (e.g. ``qemuarm``, ``qemux86``, and so forth) include a file named
       ``meta/conf/machine/include/qemu.inc`` that prepends the following
-      override to ``MACHINEOVERRIDES``: MACHINEOVERRIDES =. "qemuall:" This
+      override to ``MACHINEOVERRIDES``:
+      ::
+
+         MACHINEOVERRIDES =. "qemuall:"
+
+      This
       override allows variables to be overriden for all machines emulated
       in QEMU, like in the following example from the ``connman-conf``
-      recipe: SRC_URI_append_qemuall = "file://wired.config \\
-      file://wired-setup \\ " The underlying mechanism behind
+      recipe:
+      ::
+
+         SRC_URI_append_qemuall = "file://wired.config \
+             file://wired-setup \
+             "
+
+      The underlying mechanism behind
       ``MACHINEOVERRIDES`` is simply that it is included in the default
       value of :term:`OVERRIDES`.
-   
+
    MAINTAINER
       The email address of the distribution maintainer.
-   
+
    MIRRORS
       Specifies additional paths from which the OpenEmbedded build system
       gets source code. When the build system searches for source code, it
@@ -4145,20 +4624,20 @@ system and gives an overview of their function and contents.
       build system tries locations defined by
       :term:`PREMIRRORS`, the upstream source, and then
       locations specified by ``MIRRORS`` in that order.
-   
+
       Assuming your distribution (:term:`DISTRO`) is "poky",
       the default value for ``MIRRORS`` is defined in the
       ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
-   
+
    MLPREFIX
       Specifies a prefix has been added to :term:`PN` to create a
       special version of a recipe or package (i.e. a Multilib version). The
       variable is used in places where the prefix needs to be added to or
       removed from a the name (e.g. the :term:`BPN` variable).
       ``MLPREFIX`` gets set when a prefix has been added to ``PN``.
-   
+
       .. note::
-   
+
          The "ML" in
          MLPREFIX
          stands for "MultiLib". This representation is historical and comes
@@ -4169,7 +4648,7 @@ system and gives an overview of their function and contents.
          was turned into a prefix, it made sense to set
          MLPREFIX
          for it as well.
-   
+
       To help understand when ``MLPREFIX`` might be needed, consider when
       :term:`BBCLASSEXTEND` is used to provide a
       ``nativesdk`` version of a recipe in addition to the target version.
@@ -4177,25 +4656,37 @@ system and gives an overview of their function and contents.
       recipes by using :term:`DEPENDS`, then a dependency on
       "foo" will automatically get rewritten to a dependency on
       "nativesdk-foo". However, dependencies like the following will not
-      get rewritten automatically: do_foo[depends] += "recipe:do_foo" If
-      you want such a dependency to also get transformed, you can do the
-      following: do_foo[depends] += "${MLPREFIX}recipe:do_foo"
-   
+      get rewritten automatically:
+      ::
+
+         do_foo[depends] += "recipe:do_foo"
+
+      If you want such a dependency to also get transformed, you can do the
+      following:
+      ::
+
+         do_foo[depends] += "${MLPREFIX}recipe:do_foo"
+
    module_autoload
       This variable has been replaced by the ``KERNEL_MODULE_AUTOLOAD``
       variable. You should replace all occurrences of ``module_autoload``
       with additions to ``KERNEL_MODULE_AUTOLOAD``, for example:
-      module_autoload_rfcomm = "rfcomm"
-   
-      should now be replaced with: KERNEL_MODULE_AUTOLOAD += "rfcomm" See
-      the :term:`KERNEL_MODULE_AUTOLOAD`
-      variable for more information.
-   
+      ::
+
+         module_autoload_rfcomm = "rfcomm"
+
+      should now be replaced with:
+      ::
+
+         KERNEL_MODULE_AUTOLOAD += "rfcomm"
+
+      See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information.
+
    module_conf
-      Specifies ```modprobe.d`http://linux.die.net/man/5/modprobe.d
+      Specifies `modprobe.d <http://linux.die.net/man/5/modprobe.d>`_
       syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf``
       file.
-   
+
       You can use this variable anywhere that it can be recognized by the
       kernel recipe or out-of-tree kernel module recipe (e.g. a machine
       configuration file, a distribution configuration file, an append file
@@ -4203,64 +4694,80 @@ system and gives an overview of their function and contents.
       must also be sure to list the module name in the
       :term:`KERNEL_MODULE_AUTOLOAD`
       variable.
-   
-      Here is the general syntax: module_conf_module_name =
-      "modprobe.d-syntax" You must use the kernel module name override.
-   
+
+      Here is the general syntax:
+      ::
+
+         module_conf_module_name = "modprobe.d-syntax"
+
+      You must use the kernel module name override.
+
       Run ``man modprobe.d`` in the shell to find out more information on
       the exact syntax you want to provide with ``module_conf``.
-   
+
       Including ``module_conf`` causes the OpenEmbedded build system to
       populate the ``/etc/modprobe.d/modname.conf`` file with
       ``modprobe.d`` syntax lines. Here is an example that adds the options
       ``arg1`` and ``arg2`` to a module named ``mymodule``:
-      module_conf_mymodule = "options mymodule arg1=val1 arg2=val2"
-   
+      ::
+
+         module_conf_mymodule = "options mymodule arg1=val1 arg2=val2"
+
       For information on how to specify kernel modules to auto-load on
-      boot, see the
-      :term:`KERNEL_MODULE_AUTOLOAD`
-      variable.
-   
+      boot, see the :term:`KERNEL_MODULE_AUTOLOAD` variable.
+
    MODULE_TARBALL_DEPLOY
       Controls creation of the ``modules-*.tgz`` file. Set this variable to
       "0" to disable creation of this file, which contains all of the
       kernel modules resulting from a kernel build.
-   
+
    MODULE_TARBALL_LINK_NAME
       The link name of the kernel module tarball. This variable is set in
       the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value
+      ::
+
+         MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+
+      The value
       of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the
-      same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?=
-      "${MACHINE}"
-   
-      See the :term:`MACHINE` variable for additional
-      information.
-   
+      same file, has the following value:
+      ::
+
+         KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+
+      See the :term:`MACHINE` variable for additional information.
+
    MODULE_TARBALL_NAME
       The base name of the kernel module tarball. This variable is set in
       the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:
-      MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the
-      :term:`KERNEL_ARTIFACT_NAME` variable,
+      ::
+
+         MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+
+      The value of the :term:`KERNEL_ARTIFACT_NAME` variable,
       which is set in the same file, has the following value:
-      KERNEL_ARTIFACT_NAME ?=
-      "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
-   
+      ::
+
+         KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
    MULTIMACH_TARGET_SYS
       Uniquely identifies the type of the target system for which packages
       are being built. This variable allows output for different types of
       target systems to be put into different subdirectories of the same
       output directory.
-   
+
       The default value of this variable is:
-      ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} Some classes (e.g.
+      ::
+
+         ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}
+
+      Some classes (e.g.
       :ref:`cross-canadian <ref-classes-cross-canadian>`) modify the
       ``MULTIMACH_TARGET_SYS`` value.
-   
+
       See the :term:`STAMP` variable for an example. See the
-      :term:`STAGING_DIR_TARGET` variable for
-      more information.
-   
+      :term:`STAGING_DIR_TARGET` variable for more information.
+
    NATIVELSBSTRING
       A string identifying the host distribution. Strings consist of the
       host distributor ID followed by the release, as reported by the
@@ -4268,17 +4775,17 @@ system and gives an overview of their function and contents.
       example, when running a build on Ubuntu 12.10, the value is
       "Ubuntu-12.10". If this information is unable to be determined, the
       value resolves to "Unknown".
-   
+
       This variable is used by default to isolate native shared state
       packages for different distributions (e.g. to avoid problems with
       ``glibc`` version incompatibilities). Additionally, the variable is
       checked against
       :term:`SANITY_TESTED_DISTROS` if that
       variable is set.
-   
+
    NM
       The minimal command and arguments to run ``nm``.
-   
+
    NO_GENERIC_LICENSE
       Avoids QA errors when you use a non-common, non-CLOSED license in a
       recipe. Packages exist, such as the linux-firmware package, with many
@@ -4287,60 +4794,71 @@ system and gives an overview of their function and contents.
       which are only applicable to a specific package.
       ``NO_GENERIC_LICENSE`` is used to allow copying a license that does
       not exist in common licenses.
-   
+
       The following example shows how to add ``NO_GENERIC_LICENSE`` to a
-      recipe: NO_GENERIC_LICENSE[license_name] =
-      "license_file_in_fetched_source" The following is an example that
+      recipe:
+      ::
+
+         NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source"
+
+      The following is an example that
       uses the ``LICENSE.Abilis.txt`` file as the license from the fetched
-      source: NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
-   
+      source:
+      ::
+
+         NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
+
    NO_RECOMMENDATIONS
       Prevents installation of all "recommended-only" packages.
       Recommended-only packages are packages installed only through the
       :term:`RRECOMMENDS` variable). Setting the
-      ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on:
-      NO_RECOMMENDATIONS = "1"
-   
+      ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: ::
+
+         NO_RECOMMENDATIONS = "1"
+
       You can set this variable globally in your ``local.conf`` file or you
       can attach it to a specific image recipe by using the recipe name
-      override: NO_RECOMMENDATIONS_pn-target_image = "1"
-   
+      override: ::
+
+         NO_RECOMMENDATIONS_pn-target_image = "1"
+
       It is important to realize that if you choose to not install packages
       using this variable and some other packages are dependent on them
       (i.e. listed in a recipe's :term:`RDEPENDS`
       variable), the OpenEmbedded build system ignores your request and
       will install the packages to avoid dependency errors.
-   
+
       .. note::
-   
+
          Some recommended packages might be required for certain system
          functionality, such as kernel modules. It is up to you to add
-         packages with the
-         IMAGE_INSTALL
-         variable.
-   
+         packages with the IMAGE_INSTALL variable.
+
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
-   
+
       See the :term:`BAD_RECOMMENDATIONS` and
       the :term:`PACKAGE_EXCLUDE` variables for
       related information.
-   
+
    NOAUTOPACKAGEDEBUG
       Disables auto package from splitting ``.debug`` files. If a recipe
       requires ``FILES_${PN}-dbg`` to be set manually, the
       ``NOAUTOPACKAGEDEBUG`` can be defined allowing you to define the
-      content of the debug package. For example: NOAUTOPACKAGEDEBUG = "1"
-      FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*" FILES_${PN}-dbg
-      = "/usr/src/debug/" FILES_${QT_BASE_NAME}-demos-doc =
-      "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
-   
+      content of the debug package. For example:
+      ::
+
+         NOAUTOPACKAGEDEBUG = "1"
+         FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
+         FILES_${PN}-dbg = "/usr/src/debug/"
+         FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
+
    OBJCOPY
       The minimal command and arguments to run ``objcopy``.
-   
+
    OBJDUMP
       The minimal command and arguments to run ``objdump``.
-   
+
    OE_BINCONFIG_EXTRA_MANGLE
       When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
       this variable specifies additional arguments passed to the "sed"
@@ -4349,60 +4867,66 @@ system and gives an overview of their function and contents.
       results in all paths in these scripts being changed to point into the
       ``sysroots/`` directory so that all builds that use the script will
       use the correct directories for the cross compiling layout.
-   
-      See the ``meta/classes/binconfig.bbclass`` in the 
+
+      See the ``meta/classes/binconfig.bbclass`` in the
       :term:`Source Directory` for details on how this class
       applies these additional sed command arguments. For general
       information on the ``binconfig`` class, see the
       ":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
-   
+
    OE_IMPORTS
       An internal variable used to tell the OpenEmbedded build system what
       Python modules to import for every Python function run by the system.
-   
+
       .. note::
-   
+
          Do not set this variable. It is for internal use only.
-   
+
    OE_INIT_ENV_SCRIPT
       The name of the build environment setup script for the purposes of
       setting up the environment within the extensible SDK. The default
       value is "oe-init-build-env".
-   
+
       If you use a custom script to set up your build environment, set the
       ``OE_INIT_ENV_SCRIPT`` variable to its name.
-   
+
    OE_TERMINAL
       Controls how the OpenEmbedded build system spawns interactive
       terminals on the host development system (e.g. using the BitBake
       command with the ``-c devshell`` command-line option). For more
-      information, see the "`Using a Development
-      Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__" section in
+      information, see the ":ref:`platdev-appdev-devshell`" section in
       the Yocto Project Development Tasks Manual.
-   
+
       You can use the following values for the ``OE_TERMINAL`` variable:
-      auto gnome xfce rxvt screen konsole none
-   
+
+      - auto
+      - gnome
+      - xfce
+      - rxvt
+      - screen
+      - konsole
+      - none
+
    OEROOT
       The directory from which the top-level build environment setup script
       is sourced. The Yocto Project provides a top-level build environment
       setup script: ````` <#structure-core-script>`__. When you run this
       script, the ``OEROOT`` variable resolves to the directory that
       contains the script.
-   
+
       For additional information on how this variable is used, see the
       initialization script.
-   
+
    OLDEST_KERNEL
       Declares the oldest version of the Linux kernel that the produced
       binaries must support. This variable is passed into the build of the
       Embedded GNU C Library (``glibc``).
-   
+
       The default for this variable comes from the
       ``meta/conf/bitbake.conf`` configuration file. You can override this
       default by setting the variable in a custom distribution
       configuration file.
-   
+
    OVERRIDES
       A colon-separated list of overrides that currently apply. Overrides
       are a BitBake mechanism that allows variables to be selectively
@@ -4410,26 +4934,33 @@ system and gives an overview of their function and contents.
       ``OVERRIDES`` represents the "state" during building, which includes
       the current recipe being built, the machine for which it is being
       built, and so forth.
-   
+
       As an example, if the string "an-override" appears as an element in
       the colon-separated list in ``OVERRIDES``, then the following
       assignment will override ``FOO`` with the value "overridden" at the
-      end of parsing: FOO_an-override = "overridden" See the
+      end of parsing:
+      ::
+
+         FOO_an-override = "overridden"
+
+      See the
       ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
       section in the BitBake User Manual for more information on the
       overrides mechanism.
-   
+
       The default value of ``OVERRIDES`` includes the values of the
       :term:`CLASSOVERRIDE`,
       :term:`MACHINEOVERRIDES`, and
       :term:`DISTROOVERRIDES` variables. Another
       important override included by default is ``pn-${PN}``. This override
       allows variables to be set for a single recipe within configuration
-      (``.conf``) files. Here is an example: FOO_pn-myrecipe =
-      "myrecipe-specific value"
-   
+      (``.conf``) files. Here is an example:
+      ::
+
+         FOO_pn-myrecipe = "myrecipe-specific value"
+
       .. note::
-   
+
          An easy way to see what overrides apply is to search for
          OVERRIDES
          in the output of the
@@ -4438,128 +4969,134 @@ system and gives an overview of their function and contents.
          Viewing Variable Values
          " section in the Yocto Project Development Tasks Manual for more
          information.
-   
+
    P
       The recipe name and version. ``P`` is comprised of the following:
-      ${PN}-${PV}
-   
+      ::
+
+         ${PN}-${PV}
+
    PACKAGE_ADD_METADATA
       This variable defines additional metdata to add to packages.
-   
+
       You may find you need to inject additional metadata into packages.
       This variable allows you to do that by setting the injected data as
       the value. Multiple fields can be added by splitting the content with
       the literal separator "\n".
-   
+
       The suffixes '_IPK', '_DEB', or '_RPM' can be applied to the variable
       to do package type specific settings. It can also be made package
       specific by using the package name as a suffix.
-   
-      You can find out more about applying this variable in the "`Adding
-      custom metadata to
-      packages <&YOCTO_DOCS_DEV_URL;#adding-custom-metadata-to-packages>`__"
+
+      You can find out more about applying this variable in the
+      ":ref:`dev-manual/dev-manual-common-tasks:adding custom metadata to packages`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGE_ARCH
       The architecture of the resulting package or packages.
-   
+
       By default, the value of this variable is set to
       :term:`TUNE_PKGARCH` when building for the
       target, :term:`BUILD_ARCH` when building for the
       build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building for the
       SDK.
-   
+
       .. note::
-   
+
          See
          SDK_ARCH
          for more information.
-   
+
       However, if your recipe's output packages are built specific to the
       target machine rather than generally for the architecture of the
       machine, you should set ``PACKAGE_ARCH`` to the value of
       :term:`MACHINE_ARCH` in the recipe as follows:
-      PACKAGE_ARCH = "${MACHINE_ARCH}"
-   
+      ::
+
+         PACKAGE_ARCH = "${MACHINE_ARCH}"
+
    PACKAGE_ARCHS
       Specifies a list of architectures compatible with the target machine.
       This variable is set automatically and should not normally be
       hand-edited. Entries are separated using spaces and listed in order
       of priority. The default value for ``PACKAGE_ARCHS`` is "all any
       noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}".
-   
+
    PACKAGE_BEFORE_PN
       Enables easily adding packages to ``PACKAGES`` before ``${PN}`` so
       that those added packages can pick up files that would normally be
       included in the default package.
-   
+
    PACKAGE_CLASSES
       This variable, which is set in the ``local.conf`` configuration file
       found in the ``conf`` folder of the
       :term:`Build Directory`, specifies the package manager the
       OpenEmbedded build system uses when packaging data.
-   
+
       You can provide one or more of the following arguments for the
       variable: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk
       package_tar"
-   
+
       .. note::
-   
+
          While it is a legal option, the
          package_tar
          class has limited functionality due to no support for package
          dependencies by that backend. Therefore, it is recommended that
          you do not use it.
-   
+
       The build system uses only the first argument in the list as the
       package manager when creating your image or SDK. However, packages
       will be created using any additional packaging classes you specify.
       For example, if you use the following in your ``local.conf`` file:
-      PACKAGE_CLASSES ?= "package_ipk" The OpenEmbedded build system uses
+      ::
+
+         PACKAGE_CLASSES ?= "package_ipk"
+
+      The OpenEmbedded build system uses
       the IPK package manager to create your image or SDK.
-   
+
       For information on packaging and build performance effects as a
       result of the package manager in use, see the
       ":ref:`package.bbclass <ref-classes-package>`" section.
-   
+
    PACKAGE_DEBUG_SPLIT_STYLE
       Determines how to split up the binary and debug information when
       creating ``*-dbg`` packages to be used with the GNU Project Debugger
       (GDB).
-   
+
       With the ``PACKAGE_DEBUG_SPLIT_STYLE`` variable, you can control
       where debug information, which can include or exclude source files,
       is stored:
-   
+
       -  ".debug": Debug symbol files are placed next to the binary in a
          ``.debug`` directory on the target. For example, if a binary is
          installed into ``/bin``, the corresponding debug symbol files are
          installed in ``/bin/.debug``. Source files are placed in
          ``/usr/src/debug``.
-   
+
       -  "debug-file-directory": Debug symbol files are placed under
          ``/usr/lib/debug`` on the target, and separated by the path from
          where the binary is installed. For example, if a binary is
          installed in ``/bin``, the corresponding debug symbols are
          installed in ``/usr/lib/debug/bin``. Source files are placed in
          ``/usr/src/debug``.
-   
+
       -  "debug-without-src": The same behavior as ".debug" previously
          described with the exception that no source files are installed.
-   
+
       -  "debug-with-srcpkg": The same behavior as ".debug" previously
          described with the exception that all source files are placed in a
          separate ``*-src`` pkg. This is the default behavior.
-   
+
       You can find out more about debugging using GDB by reading the
-      "`Debugging With the GNU Project Debugger (GDB)
-      Remotely <&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug>`__" section
+      ":ref:`platdev-gdb-remotedebug`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGE_EXCLUDE_COMPLEMENTARY
       Prevents specific packages from being installed when you are
       installing complementary packages.
-   
+
       You might find that you want to prevent installing certain packages
       when you are installing complementary packages. For example, if you
       are using :term:`IMAGE_FEATURES` to install
@@ -4567,16 +5104,21 @@ system and gives an overview of their function and contents.
       particular multilib. If you find yourself in this situation, you can
       use the ``PACKAGE_EXCLUDE_COMPLEMENTARY`` variable to specify regular
       expressions to match the packages you want to exclude.
-   
+
    PACKAGE_EXCLUDE
       Lists packages that should not be installed into an image. For
-      example: PACKAGE_EXCLUDE = "package_name package_name package_name
-      ..."
-   
+      example:
+      ::
+
+         PACKAGE_EXCLUDE = "package_name package_name package_name ..."
+
       You can set this variable globally in your ``local.conf`` file or you
       can attach it to a specific image recipe by using the recipe name
-      override: PACKAGE_EXCLUDE_pn-target_image = "package_name"
-   
+      override:
+      ::
+
+         PACKAGE_EXCLUDE_pn-target_image = "package_name"
+
       If you choose to not install a package using this variable and some
       other package is dependent on it (i.e. listed in a recipe's
       :term:`RDEPENDS` variable), the OpenEmbedded build
@@ -4584,19 +5126,19 @@ system and gives an overview of their function and contents.
       halts the process with a fatal error, you can use the variable with
       an iterative development process to remove specific components from a
       system.
-   
+
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
-   
+
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`BAD_RECOMMENDATIONS` variables for
       related information.
-   
+
    PACKAGE_EXTRA_ARCHS
       Specifies the list of architectures compatible with the device CPU.
       This variable is useful when you build for several different devices
       that use miscellaneous processors such as XScale and ARM926-EJS.
-   
+
    PACKAGE_FEED_ARCHS
       Optionally specifies the package architectures used as part of the
       package feed URIs during the build. When used, the
@@ -4605,9 +5147,9 @@ system and gives an overview of their function and contents.
       :term:`PACKAGE_FEED_URIS` and
       :term:`PACKAGE_FEED_BASE_PATHS`
       variables.
-   
+
       .. note::
-   
+
          You can use the
          PACKAGE_FEEDS_ARCHS
          variable to whitelist specific package architectures. If you do
@@ -4615,73 +5157,91 @@ system and gives an overview of their function and contents.
          case, you can omit this variable. Omitting the variable results in
          all available architectures for the current machine being included
          into remote package feeds.
-   
+
       Consider the following example where the ``PACKAGE_FEED_URIS``,
       ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
-      defined in your ``local.conf`` file: PACKAGE_FEED_URIS =
-      "https://example.com/packagerepos/release \\
-      https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS =
-      "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these
-      settings, the resulting package feeds are as follows:
-      https://example.com/packagerepos/release/rpm/all
-      https://example.com/packagerepos/release/rpm/core2-64
-      https://example.com/packagerepos/release/rpm-dev/all
-      https://example.com/packagerepos/release/rpm-dev/core2-64
-      https://example.com/packagerepos/updates/rpm/all
-      https://example.com/packagerepos/updates/rpm/core2-64
-      https://example.com/packagerepos/updates/rpm-dev/all
-      https://example.com/packagerepos/updates/rpm-dev/core2-64
-   
+      defined in your ``local.conf`` file:
+      ::
+
+         PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                              https://example.com/packagerepos/updates"
+         PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+         PACKAGE_FEED_ARCHS = "all core2-64"
+
+      Given these settings, the resulting package feeds are as follows:
+      ::
+
+         https://example.com/packagerepos/release/rpm/all
+         https://example.com/packagerepos/release/rpm/core2-64
+         https://example.com/packagerepos/release/rpm-dev/all
+         https://example.com/packagerepos/release/rpm-dev/core2-64
+         https://example.com/packagerepos/updates/rpm/all
+         https://example.com/packagerepos/updates/rpm/core2-64
+         https://example.com/packagerepos/updates/rpm-dev/all
+         https://example.com/packagerepos/updates/rpm-dev/core2-64
+
    PACKAGE_FEED_BASE_PATHS
       Specifies the base path used when constructing package feed URIs. The
       ``PACKAGE_FEED_BASE_PATHS`` variable makes up the middle portion of a
       package feed URI used by the OpenEmbedded build system. The base path
       lies between the :term:`PACKAGE_FEED_URIS`
       and :term:`PACKAGE_FEED_ARCHS` variables.
-   
+
       Consider the following example where the ``PACKAGE_FEED_URIS``,
       ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
-      defined in your ``local.conf`` file: PACKAGE_FEED_URIS =
-      "https://example.com/packagerepos/release \\
-      https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS =
-      "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these
-      settings, the resulting package feeds are as follows:
-      https://example.com/packagerepos/release/rpm/all
-      https://example.com/packagerepos/release/rpm/core2-64
-      https://example.com/packagerepos/release/rpm-dev/all
-      https://example.com/packagerepos/release/rpm-dev/core2-64
-      https://example.com/packagerepos/updates/rpm/all
-      https://example.com/packagerepos/updates/rpm/core2-64
-      https://example.com/packagerepos/updates/rpm-dev/all
-      https://example.com/packagerepos/updates/rpm-dev/core2-64
-   
+      defined in your ``local.conf`` file:
+      ::
+
+         PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                              https://example.com/packagerepos/updates"
+         PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+         PACKAGE_FEED_ARCHS = "all core2-64"
+
+      Given these settings, the resulting package feeds are as follows:
+      ::
+
+         https://example.com/packagerepos/release/rpm/all
+         https://example.com/packagerepos/release/rpm/core2-64
+         https://example.com/packagerepos/release/rpm-dev/all
+         https://example.com/packagerepos/release/rpm-dev/core2-64
+         https://example.com/packagerepos/updates/rpm/all
+         https://example.com/packagerepos/updates/rpm/core2-64
+         https://example.com/packagerepos/updates/rpm-dev/all
+         https://example.com/packagerepos/updates/rpm-dev/core2-64
+
    PACKAGE_FEED_URIS
       Specifies the front portion of the package feed URI used by the
       OpenEmbedded build system. Each final package feed URI is comprised
       of ``PACKAGE_FEED_URIS``,
       :term:`PACKAGE_FEED_BASE_PATHS`, and
       :term:`PACKAGE_FEED_ARCHS` variables.
-   
+
       Consider the following example where the ``PACKAGE_FEED_URIS``,
       ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are
-      defined in your ``local.conf`` file: PACKAGE_FEED_URIS =
-      "https://example.com/packagerepos/release \\
-      https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS =
-      "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these
-      settings, the resulting package feeds are as follows:
-      https://example.com/packagerepos/release/rpm/all
-      https://example.com/packagerepos/release/rpm/core2-64
-      https://example.com/packagerepos/release/rpm-dev/all
-      https://example.com/packagerepos/release/rpm-dev/core2-64
-      https://example.com/packagerepos/updates/rpm/all
-      https://example.com/packagerepos/updates/rpm/core2-64
-      https://example.com/packagerepos/updates/rpm-dev/all
-      https://example.com/packagerepos/updates/rpm-dev/core2-64
-   
+      defined in your ``local.conf`` file:
+      ::
+
+         PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                              https://example.com/packagerepos/updates"
+         PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+         PACKAGE_FEED_ARCHS = "all core2-64"
+
+      Given these settings, the resulting package feeds are as follows:
+      ::
+
+         https://example.com/packagerepos/release/rpm/all
+         https://example.com/packagerepos/release/rpm/core2-64
+         https://example.com/packagerepos/release/rpm-dev/all
+         https://example.com/packagerepos/release/rpm-dev/core2-64
+         https://example.com/packagerepos/updates/rpm/all
+         https://example.com/packagerepos/updates/rpm/core2-64
+         https://example.com/packagerepos/updates/rpm-dev/all
+         https://example.com/packagerepos/updates/rpm-dev/core2-64
+
    PACKAGE_INSTALL
       The final list of packages passed to the package manager for
       installation into the image.
-   
+
       Because the package manager controls actual installation of all
       packages, the list of packages passed using ``PACKAGE_INSTALL`` is
       not the final list of packages that are actually installed. This
@@ -4693,21 +5253,20 @@ system and gives an overview of their function and contents.
       ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
       image. When working with an initial RAM filesystem (initramfs) image,
       use the ``PACKAGE_INSTALL`` variable. For information on creating an
-      initramfs, see the "`Building an Initial RAM Filesystem (initramfs)
-      Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section
+      initramfs, see the ":ref:`building-an-initramfs-image`" section
       in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGE_INSTALL_ATTEMPTONLY
       Specifies a list of packages the OpenEmbedded build system attempts
       to install when creating an image. If a listed package fails to
       install, the build system does not generate an error. This variable
       is generally not user-defined.
-   
+
    PACKAGE_PREPROCESS_FUNCS
       Specifies a list of functions run to pre-process the
       :term:`PKGD` directory prior to splitting the files out
       to individual packages.
-   
+
    PACKAGE_WRITE_DEPS
       Specifies a list of dependencies for post-installation and
       pre-installation scripts on native/cross tools. If your
@@ -4715,93 +5274,114 @@ system and gives an overview of their function and contents.
       creation time rather than on the target but depends on a native tool
       in order to execute, you need to list the tools in
       ``PACKAGE_WRITE_DEPS``.
-   
+
       For information on running post-installation scripts, see the
-      "`Post-Installation
-      Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGECONFIG
       This variable provides a means of enabling or disabling features of a
       recipe on a per-recipe basis. ``PACKAGECONFIG`` blocks are defined in
       recipes when you specify features and then arguments that define
       feature behaviors. Here is the basic block structure (broken over
-      multiple lines for readability): PACKAGECONFIG ??= "f1 f2 f3 ..."
-      PACKAGECONFIG[f1] = "\\ --with-f1, \\ --without-f1, \\
-      build-deps-for-f1, \\ runtime-deps-for-f1, \\
-      runtime-recommends-for-f1, \\ packageconfig-conflicts-for-f1 \\ "
-      PACKAGECONFIG[f2] = "\\ ... and so on and so on ...
-   
+      multiple lines for readability):
+      ::
+
+         PACKAGECONFIG ??= "f1 f2 f3 ..."
+         PACKAGECONFIG[f1] = "\
+             --with-f1, \
+             --without-f1, \
+             build-deps-for-f1, \
+             runtime-deps-for-f1, \
+             runtime-recommends-for-f1, \
+             packageconfig-conflicts-for-f1"
+         PACKAGECONFIG[f2] = "\
+              ... and so on and so on ...
+
       The ``PACKAGECONFIG`` variable itself specifies a space-separated
       list of the features to enable. Following the features, you can
       determine the behavior of each feature by providing up to six
       order-dependent arguments, which are separated by commas. You can
       omit any argument you like but must retain the separating commas. The
       order is important and specifies the following:
-   
+
       1. Extra arguments that should be added to the configure script
          argument list (:term:`EXTRA_OECONF` or
          :term:`PACKAGECONFIG_CONFARGS`) if
          the feature is enabled.
-   
+
       2. Extra arguments that should be added to ``EXTRA_OECONF`` or
          ``PACKAGECONFIG_CONFARGS`` if the feature is disabled.
-   
+
       3. Additional build dependencies (:term:`DEPENDS`)
          that should be added if the feature is enabled.
-   
+
       4. Additional runtime dependencies (:term:`RDEPENDS`)
          that should be added if the feature is enabled.
-   
+
       5. Additional runtime recommendations
          (:term:`RRECOMMENDS`) that should be added if
          the feature is enabled.
-   
+
       6. Any conflicting (that is, mutually exclusive) ``PACKAGECONFIG``
          settings for this feature.
-   
+
       Consider the following ``PACKAGECONFIG`` block taken from the
       ``librsvg`` recipe. In this example the feature is ``gtk``, which has
       three arguments that determine the feature's behavior.
-      PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" The
+      ::
+
+         PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3"
+
+      The
       ``--with-gtk3`` and ``gtk+3`` arguments apply only if the feature is
       enabled. In this case, ``--with-gtk3`` is added to the configure
       script argument list and ``gtk+3`` is added to ``DEPENDS``. On the
       other hand, if the feature is disabled say through a ``.bbappend``
       file in another layer, then the second argument ``--without-gtk3`` is
       added to the configure script instead.
-   
+
       The basic ``PACKAGECONFIG`` structure previously described holds true
       regardless of whether you are creating a block or changing a block.
       When creating a block, use the structure inside your recipe.
-   
+
       If you want to change an existing ``PACKAGECONFIG`` block, you can do
       so one of two ways:
-   
+
       -  *Append file:* Create an append file named
          recipename\ ``.bbappend`` in your layer and override the value of
          ``PACKAGECONFIG``. You can either completely override the
-         variable: PACKAGECONFIG = "f4 f5" Or, you can just append the
-         variable: PACKAGECONFIG_append = " f4"
-   
+         variable:
+         ::
+
+            PACKAGECONFIG = "f4 f5"
+
+         Or, you can just append the variable:
+         ::
+
+            PACKAGECONFIG_append = " f4"
+
       -  *Configuration file:* This method is identical to changing the
          block through an append file except you edit your ``local.conf``
          or ``mydistro.conf`` file. As with append files previously
          described, you can either completely override the variable:
          PACKAGECONFIG_pn-recipename = "f4 f5" Or, you can just amend the
-         variable: PACKAGECONFIG_append_pn-recipename = " f4"
-   
+         variable:
+         ::
+
+            PACKAGECONFIG_append_pn-recipename = " f4"
+
    PACKAGECONFIG_CONFARGS
       A space-separated list of configuration options generated from the
       :term:`PACKAGECONFIG` setting.
-   
+
       Classes such as :ref:`autotools <ref-classes-autotools>` and
       :ref:`cmake <ref-classes-cmake>` use ``PACKAGECONFIG_CONFARGS`` to
       pass ``PACKAGECONFIG`` options to ``configure`` and ``cmake``,
       respectively. If you are using ``PACKAGECONFIG`` but not a class that
       handles the ``do_configure`` task, then you need to use
       ``PACKAGECONFIG_CONFARGS`` appropriately.
-   
+
    PACKAGEGROUP_DISABLE_COMPLEMENTARY
       For recipes inheriting the
       :ref:`packagegroup <ref-classes-packagegroup>` class, setting
@@ -4809,25 +5389,27 @@ system and gives an overview of their function and contents.
       normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth)
       should not be automatically created by the ``packagegroup`` recipe,
       which is the default behavior.
-   
+
    PACKAGES
       The list of packages the recipe creates. The default value is the
-      following: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale
-      ${PACKAGE_BEFORE_PN} ${PN}
-   
+      following:
+      ::
+
+         ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
+
       During packaging, the :ref:`ref-tasks-package` task
       goes through ``PACKAGES`` and uses the :term:`FILES`
       variable corresponding to each package to assign files to the
       package. If a file matches the ``FILES`` variable for more than one
       package in ``PACKAGES``, it will be assigned to the earliest
       (leftmost) package.
-   
+
       Packages in the variable's list that are empty (i.e. where none of
       the patterns in ``FILES_``\ pkg match any files installed by the
       :ref:`ref-tasks-install` task) are not generated,
       unless generation is forced through the
       :term:`ALLOW_EMPTY` variable.
-   
+
    PACKAGES_DYNAMIC
       A promise that your recipe satisfies runtime dependencies for
       optional modules that are found in other recipes.
@@ -4840,17 +5422,17 @@ system and gives an overview of their function and contents.
       to include that package in an image, you will get a dependency
       failure from the packaging system during the
       :ref:`ref-tasks-rootfs` task.
-   
+
       Typically, if there is a chance that such a situation can occur and
       the package that is not created is valid without the dependency being
       satisfied, then you should use :term:`RRECOMMENDS`
       (a soft runtime dependency) instead of ``RDEPENDS``.
-   
+
       For an example of how to use the ``PACKAGES_DYNAMIC`` variable when
-      you are splitting packages, see the "`Handling Optional Module
-      Packaging <&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging>`__"
+      you are splitting packages, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:handling optional module packaging`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    PACKAGESPLITFUNCS
       Specifies a list of functions run to perform additional splitting of
       files into individual packages. Recipes can either prepend to this
@@ -4860,16 +5442,16 @@ system and gives an overview of their function and contents.
       :term:`FILES`, :term:`RDEPENDS` and
       other packaging variables appropriately in order to perform the
       desired splitting.
-   
+
    PARALLEL_MAKE
       Extra options passed to the ``make`` command during the
       :ref:`ref-tasks-compile` task in order to specify
       parallel compilation on the local build host. This variable is
       usually in the form "-j x", where x represents the maximum number of
       parallel threads ``make`` can run.
-   
+
       .. note::
-   
+
          In order for
          PARALLEL_MAKE
          to be effective,
@@ -4881,12 +5463,12 @@ system and gives an overview of their function and contents.
          . An easy way to ensure this is to use the
          oe_runmake
          function.
-   
+
       By default, the OpenEmbedded build system automatically sets this
       variable to be equal to the number of cores the build system uses.
-   
+
       .. note::
-   
+
          If the software being built experiences dependency issues during
          the
          do_compile
@@ -4896,50 +5478,49 @@ system and gives an overview of their function and contents.
          addressing race conditions, see the "
          Debugging Parallel Make Races
          " section in the Yocto Project Development Tasks Manual.
-   
+
       For single socket systems (i.e. one CPU), you should not have to
       override this variable to gain optimal parallelism during builds.
       However, if you have very large systems that employ multiple physical
       CPUs, you might want to make sure the ``PARALLEL_MAKE`` variable is
       not set higher than "-j 20".
-   
-      For more information on speeding up builds, see the "`Speeding Up a
-      Build <&YOCTO_DOCS_DEV_URL;#speeding-up-a-build>`__" section in the
-      Yocto Project Development Tasks Manual.
-   
+
+      For more information on speeding up builds, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+      section in the Yocto Project Development Tasks Manual.
+
    PARALLEL_MAKEINST
       Extra options passed to the ``make install`` command during the
       :ref:`ref-tasks-install` task in order to specify
       parallel installation. This variable defaults to the value of
       :term:`PARALLEL_MAKE`.
-   
+
       .. note::
-   
+
          In order for ``PARALLEL_MAKEINST`` to be effective, ``make`` must
          be called with
          ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy
          way to ensure this is to use the ``oe_runmake`` function.
-   
+
          If the software being built experiences dependency issues during
          the ``do_install`` task that result in race conditions, you can
          clear the ``PARALLEL_MAKEINST`` variable within the recipe as a
          workaround. For information on addressing race conditions, see the
-         "`Debugging Parallel Make
-         Races <&YOCTO_DOCS_DEV_URL;#debugging-parallel-make-races>`__"
+         ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
          section in the Yocto Project Development Tasks Manual.
-   
+
    PATCHRESOLVE
       Determines the action to take when a patch fails. You can set this
       variable to one of two values: "noop" and "user".
-   
+
       The default value of "noop" causes the build to simply fail when the
       OpenEmbedded build system cannot successfully apply a patch. Setting
       the value to "user" causes the build system to launch a shell and
       places you in the right location so that you can manually resolve the
       conflicts.
-   
+
       Set this variable in your ``local.conf`` file.
-   
+
    PATCHTOOL
       Specifies the utility used to apply patches for a recipe during the
       :ref:`ref-tasks-patch` task. You can specify one of
@@ -4947,24 +5528,28 @@ system and gives an overview of their function and contents.
       is "quilt" except for the quilt-native recipe itself. Because the
       quilt tool is not available at the time quilt-native is being
       patched, it uses "patch".
-   
+
       If you wish to use an alternative patching tool, set the variable in
-      the recipe using one of the following: PATCHTOOL = "patch" PATCHTOOL
-      = "quilt" PATCHTOOL = "git"
-   
+      the recipe using one of the following:
+      ::
+
+         PATCHTOOL = "patch"
+         PATCHTOOL = "quilt"
+         PATCHTOOL = "git"
+
    PE
       The epoch of the recipe. By default, this variable is unset. The
       variable is used to make upgrades possible when the versioning scheme
       changes in some backwards incompatible way.
-   
+
       ``PE`` is the default value of the :term:`PKGE` variable.
-   
+
    PF
       Specifies the recipe or package name and includes all version and
       revision numbers (i.e. ``glibc-2.13-r20+svnr15508/`` and
       ``bash-4.2-r1/``). This variable is comprised of the following:
       ${:term:`PN`}-${:term:`EXTENDPE`}${:term:`PV`}-${:term:`PR`}
-   
+
    PIXBUF_PACKAGES
       When inheriting the :ref:`pixbufcache <ref-classes-pixbufcache>`
       class, this variable identifies packages that contain the pixbuf
@@ -4972,139 +5557,158 @@ system and gives an overview of their function and contents.
       class assumes that the loaders are in the recipe's main package (i.e.
       ``${``\ :term:`PN`\ ``}``). Use this variable if the
       loaders you need are in a package other than that main package.
-   
+
    PKG
       The name of the resulting package created by the OpenEmbedded build
       system.
-   
+
       .. note::
-   
+
          When using the
          PKG
          variable, you must use a package name override.
-   
+
       For example, when the :ref:`debian <ref-classes-debian>` class
       renames the output package, it does so by setting
       ``PKG_packagename``.
-   
+
    PKG_CONFIG_PATH
       The path to ``pkg-config`` files for the current build context.
       ``pkg-config`` reads this variable from the environment.
-   
+
    PKGD
       Points to the destination directory for files to be packaged before
       they are split into individual packages. This directory defaults to
-      the following: ${WORKDIR}/package
-   
+      the following:
+      ::
+
+         ${WORKDIR}/package
+
       Do not change this default.
-   
+
    PKGDATA_DIR
       Points to a shared, global-state directory that holds data generated
       during the packaging process. During the packaging process, the
       :ref:`ref-tasks-packagedata` task packages data
       for each recipe and installs it into this temporary, shared area.
       This directory defaults to the following, which you should not
-      change: ${STAGING_DIR_HOST}/pkgdata For examples of how this data is
-      used, see the "`Automatically Added Runtime
-      Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+      change:
+      ::
+
+         ${STAGING_DIR_HOST}/pkgdata
+
+      For examples of how this data is used, see the
+      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual and the
-      "`Viewing Package Information with
-      ``oe-pkgdata-util`` <&YOCTO_DOCS_DEV_URL;#viewing-package-information-with-oe-pkgdata-util>`__"
+      ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
       section in the Yocto Project Development Tasks Manual. For more
       information on the shared, global-state directory, see
       :term:`STAGING_DIR_HOST`.
-   
+
    PKGDEST
       Points to the parent directory for files to be packaged after they
       have been split into individual packages. This directory defaults to
-      the following: ${WORKDIR}/packages-split
-   
+      the following:
+      ::
+
+         ${WORKDIR}/packages-split
+
       Under this directory, the build system creates directories for each
       package specified in :term:`PACKAGES`. Do not change
       this default.
-   
+
    PKGDESTWORK
       Points to a temporary work area where the
       :ref:`ref-tasks-package` task saves package metadata.
       The ``PKGDESTWORK`` location defaults to the following:
-      ${WORKDIR}/pkgdata Do not change this default.
-   
+      ::
+
+         ${WORKDIR}/pkgdata
+
+      Do not change this default.
+
       The :ref:`ref-tasks-packagedata` task copies the
       package metadata from ``PKGDESTWORK`` to
       :term:`PKGDATA_DIR` to make it available globally.
-   
+
    PKGE
       The epoch of the package(s) built by the recipe. By default, ``PKGE``
       is set to :term:`PE`.
-   
+
    PKGR
       The revision of the package(s) built by the recipe. By default,
       ``PKGR`` is set to :term:`PR`.
-   
+
    PKGV
       The version of the package(s) built by the recipe. By default,
       ``PKGV`` is set to :term:`PV`.
-   
+
    PN
       This variable can have two separate functions depending on the
       context: a recipe name or a resulting package name.
-   
+
       ``PN`` refers to a recipe name in the context of a file used by the
       OpenEmbedded build system as input to create a package. The name is
       normally extracted from the recipe file name. For example, if the
       recipe is named ``expat_2.0.1.bb``, then the default value of ``PN``
       will be "expat".
-   
+
       The variable refers to a package name in the context of a file
       created or produced by the OpenEmbedded build system.
-   
+
       If applicable, the ``PN`` variable also contains any special suffix
       or prefix. For example, using ``bash`` to build packages for the
       native machine, ``PN`` is ``bash-native``. Using ``bash`` to build
       packages for the target and for Multilib, ``PN`` would be ``bash``
       and ``lib64-bash``, respectively.
-   
+
    PNBLACKLIST
       Lists recipes you do not want the OpenEmbedded build system to build.
       This variable works in conjunction with the
       :ref:`blacklist <ref-classes-blacklist>` class, which is inherited
       globally.
-   
+
       To prevent a recipe from being built, use the ``PNBLACKLIST``
       variable in your ``local.conf`` file. Here is an example that
-      prevents ``myrecipe`` from being built: PNBLACKLIST[myrecipe] = "Not
-      supported by our organization."
-   
+      prevents ``myrecipe`` from being built:
+      ::
+
+         PNBLACKLIST[myrecipe] = "Not supported by our organization."
+
    POPULATE_SDK_POST_HOST_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the host part of the SDK. You can specify
-      functions separated by semicolons: POPULATE_SDK_POST_HOST_COMMAND +=
-      "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+          POPULATE_SDK_POST_HOST_COMMAND += "function; ... "
+
       If you need to pass the SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
       the OpenEmbedded build system when creating SDK output. See the
       :term:`SDK_DIR` variable for more information.
-   
+
    POPULATE_SDK_POST_TARGET_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the target part of the SDK. You can specify
-      functions separated by semicolons: POPULATE_SDK_POST_TARGET_COMMAND
-      += "function; ... "
-   
+      functions separated by semicolons:
+      ::
+
+         POPULATE_SDK_POST_TARGET_COMMAND += "function; ... "
+
       If you need to pass the SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
       the OpenEmbedded build system when creating SDK output. See the
       :term:`SDK_DIR` variable for more information.
-   
+
    PR
       The revision of the recipe. The default value for this variable is
       "r0". Subsequent revisions of the recipe conventionally have the
       values "r1", "r2", and so forth. When :term:`PV` increases,
       ``PR`` is conventionally reset to "r0".
-   
+
       .. note::
-   
+
          The OpenEmbedded build system does not need the aid of
          PR
          to know when to rebuild a recipe. The build system uses the task
@@ -5114,7 +5718,7 @@ system and gives an overview of their function and contents.
          and
          shared state cache
          mechanisms.
-   
+
       The ``PR`` variable primarily becomes significant when a package
       manager dynamically installs packages on an already built image. In
       this case, ``PR``, which is the default value of
@@ -5124,37 +5728,45 @@ system and gives an overview of their function and contents.
       the same ``PV`` usually means that the packages all install the same
       upstream version, but with later (``PR``) version packages including
       packaging fixes.
-   
+
       .. note::
-   
+
          PR
          does not need to be increased for changes that do not change the
          package contents or metadata.
-   
+
       Because manually managing ``PR`` can be cumbersome and error-prone,
-      an automated solution exists. See the "`Working With a PR
-      Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section
+      an automated solution exists. See the
+      ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" section
       in the Yocto Project Development Tasks Manual for more information.
-   
+
    PREFERRED_PROVIDER
       If multiple recipes provide the same item, this variable determines
       which recipe is preferred and thus provides the item (i.e. the
       preferred provider). You should always suffix this variable with the
       name of the provided item. And, you should define the variable using
       the preferred recipe's name (:term:`PN`). Here is a common
-      example: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" In the
-      previous example, multiple recipes are providing "virtual/kernel".
+      example:
+      ::
+
+         PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+
+      In the previous example, multiple recipes are providing "virtual/kernel".
       The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of
       the recipe you prefer to provide "virtual/kernel".
-   
-      Following are more examples: PREFERRED_PROVIDER_virtual/xserver =
-      "xserver-xf86" PREFERRED_PROVIDER_virtual/libgl ?= "mesa" For more
-      information, see the "`Using Virtual
-      Providers <&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers>`__"
+
+      Following are more examples:
+      ::
+
+         PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
+         PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
+
+      For more
+      information, see the ":ref:`metadata-virtual-providers`"
       section in the Yocto Project Development Tasks Manual.
-   
+
       .. note::
-   
+
          If you use a
          virtual/\*
          item with
@@ -5166,56 +5778,69 @@ system and gives an overview of their function and contents.
          is prevented from building, which is usually desirable since this
          mechanism is designed to select between mutually exclusive
          alternative providers.
-   
+
    PREFERRED_VERSION
       If multiple versions of recipes exist, this variable determines which
       version is given preference. You must always suffix the variable with
       the :term:`PN` you want to select, and you should set the
       :term:`PV` accordingly for precedence.
-   
+
       The ``PREFERRED_VERSION`` variable supports limited wildcard use
       through the "``%``" character. You can use the character to match any
       number of characters, which can be useful when specifying versions
       that contain long revision numbers that potentially change. Here are
-      two examples: PREFERRED_VERSION_python = "3.4.0"
-      PREFERRED_VERSION_linux-yocto = "5.0%"
-   
+      two examples:
+      ::
+
+         PREFERRED_VERSION_python = "3.4.0"
+         PREFERRED_VERSION_linux-yocto = "5.0%"
+
       .. note::
-   
-         The use of the "
-         %
-         " character is limited in that it only works at the end of the
+
+         The use of the "%" character is limited in that it only works at the end of the
          string. You cannot use the wildcard character in any other
          location of the string.
-   
+
       The specified version is matched against :term:`PV`, which
       does not necessarily match the version part of the recipe's filename.
       For example, consider two recipes ``foo_1.2.bb`` and ``foo_git.bb``
-      where ``foo_git.bb`` contains the following assignment: PV =
-      "1.1+git${SRCPV}" In this case, the correct way to select
+      where ``foo_git.bb`` contains the following assignment:
+      ::
+
+         PV = "1.1+git${SRCPV}"
+
+      In this case, the correct way to select
       ``foo_git.bb`` is by using an assignment such as the following:
-      PREFERRED_VERSION_foo = "1.1+git%" Compare that previous example
+      ::
+
+         PREFERRED_VERSION_foo = "1.1+git%"
+
+      Compare that previous example
       against the following incorrect example, which does not work:
-      PREFERRED_VERSION_foo = "git"
-   
+      ::
+
+         PREFERRED_VERSION_foo = "git"
+
       Sometimes the ``PREFERRED_VERSION`` variable can be set by
       configuration files in a way that is hard to change. You can use
       :term:`OVERRIDES` to set a machine-specific
-      override. Here is an example: PREFERRED_VERSION_linux-yocto_qemux86 =
-      "5.0%" Although not recommended, worst case, you can also use the
+      override. Here is an example:
+      ::
+
+         PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%"
+
+      Although not recommended, worst case, you can also use the
       "forcevariable" override, which is the strongest override possible.
-      Here is an example: PREFERRED_VERSION_linux-yocto_forcevariable =
-      "5.0%"
-   
+      Here is an example:
+      ::
+
+         PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%"
+
       .. note::
-   
-         The
-         \_forcevariable
-         override is not handled specially. This override only works
-         because the default value of
-         OVERRIDES
-         includes "forcevariable".
-   
+
+         The \_forcevariable override is not handled specially. This override
+         only works because the default value of OVERRIDES includes "forcevariable".
+
    PREMIRRORS
       Specifies additional paths from which the OpenEmbedded build system
       gets source code. When the build system searches for source code, it
@@ -5223,35 +5848,40 @@ system and gives an overview of their function and contents.
       build system tries locations defined by ``PREMIRRORS``, the upstream
       source, and then locations specified by
       :term:`MIRRORS` in that order.
-   
+
       Assuming your distribution (:term:`DISTRO`) is "poky",
       the default value for ``PREMIRRORS`` is defined in the
       ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
-   
+
       Typically, you could add a specific server for the build system to
       attempt before any others by adding something like the following to
       the ``local.conf`` configuration file in the
-      :term:`Build Directory`: PREMIRRORS_prepend = "\\
-      git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\*
-      http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\*
-      http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\*
-      http://www.yoctoproject.org/sources/ \\n" These changes cause the
+      :term:`Build Directory`:
+      ::
+
+         PREMIRRORS_prepend = "\
+             git://.*/.* http://www.yoctoproject.org/sources/ \n \
+             ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+             http://.*/.* http://www.yoctoproject.org/sources/ \n \
+             https://.*/.* http://www.yoctoproject.org/sources/ \n"
+
+      These changes cause the
       build system to intercept Git, FTP, HTTP, and HTTPS requests and
       direct them to the ``http://`` sources mirror. You can use
       ``file://`` URLs to point to local directories or network shares as
       well.
-   
+
    PRIORITY
       Indicates the importance of a package.
-   
+
       ``PRIORITY`` is considered to be part of the distribution policy
       because the importance of any given recipe depends on the purpose for
       which the distribution is being produced. Thus, ``PRIORITY`` is not
       normally set within recipes.
-   
+
       You can set ``PRIORITY`` to "required", "standard", "extra", and
       "optional", which is the default.
-   
+
    PRIVATE_LIBS
       Specifies libraries installed within a recipe that should be ignored
       by the OpenEmbedded build system's shared library resolver. This
@@ -5261,16 +5891,23 @@ system and gives an overview of their function and contents.
       private libraries to be set as a dependency on other unrelated
       packages that should instead depend on the package providing the
       standard version of the library.
-   
+
       Libraries specified in this variable should be specified by their
       file name. For example, from the Firefox recipe in meta-browser:
-      PRIVATE_LIBS = "libmozjs.so \\ libxpcom.so \\ libnspr4.so \\
-      libxul.so \\ libmozalloc.so \\ libplc4.so \\ libplds4.so"
-   
-      For more information, see the "`Automatically Added Runtime
-      Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+      ::
+
+         PRIVATE_LIBS = "libmozjs.so \
+                         libxpcom.so \
+                         libnspr4.so \
+                         libxul.so \
+                         libmozalloc.so \
+                         libplc4.so \
+                         libplds4.so"
+
+      For more information, see the
+      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
    PROVIDES
       A list of aliases by which a particular recipe can be known. By
       default, a recipe's own ``PN`` is implicitly already in its
@@ -5279,13 +5916,18 @@ system and gives an overview of their function and contents.
       aliases are synonyms for the recipe and can be useful for satisfying
       dependencies of other recipes during the build as specified by
       ``DEPENDS``.
-   
+
       Consider the following example ``PROVIDES`` statement from the recipe
-      file ``eudev_3.2.9.bb``: PROVIDES = "udev" The ``PROVIDES`` statement
+      file ``eudev_3.2.9.bb``:
+      ::
+
+         PROVIDES = "udev"
+
+      The ``PROVIDES`` statement
       results in the "eudev" recipe also being available as simply "udev".
-   
+
       .. note::
-   
+
          Given that a recipe's own recipe name is already implicitly in its
          own
          PROVIDES
@@ -5293,12 +5935,12 @@ system and gives an overview of their function and contents.
          using a simple assignment will be sufficient. In other words,
          while you could write:
          ::
-   
+
                  PROVIDES += "udev"
-                                    
-   
+
+
          in the above, the "+=" is overkill and unnecessary.
-   
+
       In addition to providing recipes under alternate names, the
       ``PROVIDES`` mechanism is also used to implement virtual targets. A
       virtual target is a name that corresponds to some particular
@@ -5306,48 +5948,52 @@ system and gives an overview of their function and contents.
       functionality in question list the virtual target in ``PROVIDES``.
       Recipes that depend on the functionality in question can include the
       virtual target in ``DEPENDS`` to leave the choice of provider open.
-   
+
       Conventionally, virtual targets have names on the form
       "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
       of the name and has no syntactical significance.
-   
+
       The :term:`PREFERRED_PROVIDER` variable is
       used to select which particular recipe provides a virtual target.
-   
+
       .. note::
-   
+
          A corresponding mechanism for virtual runtime dependencies
          (packages) exists. However, the mechanism does not depend on any
          special functionality beyond ordinary variable assignments. For
          example, ``VIRTUAL-RUNTIME_dev_manager`` refers to the package of
          the component that manages the ``/dev`` directory.
-   
+
          Setting the "preferred provider" for runtime dependencies is as
          simple as using the following assignment in a configuration file:
-   
          ::
-   
+
                  VIRTUAL-RUNTIME_dev_manager = "udev"
-                                    
-   
+
+
    PRSERV_HOST
       The network based :term:`PR` service host and port.
-   
+
       The ``conf/local.conf.sample.extended`` configuration file in the
       :term:`Source Directory` shows how the
-      ``PRSERV_HOST`` variable is set: PRSERV_HOST = "localhost:0" You must
-      set the variable if you want to automatically start a local `PR
-      service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__. You can
+      ``PRSERV_HOST`` variable is set:
+      ::
+
+         PRSERV_HOST = "localhost:0"
+
+      You must
+      set the variable if you want to automatically start a local :ref:`PR
+      service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
       set ``PRSERV_HOST`` to other values to use a remote PR service.
-   
+
    PTEST_ENABLED
-      Specifies whether or not `Package
-      Test <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__ (ptest)
+      Specifies whether or not :ref:`Package
+      Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
       functionality is enabled when building a recipe. You should not set
       this variable directly. Enabling and disabling building Package Tests
       at build time should be done by adding "ptest" to (or removing it
       from) :term:`DISTRO_FEATURES`.
-   
+
    PV
       The version of the recipe. The version is normally extracted from the
       recipe filename. For example, if the recipe is named
@@ -5355,9 +6001,9 @@ system and gives an overview of their function and contents.
       ``PV`` is generally not overridden within a recipe unless it is
       building an unstable (i.e. development) version from a source code
       repository (e.g. Git or Subversion).
-   
+
       ``PV`` is the default value of the :term:`PKGV` variable.
-   
+
    PYTHON_ABI
       When used by recipes that inherit the
       :ref:`distutils3 <ref-classes-distutils3>`,
@@ -5367,15 +6013,15 @@ system and gives an overview of their function and contents.
       Application Binary Interface (ABI) currently in use for Python. By
       default, the ABI is "m". You do not have to set this variable as the
       OpenEmbedded build system sets it for you.
-   
+
       The OpenEmbedded build system uses the ABI to construct directory
       names used when installing the Python headers and libraries in
       sysroot (e.g. ``.../python3.3m/...``).
-   
+
       Recipes that inherit the ``distutils`` class during cross-builds also
       use this variable to locate the headers and libraries of the
       appropriate Python that the extension is targeting.
-   
+
    PYTHON_PN
       When used by recipes that inherit the
       `distutils3 <ref-classes-distutils3>`,
@@ -5385,43 +6031,62 @@ system and gives an overview of their function and contents.
       major Python version being built. For Python 3.x, ``PYTHON_PN`` would
       be "python3". You do not have to set this variable as the
       OpenEmbedded build system automatically sets it for you.
-   
+
       The variable allows recipes to use common infrastructure such as the
-      following: DEPENDS += "${PYTHON_PN}-native" In the previous example,
+      following:
+      ::
+
+         DEPENDS += "${PYTHON_PN}-native"
+
+      In the previous example,
       the version of the dependency is ``PYTHON_PN``.
-   
+
    RANLIB
       The minimal command and arguments to run ``ranlib``.
-   
+
    RCONFLICTS
       The list of packages that conflict with packages. Note that packages
       will not be installed if conflicting packages are not first removed.
-   
+
       Like all package-controlling variables, you must always use them in
       conjunction with a package name override. Here is an example:
-      RCONFLICTS_${PN} = "another_conflicting_package_name"
-   
+      ::
+
+         RCONFLICTS_${PN} = "another_conflicting_package_name"
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned dependencies. Although the syntax varies
       depending on the packaging format, BitBake hides these differences
       from you. Here is the general syntax to specify versions with the
-      ``RCONFLICTS`` variable: RCONFLICTS_${PN} = "package (operator
-      version)" For ``operator``, you can specify the following: = < > <=
+      ``RCONFLICTS`` variable:
+      ::
+
+         RCONFLICTS_${PN} = "package (operator version)"
+
+      For ``operator``, you can specify the following: = < > <=
       >= For example, the following sets up a dependency on version 1.2 or
-      greater of the package ``foo``: RCONFLICTS_${PN} = "foo (>= 1.2)"
-   
+      greater of the package ``foo``:
+      ::
+
+         RCONFLICTS_${PN} = "foo (>= 1.2)"
+
    RDEPENDS
       Lists runtime dependencies of a package. These dependencies are other
       packages that must be installed in order for the package to function
       correctly. As an example, the following assignment declares that the
       package ``foo`` needs the packages ``bar`` and ``baz`` to be
-      installed: RDEPENDS_foo = "bar baz" The most common types of package
+      installed:
+      ::
+
+         RDEPENDS_foo = "bar baz"
+
+      The most common types of package
       runtime dependencies are automatically detected and added. Therefore,
       most recipes do not need to set ``RDEPENDS``. For more information,
-      see the "`Automatically Added Runtime
-      Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__"
+      see the
+      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
       The practical effect of the above ``RDEPENDS`` assignment is that
       ``bar`` and ``baz`` will be declared as dependencies inside the
       package ``foo`` when it is written out by one of the
@@ -5431,7 +6096,7 @@ system and gives an overview of their function and contents.
       :term:`PACKAGE_CLASSES`. When the
       corresponding package manager installs the package, it will know to
       also install the packages on which it depends.
-   
+
       To ensure that the packages ``bar`` and ``baz`` get built, the
       previous ``RDEPENDS`` assignment also causes a task dependency to be
       added. This dependency is from the recipe's
@@ -5439,26 +6104,31 @@ system and gives an overview of their function and contents.
       :ref:`ref-tasks-compile`) task to the
       ``do_package_write_*`` task of the recipes that build ``bar`` and
       ``baz``.
-   
+
       The names of the packages you list within ``RDEPENDS`` must be the
       names of other packages - they cannot be recipe names. Although
       package names and recipe names usually match, the important point
       here is that you are providing package names within the ``RDEPENDS``
       variable. For an example of the default list of packages created from
       a recipe, see the :term:`PACKAGES` variable.
-   
+
       Because the ``RDEPENDS`` variable applies to packages being built,
       you should always use the variable in a form with an attached package
       name (remember that a single recipe can build multiple packages). For
       example, suppose you are building a development package that depends
       on the ``perl`` package. In this case, you would use the following
-      ``RDEPENDS`` statement: RDEPENDS_${PN}-dev += "perl" In the example,
+      ``RDEPENDS`` statement:
+      ::
+
+         RDEPENDS_${PN}-dev += "perl"
+
+      In the example,
       the development package depends on the ``perl`` package. Thus, the
       ``RDEPENDS`` variable has the ``${PN}-dev`` package name as part of
       the variable.
-   
+
       .. note::
-   
+
          RDEPENDS_${PN}-dev
          includes
          ${
@@ -5472,7 +6142,7 @@ system and gives an overview of their function and contents.
          when modifying
          RDEPENDS_${PN}-dev
          . Use the "+=" operator rather than the "=" operator.
-   
+
       The package names you use with ``RDEPENDS`` must appear as they would
       in the ``PACKAGES`` variable. The :term:`PKG` variable
       allows a different name to be used for the final package (e.g. the
@@ -5480,31 +6150,38 @@ system and gives an overview of their function and contents.
       packages), but this final package name cannot be used with
       ``RDEPENDS``, which makes sense as ``RDEPENDS`` is meant to be
       independent of the package format used.
-   
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned dependencies. Although the syntax varies
       depending on the packaging format, BitBake hides these differences
       from you. Here is the general syntax to specify versions with the
-      ``RDEPENDS`` variable: RDEPENDS_${PN} = "package (operator version)"
+      ``RDEPENDS`` variable:
+      ::
+
+         RDEPENDS_${PN} = "package (operator version)"
+
       For operator, you can specify the following: = < > <= >= For version,
       provide the version number.
-   
+
       .. note::
-   
+
          You can use
          EXTENDPKGV
          to provide a full package version specification.
-   
+
       For example, the following sets up a dependency on version 1.2 or
-      greater of the package ``foo``: RDEPENDS_${PN} = "foo (>= 1.2)"
-   
+      greater of the package ``foo``:
+      ::
+
+         RDEPENDS_${PN} = "foo (>= 1.2)"
+
       For information on build-time dependencies, see the
       :term:`DEPENDS` variable. You can also see the
       ":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and
       ":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the
       BitBake User Manual for additional information on tasks and
       dependencies.
-   
+
    REQUIRED_DISTRO_FEATURES
       When inheriting the
       :ref:`distro_features_check <ref-classes-distro_features_check>`
@@ -5514,115 +6191,136 @@ system and gives an overview of their function and contents.
       ``REQUIRED_DISTRO_FEATURES`` variable lists a feature that does not
       appear in ``DISTRO_FEATURES`` within the current configuration, an
       error occurs and the build stops.
-   
+
    RM_WORK_EXCLUDE
       With ``rm_work`` enabled, this variable specifies a list of recipes
       whose work directories should not be removed. See the
       ":ref:`rm_work.bbclass <ref-classes-rm-work>`" section for more
       details.
-   
+
    ROOT_HOME
       Defines the root home directory. By default, this directory is set as
-      follows in the BitBake configuration file: ROOT_HOME ??= "/home/root"
-   
+      follows in the BitBake configuration file:
+      ::
+
+         ROOT_HOME ??= "/home/root"
+
       .. note::
-   
+
          This default value is likely used because some embedded solutions
          prefer to have a read-only root filesystem and prefer to keep
          writeable data in one place.
-   
+
       You can override the default by setting the variable in any layer or
       in the ``local.conf`` file. Because the default is set using a "weak"
       assignment (i.e. "??="), you can use either of the following forms to
-      define your override: ROOT_HOME = "/root" ROOT_HOME ?= "/root" These
+      define your override:
+      ::
+
+         ROOT_HOME = "/root"
+         ROOT_HOME ?= "/root"
+
+      These
       override examples use ``/root``, which is probably the most commonly
       used override.
-   
+
    ROOTFS
       Indicates a filesystem image to include as the root filesystem.
-   
+
       The ``ROOTFS`` variable is an optional variable used with the
       :ref:`image-live <ref-classes-image-live>` class.
-   
+
    ROOTFS_POSTINSTALL_COMMAND
       Specifies a list of functions to call after the OpenEmbedded build
       system has installed packages. You can specify functions separated by
-      semicolons: ROOTFS_POSTINSTALL_COMMAND += "function; ... "
-   
+      semicolons:
+      ::
+
+         ROOTFS_POSTINSTALL_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    ROOTFS_POSTPROCESS_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the root filesystem. You can specify functions
-      separated by semicolons: ROOTFS_POSTPROCESS_COMMAND += "function; ...
-      "
-   
+      separated by semicolons:
+      ::
+
+         ROOTFS_POSTPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    ROOTFS_POSTUNINSTALL_COMMAND
       Specifies a list of functions to call after the OpenEmbedded build
       system has removed unnecessary packages. When runtime package
       management is disabled in the image, several packages are removed
       including ``base-passwd``, ``shadow``, and ``update-alternatives``.
       You can specify functions separated by semicolons:
-      ROOTFS_POSTUNINSTALL_COMMAND += "function; ... "
-   
+      ::
+
+         ROOTFS_POSTUNINSTALL_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    ROOTFS_PREPROCESS_COMMAND
       Specifies a list of functions to call before the OpenEmbedded build
       system has created the root filesystem. You can specify functions
-      separated by semicolons: ROOTFS_PREPROCESS_COMMAND += "function; ...
-      "
-   
+      separated by semicolons:
+      ::
+
+         ROOTFS_PREPROCESS_COMMAND += "function; ... "
+
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
       directory that becomes the root filesystem image. See the
       :term:`IMAGE_ROOTFS` variable for more
       information.
-   
+
    RPROVIDES
       A list of package name aliases that a package also provides. These
       aliases are useful for satisfying runtime dependencies of other
       packages both during the build and on the target (as specified by
       ``RDEPENDS``).
-   
+
       .. note::
-   
+
          A package's own name is implicitly already in its
          RPROVIDES
          list.
-   
+
       As with all package-controlling variables, you must always use the
       variable in conjunction with a package name override. Here is an
-      example: RPROVIDES_${PN} = "widget-abi-2"
-   
+      example:
+      ::
+
+         RPROVIDES_${PN} = "widget-abi-2"
+
    RRECOMMENDS
       A list of packages that extends the usability of a package being
       built. The package being built does not depend on this list of
       packages in order to successfully build, but rather uses them for
       extended usability. To specify runtime dependencies for packages, see
       the ``RDEPENDS`` variable.
-   
+
       The package manager will automatically install the ``RRECOMMENDS``
       list of packages when installing the built package. However, you can
       prevent listed packages from being installed by using the
       :term:`BAD_RECOMMENDATIONS`,
       :term:`NO_RECOMMENDATIONS`, and
       :term:`PACKAGE_EXCLUDE` variables.
-   
+
       Packages specified in ``RRECOMMENDS`` need not actually be produced.
       However, a recipe must exist that provides each package, either
       through the :term:`PACKAGES` or
@@ -5630,55 +6328,93 @@ system and gives an overview of their function and contents.
       :term:`RPROVIDES` variable, or an error will occur
       during the build. If such a recipe does exist and the package is not
       produced, the build continues without error.
-   
+
       Because the ``RRECOMMENDS`` variable applies to packages being built,
       you should always attach an override to the variable to specify the
       particular package whose usability is being extended. For example,
       suppose you are building a development package that is extended to
       support wireless functionality. In this case, you would use the
-      following: RRECOMMENDS_${PN}-dev += "wireless_package_name" In the
+      following:
+      ::
+
+         RRECOMMENDS_${PN}-dev += "wireless_package_name"
+
+      In the
       example, the package name (``${PN}-dev``) must appear as it would in
       the ``PACKAGES`` namespace before any renaming of the output package
       by classes such as ``debian.bbclass``.
-   
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned recommends. Although the syntax varies depending
       on the packaging format, BitBake hides these differences from you.
       Here is the general syntax to specify versions with the
-      ``RRECOMMENDS`` variable: RRECOMMENDS_${PN} = "package (operator
-      version)" For ``operator``, you can specify the following: = < > <=
-      >= For example, the following sets up a recommend on version 1.2 or
-      greater of the package ``foo``: RRECOMMENDS_${PN} = "foo (>= 1.2)"
-   
+      ``RRECOMMENDS`` variable:
+      ::
+
+         RRECOMMENDS_${PN} = "package (operator version)"
+
+      For ``operator``, you can specify the following:
+
+      - =
+      - <
+      - >
+      - <=
+      - >=
+
+      For example, the following sets up a recommend on version 1.2 or
+      greater of the package ``foo``:
+      ::
+
+         RRECOMMENDS_${PN} = "foo (>= 1.2)"
+
    RREPLACES
       A list of packages replaced by a package. The package manager uses
       this variable to determine which package should be installed to
       replace other package(s) during an upgrade. In order to also have the
       other package(s) removed at the same time, you must add the name of
       the other package to the ``RCONFLICTS`` variable.
-   
+
       As with all package-controlling variables, you must use this variable
       in conjunction with a package name override. Here is an example:
-      RREPLACES_${PN} = "other_package_being_replaced"
-   
+      ::
+
+         RREPLACES_${PN} = "other_package_being_replaced"
+
       BitBake, which the OpenEmbedded build system uses, supports
       specifying versioned replacements. Although the syntax varies
       depending on the packaging format, BitBake hides these differences
       from you. Here is the general syntax to specify versions with the
-      ``RREPLACES`` variable: RREPLACES_${PN} = "package (operator
-      version)" For ``operator``, you can specify the following: = < > <=
-      >= For example, the following sets up a replacement using version 1.2
-      or greater of the package ``foo``: RREPLACES_${PN} = "foo (>= 1.2)"
-   
+      ``RREPLACES`` variable:
+      ::
+
+         RREPLACES_${PN} = "package (operator version)"
+
+      For ``operator``, you can specify the following:
+
+      - =
+      - <
+      - >
+      - <=
+      - >=
+
+      For example, the following sets up a replacement using version 1.2
+      or greater of the package ``foo``:
+      ::
+
+          RREPLACES_${PN} = "foo (>= 1.2)"
+
    RSUGGESTS
       A list of additional packages that you can suggest for installation
       by the package manager at the time a package is installed. Not all
       package managers support this functionality.
-   
+
       As with all package-controlling variables, you must always use this
       variable in conjunction with a package name override. Here is an
-      example: RSUGGESTS_${PN} = "useful_package another_package"
-   
+      example:
+      ::
+
+         RSUGGESTS_${PN} = "useful_package another_package"
+
    S
       The location in the :term:`Build Directory` where
       unpacked recipe source code resides. By default, this directory is
@@ -5689,27 +6425,33 @@ system and gives an overview of their function and contents.
       fetched from an SCM such as Git or Subversion, then you must set
       ``S`` in the recipe so that the OpenEmbedded build system knows where
       to find the unpacked source.
-   
+
       As an example, assume a :term:`Source Directory`
       top-level folder named ``poky`` and a default Build Directory at
       ``poky/build``. In this case, the work directory the build system
       uses to keep the unpacked recipe for ``db`` is the following:
-      poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 The
-      unpacked source code resides in the ``db-5.1.19`` folder.
-   
+      ::
+
+         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
+
+      The unpacked source code resides in the ``db-5.1.19`` folder.
+
       This next example assumes a Git repository. By default, Git
       repositories are cloned to ``${WORKDIR}/git`` during
       :ref:`ref-tasks-fetch`. Since this path is different
       from the default value of ``S``, you must set it specifically so the
-      source can be located: SRC_URI = "git://path/to/repo.git" S =
-      "${WORKDIR}/git"
-   
+      source can be located:
+      ::
+
+         SRC_URI = "git://path/to/repo.git"
+         S = "${WORKDIR}/git"
+
    SANITY_REQUIRED_UTILITIES
       Specifies a list of command-line utilities that should be checked for
       during the initial sanity checking process when running BitBake. If
       any of the utilities are not installed on the build host, then
       BitBake immediately exits with an error.
-   
+
    SANITY_TESTED_DISTROS
       A list of the host distribution identifiers that the build system has
       been tested against. Identifiers consist of the host distributor ID
@@ -5720,25 +6462,31 @@ system and gives an overview of their function and contents.
       :term:`NATIVELSBSTRING` does not appear in the
       list, then the build system reports a warning that indicates the
       current host distribution has not been tested as a build host.
-   
+
    SDK_ARCH
       The target architecture for the SDK. Typically, you do not directly
       set this variable. Instead, use :term:`SDKMACHINE`.
-   
+
    SDK_DEPLOY
       The directory set up and used by the
       :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which
       the SDK is deployed. The ``populate_sdk_base`` class defines
-      ``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
-   
+      ``SDK_DEPLOY`` as follows:
+      ::
+
+         SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
+
    SDK_DIR
       The parent directory used by the OpenEmbedded build system when
       creating SDK output. The
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class defines
-      the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
-   
+      the variable as follows:
+      ::
+
+         SDK_DIR = "${WORKDIR}/sdk"
+
       .. note::
-   
+
          The
          SDK_DIR
          directory is a temporary directory as it is part of
@@ -5746,47 +6494,53 @@ system and gives an overview of their function and contents.
          . The final output directory is
          SDK_DEPLOY
          .
-   
+
    SDK_EXT_TYPE
       Controls whether or not shared state artifacts are copied into the
       extensible SDK. The default value of "full" copies all of the
       required shared state artifacts into the extensible SDK. The value
       "minimal" leaves these artifacts out of the SDK.
-   
+
       .. note::
-   
+
          If you set the variable to "minimal", you need to ensure
          SSTATE_MIRRORS
          is set in the SDK's configuration to enable the artifacts to be
          fetched as needed.
-   
+
    SDK_HOST_MANIFEST
       The manifest file for the host part of the SDK. This file lists all
       the installed packages that make up the host part of the SDK. The
       file contains package information on a line-per-package basis as
-      follows: packagename packagearch version
-   
+      follows:
+      ::
+
+         packagename packagearch version
+
       The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
-      defines the manifest file as follows: SDK_HOST_MANIFEST =
-      "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is
-      derived using the :term:`SDK_DEPLOY` and
+      defines the manifest file as follows:
+      ::
+
+         SDK_HOST_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"
+
+      The location is derived using the :term:`SDK_DEPLOY` and
       :term:`TOOLCHAIN_OUTPUTNAME` variables.
-   
+
    SDK_INCLUDE_PKGDATA
       When set to "1", specifies to include the packagedata for all recipes
       in the "world" target in the extensible SDK. Including this data
       allows the ``devtool search`` command to find these recipes in search
       results, as well as allows the ``devtool add`` command to map
       dependencies more effectively.
-   
+
       .. note::
-   
+
          Enabling the
          SDK_INCLUDE_PKGDATA
          variable significantly increases build time because all of world
          needs to be built. Enabling the variable also slightly increases
          the size of the extensible SDK.
-   
+
    SDK_INCLUDE_TOOLCHAIN
       When set to "1", specifies to include the toolchain in the extensible
       SDK. Including the toolchain is useful particularly when
@@ -5795,375 +6549,417 @@ system and gives an overview of their function and contents.
       toolchain. For example, suppose you want to use the toolchain from an
       IDE or from other tools and you do not want to perform additional
       steps to install the toolchain.
-   
+
       The ``SDK_INCLUDE_TOOLCHAIN`` variable defaults to "0" if
       ``SDK_EXT_TYPE`` is set to "minimal", and defaults to "1" if
       ``SDK_EXT_TYPE`` is set to "full".
-   
+
    SDK_INHERIT_BLACKLIST
       A list of classes to remove from the :term:`INHERIT`
       value globally within the extensible SDK configuration. The
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
-      default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
-   
+      default value:
+      ::
+
+         SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
+
       Some classes are not generally applicable within the extensible SDK
       context. You can use this variable to disable those classes.
-   
+
       For additional information on how to customize the extensible SDK's
-      configuration, see the "`Configuring the Extensible
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__"
+      configuration, see the
+      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_LOCAL_CONF_BLACKLIST
       A list of variables not allowed through from the OpenEmbedded build
       system configuration into the extensible SDK configuration. Usually,
       these are variables that are specific to the machine on which the
       build system is running and thus would be potentially problematic
       within the extensible SDK.
-   
+
       By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
       excludes the following variables:
-      :term:`CONF_VERSION`
-      :term:`BB_NUMBER_THREADS`
-      :term:`bitbake:BB_NUMBER_PARSE_THREADS`
-      :term:`PARALLEL_MAKE`
-      :term:`PRSERV_HOST`
-      :term:`SSTATE_MIRRORS` :term:`DL_DIR`
-      :term:`SSTATE_DIR` :term:`TMPDIR`
-      :term:`BB_SERVER_TIMEOUT`
-   
+
+      - :term:`CONF_VERSION`
+      - :term:`BB_NUMBER_THREADS`
+      - :term:`bitbake:BB_NUMBER_PARSE_THREADS`
+      - :term:`PARALLEL_MAKE`
+      - :term:`PRSERV_HOST`
+      - :term:`SSTATE_MIRRORS` :term:`DL_DIR`
+      - :term:`SSTATE_DIR` :term:`TMPDIR`
+      - :term:`BB_SERVER_TIMEOUT`
+
       For additional information on how to customize the extensible SDK's
-      configuration, see the "`Configuring the Extensible
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__"
+      configuration, see the
+      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_LOCAL_CONF_WHITELIST
       A list of variables allowed through from the OpenEmbedded build
       system configuration into the extensible SDK configuration. By
       default, the list of variables is empty and is set in the
       :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
-   
+
       This list overrides the variables specified using the
       :term:`SDK_LOCAL_CONF_BLACKLIST`
       variable as well as any variables identified by automatic
       blacklisting due to the "/" character being found at the start of the
       value, which is usually indicative of being a path and thus might not
       be valid on the system where the SDK is installed.
-   
+
       For additional information on how to customize the extensible SDK's
-      configuration, see the "`Configuring the Extensible
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__"
+      configuration, see the
+      ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_NAME
       The base name for SDK output files. The name is derived from the
       :term:`DISTRO`, :term:`TCLIBC`,
       :term:`SDK_ARCH`,
       :term:`IMAGE_BASENAME`, and
-      :term:`TUNE_PKGARCH` variables: SDK_NAME =
-      "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
-   
+      :term:`TUNE_PKGARCH` variables:
+      ::
+
+         SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
+
    SDK_OS
       Specifies the operating system for which the SDK will be built. The
       default value is the value of :term:`BUILD_OS`.
-   
+
    SDK_OUTPUT
       The location used by the OpenEmbedded build system when creating SDK
       output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
-      class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
-      SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
-   
+      class defines the variable as follows:
+      ::
+
+         SDK_DIR = "${WORKDIR}/sdk"
+         SDK_OUTPUT = "${SDK_DIR}/image"
+         SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
+
       .. note::
-   
-         The
-         SDK_OUTPUT
-         directory is a temporary directory as it is part of
-         WORKDIR
-         by way of
-         SDK_DIR
-         . The final output directory is
-         SDK_DEPLOY
-         .
-   
+
+         The SDK_OUTPUT directory is a temporary directory as it is part of
+         WORKDIR by way of SDK_DIR. The final output directory is
+         SDK_DEPLOY.
+
    SDK_PACKAGE_ARCHS
       Specifies a list of architectures compatible with the SDK machine.
       This variable is set automatically and should not normally be
       hand-edited. Entries are separated using spaces and listed in order
       of priority. The default value for ``SDK_PACKAGE_ARCHS`` is "all any
       noarch ${SDK_ARCH}-${SDKPKGSUFFIX}".
-   
+
    SDK_POSTPROCESS_COMMAND
       Specifies a list of functions to call once the OpenEmbedded build
       system creates the SDK. You can specify functions separated by
       semicolons: SDK_POSTPROCESS_COMMAND += "function; ... "
-   
+
       If you need to pass an SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
       the OpenEmbedded build system when creating SDK output. See the
       :term:`SDK_DIR` variable for more information.
-   
+
    SDK_PREFIX
       The toolchain binary prefix used for ``nativesdk`` recipes. The
       OpenEmbedded build system uses the ``SDK_PREFIX`` value to set the
       :term:`TARGET_PREFIX` when building
       ``nativesdk`` recipes. The default value is "${SDK_SYS}-".
-   
+
    SDK_RECRDEP_TASKS
       A list of shared state tasks added to the extensible SDK. By default,
-      the following tasks are added: do_populate_lic do_package_qa
-      do_populate_sysroot do_deploy Despite the default value of "" for the
+      the following tasks are added:
+
+      - do_populate_lic
+      - do_package_qa
+      - do_populate_sysroot
+      - do_deploy
+
+      Despite the default value of "" for the
       ``SDK_RECRDEP_TASKS`` variable, the above four tasks are always added
       to the SDK. To specify tasks beyond these four, you need to use the
       ``SDK_RECRDEP_TASKS`` variable (e.g. you are defining additional
       tasks that are needed in order to build
       :term:`SDK_TARGETS`).
-   
+
    SDK_SYS
       Specifies the system, including the architecture and the operating
       system, for which the SDK will be built.
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`SDK_ARCH`,
       :term:`SDK_VENDOR`, and
       :term:`SDK_OS`. You do not need to set the ``SDK_SYS``
       variable yourself.
-   
+
    SDK_TARGET_MANIFEST
       The manifest file for the target part of the SDK. This file lists all
       the installed packages that make up the target part of the SDK. The
       file contains package information on a line-per-package basis as
-      follows: packagename packagearch version
-   
+      follows:
+      ::
+
+         packagename packagearch version
+
       The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
-      defines the manifest file as follows: SDK_TARGET_MANIFEST =
-      "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location
-      is derived using the :term:`SDK_DEPLOY` and
+      defines the manifest file as follows:
+      ::
+
+         SDK_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
+
+      The location is derived using the :term:`SDK_DEPLOY` and
       :term:`TOOLCHAIN_OUTPUTNAME` variables.
-   
+
    SDK_TARGETS
       A list of targets to install from shared state as part of the
       standard or extensible SDK installation. The default value is "${PN}"
       (i.e. the image from which the SDK is built).
-   
+
       The ``SDK_TARGETS`` variable is an internal variable and typically
       would not be changed.
-   
+
    SDK_TITLE
       The title to be printed when running the SDK installer. By default,
       this title is based on the :term:`DISTRO_NAME` or
       :term:`DISTRO` variable and is set in the
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
-      follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
-      d.getVar('DISTRO')} SDK" For the default distribution "poky",
+      follows:
+      ::
+
+         SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
+
+      For the default distribution "poky",
       ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
-   
+
       For information on how to change this default title, see the
-      "`Changing the Extensible SDK Installer
-      Title <&YOCTO_DOCS_SDK_URL;#sdk-changing-the-sdk-installer-title>`__"
+      ":ref:`sdk-manual/sdk-appendix-customizing:changing the extensible sdk installer title`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDK_UPDATE_URL
       An optional URL for an update server for the extensible SDK. If set,
       the value is used as the default update server when running
       ``devtool sdk-update`` within the extensible SDK.
-   
+
    SDK_VENDOR
       Specifies the name of the SDK vendor.
-   
+
    SDK_VERSION
       Specifies the version of the SDK. The distribution configuration file
       (e.g. ``/meta-poky/conf/distro/poky.conf``) defines the
-      ``SDK_VERSION`` as follows: SDK_VERSION =
-      "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
-   
+      ``SDK_VERSION`` as follows:
+      ::
+
+         SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
+
       For additional information, see the
       :term:`DISTRO_VERSION` and
       :term:`DATE` variables.
-   
+
    SDKEXTPATH
       The default installation directory for the Extensible SDK. By
       default, this directory is based on the :term:`DISTRO`
       variable and is set in the
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
-      follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the
+      follows:
+      ::
+
+         SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
+
+      For the
       default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
-   
+
       For information on how to change this default directory, see the
-      "`Changing the Default SDK Installation
-      Directory <&YOCTO_DOCS_SDK_URL;#sdk-changing-the-default-sdk-installation-directory>`__"
+      ":ref:`sdk-manual/sdk-appendix-customizing:changing the default sdk installation directory`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
-   
+
    SDKIMAGE_FEATURES
       Equivalent to ``IMAGE_FEATURES``. However, this variable applies to
-      the SDK generated from an image using the following command: $
-      bitbake -c populate_sdk imagename
-   
+      the SDK generated from an image using the following command:
+      ::
+
+         $ bitbake -c populate_sdk imagename
+
    SDKMACHINE
       The machine for which the SDK is built. In other words, the SDK is
       built such that it runs on the target you specify with the
       ``SDKMACHINE`` value. The value points to a corresponding ``.conf``
       file under ``conf/machine-sdk/``.
-   
+
       You can use "i686" and "x86_64" as possible values for this variable.
       The variable defaults to "i686" and is set in the local.conf file in
-      the Build Directory. SDKMACHINE ?= "i686"
-   
+      the Build Directory.
+      ::
+
+         SDKMACHINE ?= "i686"
+
       .. note::
-   
+
          You cannot set the
          SDKMACHINE
          variable in your distribution configuration file. If you do, the
          configuration will not take affect.
-   
+
    SDKPATH
       Defines the path offered to the user for installation of the SDK that
       is generated by the OpenEmbedded build system. The path appears as
       the default location for installing the SDK when you run the SDK's
       installation script. You can override the offered path when you run
       the script.
-   
+
    SDKTARGETSYSROOT
       The full path to the sysroot used for cross-compilation within an SDK
       as it will be when installed into the default
       :term:`SDKPATH`.
-   
+
    SECTION
       The section in which packages should be categorized. Package
       management utilities can make use of this variable.
-   
+
    SELECTED_OPTIMIZATION
       Specifies the optimization flags passed to the C compiler when
       building for the target. The flags are passed through the default
       value of the :term:`TARGET_CFLAGS` variable.
-   
+
       The ``SELECTED_OPTIMIZATION`` variable takes the value of
       ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the
       case, the value of ``DEBUG_OPTIMIZATION`` is used.
-   
+
    SERIAL_CONSOLE
       Defines a serial console (TTY) to enable using
       `getty <https://en.wikipedia.org/wiki/Getty_(Unix)>`__. Provide a
       value that specifies the baud rate followed by the TTY device name
       separated by a space. You cannot specify more than one TTY device:
-      SERIAL_CONSOLE = "115200 ttyS0"
-   
+      ::
+
+         SERIAL_CONSOLE = "115200 ttyS0"
+
       .. note::
-   
+
          The
          SERIAL_CONSOLE
          variable is deprecated. Please use the
          SERIAL_CONSOLES
          variable.
-   
+
    SERIAL_CONSOLES
       Defines a serial console (TTY) to enable using
       `getty <https://en.wikipedia.org/wiki/Getty_(Unix)>`__. Provide a
       value that specifies the baud rate followed by the TTY device name
       separated by a semicolon. Use spaces to separate multiple devices:
-      SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
-   
+      ::
+
+         SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
+
    SERIAL_CONSOLES_CHECK
       Specifies serial consoles, which must be listed in
       :term:`SERIAL_CONSOLES`, to check against
       ``/proc/console`` before enabling them using getty. This variable
       allows aliasing in the format: <device>:<alias>. If a device was
       listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in
-      ``/proc/console``, you would do the following: SERIAL_CONSOLES_CHECK
-      = "slcp_line0:ttyS0" This variable is currently only supported with
-      SysVinit (i.e. not with systemd).
-   
+      ``/proc/console``, you would do the following: ::
+
+         SERIAL_CONSOLES_CHECK = "slcp_line0:ttyS0"
+
+      This variable is currently only supported with SysVinit (i.e. not
+      with systemd).
+
    SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS
       A list of recipe dependencies that should not be used to determine
       signatures of tasks from one recipe when they depend on tasks from
-      another recipe. For example: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS +=
-      "intone->mplayer2"
-   
+      another recipe. For example: ::
+
+         SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
+
       In the previous example, ``intone`` depends on ``mplayer2``.
-   
+
       You can use the special token ``"*"`` on the left-hand side of the
       dependency to match all recipes except the one on the right-hand
-      side. Here is an example: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS +=
-      "*->quilt-native"
-   
+      side. Here is an example: ::
+
+         SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"
+
       In the previous example, all recipes except ``quilt-native`` ignore
       task signatures from the ``quilt-native`` recipe when determining
       their task signatures.
-   
+
       Use of this variable is one mechanism to remove dependencies that
       affect task signatures and thus force rebuilds when a recipe changes.
-   
+
       .. note::
-   
+
          If you add an inappropriate dependency for a recipe relationship,
          the software might break during runtime if the interface of the
          second recipe was changed after the first recipe had been built.
-   
+
    SIGGEN_EXCLUDERECIPES_ABISAFE
       A list of recipes that are completely stable and will never change.
       The ABI for the recipes in the list are presented by output from the
       tasks run to build the recipe. Use of this variable is one way to
       remove dependencies from one recipe on another that affect task
       signatures and thus force rebuilds when the recipe changes.
-   
+
       .. note::
-   
+
          If you add an inappropriate variable to this list, the software
          might break at runtime if the interface of the recipe was changed
          after the other had been built.
-   
+
    SITEINFO_BITS
       Specifies the number of bits for the target system CPU. The value
       should be either "32" or "64".
-   
+
    SITEINFO_ENDIANNESS
       Specifies the endian byte order of the target system. The value
       should be either "le" for little-endian or "be" for big-endian.
-   
+
    SKIP_FILEDEPS
       Enables removal of all files from the "Provides" section of an RPM
       package. Removal of these files is required for packages containing
       prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``.
-   
+
       To enable file removal, set the variable to "1" in your
-      ``conf/local.conf`` configuration file in your: 
-      :term:`Build Directory`. SKIP_FILEDEPS = "1"
-   
+      ``conf/local.conf`` configuration file in your:
+      :term:`Build Directory`.
+      ::
+
+         SKIP_FILEDEPS = "1"
+
    SOC_FAMILY
       Groups together machines based upon the same family of SOC (System On
       Chip). You typically set this variable in a common ``.inc`` file that
       you include in the configuration files of all the machines.
-   
+
       .. note::
-   
+
          You must include
          conf/machine/include/soc-family.inc
          for this variable to appear in
          MACHINEOVERRIDES
          .
-   
+
    SOLIBS
       Defines the suffix for shared libraries used on the target platform.
       By default, this suffix is ".so.*" for all Linux-based systems and is
       defined in the ``meta/conf/bitbake.conf`` configuration file.
-   
+
       You will see this variable referenced in the default values of
       ``FILES_${PN}``.
-   
+
    SOLIBSDEV
       Defines the suffix for the development symbolic link (symlink) for
       shared libraries on the target platform. By default, this suffix is
       ".so" for Linux-based systems and is defined in the
       ``meta/conf/bitbake.conf`` configuration file.
-   
+
       You will see this variable referenced in the default values of
       ``FILES_${PN}-dev``.
-   
+
    SOURCE_MIRROR_FETCH
       When you are fetching files to create a mirror of sources (i.e.
       creating a source mirror), setting ``SOURCE_MIRROR_FETCH`` to "1" in
@@ -6175,69 +6971,75 @@ system and gives an overview of their function and contents.
       variable and :term:`COMPATIBLE_HOST` variables
       specify compatibility with a machine other than that of the current
       machine or host.
-   
+
       .. note::
-   
+
          Do not set the
          SOURCE_MIRROR_FETCH
          variable unless you are creating a source mirror. In other words,
          do not set the variable during a normal build.
-   
+
    SOURCE_MIRROR_URL
       Defines your own :term:`PREMIRRORS` from which to
       first fetch source before attempting to fetch from the upstream
       specified in :term:`SRC_URI`.
-   
+
       To use this variable, you must globally inherit the
       :ref:`own-mirrors <ref-classes-own-mirrors>` class and then provide
-      the URL to your mirrors. Here is the general syntax: INHERIT +=
-      "own-mirrors" SOURCE_MIRROR_URL =
-      "http://example.com/my_source_mirror"
-   
+      the URL to your mirrors. Here is the general syntax:
+      ::
+
+         INHERIT += "own-mirrors"
+         SOURCE_MIRROR_URL = "http://example.com/my_source_mirror"
+
       .. note::
-   
+
          You can specify only a single URL in
          SOURCE_MIRROR_URL
          .
-   
+
    SPDXLICENSEMAP
       Maps commonly used license names to their SPDX counterparts found in
       ``meta/files/common-licenses/``. For the default ``SPDXLICENSEMAP``
       mappings, see the ``meta/conf/licenses.conf`` file.
-   
+
       For additional information, see the :term:`LICENSE`
       variable.
-   
+
    SPECIAL_PKGSUFFIX
       A list of prefixes for :term:`PN` used by the OpenEmbedded
       build system to create variants of recipes or packages. The list
       specifies the prefixes to strip off during certain circumstances such
       as the generation of the :term:`BPN` variable.
-   
+
    SPL_BINARY
       The file type for the Secondary Program Loader (SPL). Some devices
       use an SPL from which to boot (e.g. the BeagleBone development
       board). For such cases, you can declare the file type of the SPL
       binary in the ``u-boot.inc`` include file, which is used in the
       U-Boot recipe.
-   
+
       The SPL file type is set to "null" by default in the ``u-boot.inc``
-      file as follows: # Some versions of u-boot build an SPL (Second
-      Program Loader) image that # should be packaged along with the u-boot
-      binary as well as placed in the # deploy directory. For those
-      versions they can set the following variables # to allow packaging
-      the SPL. SPL_BINARY ?= "" SPL_BINARYNAME ?=
-      "${@os.path.basename(d.getVar("SPL_BINARY"))}" SPL_IMAGE ?=
-      "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" SPL_SYMLINK ?=
-      "${SPL_BINARYNAME}-${MACHINE}" The ``SPL_BINARY`` variable helps form
+      file as follows:
+      ::
+
+         # Some versions of u-boot build an SPL (Second Program Loader) image that
+         # should be packaged along with the u-boot binary as well as placed in the
+         # deploy directory. For those versions they can set the following variables
+         # to allow packaging the SPL.
+         SPL_BINARY ?= ""
+         SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
+         SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}"
+         SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}"
+
+      The ``SPL_BINARY`` variable helps form
       various ``SPL_*`` variables used by the OpenEmbedded build system.
-   
-      See the BeagleBone machine configuration example in the "`Creating a
-      new BSP Layer Using the ``bitbake-layers``
-      Script <&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-bitbake-layers-script>`__"
+
+      See the BeagleBone machine configuration example in the
+      ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
       section in the Yocto Project Board Support Package Developer's Guide
       for additional information.
-   
+
    SRC_URI
       The list of source files - local or remote. This variable tells the
       OpenEmbedded build system which bits to pull in for the build and how
@@ -6247,34 +7049,34 @@ system and gives an overview of their function and contents.
       append file needs to fetch a tarball, apply two patches, and include
       a custom file, the recipe or append file would include four instances
       of the variable.
-   
+
       The following list explains the available URI protocols. URI
       protocols are highly dependent on particular BitBake Fetcher
       submodules. Depending on the fetcher BitBake uses, various URL
       parameters are employed. For specifics on the supported Fetchers, see
       the ":ref:`Fetchers <bitbake:bb-fetchers>`" section in the
       BitBake User Manual.
-   
-      -  *``file://`` -* Fetches files, which are usually files shipped
+
+      -  ``file://`` - Fetches files, which are usually files shipped
          with the :term:`Metadata`, from the local machine (e.g.
-         `patch <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__ files).
+         :ref:`patch <patching-dev-environment>` files).
          The path is relative to the :term:`FILESPATH`
          variable. Thus, the build system searches, in order, from the
          following directories, which are assumed to be a subdirectories of
          the directory in which the recipe file (``.bb``) or append file
          (``.bbappend``) resides:
-   
-         -  *``${BPN}`` -* The base recipe name without any special suffix
+
+         -  ``${BPN}`` - The base recipe name without any special suffix
             or version numbers.
-   
-         -  *``${BP}`` -* ``${BPN}-${PV}``. The base recipe name and
+
+         -  ``${BP}`` - ``${BPN}-${PV}``. The base recipe name and
             version but without any special package name suffix.
-   
+
          -  *files -* Files within a directory, which is named ``files``
             and is also alongside the recipe or append file.
-   
+
          .. note::
-   
+
             If you want the build system to pick up files specified through
             a
             SRC_URI
@@ -6284,127 +7086,133 @@ system and gives an overview of their function and contents.
             variable by also using the
             FILESEXTRAPATHS
             variable from within your append file.
-   
-      -  *``bzr://`` -* Fetches files from a Bazaar revision control
+
+      -  ``bzr://`` - Fetches files from a Bazaar revision control
          repository.
-   
-      -  *``git://`` -* Fetches files from a Git revision control
+
+      -  ``git://`` - Fetches files from a Git revision control
          repository.
-   
-      -  *``osc://`` -* Fetches files from an OSC (OpenSUSE Build service)
+
+      -  ``osc://`` - Fetches files from an OSC (OpenSUSE Build service)
          revision control repository.
-   
-      -  *``repo://`` -* Fetches files from a repo (Git) repository.
-   
-      -  *``ccrc://`` -* Fetches files from a ClearCase repository.
-   
-      -  *``http://`` -* Fetches files from the Internet using ``http``.
-   
-      -  *``https://`` -* Fetches files from the Internet using ``https``.
-   
-      -  *``ftp://`` -* Fetches files from the Internet using ``ftp``.
-   
-      -  *``cvs://`` -* Fetches files from a CVS revision control
+
+      -  ``repo://`` - Fetches files from a repo (Git) repository.
+
+      -  ``ccrc://`` - Fetches files from a ClearCase repository.
+
+      -  ``http://`` - Fetches files from the Internet using ``http``.
+
+      -  ``https://`` - Fetches files from the Internet using ``https``.
+
+      -  ``ftp://`` - Fetches files from the Internet using ``ftp``.
+
+      -  ``cvs://`` - Fetches files from a CVS revision control
          repository.
-   
-      -  *``hg://`` -* Fetches files from a Mercurial (``hg``) revision
+
+      -  ``hg://`` - Fetches files from a Mercurial (``hg``) revision
          control repository.
-   
-      -  *``p4://`` -* Fetches files from a Perforce (``p4``) revision
+
+      -  ``p4://`` - Fetches files from a Perforce (``p4``) revision
          control repository.
-   
-      -  *``ssh://`` -* Fetches files from a secure shell.
-   
-      -  *``svn://`` -* Fetches files from a Subversion (``svn``) revision
+
+      -  ``ssh://`` - Fetches files from a secure shell.
+
+      -  ``svn://`` - Fetches files from a Subversion (``svn``) revision
          control repository.
-   
-      -  *``npm://`` -* Fetches JavaScript modules from a registry.
-   
+
+      -  ``npm://`` - Fetches JavaScript modules from a registry.
+
       Standard and recipe-specific options for ``SRC_URI`` exist. Here are
       standard options:
-   
-      -  *``apply`` -* Whether to apply the patch or not. The default
+
+      -  ``apply`` - Whether to apply the patch or not. The default
          action is to apply the patch.
-   
-      -  *``striplevel`` -* Which striplevel to use when applying the
+
+      -  ``striplevel`` - Which striplevel to use when applying the
          patch. The default level is 1.
-   
-      -  *``patchdir`` -* Specifies the directory in which the patch should
+
+      -  ``patchdir`` - Specifies the directory in which the patch should
          be applied. The default is ``${``\ :term:`S`\ ``}``.
-   
+
       Here are options specific to recipes building code from a revision
       control system:
-   
-      -  *``mindate`` -* Apply the patch only if
+
+      -  ``mindate`` - Apply the patch only if
          :term:`SRCDATE` is equal to or greater than
          ``mindate``.
-   
-      -  *``maxdate`` -* Apply the patch only if ``SRCDATE`` is not later
+
+      -  ``maxdate`` - Apply the patch only if ``SRCDATE`` is not later
          than ``maxdate``.
-   
-      -  *``minrev`` -* Apply the patch only if ``SRCREV`` is equal to or
+
+      -  ``minrev`` - Apply the patch only if ``SRCREV`` is equal to or
          greater than ``minrev``.
-   
-      -  *``maxrev`` -* Apply the patch only if ``SRCREV`` is not later
+
+      -  ``maxrev`` - Apply the patch only if ``SRCREV`` is not later
          than ``maxrev``.
-   
-      -  *``rev`` -* Apply the patch only if ``SRCREV`` is equal to
+
+      -  ``rev`` - Apply the patch only if ``SRCREV`` is equal to
          ``rev``.
-   
-      -  *``notrev`` -* Apply the patch only if ``SRCREV`` is not equal to
+
+      -  ``notrev`` - Apply the patch only if ``SRCREV`` is not equal to
          ``rev``.
-   
+
       Here are some additional options worth mentioning:
-   
-      -  *``unpack`` -* Controls whether or not to unpack the file if it is
+
+      -  ``unpack`` - Controls whether or not to unpack the file if it is
          an archive. The default action is to unpack the file.
-   
-      -  *``destsuffix`` -* Places the file (or extracts its contents) into
+
+      -  ``destsuffix`` - Places the file (or extracts its contents) into
          the specified subdirectory of :term:`WORKDIR` when
          the Git fetcher is used.
-   
-      -  *``subdir`` -* Places the file (or extracts its contents) into the
+
+      -  ``subdir`` - Places the file (or extracts its contents) into the
          specified subdirectory of ``WORKDIR`` when the local (``file://``)
          fetcher is used.
-   
-      -  *``localdir`` -* Places the file (or extracts its contents) into
+
+      -  ``localdir`` - Places the file (or extracts its contents) into
          the specified subdirectory of ``WORKDIR`` when the CVS fetcher is
          used.
-   
-      -  *``subpath`` -* Limits the checkout to a specific subpath of the
+
+      -  ``subpath`` - Limits the checkout to a specific subpath of the
          tree when using the Git fetcher is used.
-   
-      -  *``name`` -* Specifies a name to be used for association with
+
+      -  ``name`` - Specifies a name to be used for association with
          ``SRC_URI`` checksums when you have more than one file specified
          in ``SRC_URI``.
-   
-      -  *``downloadfilename`` -* Specifies the filename used when storing
+
+      -  ``downloadfilename`` - Specifies the filename used when storing
          the downloaded file.
-   
+
    SRC_URI_OVERRIDES_PACKAGE_ARCH
       By default, the OpenEmbedded build system automatically detects
       whether ``SRC_URI`` contains files that are machine-specific. If so,
       the build system automatically changes ``PACKAGE_ARCH``. Setting this
       variable to "0" disables this behavior.
-   
+
    SRCDATE
       The date of the source code used to build the package. This variable
       applies only if the source was fetched from a Source Code Manager
       (SCM).
-   
+
    SRCPV
       Returns the version string of the current package. This string is
       used to help define the value of :term:`PV`.
-   
+
       The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf``
       configuration file in the :term:`Source Directory` as
-      follows: SRCPV = "${@bb.fetch2.get_srcrev(d)}"
-   
+      follows:
+      ::
+
+         SRCPV = "${@bb.fetch2.get_srcrev(d)}"
+
       Recipes that need to define ``PV`` do so with the help of the
       ``SRCPV``. For example, the ``ofono`` recipe (``ofono_git.bb``)
       located in ``meta/recipes-connectivity`` in the Source Directory
-      defines ``PV`` as follows: PV = "0.12-git${SRCPV}"
-   
+      defines ``PV`` as follows:
+      ::
+
+         PV = "0.12-git${SRCPV}"
+
    SRCREV
       The revision of the source code used to build the package. This
       variable applies to Subversion, Git, Mercurial, and Bazaar only. Note
@@ -6412,9 +7220,9 @@ system and gives an overview of their function and contents.
       performing a query on the remote repository every time BitBake parses
       your recipe, you should specify a ``SRCREV`` that is a full revision
       identifier and not just a tag.
-   
+
       .. note::
-   
+
          For information on limitations when inheriting the latest revision
          of software using
          SRCREV
@@ -6423,10 +7231,10 @@ system and gives an overview of their function and contents.
          variable description and the "
          Automatically Incrementing a Binary Package Revision Number
          " section, which is in the Yocto Project Development Tasks Manual.
-   
+
    SSTATE_DIR
       The directory for the shared state cache.
-   
+
    SSTATE_MIRROR_ALLOW_NETWORK
       If set to "1", allows fetches from mirrors that are specified in
       :term:`SSTATE_MIRRORS` to work even when
@@ -6435,19 +7243,19 @@ system and gives an overview of their function and contents.
       you have set ``SSTATE_MIRRORS`` to point to an internal server for
       your shared state cache, but you want to disable any other fetching
       from the network.
-   
+
    SSTATE_MIRRORS
       Configures the OpenEmbedded build system to search other mirror
       locations for prebuilt cache data objects before building out the
       data. This variable works like fetcher :term:`MIRRORS`
       and :term:`PREMIRRORS` and points to the cache
       locations to check for the shared state (sstate) objects.
-   
+
       You can specify a filesystem directory or a remote URL such as HTTP
       or FTP. The locations you specify need to contain the shared state
       cache (sstate-cache) results from previous builds. The sstate-cache
       you point to can also be from builds on other machines.
-   
+
       When pointing to sstate build artifacts on another machine that uses
       a different GCC version for native builds, you must configure
       ``SSTATE_MIRRORS`` with a regular expression that maps local search
@@ -6455,24 +7263,27 @@ system and gives an overview of their function and contents.
       :term:`NATIVELSBSTRING` set by the
       :ref:`uninative <ref-classes-uninative>` class. For example, the
       following maps the local search path ``universal-4.9`` to the
-      server-provided path server_url_sstate_path: SSTATE_MIRRORS ?=
-      file://universal-4.9/(.*)
-      http://server_url_sstate_path/universal-4.8/\1 \\n
-   
+      server-provided path server_url_sstate_path:
+      ::
+
+         SSTATE_MIRRORS ?= "file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n"
+
       If a mirror uses the same structure as
       :term:`SSTATE_DIR`, you need to add "PATH" at the
       end as shown in the examples below. The build system substitutes the
-      correct path within the directory structure. SSTATE_MIRRORS ?= "\\
-      file://.\*
-      http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \\n \\
-      file://.\* file:///some-local-dir/sstate/PATH"
-   
+      correct path within the directory structure.
+      ::
+
+         SSTATE_MIRRORS ?= "\
+             file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
+             file://.* file:///some-local-dir/sstate/PATH"
+
    SSTATE_SCAN_FILES
       Controls the list of files the OpenEmbedded build system scans for
       hardcoded installation paths. The variable uses a space-separated
       list of filenames (not paths) with standard wildcard characters
       allowed.
-   
+
       During a build, the OpenEmbedded build system creates a shared state
       (sstate) object during the first stage of preparing the sysroots.
       That object is scanned for hardcoded paths for original installation
@@ -6482,32 +7293,32 @@ system and gives an overview of their function and contents.
       than the variable being comprehensively set. The
       :ref:`sstate <ref-classes-sstate>` class specifies the default list
       of files.
-   
+
       For details on the process, see the
       :ref:`staging <ref-classes-staging>` class.
-   
+
    STAGING_BASE_LIBDIR_NATIVE
       Specifies the path to the ``/lib`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_BASELIBDIR
       Specifies the path to the ``/lib`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_BINDIR
       Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_BINDIR_CROSS
       Specifies the path to the directory containing binary configuration
       scripts. These scripts provide configuration information for other
       software that wants to make use of libraries or include files
       provided by the software associated with the script.
-   
+
       .. note::
-   
+
          This style of build configuration has been largely replaced by
          pkg-config
          . Consequently, if
@@ -6516,36 +7327,34 @@ system and gives an overview of their function and contents.
          recommended you use
          pkg-config
          instead of a provided configuration script.
-   
+
    STAGING_BINDIR_NATIVE
       Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_DATADIR
       Specifies the path to the ``/usr/share`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_DATADIR_NATIVE
       Specifies the path to the ``/usr/share`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_DIR
       Helps construct the ``recipe-sysroots`` directory, which is used
       during packaging.
-   
+
       For information on how staging for recipe-specific sysroots occurs,
       see the :ref:`ref-tasks-populate_sysroot`
-      task, the "`Sharing Files Between
-      Recipes <&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes>`__"
+      task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`"
       section in the Yocto Project Development Tasks Manual, the
-      "`Configuration, Compilation, and
-      Staging <&YOCTO_DOCS_OM_URL;#configuration-compilation-and-staging-dev-environment>`__"
+      ":ref:`configuration-compilation-and-staging-dev-environment`"
       section in the Yocto Project Overview and Concepts Manual, and the
       :term:`SYSROOT_DIRS` variable.
-   
+
       .. note::
-   
+
          Recipes should never write files directly under the
          STAGING_DIR
          directory because the OpenEmbedded build system manages the
@@ -6557,7 +7366,7 @@ system and gives an overview of their function and contents.
          do_install
          task and then the OpenEmbedded build system will stage a subset of
          those files into the sysroot.
-   
+
    STAGING_DIR_HOST
       Specifies the path to the sysroot directory for the system on which
       the component is built to run (the system that hosts the component).
@@ -6568,16 +7377,16 @@ system and gives an overview of their function and contents.
       :term:`STAGING_DIR_NATIVE`. Depending on
       the type of recipe and the build target, ``STAGING_DIR_HOST`` can
       have the following values:
-   
+
       -  For recipes building for the target machine, the value is
          "${:term:`STAGING_DIR`}/${:term:`MACHINE`}".
-   
+
       -  For native recipes building for the build host, the value is empty
          given the assumption that when building for the build host, the
          build host's own directories should be used.
-   
+
          .. note::
-   
+
             ``-native`` recipes are not installed into host paths like such
             as ``/usr``. Rather, these recipes are installed into
             ``STAGING_DIR_NATIVE``. When compiling ``-native`` recipes,
@@ -6586,7 +7395,7 @@ system and gives an overview of their function and contents.
             :term:`CFLAGS` are set up so that both host paths
             and ``STAGING_DIR_NATIVE`` are searched for libraries and
             headers using, for example, GCC's ``-isystem`` option.
-   
+
             Thus, the emphasis is that the ``STAGING_DIR*`` variables
             should be viewed as input variables by tasks such as
             :ref:`ref-tasks-configure`,
@@ -6595,17 +7404,17 @@ system and gives an overview of their function and contents.
             root correspond to ``STAGING_DIR_HOST`` makes conceptual sense
             for ``-native`` recipes, as they make use of host headers and
             libraries.
-   
+
    STAGING_DIR_NATIVE
       Specifies the path to the sysroot directory used when building
       components that run on the build host itself.
-   
+
    STAGING_DIR_TARGET
       Specifies the path to the sysroot used for the system for which the
       component generates code. For components that do not generate code,
       which is the majority, ``STAGING_DIR_TARGET`` is set to match
       :term:`STAGING_DIR_HOST`.
-   
+
       Some recipes build binaries that can run on the target system but
       those binaries in turn generate code for another different system
       (e.g. cross-canadian recipes). Using terminology from GNU, the
@@ -6615,171 +7424,203 @@ system and gives an overview of their function and contents.
       system. The ``STAGING_DIR_HOST`` variable points to the sysroot used
       for the "HOST" system, while ``STAGING_DIR_TARGET`` points to the
       sysroot used for the "TARGET" system.
-   
+
    STAGING_ETCDIR_NATIVE
       Specifies the path to the ``/etc`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAGING_EXECPREFIXDIR
       Specifies the path to the ``/usr`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_INCDIR
       Specifies the path to the ``/usr/include`` subdirectory of the
       sysroot directory for the target for which the current recipe being
       built (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_INCDIR_NATIVE
       Specifies the path to the ``/usr/include`` subdirectory of the
       sysroot directory for the build host.
-   
+
    STAGING_KERNEL_BUILDDIR
       Points to the directory containing the kernel build artifacts.
       Recipes building software that needs to access kernel build artifacts
       (e.g. ``systemtap-uprobes``) can look in the directory specified with
       the ``STAGING_KERNEL_BUILDDIR`` variable to find these artifacts
       after the kernel has been built.
-   
+
    STAGING_KERNEL_DIR
       The directory with kernel headers that are required to build
       out-of-tree modules.
-   
+
    STAGING_LIBDIR
       Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
       directory for the target for which the current recipe is being built
       (:term:`STAGING_DIR_HOST`).
-   
+
    STAGING_LIBDIR_NATIVE
       Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
       directory for the build host.
-   
+
    STAMP
       Specifies the base path used to create recipe stamp files. The path
       to an actual stamp file is constructed by evaluating this string and
       then appending additional information. Currently, the default
       assignment for ``STAMP`` as set in the ``meta/conf/bitbake.conf``
-      file is: STAMP =
-      "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
-   
+      file is:
+      ::
+
+         STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+
       For information on how BitBake uses stamp files to determine if a
-      task should be rerun, see the "`Stamp Files and the Rerunning of
-      Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__"
+      task should be rerun, see the
+      ":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
       section in the Yocto Project Overview and Concepts Manual.
-   
+
       See :term:`STAMPS_DIR`,
       :term:`MULTIMACH_TARGET_SYS`,
       :term:`PN`, :term:`EXTENDPE`,
       :term:`PV`, and :term:`PR` for related variable
       information.
-   
+
    STAMPS_DIR
       Specifies the base directory in which the OpenEmbedded build system
       places stamps. The default directory is ``${TMPDIR}/stamps``.
-   
+
    STRIP
       The minimal command and arguments to run ``strip``, which is used to
       strip symbols.
-   
+
    SUMMARY
       The short (72 characters or less) summary of the binary package for
       packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default,
       ``SUMMARY`` is used to define the
       :term:`DESCRIPTION` variable if ``DESCRIPTION`` is
       not set in the recipe.
-   
+
    SVNDIR
       The directory in which files checked out of a Subversion system are
       stored.
-   
+
    SYSLINUX_DEFAULT_CONSOLE
       Specifies the kernel boot default console. If you want to use a
       console other than the default, set this variable in your recipe as
       follows where "X" is the console number you want to use:
-      SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
-   
+      ::
+
+         SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
+
       The :ref:`syslinux <ref-classes-syslinux>` class initially sets
       this variable to null but then checks for a value later.
-   
+
    SYSLINUX_OPTS
       Lists additional options to add to the syslinux file. You need to set
       this variable in your recipe. If you want to list multiple options,
       separate the options with a semicolon character (``;``).
-   
+
       The :ref:`syslinux <ref-classes-syslinux>` class uses this variable
       to create a set of options.
-   
+
    SYSLINUX_SERIAL
       Specifies the alternate serial port or turns it off. To turn off
       serial, set this variable to an empty string in your recipe. The
       variable's default value is set in the
       :ref:`syslinux <ref-classes-syslinux>` class as follows:
-      SYSLINUX_SERIAL ?= "0 115200"
-   
+      ::
+
+         SYSLINUX_SERIAL ?= "0 115200"
+
       The class checks for and uses the variable as needed.
-   
+
    SYSLINUX_SPLASH
       An ``.LSS`` file used as the background for the VGA boot menu when
       you use the boot menu. You need to set this variable in your recipe.
-   
+
       The :ref:`syslinux <ref-classes-syslinux>` class checks for this
       variable and if found, the OpenEmbedded build system installs the
       splash screen.
-   
+
    SYSLINUX_SERIAL_TTY
       Specifies the alternate console=tty... kernel boot argument. The
       variable's default value is set in the
       :ref:`syslinux <ref-classes-syslinux>` class as follows:
-      SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
-   
+      ::
+
+         SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
+
       The class checks for and uses the variable as needed.
-   
+
    SYSROOT_DESTDIR
       Points to the temporary directory under the work directory (default
       "``${``\ :term:`WORKDIR`\ ``}/sysroot-destdir``")
       where the files populated into the sysroot are assembled during the
       :ref:`ref-tasks-populate_sysroot` task.
-   
+
    SYSROOT_DIRS
       Directories that are staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task. By
-      default, the following directories are staged: SYSROOT_DIRS = " \\
-      ${includedir} \\ ${libdir} \\ ${base_libdir} \\
-      ${nonarch_base_libdir} \\ ${datadir} \\ "
-   
+      default, the following directories are staged:
+      ::
+
+         SYSROOT_DIRS = " \
+             ${includedir} \
+             ${libdir} \
+             ${base_libdir} \
+             ${nonarch_base_libdir} \
+             ${datadir} \
+             "
+
    SYSROOT_DIRS_BLACKLIST
       Directories that are not staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task. You
       can use this variable to exclude certain subdirectories of
       directories listed in :term:`SYSROOT_DIRS` from
       staging. By default, the following directories are not staged:
-      SYSROOT_DIRS_BLACKLIST = " \\ ${mandir} \\ ${docdir} \\ ${infodir} \\
-      ${datadir}/locale \\ ${datadir}/applications \\ ${datadir}/fonts \\
-      ${datadir}/pixmaps \\ "
-   
+      ::
+
+         SYSROOT_DIRS_BLACKLIST = " \
+             ${mandir} \
+             ${docdir} \
+             ${infodir} \
+             ${datadir}/locale \
+             ${datadir}/applications \
+             ${datadir}/fonts \
+             ${datadir}/pixmaps \
+             "
+
    SYSROOT_DIRS_NATIVE
       Extra directories staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task for
       ``-native`` recipes, in addition to those specified in
       :term:`SYSROOT_DIRS`. By default, the following
-      extra directories are staged: SYSROOT_DIRS_NATIVE = " \\ ${bindir} \\
-      ${sbindir} \\ ${base_bindir} \\ ${base_sbindir} \\ ${libexecdir} \\
-      ${sysconfdir} \\ ${localstatedir} \\ "
-   
+      extra directories are staged:
+      ::
+
+         SYSROOT_DIRS_NATIVE = " \
+             ${bindir} \
+             ${sbindir} \
+             ${base_bindir} \
+             ${base_sbindir} \
+             ${libexecdir} \
+             ${sysconfdir} \
+             ${localstatedir} \
+             "
+
       .. note::
-   
+
          Programs built by
          -native
          recipes run directly from the sysroot (
          STAGING_DIR_NATIVE
          ), which is why additional directories containing program
          executables and supporting files need to be staged.
-   
+
    SYSROOT_PREPROCESS_FUNCS
       A list of functions to execute after files are staged into the
       sysroot. These functions are usually used to apply additional
       processing on the staged files, or to stage additional files.
-   
+
    SYSTEMD_AUTO_ENABLE
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable specifies whether the specified service in
@@ -6787,111 +7628,138 @@ system and gives an overview of their function and contents.
       automatically or not. By default, the service is enabled to
       automatically start at boot time. The default setting is in the
       :ref:`systemd <ref-classes-systemd>` class as follows:
-      SYSTEMD_AUTO_ENABLE ??= "enable"
-   
+      ::
+
+         SYSTEMD_AUTO_ENABLE ??= "enable"
+
       You can disable the service by setting the variable to "disable".
-   
+
    SYSTEMD_BOOT_CFG
       When :term:`EFI_PROVIDER` is set to
       "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the
       configuration file that should be used. By default, the
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
-      ``SYSTEMD_BOOT_CFG`` as follows: SYSTEMD_BOOT_CFG ?=
-      "${:term:`S`}/loader.conf"
-   
+      ``SYSTEMD_BOOT_CFG`` as follows:
+      ::
+
+         SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf"
+
       For information on Systemd-boot, see the `Systemd-boot
       documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
-   
+
    SYSTEMD_BOOT_ENTRIES
       When :term:`EFI_PROVIDER` is set to
       "systemd-boot", the ``SYSTEMD_BOOT_ENTRIES`` variable specifies a
       list of entry files (``*.conf``) to install that contain one boot
       entry per file. By default, the
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
-      ``SYSTEMD_BOOT_ENTRIES`` as follows: SYSTEMD_BOOT_ENTRIES ?= ""
-   
+      ``SYSTEMD_BOOT_ENTRIES`` as follows:
+      ::
+
+          SYSTEMD_BOOT_ENTRIES ?= ""
+
       For information on Systemd-boot, see the `Systemd-boot
       documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
-   
+
    SYSTEMD_BOOT_TIMEOUT
       When :term:`EFI_PROVIDER` is set to
       "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the
       boot menu timeout in seconds. By default, the
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
-      ``SYSTEMD_BOOT_TIMEOUT`` as follows: SYSTEMD_BOOT_TIMEOUT ?= "10"
-   
+      ``SYSTEMD_BOOT_TIMEOUT`` as follows:
+      ::
+
+         SYSTEMD_BOOT_TIMEOUT ?= "10"
+
       For information on Systemd-boot, see the `Systemd-boot
       documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
-   
+
    SYSTEMD_PACKAGES
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable locates the systemd unit files when they are not found
       in the main recipe's package. By default, the ``SYSTEMD_PACKAGES``
       variable is set such that the systemd unit files are assumed to
-      reside in the recipes main package: SYSTEMD_PACKAGES ?= "${PN}"
-   
+      reside in the recipes main package:
+      ::
+
+         SYSTEMD_PACKAGES ?= "${PN}"
+
       If these unit files are not in this recipe's main package, you need
       to use ``SYSTEMD_PACKAGES`` to list the package or packages in which
       the build system can find the systemd unit files.
-   
+
    SYSTEMD_SERVICE
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable specifies the systemd service name for a package.
-   
+
       When you specify this file in your recipe, use a package name
       override to indicate the package to which the value applies. Here is
-      an example from the connman recipe: SYSTEMD_SERVICE_${PN} =
-      "connman.service"
-   
+      an example from the connman recipe:
+      ::
+
+         SYSTEMD_SERVICE_${PN} = "connman.service"
+
    SYSVINIT_ENABLED_GETTYS
       When using
-      `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__,
+      :ref:`SysVinit <dev-manual/dev-manual-common-tasks:enabling system services>`,
       specifies a space-separated list of the virtual terminals that should
       run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
       (allowing login), assuming :term:`USE_VT` is not set to
       "0".
-   
+
       The default value for ``SYSVINIT_ENABLED_GETTYS`` is "1" (i.e. only
       run a getty on the first virtual terminal).
-   
+
    T
       This variable points to a directory were BitBake places temporary
       files, which consist mostly of task logs and scripts, when building a
-      particular recipe. The variable is typically set as follows: T =
-      "${WORKDIR}/temp"
-   
+      particular recipe. The variable is typically set as follows:
+      ::
+
+         T = "${WORKDIR}/temp"
+
       The :term:`WORKDIR` is the directory into which
       BitBake unpacks and builds the recipe. The default ``bitbake.conf``
       file sets this variable.
-   
+
       The ``T`` variable is not to be confused with the
       :term:`TMPDIR` variable, which points to the root of
       the directory tree where BitBake places the output of an entire
       build.
-   
+
    TARGET_ARCH
       The target machine's architecture. The OpenEmbedded build system
       supports many architectures. Here is an example list of architectures
       supported. This list is by no means complete as the architecture is
-      configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel
-   
+      configurable:
+
+      - arm
+      - i586
+      - x86_64
+      - powerpc
+      - powerpc64
+      - mips
+      - mipsel
+
       For additional information on machine architectures, see the
       :term:`TUNE_ARCH` variable.
-   
+
    TARGET_AS_ARCH
       Specifies architecture-specific assembler flags for the target
       system. ``TARGET_AS_ARCH`` is initialized from
       :term:`TUNE_ASARGS` by default in the BitBake
-      configuration file (``meta/conf/bitbake.conf``): TARGET_AS_ARCH =
-      "${TUNE_ASARGS}"
-   
+      configuration file (``meta/conf/bitbake.conf``):
+      ::
+
+         TARGET_AS_ARCH = "${TUNE_ASARGS}"
+
    TARGET_CC_ARCH
       Specifies architecture-specific C compiler flags for the target
       system. ``TARGET_CC_ARCH`` is initialized from
       :term:`TUNE_CCARGS` by default.
-   
+
       .. note::
-   
+
          It is a common workaround to append
          LDFLAGS
          to
@@ -6900,7 +7768,7 @@ system and gives an overview of their function and contents.
          otherwise respect the exported
          LDFLAGS
          variable.
-   
+
    TARGET_CC_KERNEL_ARCH
       This is a specific kernel compiler flag for a CPU or Application
       Binary Interface (ABI) tune. The flag is used rarely and only for
@@ -6910,118 +7778,118 @@ system and gives an overview of their function and contents.
       different configuration. See the
       ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the
       :term:`Source Directory` for an example.
-   
+
    TARGET_CFLAGS
       Specifies the flags to pass to the C compiler when building for the
       target. When building in the target context,
       :term:`CFLAGS` is set to the value of this variable by
       default.
-   
+
       Additionally, the SDK's environment setup script sets the ``CFLAGS``
       variable in the environment to the ``TARGET_CFLAGS`` value so that
       executables built using the SDK also have the flags applied.
-   
+
    TARGET_CPPFLAGS
       Specifies the flags to pass to the C pre-processor (i.e. to both the
       C and the C++ compilers) when building for the target. When building
       in the target context, :term:`CPPFLAGS` is set to the
       value of this variable by default.
-   
+
       Additionally, the SDK's environment setup script sets the
       ``CPPFLAGS`` variable in the environment to the ``TARGET_CPPFLAGS``
       value so that executables built using the SDK also have the flags
       applied.
-   
+
    TARGET_CXXFLAGS
       Specifies the flags to pass to the C++ compiler when building for the
       target. When building in the target context,
       :term:`CXXFLAGS` is set to the value of this variable
       by default.
-   
+
       Additionally, the SDK's environment setup script sets the
       ``CXXFLAGS`` variable in the environment to the ``TARGET_CXXFLAGS``
       value so that executables built using the SDK also have the flags
       applied.
-   
+
    TARGET_FPU
       Specifies the method for handling FPU code. For FPU-less targets,
       which include most ARM CPUs, the variable must be set to "soft". If
       not, the kernel emulation gets used, which results in a performance
       penalty.
-   
+
    TARGET_LD_ARCH
       Specifies architecture-specific linker flags for the target system.
       ``TARGET_LD_ARCH`` is initialized from
       :term:`TUNE_LDARGS` by default in the BitBake
-      configuration file (``meta/conf/bitbake.conf``): TARGET_LD_ARCH =
-      "${TUNE_LDARGS}"
-   
+      configuration file (``meta/conf/bitbake.conf``):
+      ::
+
+         TARGET_LD_ARCH = "${TUNE_LDARGS}"
+
    TARGET_LDFLAGS
       Specifies the flags to pass to the linker when building for the
       target. When building in the target context,
       :term:`LDFLAGS` is set to the value of this variable
       by default.
-   
+
       Additionally, the SDK's environment setup script sets the
       :term:`LDFLAGS` variable in the environment to the
       ``TARGET_LDFLAGS`` value so that executables built using the SDK also
       have the flags applied.
-   
+
    TARGET_OS
       Specifies the target's operating system. The variable can be set to
       "linux" for glibc-based systems (GNU C Library) and to "linux-musl"
       for musl libc. For ARM/EABI targets, "linux-gnueabi" and
       "linux-musleabi" possible values exist.
-   
+
    TARGET_PREFIX
       Specifies the prefix used for the toolchain binary target tools.
-   
+
       Depending on the type of recipe and the build target,
       ``TARGET_PREFIX`` is set as follows:
-   
+
       -  For recipes building for the target machine, the value is
          "${:term:`TARGET_SYS`}-".
-   
+
       -  For native recipes, the build system sets the variable to the
          value of ``BUILD_PREFIX``.
-   
+
       -  For native SDK recipes (``nativesdk``), the build system sets the
          variable to the value of ``SDK_PREFIX``.
-   
+
    TARGET_SYS
       Specifies the system, including the architecture and the operating
       system, for which the build is occurring in the context of the
       current recipe.
-   
+
       The OpenEmbedded build system automatically sets this variable based
       on :term:`TARGET_ARCH`,
       :term:`TARGET_VENDOR`, and
       :term:`TARGET_OS` variables.
-   
+
       .. note::
-   
-         You do not need to set the
-         TARGET_SYS
-         variable yourself.
-   
+
+         You do not need to set the TARGET_SYS variable yourself.
+
       Consider these two examples:
-   
+
       -  Given a native recipe on a 32-bit, x86 machine running Linux, the
          value is "i686-linux".
-   
+
       -  Given a recipe being built for a little-endian, MIPS target
          running Linux, the value might be "mipsel-linux".
-   
+
    TARGET_VENDOR
       Specifies the name of the target vendor.
-   
+
    TCLIBC
       Specifies the GNU standard C library (``libc``) variant to use during
       the build process. This variable replaces ``POKYLIBC``, which is no
       longer supported.
-   
+
       You can select "glibc", "musl", "newlib", or "baremetal"
-   
+
    TCLIBCAPPEND
       Specifies a suffix to be appended onto the
       :term:`TMPDIR` value. The suffix identifies the
@@ -7029,13 +7897,13 @@ system and gives an overview of their function and contents.
       variants with the same :term:`Build Directory`, this
       mechanism ensures that output for different ``libc`` variants is kept
       separate to avoid potential conflicts.
-   
+
       In the ``defaultsetup.conf`` file, the default value of
       ``TCLIBCAPPEND`` is "-${TCLIBC}". However, distros such as poky,
       which normally only support one ``libc`` variant, set
       ``TCLIBCAPPEND`` to "" in their distro configuration file resulting
       in no suffix being applied.
-   
+
    TCMODE
       Specifies the toolchain selector. ``TCMODE`` controls the
       characteristics of the generated packages and images by telling the
@@ -7043,9 +7911,9 @@ system and gives an overview of their function and contents.
       the OpenEmbedded build system builds its own internal toolchain. The
       variable's default value is "default", which uses that internal
       toolchain.
-   
+
       .. note::
-   
+
          If
          TCMODE
          is set to a value other than "default", then it is your
@@ -7058,53 +7926,53 @@ system and gives an overview of their function and contents.
          Downloads
          page on the Yocto Project website and click on the "RELEASE
          INFORMATION" link for the appropriate release.
-   
+
       The ``TCMODE`` variable is similar to :term:`TCLIBC`,
       which controls the variant of the GNU standard C library (``libc``)
       used during the build process: ``glibc`` or ``musl``.
-   
+
       With additional layers, it is possible to use a pre-compiled external
       toolchain. One example is the Sourcery G++ Toolchain. The support for
       this toolchain resides in the separate Mentor Graphics
       ``meta-sourcery`` layer at
       http://github.com/MentorEmbedded/meta-sourcery/.
-   
+
       The layer's ``README`` file contains information on how to use the
       Sourcery G++ Toolchain as an external toolchain. In summary, you must
       be sure to add the layer to your ``bblayers.conf`` file in front of
       the ``meta`` layer and then set the ``EXTERNAL_TOOLCHAIN`` variable
       in your ``local.conf`` file to the location in which you installed
       the toolchain.
-   
+
       The fundamentals used for this example apply to any external
       toolchain. You can use ``meta-sourcery`` as a template for adding
       support for other external toolchains.
-   
+
    TEST_EXPORT_DIR
       The location the OpenEmbedded build system uses to export tests when
       the :term:`TEST_EXPORT_ONLY` variable is set
       to "1".
-   
+
       The ``TEST_EXPORT_DIR`` variable defaults to
       ``"${TMPDIR}/testimage/${PN}"``.
-   
+
    TEST_EXPORT_ONLY
       Specifies to export the tests only. Set this variable to "1" if you
       do not want to run the tests but you want them to be exported in a
       manner that you to run them outside of the build system.
-   
+
    TEST_LOG_DIR
       Holds the SSH log and the boot log for QEMU machines. The
       ``TEST_LOG_DIR`` variable defaults to ``"${WORKDIR}/testimage"``.
-   
+
       .. note::
-   
+
          Actual test results reside in the task log (
          log.do_testimage
          ), which is in the
          ${WORKDIR}/temp/
          directory.
-   
+
    TEST_POWERCONTROL_CMD
       For automated hardware testing, specifies the command to use to
       control the power of the target machine under test. Typically, this
@@ -7113,7 +7981,7 @@ system and gives an overview of their function and contents.
       command should expect to receive as the last argument "off", "on" or
       "cycle" specifying to power off, on, or cycle (power off and then
       power on) the device, respectively.
-   
+
    TEST_POWERCONTROL_EXTRA_ARGS
       For automated hardware testing, specifies additional arguments to
       pass through to the command specified in
@@ -7121,30 +7989,31 @@ system and gives an overview of their function and contents.
       ``TEST_POWERCONTROL_EXTRA_ARGS`` is optional. You can use it if you
       wish, for example, to separate the machine-specific and
       non-machine-specific parts of the arguments.
-   
+
    TEST_QEMUBOOT_TIMEOUT
       The time in seconds allowed for an image to boot before automated
       runtime tests begin to run against an image. The default timeout
       period to allow the boot process to reach the login prompt is 500
       seconds. You can specify a different value in the ``local.conf``
       file.
-   
-      For more information on testing images, see the "`Performing
-      Automated Runtime
-      Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+
+      For more information on testing images, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    TEST_SERIALCONTROL_CMD
       For automated hardware testing, specifies the command to use to
       connect to the serial console of the target machine under test. This
       command simply needs to connect to the serial console and forward
       that connection to standard input and output as any normal terminal
       program does.
-   
+
       For example, to use the Picocom terminal program on serial device
       ``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows:
-      TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
-   
+      ::
+
+         TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
+
    TEST_SERIALCONTROL_EXTRA_ARGS
       For automated hardware testing, specifies additional arguments to
       pass through to the command specified in
@@ -7152,238 +8021,273 @@ system and gives an overview of their function and contents.
       ``TEST_SERIALCONTROL_EXTRA_ARGS`` is optional. You can use it if you
       wish, for example, to separate the machine-specific and
       non-machine-specific parts of the command.
-   
+
    TEST_SERVER_IP
       The IP address of the build machine (host machine). This IP address
       is usually automatically detected. However, if detection fails, this
       variable needs to be set to the IP address of the build machine (i.e.
       where the build is taking place).
-   
+
       .. note::
-   
+
          The
          TEST_SERVER_IP
          variable is only used for a small number of tests such as the
          "dnf" test suite, which needs to download packages from
          WORKDIR/oe-rootfs-repo
          .
-   
+
    TEST_TARGET
       Specifies the target controller to use when running tests against a
-      test image. The default controller to use is "qemu": TEST_TARGET =
-      "qemu"
-   
+      test image. The default controller to use is "qemu":
+      ::
+
+         TEST_TARGET = "qemu"
+
       A target controller is a class that defines how an image gets
       deployed on a target and how a target is started. A layer can extend
       the controllers by adding a module in the layer's
       ``/lib/oeqa/controllers`` directory and by inheriting the
       ``BaseTarget`` class, which is an abstract class that cannot be used
       as a value of ``TEST_TARGET``.
-   
+
       You can provide the following arguments with ``TEST_TARGET``:
-   
+
       -  *"qemu":* Boots a QEMU image and runs the tests. See the
-         "`Enabling Runtime Tests on
-         QEMU <&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests>`__" section
+         ":ref:`qemu-image-enabling-tests`" section
          in the Yocto Project Development Tasks Manual for more
          information.
-   
+
       -  *"simpleremote":* Runs the tests on target hardware that is
          already up and running. The hardware can be on the network or it
          can be a device running an image on QEMU. You must also set
          :term:`TEST_TARGET_IP` when you use
          "simpleremote".
-   
+
          .. note::
-   
+
             This argument is defined in
             meta/lib/oeqa/controllers/simpleremote.py
             .
-   
-      For information on running tests on hardware, see the "`Enabling
-      Runtime Tests on
-      Hardware <&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests>`__"
+
+      For information on running tests on hardware, see the
+      ":ref:`hardware-image-enabling-tests`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    TEST_TARGET_IP
       The IP address of your hardware under test. The ``TEST_TARGET_IP``
       variable has no effect when :term:`TEST_TARGET` is
       set to "qemu".
-   
+
       When you specify the IP address, you can also include a port. Here is
-      an example: TEST_TARGET_IP = "192.168.1.4:2201" Specifying a port is
+      an example:
+      ::
+
+         TEST_TARGET_IP = "192.168.1.4:2201"
+
+      Specifying a port is
       useful when SSH is started on a non-standard port or in cases when
       your hardware under test is behind a firewall or network that is not
       directly accessible from your host and you need to do port address
       translation.
-   
+
    TEST_SUITES
       An ordered list of tests (modules) to run against an image when
       performing automated runtime testing.
-   
+
       The OpenEmbedded build system provides a core set of tests that can
       be used against images.
-   
+
       .. note::
-   
+
          Currently, there is only support for running these tests under
          QEMU.
-   
+
       Tests include ``ping``, ``ssh``, ``df`` among others. You can add
       your own tests to the list of tests by appending ``TEST_SUITES`` as
-      follows: TEST_SUITES_append = " mytest" Alternatively, you can
+      follows:
+      ::
+
+         TEST_SUITES_append = " mytest"
+
+      Alternatively, you can
       provide the "auto" option to have all applicable tests run against
-      the image. TEST_SUITES_append = " auto" Using this option causes the
+      the image.
+      ::
+
+         TEST_SUITES_append = " auto"
+
+      Using this option causes the
       build system to automatically run tests that are applicable to the
       image. Tests that are not applicable are skipped.
-   
+
       The order in which tests are run is important. Tests that depend on
       another test must appear later in the list than the test on which
       they depend. For example, if you append the list of tests with two
       tests (``test_A`` and ``test_B``) where ``test_B`` is dependent on
-      ``test_A``, then you must order the tests as follows: TEST_SUITES = "
-      test_A test_B"
-   
-      For more information on testing images, see the "`Performing
-      Automated Runtime
-      Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+      ``test_A``, then you must order the tests as follows:
+      ::
+
+         TEST_SUITES = "test_A test_B"
+
+      For more information on testing images, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual.
-   
+
    TESTIMAGE_AUTO
       Automatically runs the series of automated tests for images when an
       image is successfully built. Setting ``TESTIMAGE_AUTO`` to "1" causes
       any image that successfully builds to automatically boot under QEMU.
       Using the variable also adds in dependencies so that any SDK for
       which testing is requested is automatically built first.
-   
+
       These tests are written in Python making use of the ``unittest``
       module, and the majority of them run commands on the target system
       over ``ssh``. You can set this variable to "1" in your ``local.conf``
       file in the :term:`Build Directory` to have the
       OpenEmbedded build system automatically run these tests after an
-      image successfully builds: TESTIMAGE_AUTO = "1" For more information
-      on enabling, running, and writing these tests, see the "`Performing
-      Automated Runtime
-      Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__"
+      image successfully builds:
+
+         TESTIMAGE_AUTO = "1"
+
+      For more information
+      on enabling, running, and writing these tests, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual and the
       ":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
-   
+
    THISDIR
       The directory in which the file BitBake is currently parsing is
       located. Do not manually set this variable.
-   
+
    TIME
       The time the build was started. Times appear using the hour, minute,
       and second (HMS) format (e.g. "140159" for one minute and fifty-nine
       seconds past 1400 hours).
-   
+
    TMPDIR
       This variable is the base directory the OpenEmbedded build system
       uses for all build output and intermediate files (other than the
       shared state cache). By default, the ``TMPDIR`` variable points to
       ``tmp`` within the :term:`Build Directory`.
-   
+
       If you want to establish this directory in a location other than the
       default, you can uncomment and edit the following statement in the
       ``conf/local.conf`` file in the :term:`Source Directory`:
-      #TMPDIR = "${TOPDIR}/tmp" An
-      example use for this scenario is to set ``TMPDIR`` to a local disk,
+      ::
+
+         #TMPDIR = "${TOPDIR}/tmp"
+
+      An example use for this scenario is to set ``TMPDIR`` to a local disk,
       which does not use NFS, while having the Build Directory use NFS.
-   
+
       The filesystem used by ``TMPDIR`` must have standard filesystem
       semantics (i.e. mixed-case files are unique, POSIX file locking, and
       persistent inodes). Due to various issues with NFS and bugs in some
       implementations, NFS does not meet this minimum requirement.
       Consequently, ``TMPDIR`` cannot be on NFS.
-   
+
    TOOLCHAIN_HOST_TASK
       This variable lists packages the OpenEmbedded build system uses when
       building an SDK, which contains a cross-development environment. The
       packages specified by this variable are part of the toolchain set
       that runs on the :term:`SDKMACHINE`, and each
       package should usually have the prefix ``nativesdk-``. For example,
-      consider the following command when building an SDK: $ bitbake -c
-      populate_sdk imagename In this case, a default list of packages is
+      consider the following command when building an SDK:
+      ::
+
+         $ bitbake -c populate_sdk imagename
+
+      In this case, a default list of packages is
       set in this variable, but you can add additional packages to the
-      list. See the "`Adding Individual Packages to the Standard
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages>`__" section
+      list. See the
+      ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
       in the Yocto Project Application Development and the Extensible
       Software Development Kit (eSDK) manual for more information.
-   
+
       For background information on cross-development toolchains in the
-      Yocto Project development environment, see the "`Cross-Development
-      Toolchain
-      Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+      Yocto Project development environment, see the
+      ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
       section in the Yocto Project Overview and Concepts Manual. For
       information on setting up a cross-development environment, see the
-      `Yocto Project Application Development and the Extensible Software
-      Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
-   
+      :doc:`../sdk-manual/sdk-manual` manual.
+
    TOOLCHAIN_OUTPUTNAME
       This variable defines the name used for the toolchain output. The
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets
       the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:
-      TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See
+      ::
+
+         TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
+
+      See
       the :term:`SDK_NAME` and
       :term:`SDK_VERSION` variables for additional
       information.
-   
+
    TOOLCHAIN_TARGET_TASK
       This variable lists packages the OpenEmbedded build system uses when
       it creates the target part of an SDK (i.e. the part built for the
       target hardware), which includes libraries and headers. Use this
       variable to add individual packages to the part of the SDK that runs
-      on the target. See the "`Adding Individual Packages to the Standard
-      SDK <&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages>`__" section
+      on the target. See the
+      ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
       in the Yocto Project Application Development and the Extensible
       Software Development Kit (eSDK) manual for more information.
-   
+
       For background information on cross-development toolchains in the
-      Yocto Project development environment, see the "`Cross-Development
-      Toolchain
-      Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__"
+      Yocto Project development environment, see the
+      ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
       section in the Yocto Project Overview and Concepts Manual. For
       information on setting up a cross-development environment, see the
-      `Yocto Project Application Development and the Extensible Software
-      Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual.
-   
+      :doc:`../sdk-manual/sdk-manual` manual.
+
    TOPDIR
       The top-level :term:`Build Directory`. BitBake
       automatically sets this variable when you initialize your build
       environment using ````` <#structure-core-script>`__.
-   
+
    TRANSLATED_TARGET_ARCH
       A sanitized version of :term:`TARGET_ARCH`. This
       variable is used where the architecture is needed in a value where
       underscores are not allowed, for example within package filenames. In
       this case, dash characters replace any underscore characters used in
       ``TARGET_ARCH``.
-   
+
       Do not edit this variable.
-   
+
    TUNE_ARCH
       The GNU canonical architecture for a specific architecture (i.e.
       ``arm``, ``armeb``, ``mips``, ``mips64``, and so forth). BitBake uses
       this value to setup configuration.
-   
+
       ``TUNE_ARCH`` definitions are specific to a given architecture. The
       definitions can be a single static definition, or can be dynamically
       adjusted. You can see details for a given CPU family by looking at
       the architecture's ``README`` file. For example, the
-      ``meta/conf/machine/include/mips/README`` file in the 
+      ``meta/conf/machine/include/mips/README`` file in the
       :term:`Source Directory` provides information for
       ``TUNE_ARCH`` specific to the ``mips`` architecture.
-   
+
       ``TUNE_ARCH`` is tied closely to
       :term:`TARGET_ARCH`, which defines the target
       machine's architecture. The BitBake configuration file
       (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows:
-      TARGET_ARCH = "${TUNE_ARCH}"
-   
+      ::
+
+         TARGET_ARCH = "${TUNE_ARCH}"
+
       The following list, which is by no means complete since architectures
-      are configurable, shows supported machine architectures: arm i586
-      x86_64 powerpc powerpc64 mips mipsel
-   
+      are configurable, shows supported machine architectures:
+
+      - arm
+      - i586
+      - x86_64
+      - powerpc
+      - powerpc64
+      - mips
+      - mipsel
+
    TUNE_ASARGS
       Specifies architecture-specific assembler flags for the target
       system. The set of flags is based on the selected tune features.
@@ -7391,28 +8295,30 @@ system and gives an overview of their function and contents.
       typically under ``meta/conf/machine/include/`` and are influenced
       through :term:`TUNE_FEATURES`. For example, the
       ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
-      for the x86 architecture as follows: TUNE_ASARGS +=
-      "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
-   
+      for the x86 architecture as follows:
+      ::
+
+         TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
+
       .. note::
-   
+
          Board Support Packages (BSPs) select the tune. The selected tune,
          in turn, affects the tune variables themselves (i.e. the tune can
          supply its own set of flags).
-   
+
    TUNE_CCARGS
       Specifies architecture-specific C compiler flags for the target
       system. The set of flags is based on the selected tune features.
       ``TUNE_CCARGS`` is set using the tune include files, which are
       typically under ``meta/conf/machine/include/`` and are influenced
       through :term:`TUNE_FEATURES`.
-   
+
       .. note::
-   
+
          Board Support Packages (BSPs) select the tune. The selected tune,
          in turn, affects the tune variables themselves (i.e. the tune can
          supply its own set of flags).
-   
+
    TUNE_LDARGS
       Specifies architecture-specific linker flags for the target system.
       The set of flags is based on the selected tune features.
@@ -7420,41 +8326,49 @@ system and gives an overview of their function and contents.
       typically under ``meta/conf/machine/include/`` and are influenced
       through :term:`TUNE_FEATURES`. For example, the
       ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
-      for the x86 architecture as follows: TUNE_LDARGS +=
-      "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "",
-      d)}"
-   
+      for the x86 architecture as follows:
+      ::
+
+         TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
+
       .. note::
-   
+
          Board Support Packages (BSPs) select the tune. The selected tune,
          in turn, affects the tune variables themselves (i.e. the tune can
          supply its own set of flags).
-   
+
    TUNE_FEATURES
       Features used to "tune" a compiler for optimal use given a specific
       processor. The features are defined within the tune files and allow
       arguments (i.e. ``TUNE_*ARGS``) to be dynamically generated based on
       the features.
-   
+
       The OpenEmbedded build system verifies the features to be sure they
       are not conflicting and that they are supported.
-   
+
       The BitBake configuration file (``meta/conf/bitbake.conf``) defines
-      ``TUNE_FEATURES`` as follows: TUNE_FEATURES ??=
-      "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" See the
-      :term:`DEFAULTTUNE` variable for more information.
-   
+      ``TUNE_FEATURES`` as follows:
+      ::
+
+         TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
+
+      See the :term:`DEFAULTTUNE` variable for more information.
+
    TUNE_PKGARCH
       The package architecture understood by the packaging system to define
       the architecture, ABI, and tuning of output packages. The specific
       tune is defined using the "_tune" override as follows:
-      TUNE_PKGARCH_tune-tune = "tune"
-   
+      ::
+
+         TUNE_PKGARCH_tune-tune = "tune"
+
       These tune-specific package architectures are defined in the machine
       include files. Here is an example of the "core2-32" tuning as used in
       the ``meta/conf/machine/include/tune-core2.inc`` file:
-      TUNE_PKGARCH_tune-core2-32 = "core2-32"
-   
+      ::
+
+         TUNE_PKGARCH_tune-core2-32 = "core2-32"
+
    TUNEABI
       An underlying Application Binary Interface (ABI) used by a particular
       tuning in a given toolchain layer. Providers that use prebuilt
@@ -7462,11 +8376,11 @@ system and gives an overview of their function and contents.
       :term:`TUNEABI_OVERRIDE`, and
       :term:`TUNEABI_WHITELIST` variables to check
       compatibility of tunings against their selection of libraries.
-   
+
       If ``TUNEABI`` is undefined, then every tuning is allowed. See the
       :ref:`sanity <ref-classes-sanity>` class to see how the variable is
       used.
-   
+
    TUNEABI_OVERRIDE
       If set, the OpenEmbedded system ignores the
       :term:`TUNEABI_WHITELIST` variable.
@@ -7474,10 +8388,10 @@ system and gives an overview of their function and contents.
       ``TUNEABI_OVERRIDE``, ``TUNEABI_WHITELIST``, and
       :term:`TUNEABI` variables to check compatibility of a
       tuning against their selection of libraries.
-   
+
       See the :ref:`sanity <ref-classes-sanity>` class to see how the
       variable is used.
-   
+
    TUNEABI_WHITELIST
       A whitelist of permissible :term:`TUNEABI` values. If
       ``TUNEABI_WHITELIST`` is not set, all tunes are allowed. Providers
@@ -7485,100 +8399,112 @@ system and gives an overview of their function and contents.
       :term:`TUNEABI_OVERRIDE`, and ``TUNEABI``
       variables to check compatibility of a tuning against their selection
       of libraries.
-   
+
       See the :ref:`sanity <ref-classes-sanity>` class to see how the
       variable is used.
-   
+
    TUNECONFLICTS[feature]
       Specifies CPU or Application Binary Interface (ABI) tuning features
       that conflict with feature.
-   
+
       Known tuning conflicts are specified in the machine include files in
       the :term:`Source Directory`. Here is an example from
       the ``meta/conf/machine/include/mips/arch-mips.inc`` include file
       that lists the "o32" and "n64" features as conflicting with the "n32"
-      feature: TUNECONFLICTS[n32] = "o32 n64"
-   
+      feature:
+      ::
+
+         TUNECONFLICTS[n32] = "o32 n64"
+
    TUNEVALID[feature]
       Specifies a valid CPU or Application Binary Interface (ABI) tuning
       feature. The specified feature is stored as a flag. Valid features
       are specified in the machine include files (e.g.
       ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example
-      from that file: TUNEVALID[bigendian] = "Enable big-endian mode."
-   
+      from that file:
+      ::
+
+         TUNEVALID[bigendian] = "Enable big-endian mode."
+
       See the machine include files in the :term:`Source Directory`
       for these features.
-   
+
    UBOOT_CONFIG
       Configures the :term:`UBOOT_MACHINE` and can
       also define :term:`IMAGE_FSTYPES` for individual
       cases.
-   
-      Following is an example from the ``meta-fsl-arm`` layer. UBOOT_CONFIG
-      ??= "sd" UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
-      UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
-      UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
-      UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" In this example,
-      "sd" is selected as the configuration of the possible four for the
+
+      Following is an example from the ``meta-fsl-arm`` layer. ::
+
+         UBOOT_CONFIG ??= "sd"
+         UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
+         UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
+         UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
+         UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"
+
+      In this example, "sd" is selected as the configuration of the possible four for the
       ``UBOOT_MACHINE``. The "sd" configuration defines
       "mx6qsabreauto_config" as the value for ``UBOOT_MACHINE``, while the
       "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-boot image.
-   
+
       For more information on how the ``UBOOT_CONFIG`` is handled, see the
-      ```uboot-config`http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-config.bbclass
+      :ref:`uboot-config <ref-classes-uboot-config>`
       class.
 
    UBOOT_DTB_LOADADDRESS
       Specifies the load address for the dtb image used by U-boot. During FIT
       image creation, the ``UBOOT_DTB_LOADADDRESS`` variable is used in
-      ``kernel-fitimage`` class to specify the load address to be used in
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify
+      the load address to be used in
       creating the dtb sections of Image Tree Source for the FIT image.
 
    UBOOT_DTBO_LOADADDRESS
       Specifies the load address for the dtbo image used by U-boot.  During FIT
       image creation, the ``UBOOT_DTBO_LOADADDRESS`` variable is used in
-      ``kernel-fitimage`` class to specify the load address to be used in
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in
       creating the dtbo sections of Image Tree Source for the FIT image.
-   
+
    UBOOT_ENTRYPOINT
       Specifies the entry point for the U-Boot image. During U-Boot image
       creation, the ``UBOOT_ENTRYPOINT`` variable is passed as a
       command-line parameter to the ``uboot-mkimage`` utility.
-   
+
    UBOOT_LOADADDRESS
       Specifies the load address for the U-Boot image. During U-Boot image
       creation, the ``UBOOT_LOADADDRESS`` variable is passed as a
       command-line parameter to the ``uboot-mkimage`` utility.
-   
+
    UBOOT_LOCALVERSION
       Appends a string to the name of the local version of the U-Boot
       image. For example, assuming the version of the U-Boot image built
       was "2013.10", the full version string reported by U-Boot would be
-      "2013.10-yocto" given the following statement: UBOOT_LOCALVERSION =
-      "-yocto"
-   
+      "2013.10-yocto" given the following statement:
+      ::
+
+         UBOOT_LOCALVERSION = "-yocto"
+
    UBOOT_MACHINE
       Specifies the value passed on the ``make`` command line when building
       a U-Boot image. The value indicates the target platform
       configuration. You typically set this variable from the machine
       configuration file (i.e. ``conf/machine/machine_name.conf``).
-   
+
       Please see the "Selection of Processor Architecture and Board Type"
       section in the U-Boot README for valid values for this variable.
-   
+
    UBOOT_MAKE_TARGET
       Specifies the target called in the ``Makefile``. The default target
       is "all".
 
    UBOOT_MKIMAGE_DTCOPTS
       Options for the device tree compiler passed to mkimage '-D'
-      feature while creating FIT image in ``kernel-fitimage`` class.
+      feature while creating FIT image in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class.
 
    UBOOT_RD_LOADADDRESS
       Specifies the load address for the RAM disk image.
       During FIT image creation, the
       ``UBOOT_RD_LOADADDRESS`` variable is used
-      in ``kernel-fitimage`` class to specify the
+      in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
       load address to be used in creating the Image Tree Source for
       the FIT image.
 
@@ -7586,10 +8512,10 @@ system and gives an overview of their function and contents.
       Specifies the entrypoint for the RAM disk image.
       During FIT image creation, the
       ``UBOOT_RD_ENTRYPOINT`` variable is used
-      in ``kernel-fitimage`` class to specify the
+      in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
       entrypoint to be used in creating the Image Tree Source for
       the FIT image.
-   
+
    UBOOT_SIGN_ENABLE
       Enable signing of FIT image. The default value is "0".
 
@@ -7628,40 +8554,44 @@ system and gives an overview of their function and contents.
       configure scripts. It follows that no benefit exists in seeing a
       warning about these options. For these cases, the options are added
       to ``UNKNOWN_CONFIGURE_WHITELIST``.
-   
+
       The configure arguments check that uses
       ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the
       :ref:`insane <ref-classes-insane>` class and is only enabled if the
       recipe inherits the :ref:`autotools <ref-classes-autotools>` class.
-   
+
    UPDATERCPN
       For recipes inheriting the
       :ref:`update-rc.d <ref-classes-update-rc.d>` class, ``UPDATERCPN``
       specifies the package that contains the initscript that is enabled.
-   
+
       The default value is "${PN}". Given that almost all recipes that
       install initscripts package them in the main package for the recipe,
       you rarely need to set this variable in individual recipes.
-   
+
    UPSTREAM_CHECK_GITTAGREGEX
       You can perform a per-recipe check for what the latest upstream
       source code version is by calling ``bitbake -c checkpkg`` recipe. If
       the recipe source code is provided from Git repositories, the
       OpenEmbedded build system determines the latest upstream version by
       picking the latest tag from the list of all repository tags.
-   
+
       You can use the ``UPSTREAM_CHECK_GITTAGREGEX`` variable to provide a
       regular expression to filter only the relevant tags should the
-      default filter not work correctly. UPSTREAM_CHECK_GITTAGREGEX =
-      "git_tag_regex"
-   
+      default filter not work correctly.
+      ::
+
+         UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex"
+
    UPSTREAM_CHECK_REGEX
       Use the ``UPSTREAM_CHECK_REGEX`` variable to specify a different
       regular expression instead of the default one when the package
       checking system is parsing the page found using
       :term:`UPSTREAM_CHECK_URI`.
-      UPSTREAM_CHECK_REGEX = "package_regex"
-   
+      ::
+
+         UPSTREAM_CHECK_REGEX = "package_regex"
+
    UPSTREAM_CHECK_URI
       You can perform a per-recipe check for what the latest upstream
       source code version is by calling ``bitbake -c checkpkg`` recipe. If
@@ -7669,43 +8599,48 @@ system and gives an overview of their function and contents.
       determined by fetching the directory listing where the tarball is and
       attempting to find a later tarball. When this approach does not work,
       you can use ``UPSTREAM_CHECK_URI`` to provide a different URI that
-      contains the link to the latest tarball. UPSTREAM_CHECK_URI =
-      "recipe_url"
-   
+      contains the link to the latest tarball.
+      ::
+
+         UPSTREAM_CHECK_URI = "recipe_url"
+
    USE_DEVFS
       Determines if ``devtmpfs`` is used for ``/dev`` population. The
       default value used for ``USE_DEVFS`` is "1" when no value is
       specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a
       statically populated ``/dev`` directory.
-   
-      See the "`Selecting a Device
-      Manager <&YOCTO_DOCS_DEV_URL;#selecting-dev-manager>`__" section in
+
+      See the ":ref:`selecting-dev-manager`" section in
       the Yocto Project Development Tasks Manual for information on how to
       use this variable.
-   
+
    USE_VT
       When using
-      `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__,
+      :ref:`SysVinit <new-recipe-enabling-system-services>`,
       determines whether or not to run a
       `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
       virtual terminals in order to enable logging in through those
       terminals.
-   
+
       The default value used for ``USE_VT`` is "1" when no default value is
       specifically set. Typically, you would set ``USE_VT`` to "0" in the
       machine configuration file for machines that do not have a graphical
       display attached and therefore do not need virtual terminal
       functionality.
-   
+
    USER_CLASSES
       A list of classes to globally inherit. These classes are used by the
       OpenEmbedded build system to enable extra features (e.g.
       ``buildstats``, ``image-mklibs``, and so forth).
-   
-      The default list is set in your ``local.conf`` file: USER_CLASSES ?=
-      "buildstats image-mklibs image-prelink" For more information, see
+
+      The default list is set in your ``local.conf`` file:
+      ::
+
+         USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+
+      For more information, see
       ``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`.
-   
+
    USERADD_ERROR_DYNAMIC
       If set to ``error``, forces the OpenEmbedded build system to produce
       an error if the user identification (``uid``) and group
@@ -7713,21 +8648,26 @@ system and gives an overview of their function and contents.
       listed in :term:`USERADD_UID_TABLES` and
       :term:`USERADD_GID_TABLES`. If set to
       ``warn``, a warning will be issued instead.
-   
+
       The default behavior for the build system is to dynamically apply
       ``uid`` and ``gid`` values. Consequently, the
       ``USERADD_ERROR_DYNAMIC`` variable is by default not set. If you plan
       on using statically assigned ``gid`` and ``uid`` values, you should
       set the ``USERADD_ERROR_DYNAMIC`` variable in your ``local.conf``
-      file as follows: USERADD_ERROR_DYNAMIC = "error" Overriding the
+      file as follows:
+      ::
+
+         USERADD_ERROR_DYNAMIC = "error"
+
+      Overriding the
       default behavior implies you are going to also take steps to set
       static ``uid`` and ``gid`` values through use of the
       :term:`USERADDEXTENSION`,
       :term:`USERADD_UID_TABLES`, and
       :term:`USERADD_GID_TABLES` variables.
-   
+
       .. note::
-   
+
          There is a difference in behavior between setting
          USERADD_ERROR_DYNAMIC
          to
@@ -7745,38 +8685,44 @@ system and gives an overview of their function and contents.
          , it will only report errors for recipes that are actually built.
          This saves you from having to add static IDs for recipes that you
          know will never be built.
-   
+
    USERADD_GID_TABLES
       Specifies a password file to use for obtaining static group
       identification (``gid``) values when the OpenEmbedded build system
       adds a group to the system during package installation.
-   
+
       When applying static group identification (``gid``) values, the
       OpenEmbedded build system looks in :term:`BBPATH` for a
       ``files/group`` file and then applies those ``uid`` values. Set the
-      variable as follows in your ``local.conf`` file: USERADD_GID_TABLES =
-      "files/group"
-   
+      variable as follows in your ``local.conf`` file:
+      ::
+
+
+         USERADD_GID_TABLES = "files/group"
+
       .. note::
-   
+
          Setting the
          USERADDEXTENSION
          variable to "useradd-staticids" causes the build system to use
          static
          gid
          values.
-   
+
    USERADD_PACKAGES
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies the individual packages within the recipe
       that require users and/or groups to be added.
-   
+
       You must set this variable if the recipe inherits the class. For
       example, the following enables adding a user for the main package in
-      a recipe: USERADD_PACKAGES = "${PN}"
-   
+      a recipe:
+      ::
+
+         USERADD_PACKAGES = "${PN}"
+
       .. note::
-   
+
          It follows that if you are going to use the
          USERADD_PACKAGES
          variable, you need to set one or more of the
@@ -7786,50 +8732,57 @@ system and gives an overview of their function and contents.
          , or
          GROUPMEMS_PARAM
          variables.
-   
+
    USERADD_PARAM
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
       this variable specifies for a package what parameters should pass to
       the ``useradd`` command if you add a user to the system when the
       package is installed.
-   
-      Here is an example from the ``dbus`` recipe: USERADD_PARAM_${PN} =
-      "--system --home ${localstatedir}/lib/dbus \\ --no-create-home
-      --shell /bin/false \\ --user-group messagebus" For information on the
+
+      Here is an example from the ``dbus`` recipe:
+      ::
+
+         USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
+                                --no-create-home --shell /bin/false \
+                                --user-group messagebus"
+
+      For information on the
       standard Linux shell command ``useradd``, see
       http://linux.die.net/man/8/useradd.
-   
+
    USERADD_UID_TABLES
       Specifies a password file to use for obtaining static user
       identification (``uid``) values when the OpenEmbedded build system
       adds a user to the system during package installation.
-   
+
       When applying static user identification (``uid``) values, the
       OpenEmbedded build system looks in :term:`BBPATH` for a
       ``files/passwd`` file and then applies those ``uid`` values. Set the
-      variable as follows in your ``local.conf`` file: USERADD_UID_TABLES =
-      "files/passwd"
-   
+      variable as follows in your ``local.conf`` file:
+      ::
+
+         USERADD_UID_TABLES = "files/passwd"
+
       .. note::
-   
+
          Setting the
          USERADDEXTENSION
          variable to "useradd-staticids" causes the build system to use
          static
          uid
          values.
-   
+
    USERADDEXTENSION
       When set to "useradd-staticids", causes the OpenEmbedded build system
       to base all user and group additions on a static ``passwd`` and
       ``group`` files found in :term:`BBPATH`.
-   
+
       To use static user identification (``uid``) and group identification
       (``gid``) values, set the variable as follows in your ``local.conf``
       file: USERADDEXTENSION = "useradd-staticids"
-   
+
       .. note::
-   
+
          Setting this variable to use static
          uid
          and
@@ -7837,29 +8790,29 @@ system and gives an overview of their function and contents.
          values causes the OpenEmbedded build system to employ the
          useradd-staticids
          class.
-   
+
       If you use static ``uid`` and ``gid`` information, you must also
       specify the ``files/passwd`` and ``files/group`` files by setting the
       :term:`USERADD_UID_TABLES` and
       :term:`USERADD_GID_TABLES` variables.
       Additionally, you should also set the
       :term:`USERADD_ERROR_DYNAMIC` variable.
-   
+
    VOLATILE_LOG_DIR
       Specifies the persistence of the target's ``/var/log`` directory,
       which is used to house postinstall target log files.
-   
+
       By default, ``VOLATILE_LOG_DIR`` is set to "yes", which means the
       file is not persistent. You can override this setting by setting the
       variable to "no" to make the log directory persistent.
-   
+
    WARN_QA
       Specifies the quality assurance checks whose failures are reported as
       warnings by the OpenEmbedded build system. You set this variable in
       your distribution configuration file. For a list of the checks you
       can control with this variable, see the
       ":ref:`insane.bbclass <ref-classes-insane>`" section.
-   
+
    WKS_FILE_DEPENDS
       When placed in the recipe that builds your image, this variable lists
       build-time dependencies. The ``WKS_FILE_DEPENDS`` variable is only
@@ -7867,39 +8820,46 @@ system and gives an overview of their function and contents.
       :term:`IMAGE_FSTYPES` contains entries related
       to Wic). If your recipe does not create Wic images, the variable has
       no effect.
-   
+
       The ``WKS_FILE_DEPENDS`` variable is similar to the
       :term:`DEPENDS` variable. When you use the variable in
       your recipe that builds the Wic image, dependencies you list in the
       ``WIC_FILE_DEPENDS`` variable are added to the ``DEPENDS`` variable.
-   
+
       With the ``WKS_FILE_DEPENDS`` variable, you have the possibility to
       specify a list of additional dependencies (e.g. native tools,
       bootloaders, and so forth), that are required to build Wic images.
-      Following is an example: WKS_FILE_DEPENDS = "some-native-tool" In the
+      Following is an example:
+      ::
+
+         WKS_FILE_DEPENDS = "some-native-tool"
+
+      In the
       previous example, some-native-tool would be replaced with an actual
       native tool on which the build would depend.
-   
+
    WKS_FILE
       Specifies the location of the Wic kickstart file that is used by the
       OpenEmbedded build system to create a partitioned image
       (image\ ``.wic``). For information on how to create a partitioned
-      image, see the "`Creating Partitioned Images Using
-      Wic <&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic>`__"
+      image, see the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
       section in the Yocto Project Development Tasks Manual. For details on
-      the kickstart file format, see the "`OpenEmbedded Kickstart
-      (``.wks``) Reference <#ref-kickstart>`__" Chapter.
-   
+      the kickstart file format, see the ":doc:`../ref-manual/ref-kickstart`" Chapter.
+
    WORKDIR
       The pathname of the work directory in which the OpenEmbedded build
       system builds a recipe. This directory is located within the
       :term:`TMPDIR` directory structure and is specific to
       the recipe being built and the system for which it is being built.
-   
+
       The ``WORKDIR`` directory is defined as follows:
-      ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+      ::
+
+         ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+
       The actual directory depends on several things:
-   
+
       -  TMPDIR
          : The top-level build output directory
       -  MULTIMACH_TARGET_SYS
@@ -7916,21 +8876,24 @@ system and gives an overview of their function and contents.
          : The recipe version
       -  PR
          : The recipe revision
-   
+
       As an example, assume a Source Directory top-level folder name
       ``poky``, a default Build Directory at ``poky/build``, and a
       ``qemux86-poky-linux`` machine target system. Furthermore, suppose
       your recipe is named ``foo_1.3.0-r0.bb``. In this case, the work
       directory the build system uses to build the package would be as
-      follows: poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
-   
+      follows:
+      ::
+
+         poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+
    XSERVER
       Specifies the packages that should be installed to provide an X
       server and drivers for the current machine, assuming your image
       directly includes ``packagegroup-core-x11-xserver`` or, perhaps
       indirectly, includes "x11-base" in
       :term:`IMAGE_FEATURES`.
-   
+
       The default value of ``XSERVER``, if not specified in the machine
       configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev".