sphinx: manual updates for some links

Some links were not found by the regexp, especially because of they
are spanning across multiple lines. This patch is a manual fixup for
these patterns.

(From yocto-docs rev: 7a5cf8b372903d959d4a1f0882e6198f31f3cba5)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

3 files changed, 54 insertions, 55 deletions

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