docs: replace `FOO by :term:FOO` where possible

If a variable has a glossary entry and some rST files write about those
variables, it's better to point to the glossary entry instead of just
highlighting it by surrounding it with two tick quotes.

This was automated by the following python script:
"""
import re
from pathlib import Path

with open('objects.inv.txt', 'r') as f:
    objects = f.readlines()

with open('bitbake-objects.inv.txt', 'r') as f:
    objects = objects + f.readlines()

re_term = re.compile(r'variables.html#term-([A-Z_0-9]*)')
terms = []

for obj in objects:
    match = re_term.search(obj)
    if match and match.group(1):
        terms.append(match.group(1))

for rst in Path('.').rglob('*.rst'):
    with open(rst, 'r') as f:
        content = "".joing(f.readlines())
    for term in terms:
        content = re.sub(r'``({})``(?!.*\s*[~-]+)'.format(term), r':term:`\1`', content)

    with open(rst, 'w') as f:
        f.write(content)
"""

(From yocto-docs rev: ba49d9babfcb84bc5c26a68c8c3880a1d9c236d3)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/migration-guides/migration-1.3.rst

@@ -125,7 +125,7 @@ Image recipes that previously included ``apps-console-core`` in
 :term:`IMAGE_FEATURES` should now include ``splash``
 instead to enable the boot-up splash screen. Retaining
 ``apps-console-core`` will still include the splash screen but generates a
-warning. The ``apps-x11-core`` and ``apps-x11-games`` ``IMAGE_FEATURES``
+warning. The ``apps-x11-core`` and ``apps-x11-games`` :term:`IMAGE_FEATURES`
 features have been removed.
 
 .. _migration-1.3-removed-recipes:
@@ -185,7 +185,7 @@ include :term:`PE` as part of the filename::
 
    KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
 
-Because the ``PE`` variable is not set by default, these binary files
+Because the :term:`PE` variable is not set by default, these binary files
 could result with names that include two dash characters. Here is an
 example::
 

documentation/migration-guides/migration-1.4.rst

@@ -28,7 +28,7 @@ Differences include the following:
    and uninstall script functions ``pkg_preinst``, ``pkg_postinst``,
    ``pkg_prerm``, and ``pkg_postrm`` should always have a package name
    override. For example, use ``RDEPENDS_${PN}`` for the main package
-   instead of ``RDEPENDS``. BitBake uses more strict checks when it
+   instead of :term:`RDEPENDS`. BitBake uses more strict checks when it
    parses recipes.
 
 .. _migration-1.4-build-behavior:
@@ -53,10 +53,10 @@ Differences include the following:
    :term:`SRC_URI`, the build system now uses
    :term:`FILESOVERRIDES` instead of
    :term:`OVERRIDES` for the directory names. In
-   general, the values previously in ``OVERRIDES`` are now in
-   ``FILESOVERRIDES`` as well. However, if you relied upon an additional
-   value you previously added to ``OVERRIDES``, you might now need to
-   add it to ``FILESOVERRIDES`` unless you are already adding it through
+   general, the values previously in :term:`OVERRIDES` are now in
+   :term:`FILESOVERRIDES` as well. However, if you relied upon an additional
+   value you previously added to :term:`OVERRIDES`, you might now need to
+   add it to :term:`FILESOVERRIDES` unless you are already adding it through
    the :term:`MACHINEOVERRIDES` or
    :term:`DISTROOVERRIDES` variables, as
    appropriate. For more related changes, see the
@@ -105,7 +105,7 @@ Variables
 
 The following variables have changed:
 
--  ``SANITY_TESTED_DISTROS``: This variable now uses a distribution
+-  :term:`SANITY_TESTED_DISTROS`: This variable now uses a distribution
    ID, which is composed of the host distributor ID followed by the
    release. Previously,
    :term:`SANITY_TESTED_DISTROS` was
@@ -114,7 +114,7 @@ The following variables have changed:
    you are not specifically setting this variable, or if you are
    specifically setting it to "".
 
--  ``SRC_URI``: The ``${``\ :term:`PN`\ ``}``,
+-  :term:`SRC_URI`: The ``${``\ :term:`PN`\ ``}``,
    ``${``\ :term:`PF`\ ``}``,
    ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories
    have been dropped from the default value of the

documentation/migration-guides/migration-1.5.rst

@@ -68,7 +68,7 @@ The following changes have been made that relate to BitBake:
 -  ``${``\ :term:`P`\ ``}`` and
    ``${``\ :term:`PF`\ ``}`` are no longer added to
    :term:`PROVIDES` by default in ``bitbake.conf``.
-   These version-specific ``PROVIDES`` items were seldom used.
+   These version-specific :term:`PROVIDES` items were seldom used.
    Attempting to use them could result in two versions being built
    simultaneously rather than just one version due to the way BitBake
    resolves dependencies.
@@ -84,9 +84,9 @@ The following changes have been made to the package QA checks:
    :term:`WARN_QA` values in your configuration, check
    that they contain all of the issues that you wish to be reported.
    Previous Yocto Project versions contained a bug that meant that any
-   item not mentioned in ``ERROR_QA`` or ``WARN_QA`` would be treated as
+   item not mentioned in :term:`ERROR_QA` or :term:`WARN_QA` would be treated as
    a warning. Consequently, several important items were not already in
-   the default value of ``WARN_QA``. All of the possible QA checks are
+   the default value of :term:`WARN_QA`. All of the possible QA checks are
    now documented in the ":ref:`insane.bbclass <ref-classes-insane>`"
    section.
 
@@ -97,7 +97,7 @@ The following changes have been made to the package QA checks:
 
 -  If you are using the ``buildhistory`` class, the check for the package
    version going backwards is now controlled using a standard QA check.
-   Thus, if you have customized your ``ERROR_QA`` or ``WARN_QA`` values
+   Thus, if you have customized your :term:`ERROR_QA` or :term:`WARN_QA` values
    and still wish to have this check performed, you should add
    "version-going-backwards" to your value for one or the other
    variables depending on how you wish it to be handled. See the
@@ -129,7 +129,7 @@ The following directory changes exist:
 -  When buildhistory is enabled, its output is now written under the
    :term:`Build Directory` rather than
    :term:`TMPDIR`. Doing so makes it easier to delete
-   ``TMPDIR`` and preserve the build history. Additionally, data for
+   :term:`TMPDIR` and preserve the build history. Additionally, data for
    produced SDKs is now split by :term:`IMAGE_NAME`.
 
 -  The ``pkgdata`` directory produced as part of the packaging process
@@ -157,20 +157,20 @@ major issue in the way the values are used.
 The following changes have been made that relate to
 :term:`IMAGE_FEATURES`:
 
--  The value of ``IMAGE_FEATURES`` is now validated to ensure invalid
+-  The value of :term:`IMAGE_FEATURES` is now validated to ensure invalid
    feature items are not added. Some users mistakenly add package names
    to this variable instead of using
    :term:`IMAGE_INSTALL` in order to have the
    package added to the image, which does not work. This change is
-   intended to catch those kinds of situations. Valid ``IMAGE_FEATURES``
+   intended to catch those kinds of situations. Valid :term:`IMAGE_FEATURES`
    are drawn from ``PACKAGE_GROUP`` definitions,
    :term:`COMPLEMENTARY_GLOB` and a new
-   "validitems" varflag on ``IMAGE_FEATURES``. The "validitems" varflag
+   "validitems" varflag on :term:`IMAGE_FEATURES`. The "validitems" varflag
    change allows additional features to be added if they are not
    provided using the previous two mechanisms.
 
--  The previously deprecated "apps-console-core" ``IMAGE_FEATURES`` item
-   is no longer supported. Add "splash" to ``IMAGE_FEATURES`` if you
+-  The previously deprecated "apps-console-core" :term:`IMAGE_FEATURES` item
+   is no longer supported. Add "splash" to :term:`IMAGE_FEATURES` if you
    wish to have the splash screen enabled, since this is all that
    apps-console-core was doing.
 
@@ -285,7 +285,7 @@ Following are changes to ``udev``:
    ``udev-extraconf`` to your image.
 
 -  ``udev`` no longer brings in ``pciutils-ids`` or ``usbutils-ids``
-   through ``RRECOMMENDS``. These are not needed by ``udev`` itself and
+   through :term:`RRECOMMENDS`. These are not needed by ``udev`` itself and
    removing them saves around 350KB.
 
 .. _migration-1.5-removed-renamed-recipes:

documentation/migration-guides/migration-1.6.rst

@@ -61,7 +61,7 @@ If you do not specify a branch, BitBake looks in the default "master" branch.
 
 Alternatively, if you need to bypass this check (e.g. if you are
 fetching a revision corresponding to a tag that is not on any branch),
