sphinx: fix internal links

Many of the internal links were not converted probably from DocBook
using pandoc. After looking at the various patterns, the follow series
of 'naive' Python regexp were used to perform some additional
automatic conversion.

Also, since we rely on built-in glossary, all links to terms need to
use the sphinx :term: syntax.

This commit is generated using the following Python series of regexp:

   line = re.sub("`+(\w+)`* <(\&YOCTO_DOCS_REF_URL;)?#var-\\1>`__",
                 ":term:`\\1`",
                 line)

   line = re.sub("`+do_([a-z_]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-tasks-\\1>`__",
                 ":ref:`ref-tasks-\\1`",
                 line)

   line = re.sub("`+([a-z_\-\*\.]+).bbclass`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__",
                 ":ref:`\\1.bbclass <ref-classes-\\1>`",
                 line)

   line = re.sub("`+([a-z_\-\*\.]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__",
                 ":ref:`\\1 <ref-classes-\\1>`",
                 line)

   line = re.sub("`Source Directory <(\&YOCTO_DOCS_REF_URL;)?#source-directory>`__",
                 ":term:`Source Directory`",
                 line)

   line = re.sub("`Build Directory <(\&YOCTO_DOCS_REF_URL;)?#build-directory>`__",
                 ":term:`Build Directory`",
                 line)

   line = re.sub("`Metadata <(\&YOCTO_DOCS_REF_URL;)?#metadata>`__",
                 ":term:`Metadata`",
                 line)

   line = re.sub("`BitBake <(\&YOCTO_DOCS_REF_URL;)?#bitbake-term>`__",
                 ":term:`BitBake`",
                 line)

   line = re.sub("`Images <(\&YOCTO_DOCS_REF_URL;)?#ref-images>`__",
                 ":ref:`ref-manual/ref-images:Images`",
                 line)

   line = re.sub("`Classes <(\&YOCTO_DOCS_REF_URL;)?#ref-classes>`__",
                 ":ref:`ref-manual/ref-classes:Classes`",
                 line)

   line = re.sub("`workspace <(\&YOCTO_DOCS_REF_URL;)?#devtool-the-workspace-layer-structure>`__",
                 ":ref:`devtool-the-workspace-layer-structure`",
                 line)

   line = re.sub("`Open-?Embedded b?B?uild s?S?ystem <(\&YOCTO_DOCS_REF_URL;)?#build-system-term>`__",
                 ":term:`OpenEmbedded Build System`",
                 line)

   line = re.sub("`(OpenEmbedded-Core )?(\(?OE-Core\)? )?<(\&YOCTO_DOCS_REF_URL;)?#oe-core>`__",
                 ":term:`OpenEmbedded-Core (OE-Core)`",
                 line)

It won't catch multiline strings, but it catches a very large number
of occurences!

(From yocto-docs rev: 3f537d17de5b1fb76ba3bee196481984a4826378)

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

documentation/ref-manual/ref-features.rst

@@ -24,7 +24,7 @@ included if the distribution itself does not support them.
 
 One method you can use to determine which recipes are checking to see if
 a particular feature is contained or not is to ``grep`` through the
-`Metadata <#metadata>`__ for the feature. Here is an example that
+:term:`Metadata` for the feature. Here is an example that
 discovers the recipes whose build is potentially changed based on a
 given feature: $ cd poky $ git grep
 'contains.*MACHINE_FEATURES.*feature'
@@ -35,12 +35,12 @@ Machine Features
 ================
 
 The items below are features you can use with
-```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__. Features do not have a
+:term:`MACHINE_FEATURES`. Features do not have a
 one-to-one correspondence to packages, and they can go beyond simply
 controlling the installation of a package or packages. Sometimes a
 feature can influence how certain recipes are built. For example, a
 feature might determine whether a particular configure option is
-specified within the ```do_configure`` <#ref-tasks-configure>`__ task
+specified within the :ref:`ref-tasks-configure` task
 for a particular recipe.
 
 This feature list only represents features as shipped with the Yocto
@@ -92,18 +92,18 @@ Distro Features
 ===============
 
 The items below are features you can use with
-```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ to enable features across
+:term:`DISTRO_FEATURES` to enable features across
 your distribution. Features do not have a one-to-one correspondence to
 packages, and they can go beyond simply controlling the installation of
 a package or packages. In most cases, the presence or absence of a
 feature translates to the appropriate option supplied to the configure
-script during the ```do_configure`` <#ref-tasks-configure>`__ task for
+script during the :ref:`ref-tasks-configure` task for
 the recipes that optionally support the feature.
 
 Some distro features are also machine features. These select features
 make sense to be controlled both at the machine and distribution
 configuration level. See the
-```COMBINED_FEATURES`` <#var-COMBINED_FEATURES>`__ variable for more
+:term:`COMBINED_FEATURES` variable for more
 information.
 
 This list only represents features as shipped with the Yocto Project
@@ -189,8 +189,8 @@ Image Features
 ==============
 
 The contents of images generated by the OpenEmbedded build system can be
-controlled by the ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ and
-```EXTRA_IMAGE_FEATURES`` <#var-EXTRA_IMAGE_FEATURES>`__ variables that
+controlled by the :term:`IMAGE_FEATURES` and
+:term:`EXTRA_IMAGE_FEATURES` variables that
 you typically configure in your image recipes. Through these variables,
 you can add several different predefined packages such as development
 utilities or packages with debug information needed to investigate
@@ -254,7 +254,7 @@ The following image features are available for all images:
    a given image.
 
 Some image features are available only when you inherit the
-```core-image`` <#ref-classes-core-image>`__ class. The current list of
+:ref:`core-image <ref-classes-core-image>` class. The current list of
 these valid features is as follows:
 
 -  *hwcodecs:* Installs hardware acceleration codecs.
@@ -299,8 +299,8 @@ Feature Backfilling
 ===================
 
 Sometimes it is necessary in the OpenEmbedded build system to extend
-```MACHINE_FEATURES`` <#var-MACHINE_FEATURES>`__ or
-```DISTRO_FEATURES`` <#var-DISTRO_FEATURES>`__ to control functionality
+:term:`MACHINE_FEATURES` or
+:term:`DISTRO_FEATURES` to control functionality
 that was previously enabled and not able to be disabled. For these
 cases, we need to add an additional feature item to appear in one of
 these variables, but we do not want to force developers who have
@@ -310,8 +310,8 @@ Thus, the OpenEmbedded build system has a mechanism to automatically
 "backfill" these added features into existing distro or machine
 configurations. You can see the list of features for which this is done
 by finding the
-```DISTRO_FEATURES_BACKFILL`` <#var-DISTRO_FEATURES_BACKFILL>`__ and
-```MACHINE_FEATURES_BACKFILL`` <#var-MACHINE_FEATURES_BACKFILL>`__
+:term:`DISTRO_FEATURES_BACKFILL` and
+:term:`MACHINE_FEATURES_BACKFILL`
 variables in the ``meta/conf/bitbake.conf`` file.
 
 Because such features are backfilled by default into all configurations
@@ -319,9 +319,9 @@ as described in the previous paragraph, developers who wish to disable
 the new features need to be able to selectively prevent the backfilling
 from occurring. They can do this by adding the undesired feature or
 features to the
-```DISTRO_FEATURES_BACKFILL_CONSIDERED`` <#var-DISTRO_FEATURES_BACKFILL_CONSIDERED>`__
+:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
 or
-```MACHINE_FEATURES_BACKFILL_CONSIDERED`` <#var-MACHINE_FEATURES_BACKFILL_CONSIDERED>`__
+:term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
 variables for distro features and machine features respectively.
 
 Here are two examples to help illustrate feature backfilling: