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>

1 files changed, 5 insertions, 5 deletions

diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
index 1a07a9e7a9..fcb15a8592 100644
--- a/documentation/sdk-manual/sdk-intro.rst
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -56,8 +56,8 @@ toolchain binaries are produced for any given architecture. This feature
 takes advantage of the fact that the target hardware can be passed to
 ``gcc`` as a set of compiler options. Those options are set up by the
 environment script and contained in variables such as
-```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ and
-```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__. This reduces the space needed
+:term:`CC` and
+:term:`LD`. This reduces the space needed
 for the tools. Understand, however, that every target still needs a
 sysroot because those binaries are target-specific.
 
@@ -66,7 +66,7 @@ The SDK development environment consists of the following:
 -  The self-contained SDK, which is an architecture-specific
    cross-toolchain and matching sysroots (target and native) all built
    by the OpenEmbedded build system (e.g. the SDK). The toolchain and
-   sysroots are based on a `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__
+   sysroots are based on a :term:`Metadata`
    configuration and extensions, which allows you to cross-develop on
    the host machine for the target hardware. Additionally, the
    extensible SDK contains the ``devtool`` functionality.
@@ -107,9 +107,9 @@ when considering which to build:
 +-----------------------+-----------------------+-----------------------+
 
 \* Extensible SDK contains the toolchain and debugger if
-```SDK_EXT_TYPE`` <&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE>`__ is "full"
+:term:`SDK_EXT_TYPE` is "full"
 or
-```SDK_INCLUDE_TOOLCHAIN`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN>`__
+:term:`SDK_INCLUDE_TOOLCHAIN`
 is "1", which is the default. \*\* Sysroot is managed through the use of
 ``devtool``. Thus, it is less likely that you will corrupt your SDK
 sysroot when you try to add additional libraries. \**\* You can add