-you can add ";nobranch=1" to the end of the URL within ``SRC_URI``.
+you can add ";nobranch=1" to the end of the URL within :term:`SRC_URI`.
 
 .. _migration-1.6-bitbake-deps:
 
@@ -134,9 +134,9 @@ OpenEmbedded build system variables, see the ":doc:`/ref-manual/variables`" Chap
 
 :term:`TMPDIR` can no longer be on an NFS mount. NFS does
 not offer full POSIX locking and inode consistency and can cause
-unexpected issues if used to store ``TMPDIR``.
+unexpected issues if used to store :term:`TMPDIR`.
 
-The check for this occurs on startup. If ``TMPDIR`` is detected on an
+The check for this occurs on startup. If :term:`TMPDIR` is detected on an
 NFS mount, an error occurs.
 
 .. _migration-1.6-variable-changes-PRINC:
@@ -274,7 +274,7 @@ In addition to ``core-image-basic`` being renamed,
 Licensing
 ---------
 
-The top-level ``LICENSE`` file has been changed to better describe the
+The top-level :term:`LICENSE` file has been changed to better describe the
 license of the various components of :term:`OpenEmbedded-Core (OE-Core)`. However,
 the licensing itself remains unchanged.
 
@@ -284,7 +284,7 @@ recipes point to this file within
 ``${COREBASE}/LICENSE``) and thus the accompanying checksum must be
 changed from 3f40d7994397109285ec7b81fdeb3b58 to
 4d92cd373abda3937c2bc47fbc49d690. A better alternative is to have
-``LIC_FILES_CHKSUM`` point to a file describing the license that is
+:term:`LIC_FILES_CHKSUM` point to a file describing the license that is
 distributed with the source that the recipe is building, if possible,
 rather than pointing to ``${COREBASE}/LICENSE``.
 
@@ -297,7 +297,7 @@ The "-fpermissive" option has been removed from the default
 :term:`CFLAGS` value. You need to take action on
 individual recipes that fail when building with this option. You need to
 either patch the recipes to fix the issues reported by the compiler, or
-you need to add "-fpermissive" to ``CFLAGS`` in the recipes.
+you need to add "-fpermissive" to :term:`CFLAGS` in the recipes.
 
 .. _migration-1.6-custom-images:
 

documentation/migration-guides/migration-1.7.rst

@@ -140,9 +140,9 @@ part of the variable name. This change not only simplifies usage but
 also allows the values of these variables to be appropriately
 incorporated into task signatures and thus trigger the appropriate tasks
 to re-execute when changed. You should replace any references to
-``module_autoload_*`` with ``KERNEL_MODULE_AUTOLOAD``, and add any
+``module_autoload_*`` with :term:`KERNEL_MODULE_AUTOLOAD`, and add any
 modules for which ``module_conf_*`` is specified to
-``KERNEL_MODULE_PROBECONF``.
+:term:`KERNEL_MODULE_PROBECONF`.
 
 .. _migration-1.7-qa-check-changes:
 

documentation/migration-guides/migration-1.8.rst

@@ -153,8 +153,8 @@ The following QA Check and Validation Changes have occurred:
    instead of ``${D}``.
 
 -  :term:`S` now needs to be set to a valid value within a
-   recipe. If ``S`` is not set in the recipe, the directory is not
-   automatically created. If ``S`` does not point to a directory that
+   recipe. If :term:`S` is not set in the recipe, the directory is not
+   automatically created. If :term:`S` does not point to a directory that
    exists at the time the :ref:`ref-tasks-unpack` task
    finishes, a warning will be shown.
 

documentation/migration-guides/migration-2.0.rst

@@ -25,7 +25,7 @@ and the porting guide at
 https://gcc.gnu.org/gcc-5/porting_to.html.
 
 Alternatively, you can switch back to GCC 4.9 or 4.8 by setting
-``GCCVERSION`` in your configuration, as follows::
+:term:`GCCVERSION` in your configuration, as follows::
 
    GCCVERSION = "4.9%"
 
@@ -244,7 +244,7 @@ The following QA checks have been added:
 
 -  Added an "invalid-packageconfig" check for any options specified in
    :term:`PACKAGECONFIG` that do not match any
-   ``PACKAGECONFIG`` option defined for the recipe.
+   :term:`PACKAGECONFIG` option defined for the recipe.
 
 .. _migration-2.0-miscellaneous:
 

documentation/migration-guides/migration-2.1.rst

