ref-manual: Fixed links in the "Yocto Project Terms" section.

Fixes [YOCTO #11630]

Moving the "Yocto Project Terms" section from the dev-manual to
the ref-manual caused many links local to that section to be
incorrect.  I scrubbed the section and fixed all the links.

(From yocto-docs rev: 4b795159aa80184f26ff1181a564516840c373b2)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 180 insertions, 138 deletions

diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
index 58ee073868..deaac033a3 100644
--- a/documentation/ref-manual/introduction.xml
+++ b/documentation/ref-manual/introduction.xml
@@ -43,110 +43,123 @@
     <title>Yocto Project Terms</title>
 
     <para>
-        Following is a list of terms and definitions users new to the Yocto Project development
-        environment might find helpful.
-        While some of these terms are universal, the list includes them just in case:
+        Following is a list of terms and definitions users new to the Yocto
+        Project development environment might find helpful.
+        While some of these terms are universal, the list includes them
+        just in case:
         <itemizedlist>
-            <listitem><para><emphasis>Append Files:</emphasis> Files that append build information to
-                a recipe file.
-                Append files are known as BitBake append files and <filename>.bbappend</filename> files.
-                The OpenEmbedded build system expects every append file to have a corresponding
-                recipe (<filename>.bb</filename>) file.
+            <listitem><para>
+                <emphasis>Append Files:</emphasis>
+                Files that append build information to a recipe file.
+                Append files are known as BitBake append files and
+                <filename>.bbappend</filename> files.
+                The OpenEmbedded build system expects every append file to have
+                a corresponding recipe (<filename>.bb</filename>) file.
                 Furthermore, the append file and corresponding recipe file
                 must use the same root filename.
-                The filenames can differ only in the file type suffix used (e.g.
-                <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
-                </para>
+                The filenames can differ only in the file type suffix used
+                (e.g.
+                <filename>formfactor_0.0.bb</filename> and
+                <filename>formfactor_0.0.bbappend</filename>).</para>
+
                 <para>Information in append files extends or overrides the
                 information in the similarly-named recipe file.
                 For an example of an append file in use, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
                 section in the Yocto Project Development Manual.
                 <note>
-                    Append files can also use wildcard patterns in their version numbers
-                    so they can be applied to more than one version of the underlying recipe file.
+                    Append files can also use wildcard patterns in their
+                    version numbers so they can be applied to more than one
+                    version of the underlying recipe file.
                 </note>
                 </para></listitem>
-            <listitem><para id='bitbake-term'><emphasis>BitBake:</emphasis>
+            <listitem><para id='bitbake-term'>
+                <emphasis>BitBake:</emphasis>
                 The task executor and scheduler used by the OpenEmbedded build
                 system to build images.
                 For more information on BitBake, see the
                 <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
                 </para></listitem>
             <listitem>
-                <para id='build-directory'><emphasis>Build Directory:</emphasis>
+                <para id='build-directory'>
+                <emphasis>Build Directory:</emphasis>
                 This term refers to the area used by the OpenEmbedded build
                 system for builds.
                 The area is created when you <filename>source</filename> the
                 setup environment script that is found in the Source Directory
-                (i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                (i.e. <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
                 or
-                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
-                The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
+                <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+                The
+                <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link>
                 variable points to the Build Directory.</para>
 
-                <para>
-                    You have a lot of flexibility when creating the Build
-                    Directory.
-                    Following are some examples that show how to create the
-                    directory.
-                    The examples assume your
-                    <link linkend='source-directory'>Source Directory</link> is
-                    named <filename>poky</filename>:
-                   <itemizedlist>
-                        <listitem><para>Create the Build Directory inside your
-                            Source Directory and let the name of the Build
-                            Directory default to <filename>build</filename>:
-                            <literallayout class='monospaced'>
+                <para>You have a lot of flexibility when creating the Build
+                Directory.
+                Following are some examples that show how to create the
+                directory.
+                The examples assume your
+                <link linkend='source-directory'>Source Directory</link> is
+                named <filename>poky</filename>:
+                <itemizedlist>
+                    <listitem><para>Create the Build Directory inside your
+                        Source Directory and let the name of the Build
+                        Directory default to <filename>build</filename>:
+                        <literallayout class='monospaced'>
      $ cd $HOME/poky
      $ source &OE_INIT_FILE;
-                            </literallayout></para></listitem>
-                        <listitem><para>Create the Build Directory inside your
-                            home directory and specifically name it
-                            <filename>test-builds</filename>:
-                            <literallayout class='monospaced'>
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>Create the Build Directory inside your
+                        home directory and specifically name it
+                        <filename>test-builds</filename>:
+                        <literallayout class='monospaced'>
      $ cd $HOME
      $ source poky/&OE_INIT_FILE; test-builds
-                            </literallayout></para></listitem>
-                        <listitem><para>
-                            Provide a directory path and
-                            specifically name the Build Directory.
-                            Any intermediate folders in the pathname must
-                            exist.
-                            This next example creates a Build Directory named
-                            <filename>YP-&POKYVERSION;</filename>
-                            in your home directory within the existing
-                            directory <filename>mybuilds</filename>:
-                            <literallayout class='monospaced'>
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        Provide a directory path and specifically name the
+                        Build Directory.
+                        Any intermediate folders in the pathname must exist.
+                        This next example creates a Build Directory named
+                        <filename>YP-&POKYVERSION;</filename>
+                        in your home directory within the existing
+                        directory <filename>mybuilds</filename>:
+                        <literallayout class='monospaced'>
      $cd $HOME
      $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
-                            </literallayout></para></listitem>
-                    </itemizedlist>
-                    <note>
-                        By default, the Build Directory contains
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>,
-                        which is a temporary directory the build system uses for
-                        its work.
-                        <filename>TMPDIR</filename> cannot be under NFS.
-                        Thus, by default, the Build Directory cannot be under NFS.
-                        However, if you need the Build Directory to be under NFS,
-                        you can set this up by setting <filename>TMPDIR</filename>
-                        in your <filename>local.conf</filename> file
-                        to use a local drive.
-                        Doing so effectively separates <filename>TMPDIR</filename>
-                        from <filename>TOPDIR</filename>, which is the Build
-                        Directory.
-                    </note>
-                    </para></listitem>
-            <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
-                and inheritance so that commonly used patterns can be defined once and then easily used
-                in multiple recipes.
+                        </literallayout>
+                        </para></listitem>
+                </itemizedlist>
+                <note>
+                    By default, the Build Directory contains
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
+                    which is a temporary directory the build system uses for
+                    its work.
+                    <filename>TMPDIR</filename> cannot be under NFS.
+                    Thus, by default, the Build Directory cannot be under NFS.
+                    However, if you need the Build Directory to be under NFS,
+                    you can set this up by setting <filename>TMPDIR</filename>
+                    in your <filename>local.conf</filename> file
+                    to use a local drive.
+                    Doing so effectively separates <filename>TMPDIR</filename>
+                    from <filename>TOPDIR</filename>, which is the Build
+                    Directory.
+                </note>
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Classes:</emphasis>
+                Files that provide for logic encapsulation and inheritance so
+                that commonly used patterns can be defined once and then
+                easily used in multiple recipes.
                 For reference information on the Yocto Project classes, see the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>Classes</ulink>" chapter of the
-                Yocto Project Reference Manual.
-                Class files end with the <filename>.bbclass</filename> filename extension.
+                "<link linkend='ref-classes'>Classes</link>" chapter.
+                Class files end with the <filename>.bbclass</filename>
+                filename extension.
                 </para></listitem>
-            <listitem><para><emphasis>Configuration File:</emphasis>
+            <listitem><para>
+                <emphasis>Configuration File:</emphasis>
                 Configuration information in various <filename>.conf</filename>
                 files provides global definitions of variables.
                 The <filename>conf/local.conf</filename> configuration file in
@@ -169,52 +182,58 @@
                 </para></listitem>
             <listitem><para id='cross-development-toolchain'>
                 <emphasis>Cross-Development Toolchain:</emphasis>
-                    In general, a cross-development toolchain is a collection of
-                    software development tools and utilities that run on one
-                    architecture and allow you to develop software for a
-                    different, or targeted, architecture.
-                    These toolchains contain cross-compilers, linkers, and
-                    debuggers that are specific to the target architecture.
-                </para>
+                In general, a cross-development toolchain is a collection of
+                software development tools and utilities that run on one
+                architecture and allow you to develop software for a
+                different, or targeted, architecture.
+                These toolchains contain cross-compilers, linkers, and
+                debuggers that are specific to the target architecture.</para>
 
                 <para>The Yocto Project supports two different cross-development
-                    toolchains:
-                    <itemizedlist>
-                        <listitem><para>A toolchain only used by and within
-                            BitBake when building an image for a target
-                            architecture.</para></listitem>
-                        <listitem><para>A relocatable toolchain used outside of
-                            BitBake by developers when developing applications
-                            that will run on a targeted device.
-                            </para></listitem>
-                    </itemizedlist>
-                </para>
+                toolchains:
+                <itemizedlist>
+                    <listitem><para>
+                        A toolchain only used by and within
+                        BitBake when building an image for a target
+                        architecture.
+                        </para></listitem>
+                    <listitem><para>A relocatable toolchain used outside of
+                        BitBake by developers when developing applications
+                        that will run on a targeted device.
+                        </para></listitem>
+                </itemizedlist></para>
 
-                <para>
-                    Creation of these toolchains is simple and automated.
-                    For information on toolchain concepts as they apply to the
-                    Yocto Project, see the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
-                    section in the Yocto Project Reference Manual.
-                    You can also find more information on using the
-                    relocatable toolchain in the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
-                </para></listitem>
-            <listitem><para><emphasis>Image:</emphasis>
+                <para>Creation of these toolchains is simple and automated.
+                For information on toolchain concepts as they apply to the
+                Yocto Project, see the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+                You can also find more information on using the
+                relocatable toolchain in the
+                <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Image:</emphasis>
                 An image is an artifact of the BitBake build process given
                 a collection of recipes and related Metadata.
                 Images are the binary output that run on specific hardware or
                 QEMU and are used for specific use-cases.
-                For a list of the supported image types that the Yocto Project provides, see the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
-                chapter in the Yocto Project Reference Manual.</para></listitem>
-            <listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core,
+                For a list of the supported image types that the Yocto Project
+                provides, see the
+                "<link linkend='ref-images'>Images</link>"
+                chapter.
+                </para></listitem>
+            <listitem><para id='layer'>
+                <emphasis>Layer:</emphasis>
+                A collection of recipes representing the core,
                 a BSP, or an application stack.
                 For a discussion specifically on BSP Layers, see the
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
-                Developer's Guide.</para></listitem>
-            <listitem><para id='metadata'><emphasis>Metadata:</emphasis>
+                Developer's Guide.
+                </para></listitem>
+            <listitem><para id='metadata'>
+                <emphasis>Metadata:</emphasis>
                 The files that BitBake parses when building an image.
                 In general, Metadata includes recipes, classes, and
                 configuration files.
@@ -222,11 +241,16 @@
                 it refers to Metadata in the <filename>meta</filename>
                 branches of the kernel source Git repositories.
                 </para></listitem>
-            <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of Metadata originating
-                with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
-                This Metadata is found in the <filename>meta</filename> directory of the
-                <link linkend='source-directory'>Source Directory</link>.</para></listitem>
-            <listitem><para id='build-system-term'><emphasis>OpenEmbedded Build System:</emphasis>
+            <listitem><para id='oe-core'>
+                <emphasis>OE-Core:</emphasis>
+                A core set of Metadata originating with OpenEmbedded (OE)
+                that is shared between OE and the Yocto Project.
+                This Metadata is found in the <filename>meta</filename>
+                directory of the
+                <link linkend='source-directory'>Source Directory</link>.
+                </para></listitem>
+            <listitem><para id='build-system-term'>
+                <emphasis>OpenEmbedded Build System:</emphasis>
                 The build system specific to the Yocto Project.
                 The OpenEmbedded build system is based on another project known
                 as "Poky", which uses
@@ -243,26 +267,33 @@
                     <link linkend='poky'>Poky</link> term.
                 </note>
                 </para></listitem>
-            <listitem><para><emphasis>Package:</emphasis>
+            <listitem><para>
+                <emphasis>Package:</emphasis>
                 In the context of the Yocto Project, this term refers to a
                 recipe's packaged output produced by BitBake (i.e. a
                 "baked recipe").
                 A package is generally the compiled binaries produced from the
                 recipe's sources.
                 You "bake" something by running it through BitBake.</para>
-                <para>It is worth noting that the term "package" can, in general, have subtle
-                meanings.  For example, the packages referred to in the
-                "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>" section are
-                compiled binaries that, when installed, add functionality to your Linux
+
+                <para>It is worth noting that the term "package" can,
+                in general, have subtle meanings.
+                For example, the packages referred to in the
+                "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>"
+                section in the Yocto Project Quick Start are compiled binaries
+                that, when installed, add functionality to your Linux
                 distribution.</para>
-                <para>Another point worth noting is that historically within the Yocto Project,
-                recipes were referred to as packages - thus, the existence of several BitBake
-                variables that are seemingly mis-named,
-                (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>,
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
-                </para></listitem>
-            <listitem><para><emphasis>Package Groups:</emphasis>
+
+                <para>Another point worth noting is that historically within
+                the Yocto Project, recipes were referred to as packages - thus,
+                the existence of several BitBake variables that are seemingly
+                mis-named,
+                (e.g. <link linkend='var-PR'><filename>PR</filename></link>,
+                <link linkend='var-PV'><filename>PV</filename></link>, and
+                <link linkend='var-PE'><filename>PE</filename></link>).
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Package Groups:</emphasis>
                 Arbitrary groups of software Recipes.
                 You use package groups to hold recipes that, when built,
                 usually accomplish a single task.
@@ -272,8 +303,10 @@
                 graphics.
                 A package group is really just another recipe.
                 Because package group files are recipes, they end with the
-                <filename>.bb</filename> filename extension.</para></listitem>
-            <listitem><para id='poky'><emphasis>Poky:</emphasis>
+                <filename>.bb</filename> filename extension.
+                </para></listitem>
+            <listitem><para id='poky'>
+                <emphasis>Poky:</emphasis>
                 The term "poky" can mean several things.
                 In its most general sense, it is an open-source
                 project that was initially developed by OpenedHand.
@@ -283,6 +316,7 @@
                 After Intel Corporation acquired OpenedHand, the
                 project poky became the basis for the Yocto Project's
                 build system.</para>
+
                 <para>Within the Yocto Project source repositories,
                 <filename>poky</filename> exists as a separate Git
                 repository you can clone to yield a local copy on your
@@ -290,13 +324,15 @@
                 Thus, "poky" can refer to the local copy of the Source
                 Directory used for development within the Yocto
                 Project.</para>
+
                 <para>Finally, "poky" can refer to the default
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
+                <link linkend='var-DISTRO'><filename>DISTRO</filename></link>
                 (i.e. distribution) created when you use the Yocto
                 Project in conjunction with the
                 <filename>poky</filename> repository to build an image.
                 </para></listitem>
-            <listitem><para><emphasis>Recipe:</emphasis>
+            <listitem><para>
+                <emphasis>Recipe:</emphasis>
                 A set of instructions for building packages.
                 A recipe describes where you get source code, which patches
                 to apply, how to configure the source, how to compile it and so on.
@@ -307,7 +343,8 @@
                 <filename>.bb</filename> file extension.
                 </para></listitem>
             <listitem>
-                <para id='source-directory'><emphasis>Source Directory:</emphasis>
+                <para id='source-directory'>
+                <emphasis>Source Directory:</emphasis>
                 This term refers to the directory structure created as a result
                 of creating a local copy of the <filename>poky</filename> Git
                 repository <filename>git://git.yoctoproject.org/poky</filename>
@@ -373,16 +410,21 @@
                 </para></listitem>
             <listitem><para><emphasis>Task:</emphasis>
                 A unit of execution for BitBake (e.g.
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink>,
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>,
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink>,
+                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>,
+                <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>,
+                <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>,
                 and so forth).
                 </para></listitem>
-            <listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
-                that are not local to the development system but located in a master area that is controlled
-                by the maintainer of the source code.
-                For example, in order for a developer to work on a particular piece of code, they need to
-                first get a copy of it from an "upstream" source.</para></listitem>
+            <listitem><para>
+                <emphasis>Upstream:</emphasis>
+                A reference to source code or repositories
+                that are not local to the development system but located in a
+                master area that is controlled by the maintainer of the source
+                code.
+                For example, in order for a developer to work on a particular
+                piece of code, they need to first get a copy of it from an
+                "upstream" source.
+                </para></listitem>
         </itemizedlist>
     </para>
 </section>