34 files changed, 327 insertions, 348 deletions

diff --git a/documentation/adt-manual/adt-command.rst b/documentation/adt-manual/adt-command.rst
index 8b86544f19..de854772bb 100644
--- a/documentation/adt-manual/adt-command.rst
+++ b/documentation/adt-manual/adt-command.rst
@@ -6,8 +6,8 @@ Using the Command Line
 
 Recall that earlier the manual discussed how to use an existing
 toolchain tarball that had been installed into the default installation
-directory, ``/opt/poky/DISTRO``, which is outside of the `Build
-Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ (see the section
+directory, ``/opt/poky/DISTRO``, which is outside of the :term:`Build Directory`
+(see the section
 "`Using a Cross-Toolchain
 Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing
 your architecture-specific environment setup script initializes a
diff --git a/documentation/adt-manual/adt-intro.rst b/documentation/adt-manual/adt-intro.rst
index 40612bdddf..d6228ad864 100644
--- a/documentation/adt-manual/adt-intro.rst
+++ b/documentation/adt-manual/adt-intro.rst
@@ -12,8 +12,8 @@ application.
 Fundamentally, the ADT consists of the following:
 
 -  An architecture-specific cross-toolchain and matching sysroot both
-   built by the `OpenEmbedded build
-   system <&YOCTO_DOCS_DEV_URL;#build-system-term>`__. The toolchain and
+   built by the :term:`OpenEmbedded Build System`.
+   The toolchain and
    sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__
    configuration and extensions, which allows you to cross-develop on
    the host machine for the target hardware.
@@ -33,8 +33,8 @@ Toolchain <&YOCTO_DOCS_DEV_URL;#cross-development-toolchain>`__ consists
 of a cross-compiler, cross-linker, and cross-debugger that are used to
 develop user-space applications for targeted hardware. This toolchain is
 created either by running the ADT Installer script, a toolchain
-installer script, or through a `Build
-Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ that is based on
+installer script, or through a :term:`Build Directory`
+that is based on
 your Metadata configuration or extension for your targeted device. The
 cross-toolchain works with a matching target sysroot.
 
@@ -79,13 +79,13 @@ your application or image. QEMU is made available a number of ways:
 -  If you use the ADT Installer script to install ADT, you can specify
    whether or not to install QEMU.
 
--  If you have cloned the ``poky`` Git repository to create a `Source
-   Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__ and you have
+-  If you have cloned the ``poky`` Git repository to create a
+   :term:`Source Directory` and you have
    sourced the environment setup script, QEMU is installed and
    automatically available.
 
 -  If you have downloaded a Yocto Project release and unpacked it to
-   create a `Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__
+   create a :term:`Source Directory`
    and you have sourced the environment setup script, QEMU is installed
    and automatically available.
 
diff --git a/documentation/adt-manual/adt-package.rst b/documentation/adt-manual/adt-package.rst
index 38823a104f..dfa62163b3 100644
--- a/documentation/adt-manual/adt-package.rst
+++ b/documentation/adt-manual/adt-package.rst
@@ -59,7 +59,7 @@ add it into a working ``opkg`` repository. Use these commands: $ bitbake
 libglade $ bitbake package-index
 
 Next, source the cross-toolchain environment setup script found in the
-`Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__. Follow
+:term:`Source Directory`. Follow
 that by setting up the installation destination to point to your sysroot
 as sysroot_dir. Finally, have an OPKG configuration file conf_file that
 corresponds to the ``opkg`` repository you have just created. The
diff --git a/documentation/adt-manual/adt-prepare.rst b/documentation/adt-manual/adt-prepare.rst
index 12b1e7918c..27133d21b4 100644
--- a/documentation/adt-manual/adt-prepare.rst
+++ b/documentation/adt-manual/adt-prepare.rst
@@ -50,7 +50,7 @@ for more information.
    other mentioned benefits had you run the ADT Installer script.
 
 -  *Use the toolchain from within the Build Directory:* If you already
-   have a `Build Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__,
+   have a :term:`Build Directory`,
    you can build the cross-toolchain within the directory. However, like
    the previous method mentioned, you only get the cross-toolchain and
    QEMU - you do not get any of the other benefits without taking
@@ -79,9 +79,8 @@ the tarball using either of these methods:
    ` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory.
 
 -  *Build the Tarball:* You can use
-   `BitBake <&YOCTO_DOCS_DEV_URL;#bitbake-term>`__ to generate the
-   tarball inside an existing `Build
-   Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__.
+   :term:`BitBake` to generate the
+   tarball inside an existing :term:`Build Directory`.
 
    If you use BitBake to generate the ADT Installer tarball, you must
    ``source`` the environment setup script
@@ -90,8 +89,8 @@ the tarball using either of these methods:
    located in the Source Directory before running the ``bitbake``
    command that creates the tarball.
 
-   The following example commands establish the `Source
-   Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__, check out the
+   The following example commands establish the
+   :term:`Source Directory`, check out the
    current release branch, set up the build environment while also
    creating the default Build Directory, and run the ``bitbake`` command
    that results in the tarball
@@ -268,8 +267,8 @@ Using BitBake and the Build Directory
 -------------------------------------
 
 A final way of making the cross-toolchain available is to use BitBake to
-generate the toolchain within an existing `Build
-Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__. This method does
+generate the toolchain within an existing :term:`Build Directory`.
+This method does
 not install the toolchain into the default ``/opt`` directory. As with
 the previous method, if you need to install the target sysroot, you must
 do that separately as well.
@@ -280,8 +279,7 @@ Follow these steps to generate the toolchain into the Build Directory:
    environment setup script (i.e.
    ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
    ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-   located in the `Source
-   Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__.
+   located in the :term:`Source Directory`.
 
 2. *Check your Local Configuration File:* At this point, you should be
    sure that the :term:`MACHINE`
@@ -332,8 +330,8 @@ cross-development environment by sourcing the toolchain's environment
 setup script. If you used the ADT Installer or hand-installed
 cross-toolchain, then you can find this script in the directory you
 chose for installation. For this release, the default installation
-directory is ````. If you installed the toolchain in the `Build
-Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__, you can find the
+directory is ````. If you installed the toolchain in the
+:term:`Build Directory`, you can find the
 environment setup script for the toolchain in the Build Directory's
 ``tmp`` directory.
 
@@ -432,8 +430,8 @@ this by including the ``eclipse-debug`` image feature.
    image features.
 
 To include the ``eclipse-debug`` image feature, modify your
-``local.conf`` file in the `Build
-Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ so that the
+``local.conf`` file in the :term:`Build Directory`
+so that the
 :term:`EXTRA_IMAGE_FEATURES`
 variable includes the "eclipse-debug" feature. After modifying the
 configuration file, you can rebuild the image. Once the image is
@@ -484,8 +482,7 @@ Optionally Building a Toolchain Installer
 =========================================
 
 As an alternative to locating and downloading a toolchain installer, you
-can build the toolchain installer if you have a `Build
-Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__.
+can build the toolchain installer if you have a :term:`Build Directory`.
 
 .. note::
 
diff --git a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
index 712d5c7f8e..563c3f2d9a 100644
--- a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
@@ -162,10 +162,10 @@ an entire Linux distribution, including the toolchain, from source.
    <target>' Common targets are: core-image-minimal core-image-sato
    meta-toolchain meta-ide-support You can also run generated qemu
    images with a command like 'runqemu qemux86-64' Among other things,
-   the script creates the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
-   ``build`` in this case and is located in the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the
+   the script creates the
+   :term:`Build Directory`, which is
+   ``build`` in this case and is located in the :term:`Source Directory`.
+   After the
    script runs, your current working directory is set to the Build
    Directory. Later, when the build completes, the Build Directory
    contains all the files created during the build.
@@ -271,8 +271,8 @@ Follow these steps to add a hardware layer:
 
 4. *Add Your Layer to the Layer Configuration File:* Before you can use
    a layer during a build, you must add it to your ``bblayers.conf``
-   file, which is found in the `Build
-   Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf``
+   file, which is found in the
+   :term:`Build Directory` ``conf``
    directory.
 
    Use the ``bitbake-layers add-layer`` command to add the layer to the
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index e06b1259f0..361951b592 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -74,12 +74,12 @@ section in the Yocto Project Development Tasks Manual.
 The BSP layer's base directory (``meta-bsp_root_name``) is the root
 directory of that Layer. This directory is what you add to the
 :term:`BBLAYERS` variable in the
-``conf/bblayers.conf`` file found in your `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
+``conf/bblayers.conf`` file found in your
+:term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
 script (i.e. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__).
-Adding the root directory allows the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ to recognize the BSP
+Adding the root directory allows the :term:`OpenEmbedded Build System`
+to recognize the BSP
 layer and from it build an image. Here is an example: BBLAYERS ?= " \\
 /usr/local/src/yocto/meta \\ /usr/local/src/yocto/meta-poky \\
 /usr/local/src/yocto/meta-yocto-bsp \\ /usr/local/src/yocto/meta-mylayer
@@ -144,8 +144,7 @@ section.
    machine that uses CROPS.
 
 2. *Clone the ``poky`` Repository:* You need to have a local copy of the
-   Yocto Project `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local
+   Yocto Project :term:`Source Directory` (i.e. a local
    ``poky`` repository). See the "`Cloning the ``poky``
    Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and
    possibly the "`Checking Out by Branch in
@@ -169,8 +168,7 @@ section.
    file.
 
    1. *Navigate to Your Source Directory:* Typically, you set up the