@@ -28,8 +28,8 @@ characters. This practice is now a requirement as BitBake's datastore
 now assumes lower-case characters in order to give a slight performance
 boost during parsing. In practical terms, this requirement means that
 anything that ends up in :term:`OVERRIDES` must now
-appear in lower-case characters (e.g. values for ``MACHINE``,
-``TARGET_ARCH``, ``DISTRO``, and also recipe names if
+appear in lower-case characters (e.g. values for :term:`MACHINE`,
+:term:`TARGET_ARCH`, :term:`DISTRO`, and also recipe names if
 ``_pn-``\ recipename overrides are to be effective).
 
 .. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory:
@@ -68,7 +68,7 @@ was a historical accident that has required many classes (e.g.
 to work with sensible build systems. When upgrading to the release, you
 must edit any recipe that relies upon this old default by either setting
 ``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any
-required variable value overrides using ``EXTRA_OEMAKE``, which is
+required variable value overrides using :term:`EXTRA_OEMAKE`, which is
 typically only needed when a Makefile sets a default value for a
 variable that is inappropriate for cross-compilation using the "="
 operator rather than the "?=" operator.
@@ -376,7 +376,7 @@ These additional changes exist:
       run-postinsts
 
    With the Yocto Project 2.1 release, these packages are
-   only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since
+   only removed if "read-only-rootfs" is in :term:`IMAGE_FEATURES`, since
    they might still be needed for a read-write image even in the absence
    of a package manager (e.g. if users need to be added, modified, or
    removed at runtime).

documentation/migration-guides/migration-2.2.rst

@@ -239,7 +239,7 @@ to catch recipes that are building software without using the
 OpenEmbedded :term:`LDFLAGS`. This change could result in
 seeing some "No GNU_HASH in the elf binary" QA issues when building such
 recipes. You need to fix these recipes so that they use the expected
-``LDFLAGS``. Depending on how the software is built, the build system
+:term:`LDFLAGS`. Depending on how the software is built, the build system
 used by the software (e.g. a Makefile) might need to be patched.
 However, sometimes making this fix is as simple as adding the following
 to the recipe::
@@ -291,7 +291,7 @@ The following changes took place for BitBake:
    :term:`SRC_URI` parameters to specify these. This
    change is more in-line with how the other fetchers work for source
    control systems. Recipes that fetch from Perforce will need to be
-   updated to use ``SRCREV`` in place of specifying the source revision
+   updated to use :term:`SRCREV` in place of specifying the source revision
    within ``SRC_URI``.
 
 -  Some of BitBake's internal code structures for accessing the recipe
@@ -308,7 +308,7 @@ The following changes took place for BitBake:
    to cause any problems for most users. However, the setscene
    verification function as pointed to by
    ``BB_SETSCENE_VERIFY_FUNCTION`` needed to change signature.
-   Consequently, a new variable named ``BB_SETSCENE_VERIFY_FUNCTION2``
+   Consequently, a new variable named :term:`BB_SETSCENE_VERIFY_FUNCTION2`
    has been added allowing multiple versions of BitBake to work with
    suitably written metadata, which includes OpenEmbedded-Core and Poky.
    Anyone with custom BitBake task scheduler code might also need to

documentation/migration-guides/migration-2.3.rst

@@ -35,7 +35,7 @@ Consider the following:
    As an example, see the ``dbus`` recipe. You will see that this recipe
    has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in
    :term:`DISTRO_FEATURES`. In the example,
-   ``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``,
+   ``systemd-systemctl-native`` is added to :term:`PACKAGE_WRITE_DEPS`,
    which is also conditional on "systemd" being in ``DISTRO_FEATURES``.
 
 -  Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to
@@ -136,7 +136,7 @@ The following changes to scripts took place:
    removed because the script was found to be deleting files it should
    not have, which lead to broken build trees. Rather than trying to
    delete portions of :term:`TMPDIR` and getting it wrong,
-   it is recommended that you delete ``TMPDIR`` and have it restored
+   it is recommended that you delete :term:`TMPDIR` and have it restored
    from shared state (sstate) on subsequent builds.
 
 -  ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as
@@ -200,10 +200,10 @@ The following changes took place for BitBake:
    section in the BitBake
    User Manual for additional information.
 
--  ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
+-  ``BB_SETSCENE_VERIFY_FUNCTION`` and :term:`BB_SETSCENE_VERIFY_FUNCTION2`
    Removed: Because the mechanism they were part of is no longer
    necessary with recipe-specific sysroots, the
-   ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
+   ``BB_SETSCENE_VERIFY_FUNCTION`` and :term:`BB_SETSCENE_VERIFY_FUNCTION2`
    variables have been removed.
 
 .. _migration-2.3-absolute-symlinks:
@@ -426,10 +426,10 @@ The following miscellaneous changes have occurred:
 
 -  If the :term:`DISTRO_VERSION` value contains
    the value of the :term:`DATE` variable, which is the
-   default between Poky releases, the ``DATE`` value is explicitly
+   default between Poky releases, the :term:`DATE` value is explicitly
    excluded from ``/etc/issue`` and ``/etc/issue.net``, which is
    displayed at the login prompt, in order to avoid conflicts with
-   Multilib enabled. Regardless, the ``DATE`` value is inaccurate if the
+   Multilib enabled. Regardless, the :term:`DATE` value is inaccurate if the
    ``base-files`` recipe is restored from shared state (sstate) rather
    than rebuilt.
 
@@ -451,7 +451,7 @@ The following miscellaneous changes have occurred:
    tools.
 
 -  The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig"
-   ``DISTRO_FEATURES`` feature. Distributions that previously set::
+   :term:`DISTRO_FEATURES` feature. Distributions that previously set::
 
       USE_LDCONFIG = "0"
 
@@ -494,12 +494,12 @@ The following miscellaneous changes have occurred:
    information.
 
 -  All native and nativesdk recipes now use a separate
-   ``DISTRO_FEATURES`` value instead of sharing the value used by
+   :term:`DISTRO_FEATURES` value instead of sharing the value used by
    recipes for the target, in order to avoid unnecessary rebuilds.
 
-   The ``DISTRO_FEATURES`` for ``native`` recipes is
+   The :term:`DISTRO_FEATURES` for ``native`` recipes is
    :term:`DISTRO_FEATURES_NATIVE` added to
-   an intersection of ``DISTRO_FEATURES`` and
+   an intersection of :term:`DISTRO_FEATURES` and
    :term:`DISTRO_FEATURES_FILTER_NATIVE`.
 
    For nativesdk recipes, the corresponding variables are

documentation/migration-guides/migration-2.4.rst

@@ -63,7 +63,7 @@ occurred:
 
    -  The ``ionice`` program is now packaged in a separate
       "util-linux-ionice" package. The main ``util-linux`` package has a
-      recommended runtime dependency (i.e. ``RRECOMMENDS``) on the
+      recommended runtime dependency (i.e. :term:`RRECOMMENDS`) on the
       ``util-linux-ionice`` package.
 
 -  ``initscripts``: The ``sushell`` program is now packaged in a
@@ -71,7 +71,7 @@ occurred:
    systems to pull ``sushell`` in when ``selinux`` is enabled. The
    change also eliminates needing to pull in the entire ``initscripts``
    package. The main ``initscripts`` package has a runtime dependency
-   (i.e. ``RDEPENDS``) on the ``sushell`` package when "selinux" is in
+   (i.e. :term:`RDEPENDS`) on the ``sushell`` package when "selinux" is in
    ``DISTRO_FEATURES``.
 
 -  ``glib-2.0``: The ``glib-2.0`` package now has a recommended

documentation/migration-guides/migration-2.5.rst

@@ -281,7 +281,7 @@ The following are additional changes:
    ``IMAGE_FSTYPES``.
 
 -  Recipes with an unconditional dependency on ``libpam`` are only
-   buildable with ``pam`` in ``DISTRO_FEATURES``. If the dependency is
+   buildable with ``pam`` in :term:`DISTRO_FEATURES`. If the dependency is
    truly optional then it is recommended that the dependency be
    conditional upon ``pam`` being in ``DISTRO_FEATURES``.
 

documentation/migration-guides/migration-2.6.rst

@@ -156,11 +156,11 @@ Image/Kernel Artifact Naming Changes
 The following changes have been made:
 
 -  Name variables (e.g. :term:`IMAGE_NAME`) use a new
-   ``IMAGE_VERSION_SUFFIX`` variable instead of
-   :term:`DATETIME`. Using ``IMAGE_VERSION_SUFFIX``
+   :term:`IMAGE_VERSION_SUFFIX` variable instead of
+   :term:`DATETIME`. Using :term:`IMAGE_VERSION_SUFFIX`
    allows easier and more direct changes.
 
-   The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf``
+   The :term:`IMAGE_VERSION_SUFFIX` variable is set in the ``bitbake.conf``
    configuration file as follows::
 
       IMAGE_VERSION_SUFFIX = "-${DATETIME}"
@@ -212,19 +212,19 @@ The following changes have been made:
 The :term:`SERIAL_CONSOLE` variable has been
 functionally replaced by the
 :term:`SERIAL_CONSOLES` variable for some time.
-With the Yocto Project 2.6 release, ``SERIAL_CONSOLE`` has been
+With the Yocto Project 2.6 release, :term:`SERIAL_CONSOLE` has been
 officially deprecated.
 
-``SERIAL_CONSOLE`` will continue to work as before for the 2.6 release.
+:term:`SERIAL_CONSOLE` will continue to work as before for the 2.6 release.
 However, for the sake of future compatibility, it is recommended that
-you replace all instances of ``SERIAL_CONSOLE`` with
-``SERIAL_CONSOLES``.
+you replace all instances of :term:`SERIAL_CONSOLE` with
+:term:`SERIAL_CONSOLES`.
 
 .. note::
 
-   The only difference in usage is that ``SERIAL_CONSOLES``
+   The only difference in usage is that :term:`SERIAL_CONSOLES`
    expects entries to be separated using semicolons as compared to
-   ``SERIAL_CONSOLE``, which expects spaces.
+   :term:`SERIAL_CONSOLE`, which expects spaces.
 
 .. _migration-2.6-poky-sets-unknown-configure-option-to-qa-error:
 
@@ -387,14 +387,14 @@ QEMU (i.e. "qemu-usermode" is in
 default).
 
 If you wish to disable Python profile-guided optimization regardless of
-the value of ``MACHINE_FEATURES``, then ensure that
+the value of :term:`MACHINE_FEATURES`, then ensure that
 :term:`PACKAGECONFIG` for the ``python3`` recipe
 does not contain "pgo". You could accomplish the latter using the
 following at the configuration level::
 
    PACKAGECONFIG_remove_pn-python3 = "pgo"
 
-Alternatively, you can set ``PACKAGECONFIG`` using an append file
+Alternatively, you can set :term:`PACKAGECONFIG` using an append file
 for the ``python3`` recipe.
 
 .. _migration-2.6-miscellaneous-changes:

documentation/migration-guides/migration-2.7.rst

@@ -91,7 +91,7 @@ This section provides information about packaging changes.
    package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in
    :term:`IMAGE_FEATURES` to bring in debug
    symbols and you still need the sources, you must now also add
-   ``src-pkgs`` to ``IMAGE_FEATURES``. Source packages remain in the
+   ``src-pkgs`` to :term:`IMAGE_FEATURES`. Source packages remain in the
    target portion of the SDK by default, unless you have set your own
    value for :term:`SDKIMAGE_FEATURES` that
    does not include ``src-pkgs``.

documentation/migration-guides/migration-3.1.rst

@@ -260,7 +260,7 @@ Miscellaneous changes
 ---------------------
 
 -  The undocumented ``SRC_DISTRIBUTE_LICENSES`` variable has now been
-   removed in favour of a new ``AVAILABLE_LICENSES`` variable which is
+   removed in favour of a new :term:`AVAILABLE_LICENSES` variable which is
    dynamically set based upon license files found in
    ``${COMMON_LICENSE_DIR}`` and ``${LICENSE_PATH}``.
 

documentation/migration-guides/migration-3.2.rst

@@ -62,10 +62,10 @@ There is a possible complication where some existing recipe may break, for
 example, a recipe was found to be writing to ``${B}/install`` for
 ``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
 there were errors trying to ``chown root`` for files in this location. Another
-example was the ``tcl`` recipe where the source directory ``S`` is set to a
+example was the ``tcl`` recipe where the source directory :term:`S` is set to a
 subdirectory of the source tree but files were written out to the directory
 structure above that subdirectory. For these types of cases in your own recipes,
-extend ``PSEUDO_IGNORE_PATHS`` to cover additional paths that pseudo should not
+extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not
 be monitoring.
 
 In addition, pseudo's behaviour on mismatches has now been changed - rather
@@ -207,7 +207,7 @@ files into a subdirectory and reference that instead.
 deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
 ----------------------------------------------------------
 
-``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of ``DEPLOYDIR`` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
+``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
 
 Most recipes and classes that inherit the ``deploy`` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead.