ref-manual, overview-manual, yocto-project-qs: Moved YP Components

Fixes [YOCTO #12370]

Moved the "Yocto Project Components" section from the ref-manual to
the overview-manual.  This material falls into the "concepts" area
and is being moved from the ref-manual.  One link in the
yocto-project-qs was affected and updated.  Oh... another link in the
ref-manual for a variable also fixed.

(From yocto-docs rev: 75ced485bb223373591eb41d1b343d0c2b315345)

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

2 files changed, 3 insertions, 224 deletions

diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 251e10c83f..1b5f863970 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -10709,8 +10709,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
      PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
      PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
                     </literallayout>
-                    For more information see:
-                    <link linkend='metadata-virtual-providers'>Metadata (Virtual Providers)</link>
+                    For more information, see the
+                    "<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#metadata-virtual-providers'>Metadata (Virtual Providers)</ulink>"
+                    section in the Yocto Project Overview Manual.
                     <note>
                         If you set <filename>PREFERRED_PROVIDER</filename>
                         for a <filename>virtual/*</filename> item, then any
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 5769cd619a..d0929bd756 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -13,228 +13,6 @@
         x32, Wayland support, and Licenses.
     </para>
 
-<section id='usingpoky-components'>
-    <title>Yocto Project Components</title>
-
-    <para>
-        The
-        <link linkend='bitbake-term'>BitBake</link>
-        task executor together with various types of configuration files form
-        the OpenEmbedded Core.
-        This section overviews these components by describing their use and
-        how they interact.
-    </para>
-
-    <para>
-        BitBake handles the parsing and execution of the data files.
-        The data itself is of various types:
-        <itemizedlist>
-            <listitem><para><emphasis>Recipes:</emphasis> Provides details
-                about particular pieces of software.
-                </para></listitem>
-            <listitem><para><emphasis>Class Data:</emphasis> Abstracts
-                common build information (e.g. how to build a Linux kernel).
-                </para></listitem>
-            <listitem><para><emphasis>Configuration Data:</emphasis> Defines
-                machine-specific settings, policy decisions, and so forth.
-                Configuration data acts as the glue to bind everything
-                together.
-                </para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        BitBake knows how to combine multiple data sources together and refers
-        to each data source as a layer.
-        For information on layers, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
-        Creating Layers</ulink>" section of the Yocto Project Development
-        Tasks Manual.
-    </para>
-
-    <para>
-        Following are some brief details on these core components.
-        For additional information on how these components interact during
-        a build, see the
-        "<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#development-concepts'>Development Concepts</ulink>"
-        section in the Yocto Project Overview Manual.
-    </para>
-
-    <section id='usingpoky-components-bitbake'>
-        <title>BitBake</title>
-
-        <para>
-            BitBake is the tool at the heart of the OpenEmbedded build system
-            and is responsible for parsing the
-            <link linkend='metadata'>Metadata</link>,
-            generating a list of tasks from it, and then executing those tasks.
-        </para>
-
-        <para>
-            This section briefly introduces BitBake.
-            If you want more information on BitBake, see the
-            <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
-        </para>
-
-        <para>
-            To see a list of the options BitBake supports, use either of
-            the following commands:
-            <literallayout class='monospaced'>
-     $ bitbake -h
-     $ bitbake --help
-            </literallayout>
-        </para>
-
-        <para>
-            The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
-            <filename>packagename</filename> is the name of the package you want to build
-            (referred to as the "target" in this manual).
-            The target often equates to the first part of a recipe's filename
-            (e.g. "foo" for a recipe named
-            <filename>foo_1.3.0-r0.bb</filename>).
-            So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
-            might type the following:
-            <literallayout class='monospaced'>
-     $ bitbake matchbox-desktop
-            </literallayout>
-            Several different versions of <filename>matchbox-desktop</filename> might exist.
-            BitBake chooses the one selected by the distribution configuration.
-            You can get more details about how BitBake chooses between different
-            target versions and providers in the
-            "<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>"
-            section of the BitBake User Manual.
-        </para>
-
-        <para>
-            BitBake also tries to execute any dependent tasks first.
-            So for example, before building <filename>matchbox-desktop</filename>, BitBake
-            would build a cross compiler and <filename>glibc</filename> if they had not already
-            been built.
-        </para>
-
-        <para>
-            A useful BitBake option to consider is the <filename>-k</filename> or
-            <filename>--continue</filename> option.
-            This option instructs BitBake to try and continue processing the job
-            as long as possible even after encountering an error.
-            When an error occurs, the target that
-            failed and those that depend on it cannot be remade.
-            However, when you use this option other dependencies can still be
-            processed.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-metadata'>
-        <title>Metadata (Recipes)</title>
-
-        <para>
-            Files that have the <filename>.bb</filename> suffix are "recipes"
-            files.
-            In general, a recipe contains information about a single piece of
-            software.
-            This information includes the location from which to download the
-            unaltered source, any source patches to be applied to that source
-            (if needed), which special configuration options to apply,
-            how to compile the source files, and how to package the compiled
-            output.
-        </para>
-
-        <para>
-            The term "package" is sometimes used to refer to recipes. However,
-            since the word "package" is used for the packaged output from the OpenEmbedded
-            build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
-            this document avoids using the term "package" when referring to recipes.
-        </para>
-    </section>
-
-    <section id='metadata-virtual-providers'>
-        <title>Metadata (Virtual Providers)</title>
-
-        <para>
-            Prior to the build, if you know that several different recipes
-            provide the same functionality, you can use a virtual provider
-            (i.e. <filename>virtual/*</filename>) as a placeholder for the
-            actual provider.
-            The actual provider would be determined at build
-            time.
-            In this case, you should add <filename>virtual/*</filename>
-            to <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>,
-            rather than listing the specified provider.
-            You would select the actual provider by setting the
-            <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>
-            variable (i.e. <filename>PREFERRED_PROVIDER_virtual/*</filename>)
-            in the build's configuration file (e.g.
-            <filename>poky/build/conf/local.conf</filename>).
-            <note>
-                Any recipe that PROVIDES a <filename>virtual/*</filename> item
-                that is ultimately not selected through
-                <filename>PREFERRED_PROVIDER</filename> does not get built.
-                Preventing these recipes from building is usually the desired
-                behavior since this mechanism's purpose is to select between
-                mutually exclusive alternative providers.
-            </note>
-        </para>
-
-        <para>
-            The following lists specific examples of virtual providers:
-            <itemizedlist>
-                <listitem><para>
-                    <filename>virtual/mesa</filename>:
-                    Provides <filename>gbm.pc</filename>.
-                    </para></listitem>
-                <listitem><para>
-                    <filename>virtual/egl</filename>:
-                    Provides <filename>egl.pc</filename> and possibly
-                    <filename>wayland-egl.pc</filename>.
-                    </para></listitem>
-                <listitem><para>
-                    <filename>virtual/libgl</filename>:
-                    Provides <filename>gl.pc</filename> (i.e. libGL).
-                    </para></listitem>
-                <listitem><para>
-                    <filename>virtual/libgles1</filename>:
-                    Provides <filename>glesv1_cm.pc</filename>
-                    (i.e. libGLESv1_CM).
-                    </para></listitem>
-                <listitem><para>
-                    <filename>virtual/libgles2</filename>:
-                    Provides <filename>glesv2.pc</filename> (i.e. libGLESv2).
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id='usingpoky-components-classes'>
-        <title>Classes</title>
-
-        <para>
-            Class files (<filename>.bbclass</filename>) contain information that
-            is useful to share between
-            <link linkend='metadata'>Metadata</link> files.
-            An example is the
-            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
-            class, which contains common settings for any application that
-            Autotools uses.
-            The "<link linkend='ref-classes'>Classes</link>" chapter provides
-            details about classes and how to use them.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-configuration'>
-        <title>Configuration</title>
-
-        <para>
-            The configuration files (<filename>.conf</filename>) define various configuration 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 <filename>local.conf</filename>, which is found
-            in the
-            <link linkend='build-directory'>Build Directory</link>.
-        </para>
-    </section>
-</section>
-
 <section id="cross-development-toolchain-generation">
     <title>Cross-Development Toolchain Generation</title>