-      ``meta-intel`` Git repository inside the `Source
-      Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
+      ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g.
       ``poky``). $ cd /home/you/poky
 
    2. *Clone the Layer:* $ git clone
@@ -218,10 +216,10 @@ section.
    ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment
    setup script to define the OpenEmbedded build environment on your
    build host. $ source OE_INIT_FILE Among other things, the script
-   creates the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
-   ``build`` in this case and is located in the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the
+   creates the
+   :term:`Build Directory`, which is
+   ``build`` in this case and is located in the :term:`Source Directory`.
+   After the
    script runs, your current working directory is set to the ``build``
    directory.
 
@@ -629,8 +627,8 @@ types of files although, in practice, it is likely that you would have
 one or the other.
 
 For your BSP, you typically want to use an existing Yocto Project kernel
-recipe found in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at
+recipe found in the :term:`Source Directory`
+at
 ``meta/recipes-kernel/linux``. You can append machine-specific changes
 to the kernel recipe by using a similarly named append file, which is
 located in the BSP Layer for your target device (e.g. the
@@ -848,8 +846,8 @@ Yocto Project:
 
 -  *File System Layout:* When possible, use the same directory names in
    your BSP layer as listed in the ``recipes.txt`` file, which is found
-   in ``poky/meta`` directory of the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ or in the
+   in ``poky/meta`` directory of the :term:`Source Directory`
+   or in the
    OpenEmbedded-Core Layer (``openembedded-core``) at
    ` <http://git.openembedded.org/openembedded-core/tree/meta>`__.
 
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index e1fe881437..c019057bf8 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -48,8 +48,8 @@ Follow these general steps to create your layer without using tools:
 
 2. *Create a Directory:* Create the directory for your layer. When you
    create the layer, be sure to create the directory in an area not
-   associated with the Yocto Project `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. the cloned
+   associated with the Yocto Project :term:`Source Directory`
+   (e.g. the cloned
    ``poky`` repository).
 
    While not strictly required, prepend the name of the directory with
@@ -263,8 +263,7 @@ following list:
    repository that use the ``meta-layer_name`` format.
 
 -  *Group Your Layers Locally:* Clone your repository alongside other
-   cloned ``meta`` directories from the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__.
+   cloned ``meta`` directories from the :term:`Source Directory`.
 
 Making Sure Your Layer is Compatible With Yocto Project
 -------------------------------------------------------
@@ -449,8 +448,8 @@ does not have a corresponding recipe with a matching name. See the
 variable for information on how to handle this error.
 
 As an example, consider the main formfactor recipe and a corresponding
-formfactor append file both from the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Here is the main
+formfactor append file both from the :term:`Source Directory`.
+Here is the main
 formfactor recipe, which is named ``formfactor_0.0.bb`` and located in
 the "meta" layer at ``meta/recipes-bsp/formfactor``: SUMMARY = "Device
 formfactor information" SECTION = "base" LICENSE = "MIT"
@@ -769,8 +768,8 @@ high-level image features by using the
 variables. Although the functions for both variables are nearly
 equivalent, best practices dictate using ``IMAGE_FEATURES`` from within
 a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your
-``local.conf`` file, which is found in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
+``local.conf`` file, which is found in the
+:term:`Build Directory`.
 
 To understand how these features work, the best reference is
 ``meta/classes/core-image.bbclass``. This class lists out the available
@@ -996,8 +995,8 @@ application that builds using Autotools. Creating the base recipe using
 ``recipetool`` results in a recipe that has the pre-build dependencies,
 license requirements, and checksums configured.
 
-To run the tool, you just need to be in your `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ and have sourced the
+To run the tool, you just need to be in your
+:term:`Build Directory` and have sourced the
 build environment setup script (i.e.
 ```oe-init-build-env`` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__).
 To get help on the tool, use the following command: $ recipetool -h
@@ -1799,8 +1798,8 @@ different ways:
 
    To enable a service using systemd, your recipe needs to inherit the
    :ref:`systemd <ref-classes-systemd>` class. See
-   the ``systemd.bbclass`` file located in your `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. section for
+   the ``systemd.bbclass`` file located in your :term:`Source Directory`
+   section for
    more information.
 
 .. _new-recipe-packaging:
@@ -2251,7 +2250,7 @@ could lead to compatibility problems with ABI in the future. However,
 sometimes you have no choice.
 
 The easiest solution is to create a recipe that uses the
-```bin_package`` <&YOCTO_DOCS_REF_URL;#ref-classes-bin-package>`__ class
+:ref:`bin_package <ref-classes-bin-package>` class
 and to be sure that you are using default locations for build artifacts.
 In most cases, the ``bin_package`` class handles "skipping" the
 configure and compile steps as well as sets things up to grab packages
@@ -2739,7 +2738,7 @@ The following steps describe how to set up the AUH utility:
       your build directory.
 
    -  If you want to enable testing through the
-      ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__
+      :ref:`testimage <ref-classes-testimage*>`
       class, which is optional, you need to have the following set in
       your ``conf/local.conf`` file: INHERIT += "testimage"
 
@@ -2856,8 +2855,8 @@ could add it easily using the
 script. For example, suppose you use the ``nano.bb`` recipe from the
 ``meta-oe`` layer in the ``meta-openembedded`` repository. For this
 example, assume that the layer has been cloned into following area:
-/home/scottrif/meta-openembedded The following command from your `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ adds the layer to
+/home/scottrif/meta-openembedded The following command from your
+:term:`Build Directory` adds the layer to
 your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``): $
 bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe NOTE:
 Starting bitbake server... Parsing recipes: 100%
@@ -3014,8 +3013,8 @@ You might find it helpful during development to modify the temporary
 source code used by recipes to build packages. For example, suppose you
 are developing a patch and you need to experiment a bit to figure out
 your solution. After you have initially built the package, you can
-iteratively tweak the source code, which is located in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, and then you can
+iteratively tweak the source code, which is located in the
+:term:`Build Directory`, and then you can
 force a re-compile and quickly test your altered code. Once you settle
 on a solution, you can then preserve your changes in the form of
 patches.
@@ -3024,8 +3023,8 @@ During a build, the unpacked temporary source code used by recipes to
 build packages is available in the Build Directory as defined by the
 :term:`S` variable. Below is the default
 value for the ``S`` variable as defined in the
-``meta/conf/bitbake.conf`` configuration file in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: S =
+``meta/conf/bitbake.conf`` configuration file in the
+:term:`Source Directory`: S =
 "${WORKDIR}/${BP}" You should be aware that many recipes override the
 ``S`` variable. For example, recipes that fetch their source from Git
 usually set ``S`` to ``${WORKDIR}/git``.
@@ -3096,8 +3095,8 @@ form of a patch all using Quilt.
 Follow these general steps:
 
 1. *Find the Source Code:* Temporary source code used by the
-   OpenEmbedded build system is kept in the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. See the
+   OpenEmbedded build system is kept in the
+   :term:`Build Directory`. See the
    "`Finding Temporary Source
    Code <#finding-the-temporary-source-code>`__" section to learn how to
    locate the directory that has the temporary source code for a
@@ -3314,8 +3313,8 @@ build host running Linux.
       Build <&YOCTO_DOCS_BRIEF_URL;>`__ document.
 
 The build process creates an entire Linux distribution from source and
-places it in your `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ under
+places it in your
+:term:`Build Directory` under
 ``tmp/deploy/images``. For detailed information on the build process
 using BitBake, see the
 "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the
@@ -3372,8 +3371,8 @@ The following figure and list overviews the build process:
 
    The target is the name of the recipe you want to build. Common
    targets are the images in ``meta/recipes-core/images``,
-   ``meta/recipes-sato/images``, and so forth all found in the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Or, the target
+   ``meta/recipes-sato/images``, and so forth all found in the
+   :term:`Source Directory`. Or, the target
    can be the name of a recipe for a specific piece of software such as
    BusyBox. For more details about the images the OpenEmbedded build
    system supports, see the
@@ -3557,8 +3556,8 @@ Follow these steps to create an initramfs image:
 
 1. *Create the initramfs Image Recipe:* You can reference the
    ``core-image-minimal-initramfs.bb`` recipe found in the
-   ``meta/recipes-core`` directory of the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ as an example
+   ``meta/recipes-core`` directory of the :term:`Source Directory`
+   as an example
    from which to work.
 
 2. *Decide if You Need to Bundle the initramfs Image Into the Kernel
@@ -3715,8 +3714,8 @@ memory used for decompressing the kernel and for the ``__init__``
 functions.
 
 To help you see where you currently are with kernel and root filesystem
-sizes, you can use two tools found in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the
+sizes, you can use two tools found in the :term:`Source Directory`
+in the
 ``scripts/tiny/`` directory:
 
 -  ``ksize.py``: Reports component sizes for the kernel build objects.
@@ -4049,8 +4048,8 @@ your tunings to best consider build times and package feed maintenance.
 Building Software from an External Source
 -----------------------------------------
 
-By default, the OpenEmbedded build system uses the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ when building source
+By default, the OpenEmbedded build system uses the
+:term:`Build Directory` when building source
 code. The build process involves fetching the source files, unpacking
 them, and then patching them if necessary before the build takes place.
 
@@ -4158,8 +4157,7 @@ directory:
 2. *Start With a Clean Build:* You can start with a clean build by
    removing the
    ``${``\ :term:`TMPDIR`\ ``}``
-   directory or using a new `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
+   directory or using a new :term:`Build Directory`.
 
 3. *Build Your Target:* Use BitBake to build your target: $ bitbake
    target The build completes using the known local "snapshot" of source
@@ -4258,7 +4256,7 @@ Following are additional factors that can affect build speed:
    contents could easily be rebuilt.
 
 -  Inheriting the
-   ```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class:
+   :ref:`rm_work <ref-classes-rm-work>` class:
    Inheriting this class has shown to speed up builds due to
    significantly lower amounts of data stored in the data cache as well
    as on disk. Inheriting this class also makes cleanup of
@@ -4409,8 +4407,8 @@ meet your needs.
 In order to enable Multilib, you first need to ensure your recipe is
 extended to support multiple libraries. Many standard recipes are
 already extended and support multiple libraries. You can check in the
-``meta/conf/multilib.conf`` configuration file in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ to see how this is
+``meta/conf/multilib.conf`` configuration file in the
+:term:`Source Directory` to see how this is
 done using the
 :term:`BBCLASSEXTEND` variable.
 Eventually, all recipes will be covered and this list will not be
@@ -4436,8 +4434,8 @@ Using Multilib
 
 After you have set up the recipes, you need to define the actual
 combination of multiple libraries you want to build. You accomplish this
-through your ``local.conf`` configuration file in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. An example
+through your ``local.conf`` configuration file in the
+:term:`Build Directory`. An example
 configuration would be as follows: MACHINE = "qemux86-64" require
 conf/multilib.conf MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = "
@@ -4936,8 +4934,8 @@ Raw Mode
 
 Running Wic in raw mode allows you to specify all the partitions through
 the ``wic`` command line. The primary use for raw mode is if you have
-built your kernel outside of the Yocto Project `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. In other words, you
+built your kernel outside of the Yocto Project
+:term:`Build Directory`. In other words, you
 can point to arbitrary kernel, root filesystem locations, and so forth.
 Contrast this behavior with cooked mode where Wic looks in the Build
 Directory (e.g. ``tmp/deploy/images/``\ machine).
@@ -5210,8 +5208,8 @@ This next example demonstrates that through modification of the
 As mentioned earlier, you can use the command ``wic list images`` to
 show the list of existing kickstart files. The directory in which the
 ``directdisk-gpt.wks`` file resides is
-``scripts/lib/image/canned-wks/``, which is located in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``).
+``scripts/lib/image/canned-wks/``, which is located in the
+:term:`Source Directory` (e.g. ``poky``).
 Because available files reside in this directory, you can create and add
 your own custom files to the directory. Subsequent use of the
 ``wic list images`` command would then include your kickstart files.
@@ -5520,8 +5518,8 @@ Security Flags
 
 The Yocto Project has security flags that you can enable that help make
 your build output more secure. The security flags are in the
-``meta/conf/distro/include/security_flags.inc`` file in your `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``).
+``meta/conf/distro/include/security_flags.inc`` file in your
+:term:`Source Directory` (e.g. ``poky``).
 
 .. note::
 
@@ -5561,7 +5559,7 @@ system to make your images more secure:
    :ref:`extrausers <ref-classes-extrausers>`
    class, which is the preferred method. For an example on how to set up
    both root and user passwords, see the
-   "```extrausers.bbclass`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__"
+   ":ref:`extrausers.bbclass <ref-classes-extrausers>`"
    section.
 
    .. note::
@@ -5663,8 +5661,8 @@ layer. The following steps provide some more detail:
    limited to the list in the previous bulleted item.
 
 -  *Point to Your distribution configuration file:* In your
-   ``local.conf`` file in the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, set your
+   ``local.conf`` file in the :term:`Build Directory`,
+   set your
    :term:`DISTRO` variable to point to
    your distribution's configuration file. For example, if your
    distribution's configuration file is named ``mydistro.conf``, then
@@ -5704,8 +5702,8 @@ new build directory.
 
 The OpenEmbedded build system uses the environment variable
 ``TEMPLATECONF`` to locate the directory from which it gathers
-configuration information that ultimately ends up in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf`` directory.
+configuration information that ultimately ends up in the
+:term:`Build Directory` ``conf`` directory.
 By default, ``TEMPLATECONF`` is set as follows in the ``poky``
 repository: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} This is the
 directory used by the build system to find templates from which to build
@@ -5762,7 +5760,7 @@ the :term:`Build Directory`: INHERIT
 += "rm_work" Adding this statement deletes the work directory used for
 building a recipe once the recipe is built. For more information on
 "rm_work", see the
-```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class in the
+:ref:`rm_work <ref-classes-rm-work>` class in the
 Yocto Project Reference Manual.
 
 Working with Packages
@@ -5947,8 +5945,7 @@ The simplest form for a PR Service is for it to exist for a single host
 development system that builds the package feed (building system). For
 this scenario, you can enable a local PR Service by setting
 :term:`PRSERV_HOST` in your
-``local.conf`` file in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: PRSERV_HOST =
+``local.conf`` file in the :term:`Build Directory`: PRSERV_HOST =
 "localhost:0" Once the service is started, packages will automatically
 get increasing ``PR`` values and BitBake takes care of starting and
 stopping the server.
@@ -6253,8 +6250,8 @@ to use. In your configuration, you use the
 :term:`PACKAGE_CLASSES`
 variable to specify the format:
 
-1. Open the ``local.conf`` file inside your `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (e.g.
+1. Open the ``local.conf`` file inside your
+   :term:`Build Directory` (e.g.
    ``~/poky/build/conf/local.conf``).
 
 2. Select the desired package format as follows: PACKAGE_CLASSES ?=
@@ -6582,8 +6579,8 @@ Adding ptest to Your Build
 To add package testing to your build, add the
 :term:`DISTRO_FEATURES` and
 :term:`EXTRA_IMAGE_FEATURES`
-variables to your ``local.conf`` file, which is found in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__:
+variables to your ``local.conf`` file, which is found in the
+:term:`Build Directory`:
 DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs"
 Once your build is complete, the ptest files are installed into the
 ``/usr/lib/package/ptest`` directory within the image, where ``package``
@@ -7407,8 +7404,8 @@ dependency graphs, so you can see why something was pulled into the
 image. If you are just interested in this information and not interested
 in collecting specific package or SDK information, you can enable
 writing only image information without any history by adding the
-following to your ``conf/local.conf`` file found in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT +=
+following to your ``conf/local.conf`` file found in the
+:term:`Build Directory`: INHERIT +=
 "buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image"
 Here, you set the
 :term:`BUILDHISTORY_FEATURES`
@@ -7856,19 +7853,19 @@ You can start the tests automatically or manually:
    the OpenEmbedded build system successfully creates an image, first
    set the
    :term:`TESTIMAGE_AUTO`
-   variable to "1" in your ``local.conf`` file in the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: TESTIMAGE_AUTO =
+   variable to "1" in your ``local.conf`` file in the
+   :term:`Build Directory`: TESTIMAGE_AUTO =
    "1" Next, build your image. If the image successfully builds, the
    tests run: bitbake core-image-sato
 
 -  *Manually running tests:* To manually run the tests, first globally
    inherit the
-   ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class
+   :ref:`testimage <ref-classes-testimage*>` class
    by editing your ``local.conf`` file: INHERIT += "testimage" Next, use
    BitBake to run the tests: bitbake -c testimage image
 
-All test files reside in ``meta/lib/oeqa/runtime`` in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. A test name maps
+All test files reside in ``meta/lib/oeqa/runtime`` in the
+:term:`Source Directory`. A test name maps
 directly to a Python module. Each test module may contain a number of
 individual tests. Tests are usually grouped together by the area tested
 (e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``).
@@ -7934,8 +7931,8 @@ If your image is already built, make sure the following are set in your
 "IP-address-for-the-test-target" TEST_SERVER_IP =
 "IP-address-for-the-test-server" You can then export the tests with the
 following BitBake command form: $ bitbake image -c testexport Exporting
-the tests places them in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in
+the tests places them in the
+:term:`Build Directory` in
 ``tmp/testexport/``\ image, which is controlled by the
 ``TEST_EXPORT_DIR`` variable.
 
@@ -8158,8 +8155,8 @@ section:
 -  "`Viewing Task Variable
    Dependencies <#dev-viewing-task-variable-dependencies>`__" describes
    how to use the ``bitbake-dumpsig`` command in conjunction with key
-   subdirectories in the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ to determine
+   subdirectories in the
+   :term:`Build Directory` to determine
    variable dependencies.
 
 -  "`Running Specific Tasks <#dev-debugging-taskrunning>`__" describes
@@ -8313,7 +8310,7 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands.
 
       If you want to inspect the ``${WORKDIR}/packages-split``
       directory, make sure that
-      ```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ is not
+      :ref:`rm_work <ref-classes-rm-work>` is not
       enabled when you build the recipe.
 
 -  ``oe-pkgdata-util find-path ``\ path\ `` ...``: Lists the names of
@@ -8704,8 +8701,7 @@ the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
 and ``bbfatal``. The
 :ref:`logging <ref-classes-logging>` class
 implements these functions. See that class in the ``meta/classes``
-folder of the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ for information.
+folder of the :term:`Source Directory` for information.
 
 Logging With Python
 ~~~~~~~~~~~~~~~~~~~
@@ -8890,8 +8886,8 @@ to the file: tools/snep-send.$(OBJEXT): include/near/dbus.h
 Once you have edited the file, use the ``refresh`` command to create the
 patch: $ quilt refresh Refreshed patch patches/parallelmake.patch Once
 the patch file exists, you need to add it back to the originating recipe
-folder. Here is an example assuming a top-level `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ named ``poky``: $
+folder. Here is an example assuming a top-level
+:term:`Source Directory` named ``poky``: $
 cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
 The final thing you need to do to implement the fix in the build is to
 update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
@@ -9163,8 +9159,8 @@ Here are some other tips that you might find useful:
    virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
 
 -  Removing :term:`TMPDIR` (usually
-   ``tmp/``, within the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__) can often fix
+   ``tmp/``, within the
+   :term:`Build Directory`) can often fix
    temporary build issues. Removing ``TMPDIR`` is usually a relatively
    cheap operation, because task output will be cached in
    :term:`SSTATE_DIR` (usually
@@ -9471,8 +9467,7 @@ repository:
    methods to find out:
 
    -  *Maintenance File:* Examine the ``maintainers.inc`` file, which is
-      located in the `Source
-      Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at
+      located in the :term:`Source Directory` at
       ``meta/conf/distro/include``, to see who is responsible for code.
 
    -  *Search by File:* Using `Git <&YOCTO_DOCS_OM_URL;#git>`__, you can
@@ -9495,8 +9490,8 @@ repository:
    The Yocto Project provides two scripts that conveniently let you
    generate and send pull requests to the Yocto Project. These scripts
    are ``create-pull-request`` and ``send-pull-request``. You can find
-   these scripts in the ``scripts`` directory within the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
+   these scripts in the ``scripts`` directory within the
+   :term:`Source Directory` (e.g.
    ``~/poky/scripts``).
 
    Using these scripts correctly formats the requests without
@@ -9641,8 +9636,8 @@ As mentioned in the "`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__"
 section in the Yocto Project Overview and Concepts Manual, open source
 projects are open to the public and they consequently have different
 licensing structures in place. This section describes the mechanism by
-which the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ tracks changes to
+which the :term:`OpenEmbedded Build System`
+tracks changes to
 licensing text and covers how to maintain open source license compliance
 during your project's lifecycle. The section also describes how to
 enable commercially licensed recipes, which by default are disabled.
@@ -9947,8 +9942,8 @@ of compliance in mind.
 
 One way of doing this (but certainly not the only way) is to release
 just the source as a tarball. You can do this by adding the following to
-the ``local.conf`` file found in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT +=
+the ``local.conf`` file found in the
+:term:`Build Directory`: INHERIT +=
 "archiver" ARCHIVER_MODE[src] = "original" During the creation of your
 image, the source from all recipes that deploy packages to the image is
 placed within subdirectories of ``DEPLOY_DIR/sources`` based on the
@@ -10070,8 +10065,8 @@ The error reporting tool allows you to submit errors encountered during
 builds to a central database. Outside of the build environment, you can
 use a web interface to browse errors, view statistics, and query for
 errors. The tool works using a client-server system where the client
-portion is integrated with the installed Yocto Project `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``).
+portion is integrated with the installed Yocto Project
+:term:`Source Directory` (e.g. ``poky``).
 The server receives the information collected and saves it in a
 database.
 
@@ -10093,8 +10088,8 @@ By default, the error reporting tool is disabled. You can enable it by
 inheriting the
 :ref:`report-error <ref-classes-report-error>`
 class by adding the following statement to the end of your
-``local.conf`` file in your `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT +=
+``local.conf`` file in your
+:term:`Build Directory`. INHERIT +=
 "report-error"
 
 By default, the error reporting feature stores information in
@@ -10155,8 +10150,8 @@ The Yocto Project provides the Wayland protocol libraries and the
 reference
 `Weston <http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__
 compositor as part of its release. You can find the integrated packages
-in the ``meta`` layer of the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Specifically, you
+in the ``meta`` layer of the :term:`Source Directory`.
+Specifically, you
 can find the recipes that build both Wayland and Weston at
 ``meta/recipes-graphics/wayland``.
 
diff --git a/documentation/dev-manual/dev-manual-qemu.rst b/documentation/dev-manual/dev-manual-qemu.rst
index 653f90573e..d695b90202 100644
--- a/documentation/dev-manual/dev-manual-qemu.rst
+++ b/documentation/dev-manual/dev-manual-qemu.rst
@@ -100,8 +100,8 @@ available. Follow these general steps to run QEMU:
    Here are some additional examples to help illustrate further QEMU:
 
    -  This example starts QEMU with MACHINE set to "qemux86-64".
-      Assuming a standard `Build
-      Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, ``runqemu``
+      Assuming a standard
+      :term:`Build Directory`, ``runqemu``
       automatically finds the ``bzImage-qemux86-64.bin`` image file and
       the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4``
       (assuming the current build created a ``core-image-minimal``
@@ -232,8 +232,8 @@ be a problem when QEMU is running with KVM enabled. Specifically,
 software compiled with a certain CPU feature crashes when run on a CPU
 under KVM that does not support that feature. To work around this
 problem, you can override QEMU's runtime CPU setting by changing the
-``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the `Build
-Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``deploy/image``
+``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the
+:term:`Build Directory` ``deploy/image``
 directory. This setting specifies a ``-cpu`` option passed into QEMU in
 the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
 available supported CPU types.
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst
index fadc0bff3e..81fa7847e6 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/dev-manual-start.rst
@@ -140,8 +140,7 @@ particular working environment and set of practices.
     Following are some best practices for setting up machines used for
     developing images:
 
-    -  Have the `OpenEmbedded build
-       system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ available on
+    -  Have the :term:`OpenEmbedded Build System` available on
        the developer workstations so developers can run their own builds
        and directly rebuild the software stack.
 
@@ -740,8 +739,8 @@ Cloning and Checking Out Branches
 
 To use the Yocto Project for development, you need a release locally
 installed on your development system. This locally installed set of
-files is referred to as the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the Yocto
+files is referred to as the :term:`Source Directory`
+ in the Yocto
 Project documentation.
 
 The preferred method of creating your Source Directory is by using
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst
index f264cea159..813f4047e2 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/kernel-dev-common.rst
@@ -24,8 +24,8 @@ host is set up to use the Yocto Project. For information on how to get
 set up, see the "`Preparing the Build
 Host <&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host>`__" section in
 the Yocto Project Development Tasks Manual. Part of preparing the system
-is creating a local Git repository of the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (``poky``) on your
+is creating a local Git repository of the
+:term:`Source Directory` (``poky``) on your
 system. Follow the steps in the "`Cloning the ``poky``
 Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__"
 section in the Yocto Project Development Tasks Manual to set up your
@@ -76,8 +76,8 @@ section:
    "qemux86-64", which is fine if you are building for the QEMU emulator
    in 64-bit mode. However, if you are not, you need to set the
    ``MACHINE`` variable appropriately in your ``conf/local.conf`` file
-   found in the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e.
+   found in the
+   :term:`Build Directory` (i.e.
    ``~/poky/build`` in this example).
 
    Also, since you are preparing to work on the kernel image, you need
@@ -240,8 +240,8 @@ section:
    "qemux86-64", which is fine if you are building for the QEMU emulator
    in 64-bit mode. However, if you are not, you need to set the
    ``MACHINE`` variable appropriately in your ``conf/local.conf`` file
-   found in the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e.
+   found in the
+   :term:`Build Directory` (i.e.
    ``~/poky/build`` in this example).
 
    Also, since you are preparing to work on the kernel image, you need
@@ -289,8 +289,8 @@ section:
    ` <&YOCTO_GIT_URL;>`__.
 
    For simplicity, it is recommended that you create your copy of the
-   kernel Git repository outside of the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is
+   kernel Git repository outside of the
+   :term:`Source Directory`, which is
    usually named ``poky``. Also, be sure you are in the
    ``standard/base`` branch.
 
@@ -317,8 +317,8 @@ section:
 
 6. *Create a Local Copy of the Kernel Cache Git Repository:* For
    simplicity, it is recommended that you create your copy of the kernel
-   cache Git repository outside of the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is
+   cache Git repository outside of the
+   :term:`Source Directory`, which is
    usually named ``poky``. Also, for this example, be sure you are in
    the ``yocto-4.12`` branch.
 
@@ -483,8 +483,8 @@ ensure the build process uses the appropriate kernel branch.
 Although this particular example does not use it, the
 :term:`KERNEL_FEATURES`
 variable could be used to enable features specific to the kernel. The
-append file points to specific commits in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ Git repository and
+append file points to specific commits in the
+:term:`Source Directory` Git repository and
 the ``meta`` Git repository branches to identify the exact kernel needed
 to build the BSP.
 
@@ -781,8 +781,8 @@ the "`Getting Ready to Develop Using
 
 8. *Build the Image With Your Modified Kernel:* You can now build an
    image that includes your kernel patches. Execute the following
-   command from your `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in the terminal
+   command from your
+   :term:`Build Directory` in the terminal
    set up to run BitBake: $ cd ~/poky/build $ bitbake core-image-minimal
 
 Using Traditional Kernel Development to Patch the Kernel
@@ -1134,8 +1134,7 @@ build system applies fragments on top of and after applying the existing
 defconfig file configurations.
 
 Syntactically, the configuration statement is identical to what would
-appear in the ``.config`` file, which is in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
+appear in the ``.config`` file, which is in the :term:`Build Directory`.
 
 .. note::
 
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
index ed1486b65d..cf4c20aaeb 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
@@ -320,8 +320,8 @@ tree specific to your kernel from which to generate the new kernel
 image.
 
 The following figure shows the temporary file structure created on your
-host system when you build the kernel using Bitbake. This `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ contains all the
+host system when you build the kernel using Bitbake. This
+:term:`Build Directory` contains all the
 source files used during the build.
 
 Again, for additional information on the Yocto Project kernel's
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.rst b/documentation/kernel-dev/kernel-dev-maint-appx.rst
index d76e789d56..c0c0bc260b 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.rst
@@ -222,7 +222,7 @@ functionality.
 This behavior means that all the generated files for a particular
 machine or BSP are now in the build tree directory. The files include
 the final ``.config`` file, all the ``.o`` files, the ``.a`` files, and
-so forth. Since each machine or BSP has its own separate `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in its own separate
+so forth. Since each machine or BSP has its own separate
+:term:`Build Directory` in its own separate
 branch of the Git repository, you can easily switch between different
 builds.
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index 59096fbebf..9764b25b6d 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -6,8 +6,8 @@ Yocto Project Concepts
 
 This chapter provides explanations for Yocto Project concepts that go
 beyond the surface of "how-to" information and reference (or look-up)
-material. Concepts such as components, the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ workflow,
+material. Concepts such as components, the :term:`OpenEmbedded Build System`
+workflow,
 cross-development toolchains, shared state cache, and so forth are
 explained.
 
@@ -48,8 +48,8 @@ Concepts <#openembedded-build-system-build-concepts>`__" section.
 BitBake
 -------
 
-BitBake is the tool at the heart of the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible
+BitBake is the tool at the heart of the :term:`OpenEmbedded Build System`
+and is responsible
 for parsing the :term:`Metadata`, generating
 a list of tasks from it, and then executing those tasks.
 
@@ -109,7 +109,7 @@ Class files (``.bbclass``) contain information that is useful to share
 between recipes files. An example is the
 :ref:`autotools <ref-classes-autotools>` class,
 which contains common settings for any application that Autotools uses.
-The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the
+The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
 Yocto Project Reference Manual provides details about classes and how to
 use them.
 
@@ -123,8 +123,8 @@ variables that govern the OpenEmbedded build process. These files fall
 into several areas that define machine configuration options,
 distribution configuration options, compiler tuning options, general
 common configuration options, and user configuration options in
-``conf/local.conf``, which is found in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
+``conf/local.conf``, which is found in the :term:`Build Directory`.
+
 
 .. _overview-layers:
 
@@ -164,8 +164,8 @@ OpenEmbedded Build System Concepts
 ==================================
 
 This section takes a more detailed look inside the build process used by
-the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which is the build
+the :term:`OpenEmbedded Build System`,
+which is the build
 system specific to the Yocto Project. At the heart of the build system
 is BitBake, the task executor.
 
@@ -221,8 +221,8 @@ figure <#general-workflow-figure>`__:
 
 BitBake needs some basic configuration files in order to complete a
 build. These files are ``*.conf`` files. The minimally necessary ones
-reside as example files in the ``build/conf`` directory of the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For simplicity,
+reside as example files in the ``build/conf`` directory of the
+:term:`Source Directory`. For simplicity,
 this section refers to the Source Directory as the "Poky Directory."
 
 When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository
@@ -241,8 +241,8 @@ for creating actual configuration files when you source
 ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the
 build environment script.
 
-Sourcing the build environment script creates a `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ if one does not
+Sourcing the build environment script creates a
+:term:`Build Directory` if one does not
 already exist. BitBake uses the Build Directory for all its work during
 builds. The Build Directory has a ``conf`` directory that contains
 default versions of your ``local.conf`` and ``bblayers.conf``
@@ -357,8 +357,8 @@ Configuration Edits" box in the figure.
 
 When you launch your build with the ``bitbake target`` command, BitBake
 sorts out the configurations to ultimately define your build
-environment. It is important to understand that the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ reads the
+environment. It is important to understand that the
+:term:`OpenEmbedded Build System` reads the
 configuration files in a specific order: ``site.conf``, ``auto.conf``,
 and ``local.conf``. And, the build system applies the normal assignment
 statement rules as described in the "`Syntax and
@@ -460,7 +460,7 @@ typically find in the distribution layer:
    can be shared among recipes in the distribution. When your recipes
    inherit a class, they take on the settings and functions for that
    class. You can read more about class files in the
-   "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter of the Yocto
+   ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
    Reference Manual.
 
 -  *conf:* This area holds configuration files for the layer
@@ -643,8 +643,8 @@ Package Feeds
 -------------
 
 When the OpenEmbedded build system generates an image or an SDK, it gets
-the packages from a package feed area located in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The `general
+the packages from a package feed area located in the
+:term:`Build Directory`. The `general
 workflow figure <#general-workflow-figure>`__ shows this package feeds
 area in the upper-right corner.
 
@@ -687,7 +687,7 @@ package files are kept:
    for the i586 or qemux86 architectures.
 
 BitBake uses the
-```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`
 tasks to generate packages and place them into the package holding area
 (e.g. ``do_package_write_ipk`` for IPK packages). See the
 ":ref:`ref-tasks-package_write_deb`",
@@ -733,8 +733,8 @@ code:
 
 The :ref:`ref-tasks-fetch` and
 :ref:`ref-tasks-unpack` tasks fetch
-the source files and unpack them into the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
+the source files and unpack them into the
+:term:`Build Directory`.
 
 .. note::
 
@@ -984,7 +984,7 @@ details on how this is accomplished, you can look at
 ```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__.
 
 Depending on the type of packages being created (RPM, DEB, or IPK), the
-```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`
 task creates the actual packages and places them in the Package Feed
 area, which is ``${TMPDIR}/deploy``. You can see the "`Package
 Feeds <#package-feeds-dev-environment>`__" section for more detail on
@@ -1067,7 +1067,7 @@ processing includes creation of a manifest file and optimizations.
 The manifest file (``.manifest``) resides in the same directory as the
 root filesystem image. This file lists out, line-by-line, the installed
 packages. The manifest file is useful for the
-```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class,
+:ref:`testimage <ref-classes-testimage*>` class,
 for example, to determine whether or not to run specific tests. See the
 :term:`IMAGE_MANIFEST`
 variable for additional information.
@@ -1102,7 +1102,7 @@ as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically
 generated task would be as follows: do_image_ext4
 
 The final task involved in image creation is the
-```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__
+:ref:`do_image_complete <ref-tasks-image-complete>`
 task. This task completes the image by applying any image post
 processing as defined through the
 :term:`IMAGE_POSTPROCESS_COMMAND`
@@ -1242,7 +1242,7 @@ version of the task where instead of building something, BitBake can
 skip to the end result and simply place a set of files into specific
 locations as needed. In some cases, it makes sense to have a setscene
 task variant (e.g. generating package files in the
-```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`
 task). In other cases, it does not make sense (e.g. a
 :ref:`ref-tasks-patch` task or a
 :ref:`ref-tasks-unpack` task) since
@@ -1317,8 +1317,8 @@ this output:
    Images
    " chapter in the Yocto Project Reference Manual.
 
-The build process writes images out to the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the
+The build process writes images out to the :term:`Build Directory`
+inside the
 ``tmp/deploy/images/machine/`` folder as shown in the figure. This
 folder contains any files expected to be loaded on the target device.
 The :term:`DEPLOY_DIR` variable
@@ -1775,8 +1775,8 @@ need to fix this situation.
 Thus far, this section has limited discussion to the direct inputs into
 a task. Information based on direct inputs is referred to as the
 "basehash" in the code. However, the question of a task's indirect
-inputs still exits - items already built and present in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The checksum (or
+inputs still exits - items already built and present in the
+:term:`Build Directory`. The checksum (or
 signature) for a particular task needs to add the hashes of all the
 tasks on which the particular task depends. Choosing which dependencies
 to add is a policy decision. However, the effect is to generate a master
@@ -2117,9 +2117,9 @@ Fakeroot and Pseudo
 Some tasks are easier to implement when allowed to perform certain
 operations that are normally reserved for the root user (e.g.
 :ref:`ref-tasks-install`,
-```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__,
+:ref:`do_package_write* <ref-tasks-package_write_deb>`,
 :ref:`ref-tasks-rootfs`, and
-```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example,
+:ref:`do_image* <ref-tasks-image>`). For example,
 the ``do_install`` task benefits from being able to set the UID and GID
 of installed files to arbitrary values.
 
@@ -2139,8 +2139,8 @@ The capability to run tasks in a fake root environment is known as
 the BitBake keyword/variable flag that requests a fake root environment
 for a task.
 
-In the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, the program that
+In the :term:`OpenEmbedded Build System`,
+the program that
 implements fakeroot is known as
 `Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo
 overrides system calls by using the environment variable ``LD_PRELOAD``,
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 745d2ecf91..82562bf995 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -86,8 +86,8 @@ Once your development host is set up to use the Yocto Project, several
 methods exist for you to do work in the Yocto Project environment:
 
 -  *Command Lines, BitBake, and Shells:* Traditional development in the
-   Yocto Project involves using the `OpenEmbedded build
-   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which uses
+   Yocto Project involves using the :term:`OpenEmbedded Build System`,
+   which uses
    BitBake, in a command-line environment from a shell on your
    development host. You can accomplish this from a host that is a
    native Linux machine or from a host that has been set up with CROPS.
@@ -162,8 +162,8 @@ these tarballs gives you a snapshot of the released files.
 
 .. note::
 
-   -  The recommended method for setting up the Yocto Project `Source
-      Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and the files
+   -  The recommended method for setting up the Yocto Project
+      :term:`Source Directory` and the files
       for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__
       to create a local copy of the upstream repositories.
 
@@ -350,8 +350,8 @@ Book <http://book.git-scm.com>`__.
    software on which to develop. The Yocto Project has two scripts named
    ``create-pull-request`` and ``send-pull-request`` that ship with the
    release to facilitate this workflow. You can find these scripts in
-   the ``scripts`` folder of the `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For information
+   the ``scripts`` folder of the
+   :term:`Source Directory`. For information
    on how to use these scripts, see the "`Using Scripts to Push a Change
    Upstream and Request a
    Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in
@@ -638,8 +638,8 @@ When you build an image using the Yocto Project, the build process uses
 a known list of licenses to ensure compliance. You can find this list in
 the :term:`Source Directory` at
 ``meta/files/common-licenses``. Once the build completes, the list of
-all licenses found and used during that build are kept in the `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at
+all licenses found and used during that build are kept in the
+:term:`Build Directory` at
 ``tmp/deploy/licenses``.
 
 If a module requires a license that is not in the base list, the build
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index b27412cb25..3f98fa939c 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -180,8 +180,8 @@ developing using the Yocto Project:
    changes on the development system within the BitBake environment and
    then deploying only the updated packages to the target.
 
-   The Yocto Project `OpenEmbedded build
-   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ produces packages
+   The Yocto Project :term:`OpenEmbedded Build System`
+   produces packages
    in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy
    these packages into the running system on the target by using
    utilities on the target such as ``rpm`` or ``ipk``.
@@ -202,8 +202,8 @@ The Yocto Project's "Layer Model" is a development model for embedded
 and IoT Linux creation that distinguishes the Yocto Project from other
 simple build systems. The Layer Model simultaneously supports
 collaboration and customization. Layers are repositories that contain
-related sets of instructions that tell the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to do. You can
+related sets of instructions that tell the :term:`OpenEmbedded Build System`
+what to do. You can
 collaborate, share, and reuse layers.
 
 Layers can contain changes to previous instructions or settings at any
@@ -292,8 +292,8 @@ The Yocto Project employs a collection of components and tools used by
 the project itself, by project developers, and by those using the Yocto
 Project. These components and tools are open source projects and
 metadata that are separate from the reference distribution
-(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. Most of the
+(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the 
+:term:`OpenEmbedded Build System`. Most of the
 components and tools are downloaded separately.
 
 This section provides brief overviews of the components and tools
@@ -367,8 +367,8 @@ The following list consists of tools that help production related
 activities using the Yocto Project:
 
 -  *Auto Upgrade Helper:* This utility when used in conjunction with the
-   `OpenEmbedded build
-   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ (BitBake and
+   :term:`OpenEmbedded Build System`
+   (BitBake and
    OE-Core) automatically generates upgrades for recipes that are based
    on new versions of the recipes published upstream.
 
@@ -668,8 +668,8 @@ Project.
 
 -  *Toaster:* Regardless of what your Build Host is running, you can use
    Toaster to develop software using the Yocto Project. Toaster is a web
-   interface to the Yocto Project's `Open-Embedded build
-   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface
+   interface to the Yocto Project's :term:`OpenEmbedded Build System`.
+   The interface
    enables you to configure and run your builds. Information about
    builds is collected and stored in a database. You can use Toaster to
    configure and start builds on multiple remote build servers.
@@ -789,8 +789,7 @@ section in the BitBake User's Manual.
 The OpenEmbedded Build System Workflow
 ======================================
 
-The `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to
+The :term:`OpenEmbedded Build System` uses a "workflow" to
 accomplish image and SDK generation. The following figure overviews that
 workflow:
 
@@ -836,8 +835,8 @@ helpful for getting started:
 
 -  *Configuration Files:* Files that hold global definitions of
    variables, user-defined variables, and hardware configuration
-   information. These files tell the `Open-Embedded build
-   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to build and
+   information. These files tell the :term:`OpenEmbedded Build System`
+   what to build and
    what to put into the image to support a particular platform.
 
 -  *Extensible Software Development Kit (eSDK):* A custom SDK for
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 07244a0311..3e8127b927 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -256,8 +256,7 @@ situation changes, the team will not support spaces in pathnames.
 **A:** The toolchain configuration is very flexible and customizable. It
 is primarily controlled with the ``TCMODE`` variable. This variable
 controls which ``tcmode-*.inc`` file to include from the
-``meta/conf/distro/include`` directory within the `Source
-Directory <#source-directory>`__.
+``meta/conf/distro/include`` directory within the :term:`Source Directory`.
 
 The default value of ``TCMODE`` is "default", which tells the
 OpenEmbedded build system to use its internally built toolchain (i.e.
@@ -342,8 +341,8 @@ redirect requests through proxy servers.
 **A:** Yes - you can easily do this. When you use BitBake to build an
 image, all the build output goes into the directory created when you run
 the build environment setup script (i.e.
-````` <#structure-core-script>`__). By default, this `Build
-Directory <#build-directory>`__ is named ``build`` but can be named
+````` <#structure-core-script>`__). By default, this :term:`Build Directory`
+is named ``build`` but can be named
 anything you want.
 
 Within the Build Directory, is the ``tmp`` directory. To remove all the
@@ -379,8 +378,8 @@ system of that image. Thus, the build system provides a value of
 "/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so
 forth.
 
-Meanwhile, ``DESTDIR`` is a path within the `Build
-Directory <#build-directory>`__. However, when the recipe builds a
+Meanwhile, ``DESTDIR`` is a path within the :term:`Build Directory`.
+However, when the recipe builds a
 native program (i.e. one that is intended to run on the build machine),
 that program is never installed directly to the build machine's root
 file system. Consequently, the build system uses paths within the Build
diff --git a/documentation/ref-manual/migration.rst b/documentation/ref-manual/migration.rst
index 1d4d53647f..31959b2845 100644
--- a/documentation/ref-manual/migration.rst
+++ b/documentation/ref-manual/migration.rst
@@ -731,7 +731,7 @@ Automated Image Testing
 -----------------------
 
 A new automated image testing framework has been added through the
-```testimage.bbclass`` <#ref-classes-testimage*>`__ class. This
+:ref:`testimage.bbclass <ref-classes-testimage*>` class. This
 framework replaces the older ``imagetest-qemu`` framework.
 
 You can learn more about performing automated image tests in the
@@ -1077,7 +1077,7 @@ future releases the :ref:`autotools <ref-classes-autotools>` class
 will enable a separate build directory by default as well. Recipes
 building Autotools-based software that fails to build with a separate
 build directory should be changed to inherit from the
-```autotools-brokensep`` <#ref-classes-autotools>`__ class instead of
+:ref:`autotools-brokensep <ref-classes-autotools>` class instead of
 the ``autotools`` or ``autotools_stage``\ classes.
 
 .. _migration-1.6-building-qemu-native:
@@ -1305,7 +1305,7 @@ occurred:
    However, if the software is not capable of being built in this
    manner, you will need to either patch the software so that it can
    build separately, or you will need to change the recipe to inherit
-   the ```autotools-brokensep`` <#ref-classes-autotools>`__ class
+   the :ref:`autotools-brokensep <ref-classes-autotools>` class
    instead of the ``autotools`` or ``autotools_stage`` classes.
 
 -  *The ``--foreign`` option is no longer passed to ``automake`` when
@@ -2048,7 +2048,7 @@ time.
 A minor part of this restructuring is that the post-processing
 definitions and functions have been moved from the
 :ref:`image <ref-classes-image>` class to the
-```rootfs-postcommands`` <#ref-classes-rootfs*>`__ class. Functionally,
+:ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
 however, they remain unchanged.
 
 .. _migration-2.1-removed-recipes:
@@ -3973,7 +3973,7 @@ For names of recipes removed because of this repository change, see the
 
 Previously, it was possible for Python recipes that inherited the
 :ref:`distutils <ref-classes-distutils>` and
-```distutils3`` <#ref-classes-distutils3>`__ classes to fetch code
+:ref:`distutils3 <ref-classes-distutils3>` classes to fetch code
 during the :ref:`ref-tasks-configure` task to satisfy
 dependencies mentioned in ``setup.py`` if those dependencies were not
 provided in the sysroot (i.e. recipes providing the dependencies were
@@ -4183,7 +4183,7 @@ This section provides information about automatic testing changes:
    practices now dictate that you use the
    :term:`IMAGE_CLASSES` variable rather than the
    :term:`INHERIT` variable when you inherit the
-   ```testimage`` <#ref-classes-testimage*>`__ and
+   :ref:`testimage <ref-classes-testimage*>` and
    :ref:`testsdk <ref-classes-testsdk>` classes used for automatic
    testing.
 
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index 6449b49cd4..4b4f3bac5a 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -14,8 +14,8 @@ some default behavior.
 Any :term:`Metadata` usually found in a recipe can also be
 placed in a class file. Class files are identified by the extension
 ``.bbclass`` and are usually placed in a ``classes/`` directory beneath
-the ``meta*/`` directory found in the `Source
-Directory <#source-directory>`__. Class files can also be pointed to by
+the ``meta*/`` directory found in the :term:`Source Directory`.
+Class files can also be pointed to by
 :term:`BUILDDIR` (e.g. ``build/``) in the same way as
 ``.conf`` files in the ``conf`` directory. Class files are searched for
 in :term:`BBPATH` using the same method by which ``.conf``
@@ -555,7 +555,7 @@ used.
    ``distutils`` class in their recipes.
 
 -  Extensions that use build systems based on ``setuptools3`` require
-   the ```setuptools3`` <#ref-classes-setuptools>`__ class in their
+   the :ref:`setuptools3 <ref-classes-setuptools>` class in their
    recipes.
 
 The ``distutils3*`` classes either inherit their corresponding
@@ -592,8 +592,8 @@ ${WORKDIR}/${BPN}/{PV}/ See these variables for more information:
 :term:`PV`,
 
 For more information on the ``externalsrc`` class, see the comments in
-``meta/classes/externalsrc.bbclass`` in the `Source
-Directory <#source-directory>`__. For information on how to use the
+``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
+For information on how to use the
 ``externalsrc`` class, see the "`Building Software from an External
 Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
 section in the Yocto Project Development Tasks Manual.
@@ -1733,8 +1733,8 @@ package-specific classes:
 
 You can control the list of resulting package formats by using the
 ``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf``
-configuration file, which is located in the `Build
-Directory <#build-directory>`__. When defining the variable, you can
+configuration file, which is located in the :term:`Build Directory`.
+When defining the variable, you can
 specify one or more package types. Since images are generated from
 packages, a packaging class is needed to enable image generation. The
 first class listed in this variable is used for image generation.
@@ -2181,8 +2181,8 @@ recipe are no longer needed. However, by default, the build system
 preserves these files for inspection and possible debugging purposes. If
 you would rather have these files deleted to save disk space as the
 build progresses, you can enable ``rm_work`` by adding the following to
-your ``local.conf`` file, which is found in the `Build
-Directory <#build-directory>`__. INHERIT += "rm_work" If you are
+your ``local.conf`` file, which is found in the :term:`Build Directory`.
+INHERIT += "rm_work" If you are
 modifying and building source code out of the work directory for a
 recipe, enabling ``rm_work`` will potentially result in your changes to
 the source being lost. To exclude some recipes from having their work
@@ -2565,7 +2565,7 @@ Other classes use the ``terminal`` class anywhere a separate terminal
 session needs to be started. For example, the
 :ref:`patch <ref-classes-patch>` class assuming
 :term:`PATCHRESOLVE` is set to "user", the
-```cml1`` <#ref-classes-cml1>`__ class, and the
+:ref:`cml1 <ref-classes-cml1>` class, and the
 :ref:`devshell <ref-classes-devshell>` class all use the ``terminal``
 class.
 
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst
index 5aeaa43833..4eba5cdf16 100644
--- a/documentation/ref-manual/ref-images.rst
+++ b/documentation/ref-manual/ref-images.rst
@@ -27,8 +27,8 @@ image you want.
               
 
 From within the ``poky`` Git repository, you can use the following
-command to display the list of directories within the `Source
-Directory <#source-directory>`__ that contain image recipe files: $ ls
+command to display the list of directories within the :term:`Source Directory`
+that contain image recipe files: $ ls
 meta*/recipes*/images/*.bb
 
 Following is a list of supported recipes:
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index 95ec686a13..832f011918 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -117,7 +117,7 @@ consists of the following pieces:
    an ARM target, did the build produce ARM binaries. If, for example,
    the build produced PPC binaries then there is a problem.
 
--  ```testimage.bbclass`` <#ref-classes-testimage*>`__: This class
+-  :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
    performs runtime testing of images after they are built. The tests
    are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__
    to boot the images and check the combined runtime result boot
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index c63900e604..a21c0bdd52 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -26,8 +26,7 @@ section in the Yocto Project Development Tasks Manual.
 Top-Level Core Components
 =========================
 
-This section describes the top-level components of the `Source
-Directory <#source-directory>`__.
+This section describes the top-level components of the :term:`Source Directory`.
 
 .. _structure-core-bitbake:
 
@@ -57,8 +56,8 @@ Manual <&YOCTO_DOCS_BB_URL;>`__.
 
 This directory contains user configuration files and the output
 generated by the OpenEmbedded build system in its standard configuration
-where the source tree is combined with the output. The `Build
-Directory <#build-directory>`__ is created initially when you ``source``
+where the source tree is combined with the output. The :term:`Build Directory`
+is created initially when you ``source``
 the OpenEmbedded build environment setup script (i.e.
 ````` <#structure-core-script>`__).
 
@@ -175,8 +174,8 @@ creates the ``build/`` directory in your current working directory. If
 you provide a Build Directory argument when you ``source`` the script,
 you direct the OpenEmbedded build system to create a Build Directory of
 your choice. For example, the following command creates a Build
-Directory named ``mybuilds/`` that is outside of the `Source
-Directory <#source-directory>`__: $ source OE_INIT_FILE ~/mybuilds The
+Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:
+$ source OE_INIT_FILE ~/mybuilds The
 OpenEmbedded build system uses the template configuration files, which
 are found by default in the ``meta-poky/conf/`` directory in the Source
 Directory. See the "`Creating a Custom Template Configuration
@@ -206,8 +205,8 @@ These files are standard top-level files.
 The Build Directory - ``build/``
 ================================
 
-The OpenEmbedded build system creates the `Build
-Directory <#build-directory>`__ when you run the build environment setup
+The OpenEmbedded build system creates the :term:`Build Directory`
+when you run the build environment setup
 script ````` <#structure-core-script>`__. If you do not give the Build
 Directory a specific name when you run the setup script, the name
 defaults to ``build/``.
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index 9358a168f1..3144d303f8 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -348,8 +348,8 @@ installer:
       system.
 
    Once the build completes, you can find the ``.sh`` file that installs
-   the tools in the ``tmp/deploy/sdk`` subdirectory of the `Build
-   Directory <#build-directory>`__. The installer file has the string
+   the tools in the ``tmp/deploy/sdk`` subdirectory of the
+   :term:`Build Directory`. The installer file has the string
    "buildtools" (or "buildtools-extended") in the name.
 
 3. Transfer the ``.sh`` file from the build host to the machine that
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index f3c698ba98..4bcd0a2d00 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -409,7 +409,7 @@ dependencies specified by :term:`DEPENDS`). See the
 
 Removes work files after the OpenEmbedded build system has finished with
 them. You can learn more by looking at the
-"```rm_work.bbclass`` <#ref-classes-rm-work>`__" section.
+":ref:`rm_work.bbclass <ref-classes-rm-work>`" section.
 
 .. _ref-tasks-unpack:
 
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 4298e04965..eacc49fc3d 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -378,8 +378,8 @@ universal, the list includes them just in case:
       :ref:`ref-tasks-patch`, and so forth).
 
    Toaster
-      A web interface to the Yocto Project's `OpenEmbedded Build
-      System <#build-system-term>`__. The interface enables you to
+      A web interface to the Yocto Project's :term:`OpenEmbedded Build System`.
+      The interface enables you to
       configure and run your builds. Information about builds is collected
       and stored in a database. For information on Toaster, see the
       `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__.
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 473b672b76..aa7f59f602 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -144,8 +144,7 @@ system and gives an overview of their function and contents.
       = "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 `Source
-      Directory <#source-directory>`__.
+      ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
    
    AS
       Minimal command and arguments needed to run the assembler.
@@ -583,8 +582,8 @@ system and gives an overview of their function and contents.
    
    BBLAYERS
       Lists the layers to enable during the build. This variable is defined
-      in the ``bblayers.conf`` configuration file in the `Build
-      Directory <#build-directory>`__. Here is an example: BBLAYERS = " \\
+      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 \\ "
@@ -705,8 +704,8 @@ system and gives an overview of their function and contents.
          .
    
       For more information on how this variable works, see
-      ``meta/classes/binconfig.bbclass`` in the `Source
-      Directory <#source-directory>`__. You can also find general
+      ``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.
    
@@ -1042,8 +1041,8 @@ system and gives an overview of their function and contents.
       Bluetooth but you do not ever intend to use it.
    
    COMMON_LICENSE_DIR
-      Points to ``meta/files/common-licenses`` in the `Source
-      Directory <#source-directory>`__, which is where generic license
+      Points to ``meta/files/common-licenses`` in the
+      :term:`Source Directory`, which is where generic license
       files reside.
    
    COMPATIBLE_HOST
@@ -1391,8 +1390,8 @@ system and gives an overview of their function and contents.
          for an SDK (i.e. ``nativesdk-``)
    
    D
-      The destination directory. The location in the `Build
-      Directory <#build-directory>`__ where components are installed by the
+      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
    
@@ -1664,8 +1663,8 @@ system and gives an overview of their function and contents.
       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 `Source
-      Directory <#source-directory>`__.
+      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"
@@ -2296,8 +2295,8 @@ system and gives an overview of their function and contents.
       :term:`SRC_URI` statements.
    
       The default value for the ``FILESPATH`` variable is defined in the
-      ``base.bbclass`` class found in ``meta/classes`` in the `Source
-      Directory <#source-directory>`__: FILESPATH =
+      ``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
       ``FILESPATH`` variable is automatically extended using the overrides
@@ -2344,14 +2343,14 @@ system and gives an overview of their function and contents.
       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 `Source
-      Directory <#source-directory>`__. If you create your own file
+      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 `Build
-      Directory <#build-directory>`__, to point to your custom
+      ``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.
@@ -2717,8 +2716,8 @@ system and gives an overview of their function and contents.
    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 `Build
-      Directory <#build-directory>`__, best practices dictate that you do
+      variable from your ``local.conf`` file, which is found in the
+      :term:`Build Directory`, best practices dictate that you do
       not.
    
       .. note::
@@ -2886,13 +2885,13 @@ system and gives an overview of their function and contents.
          class is broken and is not supported. It is recommended that you
          do not use it.
    
-      The ```populate_sdk_*`` <#ref-classes-populate-sdk-*>`__ and
+      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
-      ```package_*`` <#ref-classes-package>`__ class using the
+      :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
@@ -2995,8 +2994,7 @@ system and gives an overview of their function and contents.
       wic.bz2 wic.gz wic.lzma
    
       For more information about these types of images, see
-      ``meta/classes/image_types*.bbclass`` in the `Source
-      Directory <#source-directory>`__.
+      ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
    
    INC_PR
       Helps define the recipe revision for recipes that share a common
@@ -3156,8 +3154,8 @@ system and gives an overview of their function and contents.
       :term:`IMAGE_FSTYPES` variable.
    
       The default value of this variable, which is set in the
-      ``meta/conf/bitbake.conf`` configuration file in the `Source
-      Directory <#source-directory>`__, is "cpio.gz". The Linux kernel's
+      ``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.
@@ -3945,8 +3943,8 @@ system and gives an overview of their function and contents.
    
    MACHINE
       Specifies the target device for which the image is built. You define
-      ``MACHINE`` in the ``local.conf`` file found in the `Build
-      Directory <#build-directory>`__. By default, ``MACHINE`` is set to
+      ``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"
    
@@ -4353,8 +4351,8 @@ system and gives an overview of their function and contents.
       ``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 `Source
-      Directory <#source-directory>`__ for details on how this class
+      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.
@@ -4499,8 +4497,8 @@ system and gives an overview of their function and contents.
    
    PACKAGE_CLASSES
       This variable, which is set in the ``local.conf`` configuration file
-      found in the ``conf`` folder of the `Build
-      Directory <#build-directory>`__, specifies the package manager the
+      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
@@ -5234,8 +5232,8 @@ system and gives an overview of their function and contents.
    
       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 `Build
-      Directory <#build-directory>`__: PREMIRRORS_prepend = "\\
+      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://.*/.\*
@@ -5364,8 +5362,8 @@ system and gives an overview of their function and contents.
    
    PYTHON_ABI
       When used by recipes that inherit the
-      ```distutils3`` <#ref-classes-distutils3>`__,
-      ```setuptools3`` <#ref-classes-setuptools3>`__,
+      :ref:`distutils3 <ref-classes-distutils3>`,
+      :ref:`setuptools3 <ref-classes-setuptools3>`,
       :ref:`distutils <ref-classes-distutils>`, or
       :ref:`setuptools <ref-classes-setuptools>` classes, denotes the
       Application Binary Interface (ABI) currently in use for Python. By
@@ -5382,8 +5380,8 @@ system and gives an overview of their function and contents.
    
    PYTHON_PN
       When used by recipes that inherit the
-      ```distutils3`` <#ref-classes-distutils3>`__,
-      ```setuptools3`` <#ref-classes-setuptools3>`__,
+      `distutils3 <ref-classes-distutils3>`,
+      :ref:`setuptools3 <ref-classes-setuptools3>`,
       :ref:`distutils <ref-classes-distutils>`, or
       :ref:`setuptools <ref-classes-setuptools>` classes, specifies the
       major Python version being built. For Python 3.x, ``PYTHON_PN`` would
@@ -5522,7 +5520,7 @@ system and gives an overview of their function and contents.
    RM_WORK_EXCLUDE
       With ``rm_work`` enabled, this variable specifies a list of recipes
       whose work directories should not be removed. See the
-      "```rm_work.bbclass`` <#ref-classes-rm-work>`__" section for more
+      ":ref:`rm_work.bbclass <ref-classes-rm-work>`" section for more
       details.
    
    ROOT_HOME
@@ -5731,14 +5729,14 @@ system and gives an overview of their function and contents.
    
    SDK_DEPLOY
       The directory set up and used by the
-      ```populate_sdk_base`` <#ref-classes-populate-sdk>`__ class to which
+      :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_DIR
       The parent directory used by the OpenEmbedded build system when
       creating SDK output. The
-      ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class defines
+      :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class defines
       the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
    
       .. note::
@@ -5770,7 +5768,7 @@ system and gives an overview of their function and contents.
       file contains package information on a line-per-package basis as
       follows: packagename packagearch version
    
-      The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class
+      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
@@ -5807,7 +5805,7 @@ system and gives an overview of their function and contents.
    SDK_INHERIT_BLACKLIST
       A list of classes to remove from the :term:`INHERIT`
       value globally within the extensible SDK configuration. The
-      ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class sets the
+      :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
       default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
    
       Some classes are not generally applicable within the extensible SDK
@@ -5827,7 +5825,7 @@ system and gives an overview of their function and contents.
       within the extensible SDK.
    
       By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the
-      ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class and
+      :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
       excludes the following variables:
       :term:`CONF_VERSION`
       :term:`BB_NUMBER_THREADS`
@@ -5848,7 +5846,7 @@ system and gives an overview of their function and contents.
       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
-      ```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class.
+      :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
    
       This list overrides the variables specified using the
       :term:`SDK_LOCAL_CONF_BLACKLIST`
@@ -5877,7 +5875,7 @@ system and gives an overview of their function and contents.
    
    SDK_OUTPUT
       The location used by the OpenEmbedded build system when creating SDK
-      output. The ```populate_sdk_base`` <#ref-classes-populate-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"
    
@@ -5942,7 +5940,7 @@ system and gives an overview of their function and contents.
       file contains package information on a line-per-package basis as
       follows: packagename packagearch version
    
-      The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class
+      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
@@ -5960,7 +5958,7 @@ system and gives an overview of their function and contents.
       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
-      ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as
+      :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",
       ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
@@ -5993,7 +5991,7 @@ system and gives an overview of their function and contents.
       The default installation directory for the Extensible SDK. By
       default, this directory is based on the :term:`DISTRO`
       variable and is set in the
-      ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as
+      :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
       follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the
       default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
    
@@ -6135,8 +6133,8 @@ system and gives an overview of their function and contents.
       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: `Build
-      Directory <#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
@@ -7289,8 +7287,8 @@ system and gives an overview of their function and contents.
    
       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 `Source
-      Directory <#source-directory>`__: #TMPDIR = "${TOPDIR}/tmp" An
+      ``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,
       which does not use NFS, while having the Build Directory use NFS.
    
@@ -7325,7 +7323,7 @@ system and gives an overview of their function and contents.
    
    TOOLCHAIN_OUTPUTNAME
       This variable defines the name used for the toolchain output. The
-      ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class sets
+      :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets
       the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:
       TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See
       the :term:`SDK_NAME` and
@@ -7374,8 +7372,8 @@ system and gives an overview of their function and contents.
       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 `Source
-      Directory <#source-directory>`__ provides information for
+      ``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
@@ -7510,8 +7508,8 @@ system and gives an overview of their function and contents.
       ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example
       from that file: TUNEVALID[bigendian] = "Enable big-endian mode."
    
-      See the machine include files in the `Source
-      Directory <#source-directory>`__ for these features.
+      See the machine include files in the :term:`Source Directory`
+      for these features.
    
    UBOOT_CONFIG
       Configures the :term:`UBOOT_MACHINE` and can
@@ -7696,8 +7694,7 @@ system and gives an overview of their function and contents.
    
       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 `Source
-      Directory <#source-directory>`__.
+      ``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
diff --git a/documentation/sdk-manual/sdk-appendix-customizing.rst b/documentation/sdk-manual/sdk-appendix-customizing.rst
index 8169f2bed8..3bb6ef3a19 100644
--- a/documentation/sdk-manual/sdk-appendix-customizing.rst
+++ b/documentation/sdk-manual/sdk-appendix-customizing.rst
@@ -150,7 +150,7 @@ set. If the ``DISTRO_NAME`` variable is not set, the title is derived
 from the :term:`DISTRO` variable.
 
 The
-```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__
+:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
 class defines the default value of the ``SDK_TITLE`` variable as
 follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
 d.getVar('DISTRO')} SDK"
@@ -212,7 +212,7 @@ installation directory for the SDK is based on the
 :term:`DISTRO` and
 :term:`SDKEXTPATH` variables from
 within the
-```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__
+:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
 class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can
 change this default installation directory by specifically setting the
 ``SDKEXTPATH`` variable.
@@ -276,8 +276,8 @@ source, you need to do a number of things:
 
    -  Alternatively, if you just want to set the ``SSTATE_MIRRORS``
       variable's value for the SDK alone, create a
-      ``conf/sdk-extra.conf`` file either in your `Build
-      Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ or within any
+      ``conf/sdk-extra.conf`` file either in your
+      :term:`Build Directory` or within any
       layer and put your ``SSTATE_MIRRORS`` setting within that file.
 
       .. note::
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.rst b/documentation/sdk-manual/sdk-appendix-obtain.rst
index c6efdf674c..015506de01 100644
--- a/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/documentation/sdk-manual/sdk-appendix-obtain.rst
@@ -70,8 +70,8 @@ build the SDK installer. Follow these steps:
    machine that uses CROPS.
 
 2. *Clone the ``poky`` Repository:* You need to have a local copy of the
-   Yocto Project `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local
+   Yocto Project :term:`Source Directory`
+   (i.e. a local
    ``poky`` repository). See the "`Cloning the ``poky``
    Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and
    possibly the "`Checking Out by Branch in
@@ -87,8 +87,8 @@ build the SDK installer. Follow these steps:
    ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment
    setup script to define the OpenEmbedded build environment on your
    build host. $ source OE_INIT_FILE Among other things, the script
-   creates the `Build
-   Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
+   creates the :term:`Build Directory`,
+   which is
    ``build`` in this case and is located in the Source Directory. After
    the script runs, your current working directory is set to the
    ``build`` directory.
diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/sdk-extensible.rst
index 17cd08a25c..3df2174fd9 100644
--- a/documentation/sdk-manual/sdk-extensible.rst
+++ b/documentation/sdk-manual/sdk-extensible.rst
@@ -9,8 +9,8 @@ Information covers the pieces of the SDK, how to install it, and
 presents a look at using the ``devtool`` functionality. The extensible
 SDK makes it easy to add new applications and libraries to an image,
 modify the source for an existing component, test changes on the target
-hardware, and ease integration into the rest of the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
+hardware, and ease integration into the rest of the
+:term:`OpenEmbedded Build System`.
 
 .. note::
 
diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
index fcb15a8592..88238d7dd4 100644
--- a/documentation/sdk-manual/sdk-intro.rst
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -39,8 +39,7 @@ All SDKs consist of the following:
 Additionally, an extensible SDK has tools that allow you to easily add
 new applications and libraries to an image, modify the source of an
 existing component, test changes on the target hardware, and easily
-integrate an application into the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
+integrate an application into the :term:`OpenEmbedded Build System`.
 
 You can use an SDK to independently develop and test code that is
 destined to run on some target machine. SDKs are completely
@@ -126,8 +125,7 @@ of a cross-compiler, cross-linker, and cross-debugger that are used to
 develop user-space applications for targeted hardware. Additionally, for
 an extensible SDK, the toolchain also has built-in ``devtool``
 functionality. This toolchain is created by running a SDK installer
-script or through a `Build
-Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ that is based on
+script or through a :term:`Build Directory` that is based on
 your metadata configuration or extension for your targeted device. The
 cross-toolchain works with a matching target sysroot.
 
@@ -149,8 +147,8 @@ The QEMU emulator allows you to simulate your hardware while running
 your application or image. QEMU is not part of the SDK but is made
 available a number of different ways:
 
--  If you have cloned the ``poky`` Git repository to create a `Source
-   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and you have
+-  If you have cloned the ``poky`` Git repository to create a
+   :term:`Source Directory` and you have
    sourced the environment setup script, QEMU is installed and
    automatically available.
 
diff --git a/documentation/sdk-manual/sdk-working-projects.rst b/documentation/sdk-manual/sdk-working-projects.rst
index 63f61de66d..d18568d60a 100644
--- a/documentation/sdk-manual/sdk-working-projects.rst
+++ b/documentation/sdk-manual/sdk-working-projects.rst
@@ -14,8 +14,7 @@ Once you have a suitable `cross-development
 toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__
 installed, it is very easy to develop a project using the `GNU
 Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__
-workflow, which is outside of the `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
+workflow, which is outside of the :term:`OpenEmbedded Build System`.
 
 The following figure presents a simple Autotools workflow.
 
diff --git a/documentation/toaster-manual/toaster-manual-intro.rst b/documentation/toaster-manual/toaster-manual-intro.rst
index ec50be5a91..bc4298dfce 100644
--- a/documentation/toaster-manual/toaster-manual-intro.rst
+++ b/documentation/toaster-manual/toaster-manual-intro.rst
@@ -4,8 +4,8 @@
 Introduction
 ************
 
-Toaster is a web interface to the Yocto Project's `OpenEmbedded build
-system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface
+Toaster is a web interface to the Yocto Project's
+:term:`OpenEmbedded Build System`. The interface
 enables you to configure and run your builds. Information about builds
 is collected and stored in a database. You can use Toaster to configure
 and start builds on multiple remote build servers.
diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst
index c98a27eeb8..d799b4b99b 100644
--- a/documentation/toaster-manual/toaster-manual-reference.rst
+++ b/documentation/toaster-manual/toaster-manual-reference.rst
@@ -422,15 +422,15 @@ at the
 `Django <https://docs.djangoproject.com/en/1.7/topics/settings/>`__
 site. However, several ``manage.py`` commands have been created that are
 specific to Toaster and are used to control configuration and back-end
-tasks. You can locate these commands in the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``) at
+tasks. You can locate these commands in the
+:term:`Source Directory` (e.g. ``poky``) at
 ``bitbake/lib/manage.py``. This section documents those commands.
 
 .. note::
 
    -  When using ``manage.py`` commands given a default configuration,
-      you must be sure that your working directory is set to the `Build
-      Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. Using
+      you must be sure that your working directory is set to the
+      :term:`Build Directory`. Using
       ``manage.py`` commands from the Build Directory allows Toaster to
       find the ``toaster.sqlite`` file, which is located in the Build
       Directory.
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
index 7e715403d0..360270afbf 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
@@ -12,8 +12,8 @@ dependencies as described in the "`Preparing to Use
 Toaster <#toaster-manual-start>`__" chapter, you are ready to start
 Toaster.
 
-Navigate to the root of your `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``): $
+Navigate to the root of your
+:term:`Source Directory` (e.g. ``poky``): $
 cd poky Once in that directory, source the build environment script: $
 source oe-init-build-env Next, from the build directory (e.g.
 ``poky/build``), start Toaster using this command: $ source toaster
@@ -267,8 +267,8 @@ Perform the following steps to install Toaster:
     the "`Configuring Toaster <#configuring-toaster>`__" section.
 
     This line also runs the ``checksettings`` command, which configures
-    the location of the Toaster `Build
-    Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The Toaster
+    the location of the Toaster :term:`Build Directory`.
+    The Toaster
     root directory ``TOASTER_DIR`` determines where the Toaster build
     directory is created on the file system. In the example above,
     ``TOASTER_DIR`` is set as follows: /var/www/toaster/poky This
diff --git a/documentation/toaster-manual/toaster-manual-start.rst b/documentation/toaster-manual/toaster-manual-start.rst
index 439952e15e..1114c04eab 100644
--- a/documentation/toaster-manual/toaster-manual-start.rst
+++ b/documentation/toaster-manual/toaster-manual-start.rst
@@ -28,8 +28,8 @@ Establishing Toaster System Dependencies
 Toaster requires extra Python dependencies in order to run. A Toaster
 requirements file named ``toaster-requirements.txt`` defines the Python
 dependencies. The requirements file is located in the ``bitbake``
-directory, which is located in the root directory of the `Source
-Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
+directory, which is located in the root directory of the
+:term:`Source Directory` (e.g.
 ``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a
 ``pip``, install-compatible format.