docs: ref-manual: indentation, links and highlights fixes

Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
(From yocto-docs rev: f5688a74cd9d100dee270edb9a33c02015cfabda)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 20 insertions, 35 deletions

diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index ef07354ec1..ff5d863736 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -282,17 +282,10 @@ file, it uses ``sed`` to substitute final
 
 .. note::
 
-   You can see how the
-   TEMPLATECONF
-   variable is used by looking at the
-   scripts/oe-setup-builddir
-   script in the
-   Source Directory
-   . You can find the Yocto Project version of the
-   local.conf.sample
-   file in the
-   meta-poky/conf
-   directory.
+   You can see how the ``TEMPLATECONF`` variable is used by looking at the
+   ``scripts/oe-setup-builddir``` script in the :term:`Source Directory`.
+   You can find the Yocto Project version of the ``local.conf.sample`` file in
+   the ``meta-poky/conf`` directory.
 
 .. _structure-build-conf-bblayers.conf:
 
@@ -327,16 +320,9 @@ Once the build process gets the sample file, it uses ``sed`` to substitute final
 
 .. note::
 
-   You can see how the
-   TEMPLATECONF
-   variable
-   scripts/oe-setup-builddir
-   script in the
-   Source Directory
-   . You can find the Yocto Project version of the
-   bblayers.conf.sample
-   file in the
-   meta-poky/conf/
+   You can see how the ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir``
+   script in the :term:`Source Directory`. You can find the Yocto Project
+   version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/``
    directory.
 
 .. _structure-build-conf-sanity_info:
@@ -531,19 +517,16 @@ should be automatic, and recipes should not directly reference
 
 Previous versions of the OpenEmbedded build system used to create a
 global shared sysroot per machine along with a native sysroot. Beginning
-with the DISTRO version of the Yocto Project, sysroots exist in
+with the 2.3 version of the Yocto Project, sysroots exist in
 recipe-specific :term:`WORKDIR` directories. Thus, the
 ``build/tmp/sysroots/`` directory is unused.
 
 .. note::
 
-   The
-   build/tmp/sysroots/
-   directory can still be populated using the
-   bitbake build-sysroots
-   command and can be used for compatibility in some cases. However, in
-   general it is not recommended to populate this directory. Individual
-   recipe-specific sysroots should be used.
+   The ``build/tmp/sysroots/`` directory can still be populated using the
+   ``bitbake build-sysroots`` command and can be used for compatibility in some
+   cases. However, in general it is not recommended to populate this directory.
+   Individual recipe-specific sysroots should be used.
 
 .. _structure-build-tmp-stamps:
 
@@ -554,8 +537,11 @@ This directory holds information that BitBake uses for accounting
 purposes to track what tasks have run and when they have run. The
 directory is sub-divided by architecture, package name, and version.
 Following is an example:
-stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do Although
-the files in the directory are empty of data, BitBake uses the filenames
+::
+
+      stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
+
+Although the files in the directory are empty of data, BitBake uses the filenames
 and timestamps for tracking purposes.
 
 For information on how BitBake uses stamp files to determine if a task
@@ -613,13 +599,12 @@ install" places its output that is then split into sub-packages within
 The recipe work directory - ``${WORKDIR}``.
 
 As described earlier in the
-"```build/tmp/sysroots/`` <#structure-build-tmp-sysroots>`__" section,
-beginning with the DISTRO release of the Yocto Project, the OpenEmbedded
+":ref:`structure-build-tmp-sysroots`" section,
+beginning with the 2.3 release of the Yocto Project, the OpenEmbedded
 build system builds each recipe in its own work directory (i.e.
 :term:`WORKDIR`). The path to the work directory is
 constructed using the architecture of the given build (e.g.
-:term:`TUNE_PKGARCH`,
-:term:`MACHINE_ARCH`, or "allarch"), the recipe
+:term:`TUNE_PKGARCH`, :term:`MACHINE_ARCH`, or "allarch"), the recipe
 name, and the version of the recipe (i.e.
 :term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).