getting-started: Removed accidental tracked files

I accidentally pushed a commit after building out the new getting-started
manual before applying some key files to the .gitignore file.  So,
the HTML, TGZ, and eclipse/* stuff got tracked in Git.  I don't
want that.  So I had to use the 'git rm' command to untrack those
files.

(From yocto-docs rev: 217f6db7f741cee266885a845b2b0e7faf96e537)

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

92 files changed, 0 insertions, 10021 deletions

diff --git a/documentation/getting-started/eclipse/getting-started-toc.xml b/documentation/getting-started/eclipse/getting-started-toc.xml
deleted file mode 100644
index 6f1c29af30..0000000000
--- a/documentation/getting-started/eclipse/getting-started-toc.xml
+++ /dev/null
@@ -1,86 +0,0 @@
-<?xml version="1.0" encoding="utf-8" standalone="no"?>
-<toc label="Getting Started With Yocto Project" topic="html/getting-started/index.html">
-  <topic label="The Yocto Project Overview Manual" href="html/getting-started/overview-manual-intro.html">
-    <topic label="Welcome" href="html/getting-started/overview-welcome.html"/>
-    <topic label="Other Information" href="html/getting-started/overview-other-information.html"/>
-  </topic>
-  <topic label="The Yocto Project Development Environment" href="html/getting-started/overview-development-environment.html">
-    <topic label="Introduction" href="html/getting-started/yp-intro.html"/>
-    <topic label="Open Source Philosophy" href="html/getting-started/open-source-philosophy.html"/>
-    <topic label="Workflows" href="html/getting-started/workflows.html"/>
-    <topic label="Git" href="html/getting-started/git.html">
-      <topic label="Repositories, Tags, and Branches" href="html/getting-started/repositories-tags-and-branches.html"/>
-      <topic label="Basic Commands" href="html/getting-started/basic-commands.html"/>
-    </topic>
-    <topic label="Yocto Project Source Repositories" href="html/getting-started/yocto-project-repositories.html"/>
-    <topic label="Licensing" href="html/getting-started/licensing.html"/>
-    <topic label="Recipe Syntax" href="html/getting-started/recipe-syntax.html"/>
-    <topic label="Development Concepts" href="html/getting-started/development-concepts.html">
-      <topic label="User Configuration" href="html/getting-started/user-configuration.html"/>
-      <topic label="Metadata, Machine Configuration, and Policy Configuration" href="html/getting-started/metadata-machine-configuration-and-policy-configuration.html">
-        <topic label="Distro Layer" href="html/getting-started/distro-layer.html"/>
-        <topic label="BSP Layer" href="html/getting-started/bsp-layer.html"/>
-        <topic label="Software Layer" href="html/getting-started/software-layer.html"/>
-      </topic>
-      <topic label="Sources" href="html/getting-started/sources-dev-environment.html">
-        <topic label="Upstream Project Releases" href="html/getting-started/upstream-project-releases.html"/>
-        <topic label="Local Projects" href="html/getting-started/local-projects.html"/>
-        <topic label="Source Control Managers (Optional)" href="html/getting-started/scms.html"/>
-        <topic label="Source Mirror(s)" href="html/getting-started/source-mirrors.html"/>
-      </topic>
-      <topic label="Package Feeds" href="html/getting-started/package-feeds-dev-environment.html"/>
-      <topic label="BitBake" href="html/getting-started/bitbake-dev-environment.html">
-        <topic label="Source Fetching" href="html/getting-started/source-fetching-dev-environment.html"/>
-        <topic label="Patching" href="html/getting-started/patching-dev-environment.html"/>
-        <topic label="Configuration and Compilation" href="html/getting-started/configuration-and-compilation-dev-environment.html"/>
-        <topic label="Package Splitting" href="html/getting-started/package-splitting-dev-environment.html"/>
-        <topic label="Image Generation" href="html/getting-started/image-generation-dev-environment.html"/>
-        <topic label="SDK Generation" href="html/getting-started/sdk-generation-dev-environment.html"/>
-        <topic label="Stamp Files and the Rerunning of Tasks" href="html/getting-started/stamp-files-and-the-rerunning-of-tasks.html"/>
-        <topic label="Setscene Tasks and Shared State" href="html/getting-started/setscene-tasks-and-shared-state.html"/>
-      </topic>
-      <topic label="Images" href="html/getting-started/images-dev-environment.html"/>
-      <topic label="Application Development SDK" href="html/getting-started/sdk-dev-environment.html"/>
-    </topic>
-  </topic>
-  <topic label="Yocto Project Concepts" href="html/getting-started/overview-concepts.html">
-    <topic label="Yocto Project Components" href="html/getting-started/yocto-project-components.html">
-      <topic label="BitBake" href="html/getting-started/usingpoky-components-bitbake.html"/>
-      <topic label="Metadata (Recipes)" href="html/getting-started/usingpoky-components-metadata.html"/>
-      <topic label="Metadata (Virtual Providers)" href="html/getting-started/metadata-virtual-providers.html"/>
-      <topic label="Classes" href="html/getting-started/usingpoky-components-classes.html"/>
-      <topic label="Configuration" href="html/getting-started/usingpoky-components-configuration.html"/>
-    </topic>
-    <topic label="Cross-Development Toolchain Generation" href="html/getting-started/cross-development-toolchain-generation.html"/>
-    <topic label="Shared State Cache" href="html/getting-started/shared-state-cache.html">
-      <topic label="Overall Architecture" href="html/getting-started/overall-architecture.html"/>
-      <topic label="Checksums (Signatures)" href="html/getting-started/overview-checksums.html"/>
-      <topic label="Shared State" href="html/getting-started/shared-state.html"/>
-      <topic label="Tips and Tricks" href="html/getting-started/tips-and-tricks.html">
-        <topic label="Debugging" href="html/getting-started/overview-debugging.html"/>
-        <topic label="Invalidating Shared State" href="html/getting-started/invalidating-shared-state.html"/>
-      </topic>
-    </topic>
-    <topic label="Automatically Added Runtime Dependencies" href="html/getting-started/automatically-added-runtime-dependencies.html"/>
-    <topic label="Fakeroot and Pseudo" href="html/getting-started/fakeroot-and-pseudo.html"/>
-    <topic label="Wayland" href="html/getting-started/wayland.html">
-      <topic label="Support" href="html/getting-started/wayland-support.html"/>
-      <topic label="Enabling Wayland in an Image" href="html/getting-started/enabling-wayland-in-an-image.html">
-        <topic label="Building" href="html/getting-started/enable-building.html"/>
-        <topic label="Installing" href="html/getting-started/enable-installation-in-an-image.html"/>
-      </topic>
-      <topic label="Running Weston" href="html/getting-started/running-weston.html"/>
-    </topic>
-    <topic label="Licenses" href="html/getting-started/overview-licenses.html">
-      <topic label="Tracking License Changes" href="html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html">
-        <topic label="Specifying the LIC_FILES_CHKSUM Variable" href="html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html"/>
-        <topic label="Explanation of Syntax" href="html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html"/>
-      </topic>
-      <topic label="Enabling Commercially Licensed Recipes" href="html/getting-started/enabling-commercially-licensed-recipes.html">
-        <topic label="License Flag Matching" href="html/getting-started/license-flag-matching.html"/>
-        <topic label="Other Variables Related to Commercial Licenses" href="html/getting-started/other-variables-related-to-commercial-licenses.html"/>
-      </topic>
-    </topic>
-    <topic label="x32 psABI" href="html/getting-started/x32.html"/>
-  </topic>
-</toc>
diff --git a/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html b/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html
deleted file mode 100644
index 885ee089e1..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html
+++ /dev/null
@@ -1,164 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.4.�Automatically Added Runtime Dependencies</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="invalidating-shared-state.html" title="3.3.4.2.�Invalidating Shared State">
-<link rel="next" href="fakeroot-and-pseudo.html" title="3.5.�Fakeroot and Pseudo">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4.�Automatically Added Runtime Dependencies">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="automatically-added-runtime-dependencies"></a>3.4.�Automatically Added Runtime Dependencies</h2></div></div></div>
-<p>
-            The OpenEmbedded build system automatically adds common types of
-            runtime dependencies between packages, which means that you do not
-            need to explicitly declare the packages using
-            <a class="link" href="../ref-manual/var-RDEPENDS.html" target="_self"><code class="filename">RDEPENDS</code></a>.
-            Three automatic mechanisms exist (<code class="filename">shlibdeps</code>,
-            <code class="filename">pcdeps</code>, and <code class="filename">depchains</code>)
-            that handle shared libraries, package configuration (pkg-config)
-            modules, and <code class="filename">-dev</code> and
-            <code class="filename">-dbg</code> packages, respectively.
-            For other types of runtime dependencies, you must manually declare
-            the dependencies.
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p>
-                    <code class="filename">shlibdeps</code>:
-                    During the
-                    <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>
-                    task of each recipe, all shared libraries installed by the
-                    recipe are located.
-                    For each shared library, the package that contains the
-                    shared library is registered as providing the shared
-                    library.
-                    More specifically, the package is registered as providing
-                    the
-                    <a class="ulink" href="https://en.wikipedia.org/wiki/Soname" target="_self">soname</a>
-                    of the library.
-                    The resulting shared-library-to-package mapping
-                    is saved globally in
-                    <a class="link" href="../ref-manual/var-PKGDATA_DIR.html" target="_self"><code class="filename">PKGDATA_DIR</code></a>
-                    by the
-                    <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>
-                    task.</p>
-<p>Simultaneously, all executables and shared libraries
-                    installed by the recipe are inspected to see what shared
-                    libraries they link against.
-                    For each shared library dependency that is found,
-                    <code class="filename">PKGDATA_DIR</code> is queried to
-                    see if some package (likely from a different recipe)
-                    contains the shared library.
-                    If such a package is found, a runtime dependency is added
-                    from the package that depends on the shared library to the
-                    package that contains the library.</p>
-<p>The automatically added runtime dependency also
-                    includes a version restriction.
-                    This version restriction specifies that at least the
-                    current version of the package that provides the shared
-                    library must be used, as if
-                    "<em class="replaceable"><code>package</code></em> (&gt;= <em class="replaceable"><code>version</code></em>)"
-                    had been added to
-                    <a class="link" href="../ref-manual/var-RDEPENDS.html" target="_self"><code class="filename">RDEPENDS</code></a>.
-                    This forces an upgrade of the package containing the shared
-                    library when installing the package that depends on the
-                    library, if needed.</p>
-<p>If you want to avoid a package being registered as
-                    providing a particular shared library (e.g. because the library
-                    is for internal use only), then add the library to
-                    <a class="link" href="../ref-manual/var-PRIVATE_LIBS.html" target="_self"><code class="filename">PRIVATE_LIBS</code></a>
-                    inside the package's recipe.
-                    </p>
-</li>
-<li class="listitem">
-<p>
-                    <code class="filename">pcdeps</code>:
-                    During the
-                    <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>
-                    task of each recipe, all pkg-config modules
-                    (<code class="filename">*.pc</code> files) installed by the recipe
-                    are located.
-                    For each module, the package that contains the module is
-                    registered as providing the module.
-                    The resulting module-to-package mapping is saved globally in
-                    <a class="link" href="../ref-manual/var-PKGDATA_DIR.html" target="_self"><code class="filename">PKGDATA_DIR</code></a>
-                    by the
-                    <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>
-                    task.</p>
-<p>Simultaneously, all pkg-config modules installed by
-                    the recipe are inspected to see what other pkg-config
-                    modules they depend on.
-                    A module is seen as depending on another module if it
-                    contains a "Requires:" line that specifies the other module.
-                    For each module dependency,
-                    <code class="filename">PKGDATA_DIR</code> is queried to see if some
-                    package contains the module.
-                    If such a package is found, a runtime dependency is added
-                    from the package that depends on the module to the package
-                    that contains the module.
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        The <code class="filename">pcdeps</code> mechanism most often
-                        infers dependencies between <code class="filename">-dev</code>
-                        packages.
-                    </div>
-<p>
-                    </p>
-</li>
-<li class="listitem">
-<p>
-                    <code class="filename">depchains</code>:
-                    If a package <code class="filename">foo</code> depends on a package
-                    <code class="filename">bar</code>, then <code class="filename">foo-dev</code>
-                    and <code class="filename">foo-dbg</code> are also made to depend on
-                    <code class="filename">bar-dev</code> and
-                    <code class="filename">bar-dbg</code>, respectively.
-                    Taking the <code class="filename">-dev</code> packages as an
-                    example, the <code class="filename">bar-dev</code> package might
-                    provide headers and shared library symlinks needed by
-                    <code class="filename">foo-dev</code>, which shows the need
-                    for a dependency between the packages.</p>
-<p>The dependencies added by
-                    <code class="filename">depchains</code> are in the form of
-                    <a class="link" href="../ref-manual/var-RRECOMMENDS.html" target="_self"><code class="filename">RRECOMMENDS</code></a>.
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        By default, <code class="filename">foo-dev</code> also has an
-                        <code class="filename">RDEPENDS</code>-style dependency on
-                        <code class="filename">foo</code>, because the default value of
-                        <code class="filename">RDEPENDS_${PN}-dev</code> (set in
-                        <code class="filename">bitbake.conf</code>) includes
-                        "${PN}".
-                    </div>
-<p>To ensure that the dependency chain is never broken,
-                    <code class="filename">-dev</code> and <code class="filename">-dbg</code>
-                    packages are always generated by default, even if the
-                    packages turn out to be empty.
-                    See the
-                    <a class="link" href="../ref-manual/var-ALLOW_EMPTY.html" target="_self"><code class="filename">ALLOW_EMPTY</code></a>
-                    variable for more information.
-                    </p>
-</li>
-</ul></div>
-<p>
-        </p>
-<p>
-            The <code class="filename">do_package</code> task depends on the
-            <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>
-            task of each recipe in
-            <a class="link" href="../ref-manual/var-DEPENDS.html" target="_self"><code class="filename">DEPENDS</code></a>
-            through use of a
-            <code class="filename">[</code><a class="link" href="../bitbake-user-manual/variable-flags.html" target="_self"><code class="filename">deptask</code></a><code class="filename">]</code>
-            declaration, which guarantees that the required
-            shared-library/module-to-package mapping information will be available
-            when needed as long as <code class="filename">DEPENDS</code> has been
-            correctly set.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/basic-commands.html b/documentation/getting-started/eclipse/html/getting-started/basic-commands.html
deleted file mode 100644
index b145086974..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/basic-commands.html
+++ /dev/null
@@ -1,176 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.4.2.�Basic Commands</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="git.html" title="2.4.�Git">
-<link rel="prev" href="repositories-tags-and-branches.html" title="2.4.1.�Repositories, Tags, and Branches">
-<link rel="next" href="yocto-project-repositories.html" title="2.5.�Yocto Project Source Repositories">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.2.�Basic Commands">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="basic-commands"></a>2.4.2.�Basic Commands</h3></div></div></div>
-<p>
-            Git has an extensive set of commands that lets you manage changes
-            and perform collaboration over the life of a project.
-            Conveniently though, you can manage with a small set of basic
-            operations and workflows once you understand the basic
-            philosophy behind Git.
-            You do not have to be an expert in Git to be functional.
-            A good place to look for instruction on a minimal set of Git
-            commands is
-            <a class="ulink" href="http://git-scm.com/documentation" target="_self">here</a>.
-        </p>
-<p>
-            If you do not know much about Git, you should educate
-            yourself by visiting the links previously mentioned.
-        </p>
-<p>
-            The following list of Git commands briefly describes some basic
-            Git operations as a way to get started.
-            As with any set of commands, this list (in most cases) simply shows
-            the base command and omits the many arguments they support.
-            See the Git documentation for complete descriptions and strategies
-            on how to use these commands:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git init</code>:</em></span>
-                    Initializes an empty Git repository.
-                    You cannot use Git commands unless you have a
-                    <code class="filename">.git</code> repository.
-                    </p></li>
-<li class="listitem"><p><a name="git-commands-clone"></a>
-                    <span class="emphasis"><em><code class="filename">git clone</code>:</em></span>
-                    Creates a local clone of a Git repository that is on
-                    equal footing with a fellow developer&#8217;s Git repository
-                    or an upstream repository.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git add</code>:</em></span>
-                    Locally stages updated file contents to the index that
-                    Git uses to track changes.
-                    You must stage all files that have changed before you
-                    can commit them.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git commit</code>:</em></span>
-                    Creates a local "commit" that documents the changes you
-                    made.
-                    Only changes that have been staged can be committed.
-                    Commits are used for historical purposes, for determining
-                    if a maintainer of a project will allow the change,
-                    and for ultimately pushing the change from your local
-                    Git repository into the project&#8217;s upstream repository.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git status</code>:</em></span>
-                    Reports any modified files that possibly need to be
-                    staged and gives you a status of where you stand regarding
-                    local commits as compared to the upstream repository.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git checkout</code> <em class="replaceable"><code>branch-name</code></em>:</em></span>
-                    Changes your working branch.
-                    This command is analogous to "cd".
-                    </p></li>
-<li class="listitem"><p><span class="emphasis"><em><code class="filename">git checkout &#8211;b</code> <em class="replaceable"><code>working-branch</code></em>:</em></span>
-                    Creates and checks out a working branch on your local
-                    machine that you can use to isolate your work.
-                    It is a good idea to use local branches when adding
-                    specific features or changes.
-                    Using isolated branches facilitates easy removal of
-                    changes if they do not work out.
-                    </p></li>
-<li class="listitem"><p><span class="emphasis"><em><code class="filename">git branch</code>:</em></span>
-                    Displays the existing local branches associated with your
-                    local repository.
-                    The branch that you have currently checked out is noted
-                    with an asterisk character.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git branch -D</code> <em class="replaceable"><code>branch-name</code></em>:</em></span>
-                    Deletes an existing local branch.
-                    You need to be in a local branch other than the one you
-                    are deleting in order to delete
-                    <em class="replaceable"><code>branch-name</code></em>.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git pull</code>:</em></span>
-                    Retrieves information from an upstream Git repository
-                    and places it in your local Git repository.
-                    You use this command to make sure you are synchronized with
-                    the repository from which you are basing changes
-                    (.e.g. the "master" branch).
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git push</code>:</em></span>
-                    Sends all your committed local changes to the upstream Git
-                    repository that your local repository is tracking
-                    (e.g. a contribution repository).
-                    The maintainer of the project draws from these repositories
-                    to merge changes (commits) into the appropriate branch
-                    of project's upstream repository.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git merge</code>:</em></span>
-                    Combines or adds changes from one
-                    local branch of your repository with another branch.
-                    When you create a local Git repository, the default branch
-                    is named "master".
-                    A typical workflow is to create a temporary branch that is
-                    based off "master" that you would use for isolated work.
-                    You would make your changes in that isolated branch,
-                    stage and commit them locally, switch to the "master"
-                    branch, and then use the <code class="filename">git merge</code>
-                    command to apply the changes from your isolated branch
-                    into the currently checked out branch (e.g. "master").
-                    After the merge is complete and if you are done with
-                    working in that isolated branch, you can safely delete
-                    the isolated branch.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git cherry-pick</code>:</em></span>
-                    Choose and apply specific commits from one branch
-                    into another branch.
-                    There are times when you might not be able to merge
-                    all the changes in one branch with
-                    another but need to pick out certain ones.
-                    </p></li>
-<li class="listitem">
-<p>
-                    <span class="emphasis"><em><code class="filename">gitk</code>:</em></span>
-                    Provides a GUI view of the branches and changes in your
-                    local Git repository.
-                    This command is a good way to graphically see where things
-                    have diverged in your local repository.
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        You need to install the <code class="filename">gitk</code>
-                        package on your development system to use this
-                        command.
-                    </div>
-<p>
-                    </p>
-</li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git log</code>:</em></span>
-                    Reports a history of your commits to the repository.
-                    This report lists all commits regardless of whether you
-                    have pushed them upstream or not.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git diff</code>:</em></span>
-                    Displays line-by-line differences between a local
-                    working file and the same file as understood by Git.
-                    This command is useful to see what you have changed
-                    in any given file.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html
deleted file mode 100644
index eda2c3370f..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html
+++ /dev/null
@@ -1,31 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.�BitBake</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="package-feeds-dev-environment.html" title="2.8.4.�Package Feeds">
-<link rel="next" href="source-fetching-dev-environment.html" title="2.8.5.1.�Source Fetching">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.�BitBake">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="bitbake-dev-environment"></a>2.8.5.�BitBake</h3></div></div></div>
-<p>
-            The OpenEmbedded build system uses
-            <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a>
-            to produce images.
-            You can see from the
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>,
-            the BitBake area consists of several functional areas.
-            This section takes a closer look at each of those areas.
-        </p>
-<p>
-            Separate documentation exists for the BitBake tool.
-            See the
-            <a class="link" href="../bitbake-user-manual/bitbake-user-manual.html" target="_self">BitBake User Manual</a>
-            for reference material on BitBake.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html b/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html
deleted file mode 100644
index 2d009d5720..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html
+++ /dev/null
@@ -1,54 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.2.2.�BSP Layer</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2.�Metadata, Machine Configuration, and Policy Configuration">
-<link rel="prev" href="distro-layer.html" title="2.8.2.1.�Distro Layer">
-<link rel="next" href="software-layer.html" title="2.8.2.3.�Software Layer">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.2.�BSP Layer">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="bsp-layer"></a>2.8.2.2.�BSP Layer</h4></div></div></div>
-<p>
-                The BSP Layer provides machine configurations.
-                Everything in this layer is specific to the machine for which
-                you are building the image or the SDK.
-                A common structure or form is defined for BSP layers.
-                You can learn more about this structure in the
-                <a class="link" href="../bsp-guide/index.html" target="_self">Yocto Project Board Support Package (BSP) Developer's Guide</a>.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    In order for a BSP layer to be considered compliant with the
-                    Yocto Project, it must meet some structural requirements.
-                </div>
-<p>
-            </p>
-<p>
-                The BSP Layer's configuration directory contains
-                configuration files for the machine
-                (<code class="filename">conf/machine/<em class="replaceable"><code>machine</code></em>.conf</code>) and,
-                of course, the layer (<code class="filename">conf/layer.conf</code>).
-            </p>
-<p>
-                The remainder of the layer is dedicated to specific recipes
-                by function: <code class="filename">recipes-bsp</code>,
-                <code class="filename">recipes-core</code>,
-                <code class="filename">recipes-graphics</code>, and
-                <code class="filename">recipes-kernel</code>.
-                Metadata can exist for multiple formfactors, graphics
-                support systems, and so forth.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    While the figure shows several <code class="filename">recipes-*</code>
-                    directories, not all these directories appear in all
-                    BSP layers.
-                </div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.html
deleted file mode 100644
index 9a94cc47da..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.html
+++ /dev/null
@@ -1,93 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.3.�Configuration and Compilation</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="patching-dev-environment.html" title="2.8.5.2.�Patching">
-<link rel="next" href="package-splitting-dev-environment.html" title="2.8.5.4.�Package Splitting">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.3.�Configuration and Compilation">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="configuration-and-compilation-dev-environment"></a>2.8.5.3.�Configuration and Compilation</h4></div></div></div>
-<p>
-                After source code is patched, BitBake executes tasks that
-                configure and compile the source code:
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 450px"><td align="center"><img src="figures/configuration-compile-autoreconf.png" align="middle" width="630"></td></tr></table>
-<p>
-            </p>
-<p>
-                This step in the build process consists of three tasks:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                        <span class="emphasis"><em><a class="link" href="../ref-manual/ref-tasks-prepare_recipe_sysroot.html" target="_self"><code class="filename">do_prepare_recipe_sysroot</code></a>:</em></span>
-                        This task sets up the two sysroots in
-                        <code class="filename">${</code><a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a><code class="filename">}</code>
-                        (i.e. <code class="filename">recipe-sysroot</code> and
-                        <code class="filename">recipe-sysroot-native</code>) so that
-                        the sysroots contain the contents of the
-                        <a class="link" href="../ref-manual/ref-tasks-populate_sysroot.html" target="_self"><code class="filename">do_populate_sysroot</code></a>
-                        tasks of the recipes on which the recipe
-                        containing the tasks depends.
-                        A sysroot exists for both the target and for the native
-                        binaries, which run on the host system.
-                        </p></li>
-<li class="listitem">
-<p><span class="emphasis"><em><code class="filename">do_configure</code>:</em></span>
-                        This task configures the source by enabling and
-                        disabling any build-time and configuration options for
-                        the software being built.
-                        Configurations can come from the recipe itself as well
-                        as from an inherited class.
-                        Additionally, the software itself might configure itself
-                        depending on the target for which it is being built.
-                        </p>
-<p>The configurations handled by the
-                        <a class="link" href="../ref-manual/ref-tasks-configure.html" target="_self"><code class="filename">do_configure</code></a>
-                        task are specific
-                        to source code configuration for the source code
-                        being built by the recipe.</p>
-<p>If you are using the
-                        <a class="link" href="../ref-manual/ref-classes-autotools.html" target="_self"><code class="filename">autotools</code></a>
-                        class,
-                        you can add additional configuration options by using
-                        the
-                        <a class="link" href="../ref-manual/var-EXTRA_OECONF.html" target="_self"><code class="filename">EXTRA_OECONF</code></a>
-                        or
-                        <a class="link" href="../ref-manual/var-PACKAGECONFIG_CONFARGS.html" target="_self"><code class="filename">PACKAGECONFIG_CONFARGS</code></a>
-                        variables.
-                        For information on how this variable works within
-                        that class, see the
-                        <code class="filename">meta/classes/autotools.bbclass</code> file.
-                        </p>
-</li>
-<li class="listitem"><p><span class="emphasis"><em><code class="filename">do_compile</code>:</em></span>
-                        Once a configuration task has been satisfied, BitBake
-                        compiles the source using the
-                        <a class="link" href="../ref-manual/ref-tasks-compile.html" target="_self"><code class="filename">do_compile</code></a>
-                        task.
-                        Compilation occurs in the directory pointed to by the
-                        <a class="link" href="../ref-manual/var-B.html" target="_self"><code class="filename">B</code></a>
-                        variable.
-                        Realize that the <code class="filename">B</code> directory is, by
-                        default, the same as the
-                        <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a>
-                        directory.</p></li>
-<li class="listitem"><p><span class="emphasis"><em><code class="filename">do_install</code>:</em></span>
-                        Once compilation is done, BitBake executes the
-                        <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a>
-                        task.
-                        This task copies files from the <code class="filename">B</code>
-                        directory and places them in a holding area pointed to
-                        by the
-                        <a class="link" href="../ref-manual/var-D.html" target="_self"><code class="filename">D</code></a>
-                        variable.</p></li>
-</ul></div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html b/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html
deleted file mode 100644
index a1aef9119d..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html
+++ /dev/null
@@ -1,241 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.2.�Cross-Development Toolchain Generation</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="usingpoky-components-configuration.html" title="3.1.5.�Configuration">
-<link rel="next" href="shared-state-cache.html" title="3.3.�Shared State Cache">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2.�Cross-Development Toolchain Generation">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="cross-development-toolchain-generation"></a>3.2.�Cross-Development Toolchain Generation</h2></div></div></div>
-<p>
-            The Yocto Project does most of the work for you when it comes to
-            creating
-            <a class="link" href="../ref-manual/cross-development-toolchain.html" target="_self">cross-development toolchains</a>.
-            This section provides some technical background on how
-            cross-development toolchains are created and used.
-            For more information on toolchains, you can also see the
-            <a class="link" href="../sdk-manual/index.html" target="_self">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>
-            manual.
-        </p>
-<p>
-            In the Yocto Project development environment, cross-development
-            toolchains are used to build the image and applications that run
-            on the target hardware.
-            With just a few commands, the OpenEmbedded build system creates
-            these necessary toolchains for you.
-        </p>
-<p>
-            The following figure shows a high-level build environment regarding
-            toolchain construction and use.
-        </p>
-<p>
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 540px"><td align="center"><img src="figures/cross-development-toolchains.png" align="middle" width="720"></td></tr></table>
-<p>
-        </p>
-<p>
-            Most of the work occurs on the Build Host.
-            This is the machine used to build images and generally work within the
-            the Yocto Project environment.
-            When you run BitBake to create an image, the OpenEmbedded build system
-            uses the host <code class="filename">gcc</code> compiler to bootstrap a
-            cross-compiler named <code class="filename">gcc-cross</code>.
-            The <code class="filename">gcc-cross</code> compiler is what BitBake uses to
-            compile source files when creating the target image.
-            You can think of <code class="filename">gcc-cross</code> simply as an
-            automatically generated cross-compiler that is used internally within
-            BitBake only.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                The extensible SDK does not use
-                <code class="filename">gcc-cross-canadian</code> since this SDK
-                ships a copy of the OpenEmbedded build system and the sysroot
-                within it contains <code class="filename">gcc-cross</code>.
-            </div>
-<p>
-        </p>
-<p>
-            The chain of events that occurs when <code class="filename">gcc-cross</code> is
-            bootstrapped is as follows:
-            </p>
-<pre class="literallayout">
-     gcc -&gt; binutils-cross -&gt; gcc-cross-initial -&gt; linux-libc-headers -&gt; glibc-initial -&gt; glibc -&gt; gcc-cross -&gt; gcc-runtime
-            </pre>
-<p>
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    <code class="filename">gcc</code>:
-                    The build host's GNU Compiler Collection (GCC).
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">binutils-cross</code>:
-                    The bare minimum binary utilities needed in order to run
-                    the <code class="filename">gcc-cross-initial</code> phase of the
-                    bootstrap operation.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">gcc-cross-initial</code>:
-                    An early stage of the bootstrap process for creating
-                    the cross-compiler.
-                    This stage builds enough of the <code class="filename">gcc-cross</code>,
-                    the C library, and other pieces needed to finish building the
-                    final cross-compiler in later stages.
-                    This tool is a "native" package (i.e. it is designed to run on
-                    the build host).
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">linux-libc-headers</code>:
-                    Headers needed for the cross-compiler.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">glibc-initial</code>:
-                    An initial version of the Embedded GLIBC needed to bootstrap
-                    <code class="filename">glibc</code>.
-                    </p></li>
-<li class="listitem">
-<p>
-                    <code class="filename">gcc-cross</code>:
-                    The final stage of the bootstrap process for the
-                    cross-compiler.
-                    This stage results in the actual cross-compiler that
-                    BitBake uses when it builds an image for a targeted
-                    device.
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        If you are replacing this cross compiler toolchain
-                        with a custom version, you must replace
-                        <code class="filename">gcc-cross</code>.
-                    </div>
-<p>
-                    This tool is also a "native" package (i.e. it is
-                    designed to run on the build host).
-                    </p>
-</li>
-<li class="listitem"><p>
-                    <code class="filename">gcc-runtime</code>:
-                    Runtime libraries resulting from the toolchain bootstrapping
-                    process.
-                    This tool produces a binary that consists of the
-                    runtime libraries need for the targeted device.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            You can use the OpenEmbedded build system to build an installer for
-            the relocatable SDK used to develop applications.
-            When you run the installer, it installs the toolchain, which contains
-            the development tools (e.g., the
-            <code class="filename">gcc-cross-canadian</code>),
-            <code class="filename">binutils-cross-canadian</code>, and other
-            <code class="filename">nativesdk-*</code> tools,
-            which are tools native to the SDK (i.e. native to
-            <a class="link" href="../ref-manual/var-SDK_ARCH.html" target="_self"><code class="filename">SDK_ARCH</code></a>),
-            you need to cross-compile and test your software.
-            The figure shows the commands you use to easily build out this
-            toolchain.
-            This cross-development toolchain is built to execute on the
-            <a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>,
-            which might or might not be the same
-            machine as the Build Host.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                If your target architecture is supported by the Yocto Project,
-                you can take advantage of pre-built images that ship with the
-                Yocto Project and already contain cross-development toolchain
-                installers.
-            </div>
-<p>
-        </p>
-<p>
-            Here is the bootstrap process for the relocatable toolchain:
-            </p>
-<pre class="literallayout">
-     gcc -&gt; binutils-crosssdk -&gt; gcc-crosssdk-initial -&gt; linux-libc-headers -&gt;
-        glibc-initial -&gt; nativesdk-glibc -&gt; gcc-crosssdk -&gt; gcc-cross-canadian
-            </pre>
-<p>
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    <code class="filename">gcc</code>:
-                    The build host's GNU Compiler Collection (GCC).
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">binutils-crosssdk</code>:
-                    The bare minimum binary utilities needed in order to run
-                    the <code class="filename">gcc-crosssdk-initial</code> phase of the
-                    bootstrap operation.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">gcc-crosssdk-initial</code>:
-                    An early stage of the bootstrap process for creating
-                    the cross-compiler.
-                    This stage builds enough of the
-                    <code class="filename">gcc-crosssdk</code> and supporting pieces so that
-                    the final stage of the bootstrap process can produce the
-                    finished cross-compiler.
-                    This tool is a "native" binary that runs on the build host.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">linux-libc-headers</code>:
-                    Headers needed for the cross-compiler.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">glibc-initial</code>:
-                    An initial version of the Embedded GLIBC needed to bootstrap
-                    <code class="filename">nativesdk-glibc</code>.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">nativesdk-glibc</code>:
-                    The Embedded GLIBC needed to bootstrap the
-                    <code class="filename">gcc-crosssdk</code>.
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">gcc-crosssdk</code>:
-                    The final stage of the bootstrap process for the
-                    relocatable cross-compiler.
-                    The <code class="filename">gcc-crosssdk</code> is a transitory compiler
-                    and never leaves the build host.
-                    Its purpose is to help in the bootstrap process to create the
-                    eventual relocatable <code class="filename">gcc-cross-canadian</code>
-                    compiler, which is relocatable.
-                    This tool is also a "native" package (i.e. it is
-                    designed to run on the build host).
-                    </p></li>
-<li class="listitem"><p>
-                    <code class="filename">gcc-cross-canadian</code>:
-                    The final relocatable cross-compiler.
-                    When run on the
-                    <a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>,
-                    this tool
-                    produces executable code that runs on the target device.
-                    Only one cross-canadian compiler is produced per architecture
-                    since they can be targeted at different processor optimizations
-                    using configurations passed to the compiler through the
-                    compile commands.
-                    This circumvents the need for multiple compilers and thus
-                    reduces the size of the toolchains.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-            For information on advantages gained when building a
-            cross-development toolchain installer, see the
-            "<a class="link" href="../sdk-manual/sdk-building-an-sdk-installer.html" target="_self">Building an SDK Installer</a>"
-            section in the Yocto Project Application Development and the
-            Extensible Software Development Kit (eSDK) manual.
-        </div>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/development-concepts.html b/documentation/getting-started/eclipse/html/getting-started/development-concepts.html
deleted file mode 100644
index ccfb73189a..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/development-concepts.html
+++ /dev/null
@@ -1,66 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.�Development Concepts</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="recipe-syntax.html" title="2.7.�Recipe Syntax">
-<link rel="next" href="user-configuration.html" title="2.8.1.�User Configuration">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.�Development Concepts">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="development-concepts"></a>2.8.�Development Concepts</h2></div></div></div>
-<p>
-        This section takes a more detailed look inside the development
-        process.
-        The following diagram represents development at a high level.
-        The remainder of this chapter expands on the fundamental input, output,
-        process, and
-        <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>) blocks
-        that make up development in the Yocto Project environment.
-    </p>
-<p><a name="general-yocto-environment-figure"></a>
-        </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 383px"><td align="center"><img src="figures/yocto-environment-ref.png" align="middle" height="383"></td></tr></table>
-<p>
-    </p>
-<p>
-        In general, development consists of several functional areas:
-        </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><span class="emphasis"><em>User Configuration:</em></span>
-                Metadata you can use to control the build process.
-                </p></li>
-<li class="listitem"><p><span class="emphasis"><em>Metadata Layers:</em></span>
-                Various layers that provide software, machine, and
-                distro Metadata.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Source Files:</em></span>
-                Upstream releases, local projects, and SCMs.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Build System:</em></span>
-                Processes under the control of
-                <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a>.
-                This block expands on how BitBake fetches source, applies
-                patches, completes compilation, analyzes output for package
-                generation, creates and tests packages, generates images, and
-                generates cross-development tools.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Package Feeds:</em></span>
-                Directories containing output packages (RPM, DEB or IPK),
-                which are subsequently used in the construction of an image or
-                SDK, produced by the build system.
-                These feeds can also be copied and shared using a web server or
-                other means to facilitate extending or updating existing
-                images on devices at runtime if runtime package management is
-                enabled.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Images:</em></span>
-                Images produced by the development process.
-                </p></li>
-<li class="listitem"><p><span class="emphasis"><em>Application Development SDK:</em></span>
-                Cross-development tools that are produced along with an image
-                or separately with BitBake.</p></li>
-</ul></div>
-<p>
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/distro-layer.html b/documentation/getting-started/eclipse/html/getting-started/distro-layer.html
deleted file mode 100644
index da6da55986..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/distro-layer.html
+++ /dev/null
@@ -1,60 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.2.1.�Distro Layer</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2.�Metadata, Machine Configuration, and Policy Configuration">
-<link rel="prev" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2.�Metadata, Machine Configuration, and Policy Configuration">
-<link rel="next" href="bsp-layer.html" title="2.8.2.2.�BSP Layer">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.1.�Distro Layer">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="distro-layer"></a>2.8.2.1.�Distro Layer</h4></div></div></div>
-<p>
-                The distribution layer provides policy configurations for your
-                distribution.
-                Best practices dictate that you isolate these types of
-                configurations into their own layer.
-                Settings you provide in
-                <code class="filename">conf/distro/<em class="replaceable"><code>distro</code></em>.conf</code> override
-                similar
-                settings that BitBake finds in your
-                <code class="filename">conf/local.conf</code> file in the Build
-                Directory.
-            </p>
-<p>
-                The following list provides some explanation and references
-                for what you typically find in the distribution layer:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><span class="emphasis"><em>classes:</em></span>
-                        Class files (<code class="filename">.bbclass</code>) hold
-                        common functionality that can be shared among
-                        recipes in the distribution.
-                        When your recipes inherit a class, they take on the
-                        settings and functions for that class.
-                        You can read more about class files in the
-                        "<a class="link" href="../ref-manual/ref-classes.html" target="_self">Classes</a>"
-                        section of the Yocto Reference Manual.
-                        </p></li>
-<li class="listitem"><p><span class="emphasis"><em>conf:</em></span>
-                        This area holds configuration files for the
-                        layer (<code class="filename">conf/layer.conf</code>),
-                        the distribution
-                        (<code class="filename">conf/distro/<em class="replaceable"><code>distro</code></em>.conf</code>),
-                        and any distribution-wide include files.
-                        </p></li>
-<li class="listitem"><p><span class="emphasis"><em>recipes-*:</em></span>
-                        Recipes and append files that affect common
-                        functionality across the distribution.
-                        This area could include recipes and append files
-                        to add distribution-specific configuration,
-                        initialization scripts, custom image recipes,
-                        and so forth.</p></li>
-</ul></div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/enable-building.html b/documentation/getting-started/eclipse/html/getting-started/enable-building.html
deleted file mode 100644
index af70491f97..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/enable-building.html
+++ /dev/null
@@ -1,37 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.6.2.1.�Building</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="enabling-wayland-in-an-image.html" title="3.6.2.�Enabling Wayland in an Image">
-<link rel="prev" href="enabling-wayland-in-an-image.html" title="3.6.2.�Enabling Wayland in an Image">
-<link rel="next" href="enable-installation-in-an-image.html" title="3.6.2.2.�Installing">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.2.1.�Building">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="enable-building"></a>3.6.2.1.�Building</h4></div></div></div>
-<p>
-                    To cause Mesa to build the <code class="filename">wayland-egl</code>
-                    platform and Weston to build Wayland with Kernel Mode
-                    Setting
-                    (<a class="ulink" href="https://wiki.archlinux.org/index.php/Kernel_Mode_Setting" target="_self">KMS</a>)
-                    support, include the "wayland" flag in the
-                    <a class="link" href="../ref-manual/var-DISTRO_FEATURES.html" target="_self"><code class="filename">DISTRO_FEATURES</code></a>
-                    statement in your <code class="filename">local.conf</code> file:
-                    </p>
-<pre class="literallayout">
-     DISTRO_FEATURES_append = " wayland"
-                    </pre>
-<p>
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        If X11 has been enabled elsewhere, Weston will build
-                        Wayland with X11 support
-                    </div>
-<p>
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html b/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html
deleted file mode 100644
index 490f1d1036..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html
+++ /dev/null
@@ -1,27 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.6.2.2.�Installing</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="enabling-wayland-in-an-image.html" title="3.6.2.�Enabling Wayland in an Image">
-<link rel="prev" href="enable-building.html" title="3.6.2.1.�Building">
-<link rel="next" href="running-weston.html" title="3.6.3.�Running Weston">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.2.2.�Installing">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="enable-installation-in-an-image"></a>3.6.2.2.�Installing</h4></div></div></div>
-<p>
-                    To install the Wayland feature into an image, you must
-                    include the following
-                    <a class="link" href="../ref-manual/var-CORE_IMAGE_EXTRA_INSTALL.html" target="_self"><code class="filename">CORE_IMAGE_EXTRA_INSTALL</code></a>
-                    statement in your <code class="filename">local.conf</code> file:
-                    </p>
-<pre class="literallayout">
-     CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
-                    </pre>
-<p>
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html b/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html
deleted file mode 100644
index 1a31d0e6b1..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html
+++ /dev/null
@@ -1,91 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.2.�Enabling Commercially Licensed Recipes</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-licenses.html" title="3.7.�Licenses">
-<link rel="prev" href="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html" title="3.7.1.2.�Explanation of Syntax">
-<link rel="next" href="license-flag-matching.html" title="3.7.2.1.�License Flag Matching">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.2.�Enabling Commercially Licensed Recipes">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="enabling-commercially-licensed-recipes"></a>3.7.2.�Enabling Commercially Licensed Recipes</h3></div></div></div>
-<p>
-                By default, the OpenEmbedded build system disables
-                components that have commercial or other special licensing
-                requirements.
-                Such requirements are defined on a
-                recipe-by-recipe basis through the
-                <a class="link" href="../ref-manual/var-LICENSE_FLAGS.html" target="_self"><code class="filename">LICENSE_FLAGS</code></a>
-                variable definition in the affected recipe.
-                For instance, the
-                <code class="filename">poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
-                recipe contains the following statement:
-                </p>
-<pre class="literallayout">
-     LICENSE_FLAGS = "commercial"
-                </pre>
-<p>
-                Here is a slightly more complicated example that contains both
-                an explicit recipe name and version (after variable expansion):
-                </p>
-<pre class="literallayout">
-     LICENSE_FLAGS = "license_${PN}_${PV}"
-                </pre>
-<p>
-                    In order for a component restricted by a
-                <code class="filename">LICENSE_FLAGS</code> definition to be enabled and
-                included in an image, it needs to have a matching entry in the
-                global
-                    <a class="link" href="../ref-manual/var-LICENSE_FLAGS_WHITELIST.html" target="_self"><code class="filename">LICENSE_FLAGS_WHITELIST</code></a>
-                variable, which is a variable typically defined in your
-                <code class="filename">local.conf</code> file.
-                For example, to enable the
-                <code class="filename">poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
-                    package, you could add either the string
-                    "commercial_gst-plugins-ugly" or the more general string
-                    "commercial" to <code class="filename">LICENSE_FLAGS_WHITELIST</code>.
-                See the
-                "<a class="link" href="license-flag-matching.html" title="3.7.2.1.�License Flag Matching">License Flag Matching</a>"
-                section for a full
-                explanation of how <code class="filename">LICENSE_FLAGS</code> matching
-                works.
-                Here is the example:
-                </p>
-<pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
-                </pre>
-<p>
-                    Likewise, to additionally enable the package built from the
-                recipe containing
-                    <code class="filename">LICENSE_FLAGS = "license_${PN}_${PV}"</code>,
-                and assuming that the actual recipe name was
-                <code class="filename">emgd_1.10.bb</code>, the following string would
-                enable that package as well as the original
-                <code class="filename">gst-plugins-ugly</code> package:
-                </p>
-<pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
-                </pre>
-<p>
-                    As a convenience, you do not need to specify the complete
-                license string in the whitelist for every package.
-                You can use an abbreviated form, which consists
-                of just the first portion or portions of the license
-                string before the initial underscore character or characters.
-                A partial string will match any license that contains the
-                given string as the first portion of its license.
-                For example, the following whitelist string will also match
-                both of the packages previously mentioned as well as any other
-                packages that have licenses starting with "commercial" or
-                "license".
-                </p>
-<pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial license"
-                </pre>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html b/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html
deleted file mode 100644
index 6a325dbfd2..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html
+++ /dev/null
@@ -1,20 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.6.2.�Enabling Wayland in an Image</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="wayland.html" title="3.6.�Wayland">
-<link rel="prev" href="wayland-support.html" title="3.6.1.�Support">
-<link rel="next" href="enable-building.html" title="3.6.2.1.�Building">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.2.�Enabling Wayland in an Image">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="enabling-wayland-in-an-image"></a>3.6.2.�Enabling Wayland in an Image</h3></div></div></div>
-<p>
-                To enable Wayland, you need to enable it to be built and enable
-                it to be included in the image.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html b/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html
deleted file mode 100644
index 8354ad6730..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html
+++ /dev/null
@@ -1,91 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.5.�Fakeroot and Pseudo</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="automatically-added-runtime-dependencies.html" title="3.4.�Automatically Added Runtime Dependencies">
-<link rel="next" href="wayland.html" title="3.6.�Wayland">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.5.�Fakeroot and Pseudo">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fakeroot-and-pseudo"></a>3.5.�Fakeroot and Pseudo</h2></div></div></div>
-<p>
-            Some tasks are easier to implement when allowed to perform certain
-            operations that are normally reserved for the root user (e.g.
-            <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a>,
-            <a class="link" href="../ref-manual/ref-tasks-package_write_deb.html" target="_self"><code class="filename">do_package_write*</code></a>,
-            <a class="link" href="../ref-manual/ref-tasks-rootfs.html" target="_self"><code class="filename">do_rootfs</code></a>,
-            and
-            <a class="link" href="../ref-manual/ref-tasks-image.html" target="_self"><code class="filename">do_image*</code></a>).
-            For example, the <code class="filename">do_install</code> task benefits
-            from being able to set the UID and GID of installed files to
-            arbitrary values.
-        </p>
-<p>
-            One approach to allowing tasks to perform root-only operations
-            would be to require BitBake to run as root.
-            However, this method is cumbersome and has security issues.
-            The approach that is actually used is to run tasks that benefit
-            from root privileges in a "fake" root environment.
-            Within this environment, the task and its child processes believe
-            that they are running as the root user, and see an internally
-            consistent view of the filesystem.
-            As long as generating the final output (e.g. a package or an image)
-            does not require root privileges, the fact that some earlier
-            steps ran in a fake root environment does not cause problems.
-        </p>
-<p>
-            The capability to run tasks in a fake root environment is known as
-            "<a class="ulink" href="http://man.he.net/man1/fakeroot" target="_self">fakeroot</a>",
-            which is derived from the BitBake keyword/variable
-            flag that requests a fake root environment for a task.
-        </p>
-<p>
-            In the OpenEmbedded build system, the program that implements
-            fakeroot is known as Pseudo.
-            Pseudo overrides system calls by using the environment variable
-            <code class="filename">LD_PRELOAD</code>, which results in the illusion
-            of running as root.
-            To keep track of "fake" file ownership and permissions resulting
-            from operations that require root permissions, Pseudo uses
-            an SQLite 3 database.
-            This database is stored in
-            <code class="filename">${</code><a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a><code class="filename">}/pseudo/files.db</code>
-            for individual recipes.
-            Storing the database in a file as opposed to in memory
-            gives persistence between tasks and builds, which is not
-            accomplished using fakeroot.
-            </p>
-<div class="note" title="Caution" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Caution</h3>
-                If you add your own task that manipulates the same files or
-                directories as a fakeroot task, then that task also needs to
-                run under fakeroot.
-                Otherwise, the task cannot run root-only operations, and
-                cannot see the fake file ownership and permissions set by the
-                other task.
-                You need to also add a dependency on
-                <code class="filename">virtual/fakeroot-native:do_populate_sysroot</code>,
-                giving the following:
-                <pre class="literallayout">
-       fakeroot do_mytask () {
-           ...
-       }
-       do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"
-                </pre>
-</div>
-<p>
-            For more information, see the
-            <a class="link" href="../bitbake-user-manual/var-FAKEROOT.html" target="_self"><code class="filename">FAKEROOT*</code></a>
-            variables in the BitBake User Manual.
-            You can also reference the
-            "<a class="ulink" href="http://www.ibm.com/developerworks/opensource/library/os-aapseudo1/index.html" target="_self">Pseudo</a>"
-            and
-            "<a class="ulink" href="https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot" target="_self">Why Not Fakeroot?</a>"
-            articles for background information on Pseudo.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png b/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png
deleted file mode 100644
index 8264410504..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png b/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png
deleted file mode 100644
index 04f2794ea9..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png b/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png
deleted file mode 100644
index a07464f04c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png b/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png
deleted file mode 100644
index d36670a198..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png b/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png
deleted file mode 100644
index f38b078ab7..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png b/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png
deleted file mode 100644
index e401330a12..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png b/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png
deleted file mode 100644
index 71a48dc6f4..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/images.png b/documentation/getting-started/eclipse/html/getting-started/figures/images.png
deleted file mode 100644
index d99eac1fbf..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/images.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png b/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png
deleted file mode 100644
index 96303b8781..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png b/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png
deleted file mode 100644
index 0a4f2e74f3..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png b/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png
deleted file mode 100644
index 37c9c32506..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/patching.png b/documentation/getting-started/eclipse/html/getting-started/figures/patching.png
deleted file mode 100644
index 8ecd018502..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/patching.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png b/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png
deleted file mode 100755
index adbe1f4acf..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png b/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png
deleted file mode 100644
index 5c36b7548b..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png b/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png
deleted file mode 100644
index 26aefb50c2..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png b/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png
deleted file mode 100644
index f7515058ef..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png b/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png
deleted file mode 100644
index 603300b6d2..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png b/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png
deleted file mode 100644
index c298401fc3..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png b/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png
deleted file mode 100644
index 650c6c8030..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png b/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png
deleted file mode 100644
index 5770be6883..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png
+++ /dev/null
diff --git a/documentation/getting-started/eclipse/html/getting-started/git.html b/documentation/getting-started/eclipse/html/getting-started/git.html
deleted file mode 100644
index 7e652a4efa..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/git.html
+++ /dev/null
@@ -1,51 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.4.�Git</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="workflows.html" title="2.3.�Workflows">
-<link rel="next" href="repositories-tags-and-branches.html" title="2.4.1.�Repositories, Tags, and Branches">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.�Git">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="git"></a>2.4.�Git</h2></div></div></div>
-<p>
-        The Yocto Project makes extensive use of Git, which is a
-        free, open source distributed version control system.
-        Git supports distributed development, non-linear development,
-        and can handle large projects.
-        It is best that you have some fundamental understanding
-        of how Git tracks projects and how to work with Git if
-        you are going to use the Yocto Project for development.
-        This section provides a quick overview of how Git works and
-        provides you with a summary of some essential Git commands.
-        </p>
-<div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Notes</h3>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    For more information on Git, see
-                    <a class="ulink" href="http://git-scm.com/documentation" target="_self">http://git-scm.com/documentation</a>.
-                    </p></li>
-<li class="listitem"><p>
-                    If you need to download Git, it is recommended that you add
-                    Git to your system through your distribution's "software
-                    store" (e.g. for Ubuntu, use the Ubuntu Software feature).
-                    For the Git download page, see
-                    <a class="ulink" href="http://git-scm.com/download" target="_self">http://git-scm.com/download</a>.
-                    </p></li>
-<li class="listitem"><p>
-                    For examples beyond the limited few in this section on how
-                    to use Git with the Yocto Project, see the
-                    "<a class="link" href="../dev-manual/working-with-yocto-project-source-files.html" target="_self">Working With Yocto Project Source Files</a>"
-                    section in the Yocto Project Development Tasks Manual.
-                    </p></li>
-</ul></div>
-</div>
-<p>
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html
deleted file mode 100644
index 9f682d082c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html
+++ /dev/null
@@ -1,178 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.5.�Image Generation</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="package-splitting-dev-environment.html" title="2.8.5.4.�Package Splitting">
-<link rel="next" href="sdk-generation-dev-environment.html" title="2.8.5.6.�SDK Generation">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.5.�Image Generation">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="image-generation-dev-environment"></a>2.8.5.5.�Image Generation</h4></div></div></div>
-<p>
-                Once packages are split and stored in the Package Feeds area,
-                the OpenEmbedded build system uses BitBake to generate the
-                root filesystem image:
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 630px"><td align="center"><img src="figures/image-generation.png" align="middle" width="540"></td></tr></table>
-<p>
-            </p>
-<p>
-                The image generation process consists of several stages and
-                depends on several tasks and variables.
-                The
-                <a class="link" href="../ref-manual/ref-tasks-rootfs.html" target="_self"><code class="filename">do_rootfs</code></a>
-                task creates the root filesystem (file and directory structure)
-                for an image.
-                This task uses several key variables to help create the list
-                of packages to actually install:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><a class="link" href="../ref-manual/var-IMAGE_INSTALL.html" target="_self"><code class="filename">IMAGE_INSTALL</code></a>:
-                        Lists out the base set of packages to install from
-                        the Package Feeds area.</p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_EXCLUDE.html" target="_self"><code class="filename">PACKAGE_EXCLUDE</code></a>:
-                        Specifies packages that should not be installed.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-IMAGE_FEATURES.html" target="_self"><code class="filename">IMAGE_FEATURES</code></a>:
-                        Specifies features to include in the image.
-                        Most of these features map to additional packages for
-                        installation.</p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_CLASSES.html" target="_self"><code class="filename">PACKAGE_CLASSES</code></a>:
-                        Specifies the package backend to use and consequently
-                        helps determine where to locate packages within the
-                        Package Feeds area.</p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-IMAGE_LINGUAS.html" target="_self"><code class="filename">IMAGE_LINGUAS</code></a>:
-                        Determines the language(s) for which additional
-                        language support packages are installed.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_INSTALL.html" target="_self"><code class="filename">PACKAGE_INSTALL</code></a>:
-                        The final list of packages passed to the package manager
-                        for installation into the image.
-                        </p></li>
-</ul></div>
-<p>
-            </p>
-<p>
-                With
-                <a class="link" href="../ref-manual/var-IMAGE_ROOTFS.html" target="_self"><code class="filename">IMAGE_ROOTFS</code></a>
-                pointing to the location of the filesystem under construction and
-                the <code class="filename">PACKAGE_INSTALL</code> variable providing the
-                final list of packages to install, the root file system is
-                created.
-            </p>
-<p>
-                Package installation is under control of the package manager
-                (e.g. dnf/rpm, opkg, or apt/dpkg) regardless of whether or
-                not package management is enabled for the target.
-                At the end of the process, if package management is not
-                enabled for the target, the package manager's data files
-                are deleted from the root filesystem.
-                As part of the final stage of package installation, postinstall
-                scripts that are part of the packages are run.
-                Any scripts that fail to run
-                on the build host are run on the target when the target system
-                is first booted.
-                If you are using a
-                <a class="link" href="../dev-manual/creating-a-read-only-root-filesystem.html" target="_self">read-only root filesystem</a>,
-                all the post installation scripts must succeed during the
-                package installation phase since the root filesystem is
-                read-only.
-            </p>
-<p>
-                The final stages of the <code class="filename">do_rootfs</code> task
-                handle post processing.
-                Post processing includes creation of a manifest file and
-                optimizations.
-            </p>
-<p>
-                The manifest file (<code class="filename">.manifest</code>) resides
-                in the same directory as the root filesystem image.
-                This file lists out, line-by-line, the installed packages.
-                The manifest file is useful for the
-                <a class="link" href="../ref-manual/ref-classes-testimage*.html" target="_self"><code class="filename">testimage</code></a>
-                class, for example, to determine whether or not to run
-                specific tests.
-                See the
-                <a class="link" href="../ref-manual/var-IMAGE_MANIFEST.html" target="_self"><code class="filename">IMAGE_MANIFEST</code></a>
-                variable for additional information.
-            </p>
-<p>
-                Optimizing processes run across the image include
-                <code class="filename">mklibs</code>, <code class="filename">prelink</code>,
-                and any other post-processing commands as defined by the
-                <a class="link" href="../ref-manual/var-ROOTFS_POSTPROCESS_COMMAND.html" target="_self"><code class="filename">ROOTFS_POSTPROCESS_COMMAND</code></a>
-                variable.
-                The <code class="filename">mklibs</code> process optimizes the size
-                of the libraries, while the
-                <code class="filename">prelink</code> process optimizes the dynamic
-                linking of shared libraries to reduce start up time of
-                executables.
-            </p>
-<p>
-                After the root filesystem is built, processing begins on
-                the image through the
-                <a class="link" href="../ref-manual/ref-tasks-image.html" target="_self"><code class="filename">do_image</code></a>
-                task.
-                The build system runs any pre-processing commands as defined
-                by the
-                <a class="link" href="../ref-manual/var-IMAGE_PREPROCESS_COMMAND.html" target="_self"><code class="filename">IMAGE_PREPROCESS_COMMAND</code></a>
-                variable.
-                This variable specifies a list of functions to call before
-                the OpenEmbedded build system creates the final image output
-                files.
-            </p>
-<p>
-                The OpenEmbedded build system dynamically creates
-                <code class="filename">do_image_*</code> tasks as needed, based
-                on the image types specified in the
-                <a class="link" href="../ref-manual/var-IMAGE_FSTYPES.html" target="_self"><code class="filename">IMAGE_FSTYPES</code></a>
-                variable.
-                The process turns everything into an image file or a set of
-                image files and compresses the root filesystem image to reduce
-                the overall size of the image.
-                The formats used for the root filesystem depend on the
-                <code class="filename">IMAGE_FSTYPES</code> variable.
-            </p>
-<p>
-                As an example, a dynamically created task when creating a
-                particular image <em class="replaceable"><code>type</code></em> would take the
-                following form:
-                </p>
-<pre class="literallayout">
-     do_image_<em class="replaceable"><code>type</code></em>[depends]
-                </pre>
-<p>
-                So, if the <em class="replaceable"><code>type</code></em> as specified by the
-                <code class="filename">IMAGE_FSTYPES</code> were
-                <code class="filename">ext4</code>, the dynamically generated task
-                would be as follows:
-                </p>
-<pre class="literallayout">
-     do_image_ext4[depends]
-                </pre>
-<p>
-            </p>
-<p>
-                The final task involved in image creation is the
-                <a class="link" href="../ref-manual/ref-tasks-image-complete.html" target="_self"><code class="filename">do_image_complete</code></a>
-                task.
-                This task completes the image by applying any image
-                post processing as defined through the
-                <a class="link" href="../ref-manual/var-IMAGE_POSTPROCESS_COMMAND.html" target="_self"><code class="filename">IMAGE_POSTPROCESS_COMMAND</code></a>
-                variable.
-                The variable specifies a list of functions to call once the
-                OpenEmbedded build system has created the final image output
-                files.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                The entire image generation process is run under Pseudo.
-                Running under Pseudo ensures that the files in the root
-                filesystem have correct ownership.
-            </div>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html
deleted file mode 100644
index 2561f1f4a6..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html
+++ /dev/null
@@ -1,99 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.6.�Images</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="setscene-tasks-and-shared-state.html" title="2.8.5.8.�Setscene Tasks and Shared State">
-<link rel="next" href="sdk-dev-environment.html" title="2.8.7.�Application Development SDK">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.6.�Images">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="images-dev-environment"></a>2.8.6.�Images</h3></div></div></div>
-<p>
-            The images produced by the OpenEmbedded build system
-            are compressed forms of the
-            root filesystem that are ready to boot on a target device.
-            You can see from the
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>
-            that BitBake output, in part, consists of images.
-            This section is going to look more closely at this output:
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="495"><tr style="height: 495px"><td align="center"><img src="figures/images.png" align="middle" width="495"></td></tr></table>
-<p>
-        </p>
-<p>
-            For a list of example images that the Yocto Project provides,
-            see the
-            "<a class="link" href="../ref-manual/ref-images.html" target="_self">Images</a>"
-            chapter in the Yocto Project Reference Manual.
-        </p>
-<p>
-            Images are written out to the
-            <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>
-            inside the
-            <code class="filename">tmp/deploy/images/<em class="replaceable"><code>machine</code></em>/</code>
-            folder as shown in the figure.
-            This folder contains any files expected to be loaded on the
-            target device.
-            The
-            <a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>
-            variable points to the <code class="filename">deploy</code> directory,
-            while the
-            <a class="link" href="../ref-manual/var-DEPLOY_DIR_IMAGE.html" target="_self"><code class="filename">DEPLOY_DIR_IMAGE</code></a>
-            variable points to the appropriate directory containing images for
-            the current configuration.
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><code class="filename"><em class="replaceable"><code>kernel-image</code></em></code>:
-                    A kernel binary file.
-                    The
-                    <a class="link" href="../ref-manual/var-KERNEL_IMAGETYPE.html" target="_self"><code class="filename">KERNEL_IMAGETYPE</code></a>
-                    variable setting determines the naming scheme for the
-                    kernel image file.
-                    Depending on that variable, the file could begin with
-                    a variety of naming strings.
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple image files for the
-                    machine.</p></li>
-<li class="listitem"><p><code class="filename"><em class="replaceable"><code>root-filesystem-image</code></em></code>:
-                    Root filesystems for the target device (e.g.
-                    <code class="filename">*.ext3</code> or <code class="filename">*.bz2</code>
-                    files).
-                    The
-                    <a class="link" href="../ref-manual/var-IMAGE_FSTYPES.html" target="_self"><code class="filename">IMAGE_FSTYPES</code></a>
-                    variable setting determines the root filesystem image
-                    type.
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple root filesystems for the
-                    machine.</p></li>
-<li class="listitem"><p><code class="filename"><em class="replaceable"><code>kernel-modules</code></em></code>:
-                    Tarballs that contain all the modules built for the kernel.
-                    Kernel module tarballs exist for legacy purposes and
-                    can be suppressed by setting the
-                    <a class="link" href="../ref-manual/var-MODULE_TARBALL_DEPLOY.html" target="_self"><code class="filename">MODULE_TARBALL_DEPLOY</code></a>
-                    variable to "0".
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple kernel module tarballs
-                    for the machine.</p></li>
-<li class="listitem"><p><code class="filename"><em class="replaceable"><code>bootloaders</code></em></code>:
-                    Bootloaders supporting the image, if applicable to the
-                    target machine.
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple bootloaders for the
-                    machine.</p></li>
-<li class="listitem"><p><code class="filename"><em class="replaceable"><code>symlinks</code></em></code>:
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    folder contains
-                    a symbolic link that points to the most recently built file
-                    for each machine.
-                    These links might be useful for external scripts that
-                    need to obtain the latest version of each file.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/index.html b/documentation/getting-started/eclipse/html/getting-started/index.html
deleted file mode 100644
index 94826ce0c6..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/index.html
+++ /dev/null
@@ -1,154 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Getting Started With Yocto Project</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="next" href="overview-manual-intro.html" title="Chapter�1.�The Yocto Project Overview Manual">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div lang="en" class="book" title="Getting Started With Yocto Project">
-<div class="titlepage">
-<div>
-<div><h1 class="title">
-<a name="getting-started-manual"></a>
-            Getting Started With Yocto Project
-        </h1></div>
-<div><div class="authorgroup">
-            <div class="author">
-<h3 class="author">
-<span class="firstname">Scott</span> <span class="surname">Rifenbark</span>
-</h3>
-<div class="affiliation">
-                    <span class="orgname">Scotty's Documentation Services, INC<br></span>
-                </div>
-<code class="email">&lt;<a class="email" href="mailto:srifenbark@gmail.com">srifenbark@gmail.com</a>&gt;</code>
-</div>
-        </div></div>
-<div><p class="copyright">Copyright � 2010-2018 Linux Foundation</p></div>
-<div><div class="legalnotice" title="Legal Notice">
-<a name="idm45823191546992"></a>
-      <p>
-          Permission is granted to copy, distribute and/or modify this document under
-          the terms of the <a class="ulink" href="http://creativecommons.org/licenses/by-sa/2.0/uk/" target="_self">
-          Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</a> as published by
-          Creative Commons.
-      </p>
-           <div class="note" title="Manual Notes" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Manual Notes</h3>
-               <div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                       This version of the
-                       <span class="emphasis"><em>Yocto Project Overview Manual</em></span>
-                       is for the 2.5 release of the
-                       Yocto Project.
-                       To be sure you have the latest version of the manual
-                       for this release, use the manual from the
-                       <a class="ulink" href="http://www.yoctoproject.org/documentation" target="_self">Yocto Project documentation page</a>.
-                       </p></li>
-<li class="listitem"><p>
-                       For manuals associated with other releases of the Yocto
-                       Project, go to the
-                       <a class="ulink" href="http://www.yoctoproject.org/documentation" target="_self">Yocto Project documentation page</a>
-                       and use the drop-down "Active Releases" button
-                       and choose the manual associated with the desired
-                       Yocto Project.
-                       </p></li>
-<li class="listitem"><p>
-                        To report any inaccuracies or problems with this
-                        manual, send an email to the Yocto Project
-                        discussion group at
-                        <code class="filename">yocto@yoctoproject.com</code> or log into
-                        the freenode <code class="filename">#yocto</code> channel.
-                        </p></li>
-</ul></div>
-           </div>
-    </div></div>
-<div><div class="revhistory"><table border="1" width="100%" summary="Revision history">
-<tr><th align="left" valign="top" colspan="2"><b>Revision History</b></th></tr>
-            <tr>
-<td align="left">Revision 2.5</td>
-<td align="left">April 2018</td>
-</tr>
-<tr><td align="left" colspan="2">The initial document released with the Yocto Project 2.5 Release.</td></tr>
-        </table></div></div>
-</div>
-<hr>
-</div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="chapter"><a href="overview-manual-intro.html">1. The Yocto Project Overview Manual</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="overview-welcome.html">1.1. Welcome</a></span></dt>
-<dt><span class="section"><a href="overview-other-information.html">1.2. Other Information</a></span></dt>
-</dl></dd>
-<dt><span class="chapter"><a href="overview-development-environment.html">2. The Yocto Project Development Environment</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="yp-intro.html">2.1. Introduction</a></span></dt>
-<dt><span class="section"><a href="open-source-philosophy.html">2.2. Open Source Philosophy</a></span></dt>
-<dt><span class="section"><a href="workflows.html">2.3. Workflows</a></span></dt>
-<dt><span class="section"><a href="git.html">2.4. Git</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="repositories-tags-and-branches.html">2.4.1. Repositories, Tags, and Branches</a></span></dt>
-<dt><span class="section"><a href="basic-commands.html">2.4.2. Basic Commands</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="yocto-project-repositories.html">2.5. Yocto Project Source Repositories</a></span></dt>
-<dt><span class="section"><a href="licensing.html">2.6. Licensing</a></span></dt>
-<dt><span class="section"><a href="recipe-syntax.html">2.7. Recipe Syntax</a></span></dt>
-<dt><span class="section"><a href="development-concepts.html">2.8. Development Concepts</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="user-configuration.html">2.8.1. User Configuration</a></span></dt>
-<dt><span class="section"><a href="metadata-machine-configuration-and-policy-configuration.html">2.8.2. Metadata, Machine Configuration, and Policy Configuration</a></span></dt>
-<dt><span class="section"><a href="sources-dev-environment.html">2.8.3. Sources</a></span></dt>
-<dt><span class="section"><a href="package-feeds-dev-environment.html">2.8.4. Package Feeds</a></span></dt>
-<dt><span class="section"><a href="bitbake-dev-environment.html">2.8.5. BitBake</a></span></dt>
-<dt><span class="section"><a href="images-dev-environment.html">2.8.6. Images</a></span></dt>
-<dt><span class="section"><a href="sdk-dev-environment.html">2.8.7. Application Development SDK</a></span></dt>
-</dl></dd>
-</dl></dd>
-<dt><span class="chapter"><a href="overview-concepts.html">3. Yocto Project Concepts</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="yocto-project-components.html">3.1. Yocto Project Components</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="usingpoky-components-bitbake.html">3.1.1. BitBake</a></span></dt>
-<dt><span class="section"><a href="usingpoky-components-metadata.html">3.1.2. Metadata (Recipes)</a></span></dt>
-<dt><span class="section"><a href="metadata-virtual-providers.html">3.1.3. Metadata (Virtual Providers)</a></span></dt>
-<dt><span class="section"><a href="usingpoky-components-classes.html">3.1.4. Classes</a></span></dt>
-<dt><span class="section"><a href="usingpoky-components-configuration.html">3.1.5. Configuration</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="cross-development-toolchain-generation.html">3.2. Cross-Development Toolchain Generation</a></span></dt>
-<dt><span class="section"><a href="shared-state-cache.html">3.3. Shared State Cache</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="overall-architecture.html">3.3.1. Overall Architecture</a></span></dt>
-<dt><span class="section"><a href="overview-checksums.html">3.3.2. Checksums (Signatures)</a></span></dt>
-<dt><span class="section"><a href="shared-state.html">3.3.3. Shared State</a></span></dt>
-<dt><span class="section"><a href="tips-and-tricks.html">3.3.4. Tips and Tricks</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="automatically-added-runtime-dependencies.html">3.4. Automatically Added Runtime Dependencies</a></span></dt>
-<dt><span class="section"><a href="fakeroot-and-pseudo.html">3.5. Fakeroot and Pseudo</a></span></dt>
-<dt><span class="section"><a href="wayland.html">3.6. Wayland</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="wayland-support.html">3.6.1. Support</a></span></dt>
-<dt><span class="section"><a href="enabling-wayland-in-an-image.html">3.6.2. Enabling Wayland in an Image</a></span></dt>
-<dt><span class="section"><a href="running-weston.html">3.6.3. Running Weston</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="overview-licenses.html">3.7. Licenses</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="usingpoky-configuring-LIC_FILES_CHKSUM.html">3.7.1. Tracking License Changes</a></span></dt>
-<dt><span class="section"><a href="enabling-commercially-licensed-recipes.html">3.7.2. Enabling Commercially Licensed Recipes</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="x32.html">3.8. x32 psABI</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-    
-
-    
-
-    
-
-    
-
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/index.xml b/documentation/getting-started/eclipse/html/getting-started/index.xml
deleted file mode 100644
index 9edb4b92ac..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/index.xml
+++ /dev/null
@@ -1,2 +0,0 @@
-<?xml version="1.0" encoding="utf-8" standalone="no"?>
-<index/>
diff --git a/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html b/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html
deleted file mode 100644
index ef4a2aac5e..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html
+++ /dev/null
@@ -1,77 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.4.2.�Invalidating Shared State</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="tips-and-tricks.html" title="3.3.4.�Tips and Tricks">
-<link rel="prev" href="overview-debugging.html" title="3.3.4.1.�Debugging">
-<link rel="next" href="automatically-added-runtime-dependencies.html" title="3.4.�Automatically Added Runtime Dependencies">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.4.2.�Invalidating Shared State">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="invalidating-shared-state"></a>3.3.4.2.�Invalidating Shared State</h4></div></div></div>
-<p>
-                    The OpenEmbedded build system uses checksums and shared
-                    state cache to avoid unnecessarily rebuilding tasks.
-                    Collectively, this scheme is known as "shared state code."
-                </p>
-<p>
-                    As with all schemes, this one has some drawbacks.
-                    It is possible that you could make implicit changes to your
-                    code that the checksum calculations do not take into
-                    account.
-                    These implicit changes affect a task's output but do not
-                    trigger the shared state code into rebuilding a recipe.
-                    Consider an example during which a tool changes its output.
-                    Assume that the output of <code class="filename">rpmdeps</code>
-                    changes.
-                    The result of the change should be that all the
-                    <code class="filename">package</code> and
-                    <code class="filename">package_write_rpm</code> shared state cache
-                    items become invalid.
-                    However, because the change to the output is
-                    external to the code and therefore implicit,
-                    the associated shared state cache items do not become
-                    invalidated.
-                    In this case, the build process uses the cached items
-                    rather than running the task again.
-                    Obviously, these types of implicit changes can cause
-                    problems.
-                </p>
-<p>
-                    To avoid these problems during the build, you need to
-                    understand the effects of any changes you make.
-                    Realize that changes you make directly to a function
-                    are automatically factored into the checksum calculation.
-                    Thus, these explicit changes invalidate the associated
-                    area of shared state cache.
-                    However, you need to be aware of any implicit changes that
-                    are not obvious changes to the code and could affect
-                    the output of a given task.
-                </p>
-<p>
-                    When you identify an implicit change, you can easily
-                    take steps to invalidate the cache and force the tasks
-                    to run.
-                    The steps you can take are as simple as changing a
-                    function's comments in the source code.
-                    For example, to invalidate package shared state files,
-                    change the comment statements of
-                    <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>
-                    or the comments of one of the functions it calls.
-                    Even though the change is purely cosmetic, it causes the
-                    checksum to be recalculated and forces the OpenEmbedded
-                    build system to run the task again.
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        For an example of a commit that makes a cosmetic
-                        change to invalidate shared state, see this
-                        <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54" target="_self">commit</a>.
-                    </div>
-<p>
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html b/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html
deleted file mode 100644
index 1e08bafad1..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html
+++ /dev/null
@@ -1,126 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.2.1.�License Flag Matching</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="enabling-commercially-licensed-recipes.html" title="3.7.2.�Enabling Commercially Licensed Recipes">
-<link rel="prev" href="enabling-commercially-licensed-recipes.html" title="3.7.2.�Enabling Commercially Licensed Recipes">
-<link rel="next" href="other-variables-related-to-commercial-licenses.html" title="3.7.2.2.�Other Variables Related to Commercial Licenses">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.2.1.�License Flag Matching">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="license-flag-matching"></a>3.7.2.1.�License Flag Matching</h4></div></div></div>
-<p>
-                            License flag matching allows you to control what recipes
-                    the OpenEmbedded build system includes in the build.
-                    Fundamentally, the build system attempts to match
-                    <a class="link" href="../ref-manual/var-LICENSE_FLAGS.html" target="_self"><code class="filename">LICENSE_FLAGS</code></a>
-                    strings found in recipes against
-                    <a class="link" href="../ref-manual/var-LICENSE_FLAGS_WHITELIST.html" target="_self"><code class="filename">LICENSE_FLAGS_WHITELIST</code></a>
-                    strings found in the whitelist.
-                    A match causes the build system to include a recipe in the
-                    build, while failure to find a match causes the build
-                    system to exclude a recipe.
-                </p>
-<p>
-                    In general, license flag matching is simple.
-                    However, understanding some concepts will help you
-                    correctly and effectively use matching.
-                </p>
-<p>
-                    Before a flag
-                    defined by a particular recipe is tested against the
-                    contents of the whitelist, the expanded string
-                    <code class="filename">_${PN}</code> is appended to the flag.
-                    This expansion makes each
-                    <code class="filename">LICENSE_FLAGS</code> value recipe-specific.
-                    After expansion, the string is then matched against the
-                    whitelist.
-                    Thus, specifying
-                    <code class="filename">LICENSE_FLAGS = "commercial"</code>
-                    in recipe "foo", for example, results in the string
-                    <code class="filename">"commercial_foo"</code>.
-                    And, to create a match, that string must appear in the
-                    whitelist.
-                </p>
-<p>
-                    Judicious use of the <code class="filename">LICENSE_FLAGS</code>
-                    strings and the contents of the
-                    <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable
-                    allows you a lot of flexibility for including or excluding
-                    recipes based on licensing.
-                    For example, you can broaden the matching capabilities by
-                    using license flags string subsets in the whitelist.
-                    </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                        When using a string subset, be sure to use the part of
-                        the expanded string that precedes the appended
-                        underscore character (e.g.
-                        <code class="filename">usethispart_1.3</code>,
-                        <code class="filename">usethispart_1.4</code>, and so forth).
-                    </div>
-<p>
-                    For example, simply specifying the string "commercial" in
-                    the whitelist matches any expanded
-                    <code class="filename">LICENSE_FLAGS</code> definition that starts
-                    with the string "commercial" such as "commercial_foo" and
-                    "commercial_bar", which are the strings the build system
-                    automatically generates for hypothetical recipes named
-                    "foo" and "bar" assuming those recipes simply specify the
-                    following:
-                    </p>
-<pre class="literallayout">
-     LICENSE_FLAGS = "commercial"
-                    </pre>
-<p>
-                    Thus, you can choose to exhaustively
-                    enumerate each license flag in the whitelist and
-                    allow only specific recipes into the image, or
-                    you can use a string subset that causes a broader range of
-                    matches to allow a range of recipes into the image.
-                </p>
-<p>
-                    This scheme works even if the
-                    <code class="filename">LICENSE_FLAGS</code> string already
-                    has <code class="filename">_${PN}</code> appended.
-                    For example, the build system turns the license flag
-                    "commercial_1.2_foo" into "commercial_1.2_foo_foo" and
-                    would match both the general "commercial" and the specific
-                    "commercial_1.2_foo" strings found in the whitelist, as
-                    expected.
-                </p>
-<p>
-                    Here are some other scenarios:
-                    </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                            You can specify a versioned string in the recipe
-                            such as "commercial_foo_1.2" in a "foo" recipe.
-                            The build system expands this string to
-                            "commercial_foo_1.2_foo".
-                            Combine this license flag with a whitelist that has
-                            the string "commercial" and you match the flag
-                            along with any other flag that starts with the
-                            string "commercial".
-                            </p></li>
-<li class="listitem"><p>
-                            Under the same circumstances, you can use
-                            "commercial_foo" in the whitelist and the build
-                            system not only matches "commercial_foo_1.2" but
-                            also matches any license flag with the string
-                            "commercial_foo", regardless of the version.
-                            </p></li>
-<li class="listitem"><p>
-                            You can be very specific and use both the
-                            package and version parts in the whitelist (e.g.
-                            "commercial_foo_1.2") to specifically match a
-                            versioned recipe.
-                            </p></li>
-</ul></div>
-<p>
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/licensing.html b/documentation/getting-started/eclipse/html/getting-started/licensing.html
deleted file mode 100644
index ade868705c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/licensing.html
+++ /dev/null
@@ -1,91 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.6.�Licensing</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="yocto-project-repositories.html" title="2.5.�Yocto Project Source Repositories">
-<link rel="next" href="recipe-syntax.html" title="2.7.�Recipe Syntax">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.6.�Licensing">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="licensing"></a>2.6.�Licensing</h2></div></div></div>
-<p>
-        Because open source projects are open to the public, they have
-        different licensing structures in place.
-        License evolution for both Open Source and Free Software has an
-        interesting history.
-        If you are interested in this history, you can find basic information
-        here:
-        </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                <a class="ulink" href="http://en.wikipedia.org/wiki/Open-source_license" target="_self">Open source license history</a>
-                </p></li>
-<li class="listitem"><p>
-                <a class="ulink" href="http://en.wikipedia.org/wiki/Free_software_license" target="_self">Free software license history</a>
-                </p></li>
-</ul></div>
-<p>
-    </p>
-<p>
-        In general, the Yocto Project is broadly licensed under the
-        Massachusetts Institute of Technology (MIT) License.
-        MIT licensing permits the reuse of software within proprietary
-        software as long as the license is distributed with that software.
-        MIT is also compatible with the GNU General Public License (GPL).
-        Patches to the Yocto Project follow the upstream licensing scheme.
-        You can find information on the MIT license
-        <a class="ulink" href="http://www.opensource.org/licenses/mit-license.php" target="_self">here</a>.
-        You can find information on the GNU GPL
-        <a class="ulink" href="http://www.opensource.org/licenses/LGPL-3.0" target="_self">here</a>.
-    </p>
-<p>
-        When you build an image using the Yocto Project, the build process
-        uses a known list of licenses to ensure compliance.
-        You can find this list in the
-        <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>
-        at <code class="filename">meta/files/common-licenses</code>.
-        Once the build completes, the list of all licenses found and used
-        during that build are kept in the
-        <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>
-        at <code class="filename">tmp/deploy/licenses</code>.
-    </p>
-<p>
-        If a module requires a license that is not in the base list, the
-        build process generates a warning during the build.
-        These tools make it easier for a developer to be certain of the
-        licenses with which their shipped products must comply.
-        However, even with these tools it is still up to the developer to
-        resolve potential licensing issues.
-    </p>
-<p>
-        The base list of licenses used by the build process is a combination
-        of the Software Package Data Exchange (SPDX) list and the Open
-        Source Initiative (OSI) projects.
-        <a class="ulink" href="http://spdx.org" target="_self">SPDX Group</a> is a working group of
-        the Linux Foundation that maintains a specification for a standard
-        format for communicating the components, licenses, and copyrights
-        associated with a software package.
-        <a class="ulink" href="http://opensource.org" target="_self">OSI</a> is a corporation
-        dedicated to the Open Source Definition and the effort for reviewing
-        and approving licenses that conform to the Open Source Definition
-        (OSD).
-    </p>
-<p>
-        You can find a list of the combined SPDX and OSI licenses that the
-        Yocto Project uses in the
-        <code class="filename">meta/files/common-licenses</code> directory in your
-        <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>.
-    </p>
-<p>
-        For information that can help you maintain compliance with various
-        open source licensing during the lifecycle of a product created using
-        the Yocto Project, see the
-        "<a class="link" href="../dev-manual/maintaining-open-source-license-compliance-during-your-products-lifecycle.html" target="_self">Maintaining Open Source License Compliance During Your Product's Lifecycle</a>"
-        section in the Yocto Project Development Tasks Manual.
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/local-projects.html b/documentation/getting-started/eclipse/html/getting-started/local-projects.html
deleted file mode 100644
index 9ed618701c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/local-projects.html
+++ /dev/null
@@ -1,39 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.3.2.�Local Projects</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="sources-dev-environment.html" title="2.8.3.�Sources">
-<link rel="prev" href="upstream-project-releases.html" title="2.8.3.1.�Upstream Project Releases">
-<link rel="next" href="scms.html" title="2.8.3.3.�Source Control Managers (Optional)">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.2.�Local Projects">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="local-projects"></a>2.8.3.2.�Local Projects</h4></div></div></div>
-<p>
-                Local projects are custom bits of software the user provides.
-                These bits reside somewhere local to a project - perhaps
-                a directory into which the user checks in items (e.g.
-                a local directory containing a development source tree
-                used by the group).
-            </p>
-<p>
-                The canonical method through which to include a local project
-                is to use the
-                <a class="link" href="../ref-manual/ref-classes-externalsrc.html" target="_self"><code class="filename">externalsrc</code></a>
-                class to include that local project.
-                You use either the <code class="filename">local.conf</code> or a
-                recipe's append file to override or set the
-                recipe to point to the local directory on your disk to pull
-                in the whole source tree.
-            </p>
-<p>
-                For information on how to use the
-                <code class="filename">externalsrc</code> class, see the
-                "<a class="link" href="../ref-manual/ref-classes-externalsrc.html" target="_self"><code class="filename">externalsrc.bbclass</code></a>"
-                section.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.html b/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.html
deleted file mode 100644
index 24f32f394f..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.html
+++ /dev/null
@@ -1,93 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.2.�Metadata, Machine Configuration, and Policy Configuration</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="user-configuration.html" title="2.8.1.�User Configuration">
-<link rel="next" href="distro-layer.html" title="2.8.2.1.�Distro Layer">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.�Metadata, Machine Configuration, and Policy Configuration">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="metadata-machine-configuration-and-policy-configuration"></a>2.8.2.�Metadata, Machine Configuration, and Policy Configuration</h3></div></div></div>
-<p>
-            The previous section described the user configurations that
-            define BitBake's global behavior.
-            This section takes a closer look at the layers the build system
-            uses to further control the build.
-            These layers provide Metadata for the software, machine, and
-            policy.
-        </p>
-<p>
-            In general, three types of layer input exist:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><span class="emphasis"><em>Policy Configuration:</em></span>
-                    Distribution Layers provide top-level or general
-                    policies for the image or SDK being built.
-                    For example, this layer would dictate whether BitBake
-                    produces RPM or IPK packages.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Machine Configuration:</em></span>
-                    Board Support Package (BSP) layers provide machine
-                    configurations.
-                    This type of information is specific to a particular
-                    target architecture.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Metadata:</em></span>
-                    Software layers contain user-supplied recipe files,
-                    patches, and append files.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            The following figure shows an expanded representation of the
-            Metadata, Machine Configuration, and Policy Configuration input
-            (layers) boxes of the
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>:
-        </p>
-<p>
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 675px"><td align="center"><img src="figures/layer-input.png" align="middle" width="720"></td></tr></table>
-<p>
-        </p>
-<p>
-            In general, all layers have a similar structure.
-            They all contain a licensing file
-            (e.g. <code class="filename">COPYING</code>) if the layer is to be
-            distributed, a <code class="filename">README</code> file as good practice
-            and especially if the layer is to be distributed, a
-            configuration directory, and recipe directories.
-        </p>
-<p>
-            The Yocto Project has many layers that can be used.
-            You can see a web-interface listing of them on the
-            <a class="ulink" href="http://git.yoctoproject.org/" target="_self">Source Repositories</a>
-            page.
-            The layers are shown at the bottom categorized under
-            "Yocto Metadata Layers."
-            These layers are fundamentally a subset of the
-            <a class="ulink" href="http://layers.openembedded.org/layerindex/layers/" target="_self">OpenEmbedded Metadata Index</a>,
-            which lists all layers provided by the OpenEmbedded community.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                Layers exist in the Yocto Project Source Repositories that
-                cannot be found in the OpenEmbedded Metadata Index.
-                These layers are either deprecated or experimental in nature.
-            </div>
-<p>
-        </p>
-<p>
-            BitBake uses the <code class="filename">conf/bblayers.conf</code> file,
-            which is part of the user configuration, to find what layers it
-            should be using as part of the build.
-        </p>
-<p>
-            For more information on layers, see the
-            "<a class="link" href="../dev-manual/understanding-and-creating-layers.html" target="_self">Understanding and Creating Layers</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html b/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html
deleted file mode 100644
index ebbae37990..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html
+++ /dev/null
@@ -1,74 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.1.3.�Metadata (Virtual Providers)</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-<link rel="prev" href="usingpoky-components-metadata.html" title="3.1.2.�Metadata (Recipes)">
-<link rel="next" href="usingpoky-components-classes.html" title="3.1.4.�Classes">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.3.�Metadata (Virtual Providers)">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="metadata-virtual-providers"></a>3.1.3.�Metadata (Virtual Providers)</h3></div></div></div>
-<p>
-                Prior to the build, if you know that several different recipes
-                provide the same functionality, you can use a virtual provider
-                (i.e. <code class="filename">virtual/*</code>) as a placeholder for the
-                actual provider.
-                The actual provider would be determined at build time.
-                In this case, you should add <code class="filename">virtual/*</code>
-                to
-                <a class="link" href="../ref-manual/var-DEPENDS.html" target="_self"><code class="filename">DEPENDS</code></a>,
-                rather than listing the specified provider.
-                You would select the actual provider by setting the
-                <a class="link" href="../ref-manual/var-PREFERRED_PROVIDER.html" target="_self"><code class="filename">PREFERRED_PROVIDER</code></a>
-                variable (i.e.
-                <code class="filename">PREFERRED_PROVIDER_virtual/*</code>)
-                in the build's configuration file (e.g.
-                <code class="filename">poky/build/conf/local.conf</code>).
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    Any recipe that PROVIDES a <code class="filename">virtual/*</code>
-                    item that is ultimately not selected through
-                    <code class="filename">PREFERRED_PROVIDER</code> 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.
-                </div>
-<p>
-            </p>
-<p>
-                The following lists specific examples of virtual providers:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                        <code class="filename">virtual/mesa</code>:
-                        Provides <code class="filename">gbm.pc</code>.
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">virtual/egl</code>:
-                        Provides <code class="filename">egl.pc</code> and possibly
-                        <code class="filename">wayland-egl.pc</code>.
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">virtual/libgl</code>:
-                        Provides <code class="filename">gl.pc</code> (i.e. libGL).
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">virtual/libgles1</code>:
-                        Provides <code class="filename">glesv1_cm.pc</code>
-                        (i.e. libGLESv1_CM).
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">virtual/libgles2</code>:
-                        Provides <code class="filename">glesv2.pc</code>
-                        (i.e. libGLESv2).
-                        </p></li>
-</ul></div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html b/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html
deleted file mode 100644
index bd9467e001..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html
+++ /dev/null
@@ -1,54 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.2.�Open Source Philosophy</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="yp-intro.html" title="2.1.�Introduction">
-<link rel="next" href="workflows.html" title="2.3.�Workflows">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.2.�Open Source Philosophy">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="open-source-philosophy"></a>2.2.�Open Source Philosophy</h2></div></div></div>
-<p>
-        Open source philosophy is characterized by software development
-        directed by peer production and collaboration through an active
-        community of developers.
-        Contrast this to the more standard centralized development models
-        used by commercial software companies where a finite set of developers
-        produces a product for sale using a defined set of procedures that
-        ultimately result in an end product whose architecture and source
-        material are closed to the public.
-    </p>
-<p>
-        Open source projects conceptually have differing concurrent agendas,
-        approaches, and production.
-        These facets of the development process can come from anyone in the
-        public (community) that has a stake in the software project.
-        The open source environment contains new copyright, licensing, domain,
-        and consumer issues that differ from the more traditional development
-        environment.
-        In an open source environment, the end product, source material,
-        and documentation are all available to the public at no cost.
-    </p>
-<p>
-        A benchmark example of an open source project is the Linux kernel,
-        which was initially conceived and created by Finnish computer science
-        student Linus Torvalds in 1991.
-        Conversely, a good example of a non-open source project is the
-        <span class="trademark">Windows</span>� family of operating
-        systems developed by
-        <span class="trademark">Microsoft</span>� Corporation.
-    </p>
-<p>
-        Wikipedia has a good historical description of the Open Source
-        Philosophy
-        <a class="ulink" href="http://en.wikipedia.org/wiki/Open_source" target="_self">here</a>.
-        You can also find helpful information on how to participate in the
-        Linux Community
-        <a class="ulink" href="http://ldn.linuxfoundation.org/book/how-participate-linux-community" target="_self">here</a>.
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html b/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html
deleted file mode 100644
index 73d152bb40..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html
+++ /dev/null
@@ -1,59 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.2.2.�Other Variables Related to Commercial Licenses</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="enabling-commercially-licensed-recipes.html" title="3.7.2.�Enabling Commercially Licensed Recipes">
-<link rel="prev" href="license-flag-matching.html" title="3.7.2.1.�License Flag Matching">
-<link rel="next" href="x32.html" title="3.8.�x32 psABI">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.2.2.�Other Variables Related to Commercial Licenses">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="other-variables-related-to-commercial-licenses"></a>3.7.2.2.�Other Variables Related to Commercial Licenses</h4></div></div></div>
-<p>
-                    Other helpful variables related to commercial
-                    license handling exist and are defined in the
-                    <code class="filename">poky/meta/conf/distro/include/default-distrovars.inc</code> file:
-                    </p>
-<pre class="literallayout">
-     COMMERCIAL_AUDIO_PLUGINS ?= ""
-     COMMERCIAL_VIDEO_PLUGINS ?= ""
-                    </pre>
-<p>
-                    If you want to enable these components, you can do so by
-                    making sure you have statements similar to the following
-                    in your <code class="filename">local.conf</code> configuration file:
-                    </p>
-<pre class="literallayout">
-     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
-        gst-plugins-ugly-mpegaudioparse"
-     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
-        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
-                    </pre>
-<p>
-                    Of course, you could also create a matching whitelist
-                    for those components using the more general "commercial"
-                    in the whitelist, but that would also enable all the
-                    other packages with
-                    <a class="link" href="../ref-manual/var-LICENSE_FLAGS.html" target="_self"><code class="filename">LICENSE_FLAGS</code></a>
-                    containing "commercial", which you may or may not want:
-                    </p>
-<pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial"
-                    </pre>
-<p>
-                </p>
-<p>
-                    Specifying audio and video plug-ins as part of the
-                    <code class="filename">COMMERCIAL_AUDIO_PLUGINS</code> and
-                    <code class="filename">COMMERCIAL_VIDEO_PLUGINS</code> statements
-                    (along with the enabling
-                    <code class="filename">LICENSE_FLAGS_WHITELIST</code>) includes the
-                    plug-ins or components into built images, thus adding
-                    support for media formats or components.
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html b/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html
deleted file mode 100644
index 974b05792a..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html
+++ /dev/null
@@ -1,40 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.1.�Overall Architecture</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="shared-state-cache.html" title="3.3.�Shared State Cache">
-<link rel="prev" href="shared-state-cache.html" title="3.3.�Shared State Cache">
-<link rel="next" href="overview-checksums.html" title="3.3.2.�Checksums (Signatures)">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.1.�Overall Architecture">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="overall-architecture"></a>3.3.1.�Overall Architecture</h3></div></div></div>
-<p>
-                When determining what parts of the system need to be built,
-                BitBake works on a per-task basis rather than a per-recipe
-                basis.
-                You might wonder why using a per-task basis is preferred over
-                a per-recipe basis.
-                To help explain, consider having the IPK packaging backend
-                enabled and then switching to DEB.
-                In this case, the
-                <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a>
-                and
-                <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>
-                task outputs are still valid.
-                However, with a per-recipe approach, the build would not
-                include the <code class="filename">.deb</code> files.
-                Consequently, you would have to invalidate the whole build and
-                rerun it.
-                Rerunning everything is not the best solution.
-                Also, in this case, the core must be "taught" much about
-                specific tasks.
-                This methodology does not scale well and does not allow users
-                to easily add new tasks in layers or as external recipes
-                without touching the packaged-staging core.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html b/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html
deleted file mode 100644
index 09ad110f71..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html
+++ /dev/null
@@ -1,209 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.2.�Checksums (Signatures)</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="shared-state-cache.html" title="3.3.�Shared State Cache">
-<link rel="prev" href="overall-architecture.html" title="3.3.1.�Overall Architecture">
-<link rel="next" href="shared-state.html" title="3.3.3.�Shared State">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.2.�Checksums (Signatures)">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="overview-checksums"></a>3.3.2.�Checksums (Signatures)</h3></div></div></div>
-<p>
-                The shared state code uses a checksum, which is a unique
-                signature of a task's inputs, to determine if a task needs to
-                be run again.
-                Because it is a change in a task's inputs that triggers a
-                rerun, the process needs to detect all the inputs to a given
-                task.
-                For shell tasks, this turns out to be fairly easy because
-                the build process generates a "run" shell script for each task
-                and it is possible to create a checksum that gives you a good
-                idea of when the task's data changes.
-            </p>
-<p>
-                To complicate the problem, there are things that should not be
-                included in the checksum.
-                First, there is the actual specific build path of a given
-                task - the
-                <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>.
-                It does not matter if the work directory changes because it
-                should not affect the output for target packages.
-                Also, the build process has the objective of making native
-                or cross packages relocatable.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    Both native and cross packages run on the build host.
-                    However, cross packages generate output for the target
-                    architecture.
-                </div>
-<p>
-                The checksum therefore needs to exclude
-                <code class="filename">WORKDIR</code>.
-                The simplistic approach for excluding the work directory is to
-                set <code class="filename">WORKDIR</code> to some fixed value and
-                create the checksum for the "run" script.
-            </p>
-<p>
-                Another problem results from the "run" scripts containing
-                functions that might or might not get called.
-                The incremental build solution contains code that figures out
-                dependencies between shell functions.
-                This code is used to prune the "run" scripts down to the
-                minimum set, thereby alleviating this problem and making the
-                "run" scripts much more readable as a bonus.
-            </p>
-<p>
-                So far we have solutions for shell scripts.
-                What about Python tasks?
-                The same approach applies even though these tasks are more
-                difficult.
-                The process needs to figure out what variables a Python
-                function accesses and what functions it calls.
-                Again, the incremental build solution contains code that first
-                figures out the variable and function dependencies, and then
-                creates a checksum for the data used as the input to the task.
-            </p>
-<p>
-                Like the <code class="filename">WORKDIR</code> case, situations exist
-                where dependencies should be ignored.
-                For these cases, you can instruct the build process to
-                ignore a dependency by using a line like the following:
-                </p>
-<pre class="literallayout">
-     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
-                </pre>
-<p>
-                This example ensures that the
-                <a class="link" href="../ref-manual/var-PACKAGE_ARCHS.html" target="_self"><code class="filename">PACKAGE_ARCHS</code></a>
-                variable does not depend on the value of
-                <a class="link" href="../ref-manual/var-MACHINE.html" target="_self"><code class="filename">MACHINE</code></a>,
-                even if it does reference it.
-            </p>
-<p>
-                Equally, there are cases where we need to add dependencies
-                BitBake is not able to find.
-                You can accomplish this by using a line like the following:
-                </p>
-<pre class="literallayout">
-      PACKAGE_ARCHS[vardeps] = "MACHINE"
-                </pre>
-<p>
-                This example explicitly adds the <code class="filename">MACHINE</code>
-                variable as a dependency for
-                <code class="filename">PACKAGE_ARCHS</code>.
-            </p>
-<p>
-                Consider a case with in-line Python, for example, where
-                BitBake is not able to figure out dependencies.
-                When running in debug mode (i.e. using
-                <code class="filename">-DDD</code>), BitBake produces output when it
-                discovers something for which it cannot figure out dependencies.
-                The Yocto Project team has currently not managed to cover
-                those dependencies in detail and is aware of the need to fix
-                this situation.
-            </p>
-<p>
-                Thus far, this section has limited discussion to the direct
-                inputs into a task.
-                Information based on direct inputs is referred to as the
-                "basehash" in the code.
-                However, there is still the question of a task's indirect
-                inputs - the things that were already built and present in the
-                <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>.
-                The checksum (or signature) for a particular task needs to add
-                the hashes of all the tasks on which the particular task
-                depends.
-                Choosing which dependencies to add is a policy decision.
-                However, the effect is to generate a master checksum that
-                combines the basehash and the hashes of the task's
-                dependencies.
-            </p>
-<p>
-                At the code level, there are a variety of ways both the
-                basehash and the dependent task hashes can be influenced.
-                Within the BitBake configuration file, we can give BitBake
-                some extra information to help it construct the basehash.
-                The following statement effectively results in a list of
-                global variable dependency excludes - variables never
-                included in any checksum:
-                </p>
-<pre class="literallayout">
-     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
-         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
-         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
-         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
-         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
-                </pre>
-<p>
-                The previous example excludes
-                <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>
-                since that variable is actually constructed as a path within
-                <a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a>,
-                which is on the whitelist.
-            </p>
-<p>
-                The rules for deciding which hashes of dependent tasks to
-                include through dependency chains are more complex and are
-                generally accomplished with a Python function.
-                The code in <code class="filename">meta/lib/oe/sstatesig.py</code> shows
-                two examples of this and also illustrates how you can insert
-                your own policy into the system if so desired.
-                This file defines the two basic signature generators
-                <a class="link" href="../ref-manual/oe-core.html" target="_self">OE-Core</a>
-                uses:  "OEBasic" and "OEBasicHash".
-                By default, there is a dummy "noop" signature handler enabled
-                in BitBake.
-                This means that behavior is unchanged from previous versions.
-                OE-Core uses the "OEBasicHash" signature handler by default
-                through this setting in the <code class="filename">bitbake.conf</code>
-                file:
-                </p>
-<pre class="literallayout">
-     BB_SIGNATURE_HANDLER ?= "OEBasicHash"
-                </pre>
-<p>
-                The "OEBasicHash" <code class="filename">BB_SIGNATURE_HANDLER</code>
-                is the same as the "OEBasic" version but adds the task hash to
-                the stamp files.
-                This results in any
-                <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>
-                change that changes the task hash, automatically
-                causing the task to be run again.
-                This removes the need to bump
-                <a class="link" href="../ref-manual/var-PR.html" target="_self"><code class="filename">PR</code></a>
-                values, and changes to Metadata automatically ripple across
-                the build.
-            </p>
-<p>
-                It is also worth noting that the end result of these
-                signature generators is to make some dependency and hash
-                information available to the build.
-                This information includes:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                        <code class="filename">BB_BASEHASH_task-</code><em class="replaceable"><code>taskname</code></em>:
-                        The base hashes for each task in the recipe.
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">BB_BASEHASH_</code><em class="replaceable"><code>filename</code></em><code class="filename">:</code><em class="replaceable"><code>taskname</code></em>:
-                        The base hashes for each dependent task.
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">BBHASHDEPS_</code><em class="replaceable"><code>filename</code></em><code class="filename">:</code><em class="replaceable"><code>taskname</code></em>:
-                        The task dependencies for each task.
-                        </p></li>
-<li class="listitem"><p>
-                        <code class="filename">BB_TASKHASH</code>:
-                        The hash of the currently running task.
-                        </p></li>
-</ul></div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html b/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html
deleted file mode 100644
index 855d22e109..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html
+++ /dev/null
@@ -1,57 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter�3.�Yocto Project Concepts</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="index.html" title="Getting Started With Yocto Project">
-<link rel="prev" href="sdk-dev-environment.html" title="2.8.7.�Application Development SDK">
-<link rel="next" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter�3.�Yocto Project Concepts">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="overview-concepts"></a>Chapter�3.�Yocto Project Concepts</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="section"><a href="yocto-project-components.html">3.1. Yocto Project Components</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="usingpoky-components-bitbake.html">3.1.1. BitBake</a></span></dt>
-<dt><span class="section"><a href="usingpoky-components-metadata.html">3.1.2. Metadata (Recipes)</a></span></dt>
-<dt><span class="section"><a href="metadata-virtual-providers.html">3.1.3. Metadata (Virtual Providers)</a></span></dt>
-<dt><span class="section"><a href="usingpoky-components-classes.html">3.1.4. Classes</a></span></dt>
-<dt><span class="section"><a href="usingpoky-components-configuration.html">3.1.5. Configuration</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="cross-development-toolchain-generation.html">3.2. Cross-Development Toolchain Generation</a></span></dt>
-<dt><span class="section"><a href="shared-state-cache.html">3.3. Shared State Cache</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="overall-architecture.html">3.3.1. Overall Architecture</a></span></dt>
-<dt><span class="section"><a href="overview-checksums.html">3.3.2. Checksums (Signatures)</a></span></dt>
-<dt><span class="section"><a href="shared-state.html">3.3.3. Shared State</a></span></dt>
-<dt><span class="section"><a href="tips-and-tricks.html">3.3.4. Tips and Tricks</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="automatically-added-runtime-dependencies.html">3.4. Automatically Added Runtime Dependencies</a></span></dt>
-<dt><span class="section"><a href="fakeroot-and-pseudo.html">3.5. Fakeroot and Pseudo</a></span></dt>
-<dt><span class="section"><a href="wayland.html">3.6. Wayland</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="wayland-support.html">3.6.1. Support</a></span></dt>
-<dt><span class="section"><a href="enabling-wayland-in-an-image.html">3.6.2. Enabling Wayland in an Image</a></span></dt>
-<dt><span class="section"><a href="running-weston.html">3.6.3. Running Weston</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="overview-licenses.html">3.7. Licenses</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="usingpoky-configuring-LIC_FILES_CHKSUM.html">3.7.1. Tracking License Changes</a></span></dt>
-<dt><span class="section"><a href="enabling-commercially-licensed-recipes.html">3.7.2. Enabling Commercially Licensed Recipes</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="x32.html">3.8. x32 psABI</a></span></dt>
-</dl>
-</div>
-<p>
-        This chapter describes concepts for various areas of the Yocto Project.
-        Currently, topics include Yocto Project components, cross-development
-        generation, shared state (sstate) cache, runtime dependencies,
-        Pseudo and Fakeroot, x32 psABI, Wayland support, and Licenses.
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html b/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html
deleted file mode 100644
index b8b4c880e7..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html
+++ /dev/null
@@ -1,28 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.4.1.�Debugging</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="tips-and-tricks.html" title="3.3.4.�Tips and Tricks">
-<link rel="prev" href="tips-and-tricks.html" title="3.3.4.�Tips and Tricks">
-<link rel="next" href="invalidating-shared-state.html" title="3.3.4.2.�Invalidating Shared State">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.4.1.�Debugging">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="overview-debugging"></a>3.3.4.1.�Debugging</h4></div></div></div>
-<p>
-                    Seeing what metadata went into creating the input signature
-                    of a shared state (sstate) task can be a useful debugging
-                    aid.
-                    This information is available in signature information
-                    (<code class="filename">siginfo</code>) files in
-                    <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a>.
-                    For information on how to view and interpret information in
-                    <code class="filename">siginfo</code> files, see the
-                    "<a class="link" href="../dev-manual/dev-viewing-task-variable-dependencies.html" target="_self">Viewing Task Variable Dependencies</a>"
-                    section in the Yocto Project Development Tasks Manual.
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html b/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html
deleted file mode 100644
index c8030fee19..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html
+++ /dev/null
@@ -1,56 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter�2.�The Yocto Project Development Environment</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="index.html" title="Getting Started With Yocto Project">
-<link rel="prev" href="overview-other-information.html" title="1.2.�Other Information">
-<link rel="next" href="yp-intro.html" title="2.1.�Introduction">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter�2.�The Yocto Project Development Environment">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="overview-development-environment"></a>Chapter�2.�The Yocto Project Development Environment</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="section"><a href="yp-intro.html">2.1. Introduction</a></span></dt>
-<dt><span class="section"><a href="open-source-philosophy.html">2.2. Open Source Philosophy</a></span></dt>
-<dt><span class="section"><a href="workflows.html">2.3. Workflows</a></span></dt>
-<dt><span class="section"><a href="git.html">2.4. Git</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="repositories-tags-and-branches.html">2.4.1. Repositories, Tags, and Branches</a></span></dt>
-<dt><span class="section"><a href="basic-commands.html">2.4.2. Basic Commands</a></span></dt>
-</dl></dd>
-<dt><span class="section"><a href="yocto-project-repositories.html">2.5. Yocto Project Source Repositories</a></span></dt>
-<dt><span class="section"><a href="licensing.html">2.6. Licensing</a></span></dt>
-<dt><span class="section"><a href="recipe-syntax.html">2.7. Recipe Syntax</a></span></dt>
-<dt><span class="section"><a href="development-concepts.html">2.8. Development Concepts</a></span></dt>
-<dd><dl>
-<dt><span class="section"><a href="user-configuration.html">2.8.1. User Configuration</a></span></dt>
-<dt><span class="section"><a href="metadata-machine-configuration-and-policy-configuration.html">2.8.2. Metadata, Machine Configuration, and Policy Configuration</a></span></dt>
-<dt><span class="section"><a href="sources-dev-environment.html">2.8.3. Sources</a></span></dt>
-<dt><span class="section"><a href="package-feeds-dev-environment.html">2.8.4. Package Feeds</a></span></dt>
-<dt><span class="section"><a href="bitbake-dev-environment.html">2.8.5. BitBake</a></span></dt>
-<dt><span class="section"><a href="images-dev-environment.html">2.8.6. Images</a></span></dt>
-<dt><span class="section"><a href="sdk-dev-environment.html">2.8.7. Application Development SDK</a></span></dt>
-</dl></dd>
-</dl>
-</div>
-<p>
-    This chapter takes a look at the Yocto Project development
-    environment and also provides a detailed look at what goes on during
-    development in that environment.
-    The chapter provides Yocto Project Development environment concepts that
-    help you understand how work is accomplished in an open source environment,
-    which is very different as compared to work accomplished in a closed,
-    proprietary environment.
-</p>
-<p>
-    Specifically, this chapter addresses open source philosophy, workflows,
-    Git, source repositories, licensing, recipe syntax, and development
-    syntax.
-</p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html b/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html
deleted file mode 100644
index eca1f71d2d..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html
+++ /dev/null
@@ -1,29 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.�Licenses</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="running-weston.html" title="3.6.3.�Running Weston">
-<link rel="next" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1.�Tracking License Changes">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.�Licenses">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="overview-licenses"></a>3.7.�Licenses</h2></div></div></div>
-<p>
-            This section describes the mechanism by which the OpenEmbedded
-            build system tracks changes to licensing text.
-            The section also describes how to enable commercially licensed
-            recipes, which by default are disabled.
-        </p>
-<p>
-            For information that can help you maintain compliance with
-            various open source licensing during the lifecycle of the product,
-            see the
-            "<a class="link" href="../dev-manual/maintaining-open-source-license-compliance-during-your-products-lifecycle.html" target="_self">Maintaining Open Source License Compliance During Your Project's Lifecycle</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html b/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html
deleted file mode 100644
index ab4e1f338f..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html
+++ /dev/null
@@ -1,23 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>Chapter�1.�The Yocto Project Overview Manual</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="index.html" title="Getting Started With Yocto Project">
-<link rel="prev" href="index.html" title="Getting Started With Yocto Project">
-<link rel="next" href="overview-welcome.html" title="1.1.�Welcome">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter�1.�The Yocto Project Overview Manual">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="overview-manual-intro"></a>Chapter�1.�The Yocto Project Overview Manual</h2></div></div></div>
-<div class="toc">
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><span class="section"><a href="overview-welcome.html">1.1. Welcome</a></span></dt>
-<dt><span class="section"><a href="overview-other-information.html">1.2. Other Information</a></span></dt>
-</dl>
-</div>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html b/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html
deleted file mode 100644
index 03210c6ebf..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html
+++ /dev/null
@@ -1,31 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>1.2.�Other Information</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-manual-intro.html" title="Chapter�1.�The Yocto Project Overview Manual">
-<link rel="prev" href="overview-welcome.html" title="1.1.�Welcome">
-<link rel="next" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.2.�Other Information">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="overview-other-information"></a>1.2.�Other Information</h2></div></div></div>
-<p>
-            Because this manual presents information for many different
-            topics, supplemental information is recommended for full
-            comprehension.
-            For additional introductory information on the Yocto Project, see
-            the <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project Website</a>.
-            You can find an introductory to using the Yocto Project by working
-            through the
-            <a class="link" href="../yocto-project-qs/index.html" target="_self">Yocto Project Quick Start</a>.
-        </p>
-<p>
-            For a comprehensive list of links and other documentation, see the
-            "<a class="link" href="../ref-manual/resources-links-and-related-documentation.html" target="_self">Links and Related Documentation</a>"
-            section in the Yocto Project Reference Manual.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html b/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html
deleted file mode 100644
index 1bc34e081c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html
+++ /dev/null
@@ -1,85 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>1.1.�Welcome</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-manual-intro.html" title="Chapter�1.�The Yocto Project Overview Manual">
-<link rel="prev" href="overview-manual-intro.html" title="Chapter�1.�The Yocto Project Overview Manual">
-<link rel="next" href="overview-other-information.html" title="1.2.�Other Information">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.1.�Welcome">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="overview-welcome"></a>1.1.�Welcome</h2></div></div></div>
-<p>
-            Welcome to the Yocto Project Overview Manual!
-            This manual introduces the Yocto Project by providing concepts,
-            software overviews, best-known-methods (BKMs), and any other
-            high-level introductory information suitable for a new Yocto
-            Project user.
-        </p>
-<p>
-            The following list describes what you can get from this manual:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            This manual does not give you the following:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Step-by-step Instructions for Development Tasks:</em></span>
-                    Instructional procedures reside in other manuals within
-                    the Yocto Project documentation set.
-                    For example, the
-                    <a class="link" href="../dev-manual/index.html" target="_self">Yocto Project Development Tasks Manual</a>
-                    provides examples on how to perform various development
-                    tasks.
-                    As another example, the
-                    <a class="link" href="../sdk-manual/index.html" target="_self">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>
-                    manual contains detailed instructions on how to install an
-                    SDK, which is used to develop applications for target
-                    hardware.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Reference Material:</em></span>
-                    This type of material resides in an appropriate reference
-                    manual.
-                    For example, system variables are documented in the
-                    <a class="link" href="../ref-manual/index.html" target="_self">Yocto Project Reference Manual</a>.
-                    As another example, the
-                    <a class="link" href="../bsp-guide/index.html" target="_self">Yocto Project Board Support Package (BSP) Developer's Guide</a>
-                    contains reference information on BSPs.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Detailed Public Information Not Specific to the
-                    Yocto Project:</em></span>
-                    For example, exhaustive information on how to use the
-                    Source Control Manager Git is better covered with Internet
-                    searches and official Git Documentation than through the
-                    Yocto Project documentation.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html
deleted file mode 100644
index ad3d67f660..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html
+++ /dev/null
@@ -1,98 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.4.�Package Feeds</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="source-mirrors.html" title="2.8.3.4.�Source Mirror(s)">
-<link rel="next" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.4.�Package Feeds">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="package-feeds-dev-environment"></a>2.8.4.�Package Feeds</h3></div></div></div>
-<p>
-            When the OpenEmbedded build system generates an image or an SDK,
-            it gets the packages from a package feed area located in the
-            <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>.
-            The
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>
-            shows this package feeds area in the upper-right corner.
-        </p>
-<p>
-            This section looks a little closer into the package feeds area used
-            by the build system.
-            Here is a more detailed look at the area:
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 540px"><td align="center"><img src="figures/package-feeds.png" align="middle" width="630"></td></tr></table>
-<p>
-        </p>
-<p>
-            Package feeds are an intermediary step in the build process.
-            The OpenEmbedded build system provides classes to generate
-            different package types, and you specify which classes to enable
-            through the
-            <a class="link" href="../ref-manual/var-PACKAGE_CLASSES.html" target="_self"><code class="filename">PACKAGE_CLASSES</code></a>
-            variable.
-            Before placing the packages into package feeds,
-            the build process validates them with generated output quality
-            assurance checks through the
-            <a class="link" href="../ref-manual/ref-classes-insane.html" target="_self"><code class="filename">insane</code></a>
-            class.
-        </p>
-<p>
-            The package feed area resides in the Build Directory.
-            The directory the build system uses to temporarily store packages
-            is determined by a combination of variables and the particular
-            package manager in use.
-            See the "Package Feeds" box in the illustration and note the
-            information to the right of that area.
-            In particular, the following defines where package files are
-            kept:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>:
-                    Defined as <code class="filename">tmp/deploy</code> in the Build
-                    Directory.
-                    </p></li>
-<li class="listitem"><p><code class="filename">DEPLOY_DIR_*</code>:
-                    Depending on the package manager used, the package type
-                    sub-folder.
-                    Given RPM, IPK, or DEB packaging and tarball creation, the
-                    <a class="link" href="../ref-manual/var-DEPLOY_DIR_RPM.html" target="_self"><code class="filename">DEPLOY_DIR_RPM</code></a>,
-                    <a class="link" href="../ref-manual/var-DEPLOY_DIR_IPK.html" target="_self"><code class="filename">DEPLOY_DIR_IPK</code></a>,
-                    <a class="link" href="../ref-manual/var-DEPLOY_DIR_DEB.html" target="_self"><code class="filename">DEPLOY_DIR_DEB</code></a>,
-                    or
-                    <a class="link" href="../ref-manual/var-DEPLOY_DIR_TAR.html" target="_self"><code class="filename">DEPLOY_DIR_TAR</code></a>,
-                    variables are used, respectively.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_ARCH.html" target="_self"><code class="filename">PACKAGE_ARCH</code></a>:
-                    Defines architecture-specific sub-folders.
-                    For example, packages could exist for the i586 or qemux86
-                    architectures.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            BitBake uses the <code class="filename">do_package_write_*</code> tasks to
-            generate packages and place them into the package holding area (e.g.
-            <code class="filename">do_package_write_ipk</code> for IPK packages).
-            See the
-            "<a class="link" href="../ref-manual/ref-tasks-package_write_deb.html" target="_self"><code class="filename">do_package_write_deb</code></a>",
-            "<a class="link" href="../ref-manual/ref-tasks-package_write_ipk.html" target="_self"><code class="filename">do_package_write_ipk</code></a>",
-            "<a class="link" href="../ref-manual/ref-tasks-package_write_rpm.html" target="_self"><code class="filename">do_package_write_rpm</code></a>",
-            and
-            "<a class="link" href="../ref-manual/ref-tasks-package_write_tar.html" target="_self"><code class="filename">do_package_write_tar</code></a>"
-            sections for additional information.
-            As an example, consider a scenario where an IPK packaging manager
-            is being used and package architecture support for both i586
-            and qemux86 exist.
-            Packages for the i586 architecture are placed in
-            <code class="filename">build/tmp/deploy/ipk/i586</code>, while packages for
-            the qemux86 architecture are placed in
-            <code class="filename">build/tmp/deploy/ipk/qemux86</code>.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html
deleted file mode 100644
index 882d66c31c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html
+++ /dev/null
@@ -1,94 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.4.�Package Splitting</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="configuration-and-compilation-dev-environment.html" title="2.8.5.3.�Configuration and Compilation">
-<link rel="next" href="image-generation-dev-environment.html" title="2.8.5.5.�Image Generation">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.4.�Package Splitting">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="package-splitting-dev-environment"></a>2.8.5.4.�Package Splitting</h4></div></div></div>
-<p>
-                After source code is configured and compiled, the
-                OpenEmbedded build system analyzes
-                the results and splits the output into packages:
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 630px"><td align="center"><img src="figures/analysis-for-package-splitting.png" align="middle" width="630"></td></tr></table>
-<p>
-            </p>
-<p>
-                The
-                <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>
-                and
-                <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>
-                tasks combine to analyze
-                the files found in the
-                <a class="link" href="../ref-manual/var-D.html" target="_self"><code class="filename">D</code></a> directory
-                and split them into subsets based on available packages and
-                files.
-                The analyzing process involves the following as well as other
-                items: splitting out debugging symbols,
-                looking at shared library dependencies between packages,
-                and looking at package relationships.
-                The <code class="filename">do_packagedata</code> task creates package
-                metadata based on the analysis such that the
-                OpenEmbedded build system can generate the final packages.
-                Working, staged, and intermediate results of the analysis
-                and package splitting process use these areas:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PKGD.html" target="_self"><code class="filename">PKGD</code></a> -
-                        The destination directory for packages before they are
-                        split.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PKGDATA_DIR.html" target="_self"><code class="filename">PKGDATA_DIR</code></a> -
-                        A shared, global-state directory that holds data
-                        generated during the packaging process.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PKGDESTWORK.html" target="_self"><code class="filename">PKGDESTWORK</code></a> -
-                        A temporary work area used by the
-                        <code class="filename">do_package</code> task.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PKGDEST.html" target="_self"><code class="filename">PKGDEST</code></a> -
-                        The parent directory for packages after they have
-                        been split.
-                        </p></li>
-</ul></div>
-<p>
-                The <a class="link" href="../ref-manual/var-FILES.html" target="_self"><code class="filename">FILES</code></a>
-                variable defines the files that go into each package in
-                <a class="link" href="../ref-manual/var-PACKAGES.html" target="_self"><code class="filename">PACKAGES</code></a>.
-                If you want details on how this is accomplished, you can
-                look at the
-                <a class="link" href="../ref-manual/ref-classes-package.html" target="_self"><code class="filename">package</code></a>
-                class.
-            </p>
-<p>
-                Depending on the type of packages being created (RPM, DEB, or
-                IPK), the <code class="filename">do_package_write_*</code> task
-                creates the actual packages and places them in the
-                Package Feed area, which is
-                <code class="filename">${TMPDIR}/deploy</code>.
-                You can see the
-                "<a class="link" href="package-feeds-dev-environment.html" title="2.8.4.�Package Feeds">Package Feeds</a>"
-                section for more detail on that part of the build process.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    Support for creating feeds directly from the
-                    <code class="filename">deploy/*</code> directories does not exist.
-                    Creating such feeds usually requires some kind of feed
-                    maintenance mechanism that would upload the new packages
-                    into an official package feed (e.g. the
-                    �ngstr�m distribution).
-                    This functionality is highly distribution-specific
-                    and thus is not provided out of the box.
-                </div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html
deleted file mode 100644
index 60ae6b020b..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.2.�Patching</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="source-fetching-dev-environment.html" title="2.8.5.1.�Source Fetching">
-<link rel="next" href="configuration-and-compilation-dev-environment.html" title="2.8.5.3.�Configuration and Compilation">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.2.�Patching">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="patching-dev-environment"></a>2.8.5.2.�Patching</h4></div></div></div>
-<p>
-                Once source code is fetched and unpacked, BitBake locates
-                patch files and applies them to the source files:
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 450px"><td align="center"><img src="figures/patching.png" align="middle" width="540"></td></tr></table>
-<p>
-            </p>
-<p>
-                The
-                <a class="link" href="../ref-manual/ref-tasks-patch.html" target="_self"><code class="filename">do_patch</code></a>
-                task processes recipes by
-                using the
-                <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a>
-                variable to locate applicable patch files, which by default
-                are <code class="filename">*.patch</code> or
-                <code class="filename">*.diff</code> files, or any file if
-                "apply=yes" is specified for the file in
-                <code class="filename">SRC_URI</code>.
-            </p>
-<p>
-                BitBake finds and applies multiple patches for a single recipe
-                in the order in which it finds the patches.
-                Patches are applied to the recipe's source files located in the
-                <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a>
-                directory.
-            </p>
-<p>
-                For more information on how the source directories are
-                created, see the
-                "<a class="link" href="source-fetching-dev-environment.html" title="2.8.5.1.�Source Fetching">Source Fetching</a>"
-                section.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html b/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html
deleted file mode 100644
index fcf46d9d35..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html
+++ /dev/null
@@ -1,383 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.7.�Recipe Syntax</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="licensing.html" title="2.6.�Licensing">
-<link rel="next" href="development-concepts.html" title="2.8.�Development Concepts">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.7.�Recipe Syntax">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="recipe-syntax"></a>2.7.�Recipe Syntax</h2></div></div></div>
-<p>
-        Understanding recipe file syntax is important for
-        writing recipes.
-        The following list overviews the basic items that make up a
-        BitBake recipe file.
-        For more complete BitBake syntax descriptions, see the
-        "<a class="link" href="../bitbake-user-manual/bitbake-user-manual-metadata.html" target="_self">Syntax and Operators</a>"
-        chapter of the BitBake User Manual.
-        </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p><span class="emphasis"><em>Variable Assignments and Manipulations:</em></span>
-                Variable assignments allow a value to be assigned to a
-                variable.
-                The assignment can be static text or might include
-                the contents of other variables.
-                In addition to the assignment, appending and prepending
-                operations are also supported.</p>
-<p>The following example shows some of the ways
-                you can use variables in recipes:
-                </p>
-<pre class="literallayout">
-     S = "${WORKDIR}/postfix-${PV}"
-     CFLAGS += "-DNO_ASM"
-     SRC_URI_append = " file://fixup.patch"
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Functions:</em></span>
-                Functions provide a series of actions to be performed.
-                You usually use functions to override the default
-                implementation of a task function or to complement
-                a default function (i.e. append or prepend to an
-                existing function).
-                Standard functions use <code class="filename">sh</code> shell
-                syntax, although access to OpenEmbedded variables and
-                internal methods are also available.</p>
-<p>The following is an example function from the
-                <code class="filename">sed</code> recipe:
-                </p>
-<pre class="literallayout">
-     do_install () {
-         autotools_do_install
-         install -d ${D}${base_bindir}
-         mv ${D}${bindir}/sed ${D}${base_bindir}/sed
-         rmdir ${D}${bindir}/
-     }
-                </pre>
-<p>
-                It is also possible to implement new functions that
-                are called between existing tasks as long as the
-                new functions are not replacing or complementing the
-                default functions.
-                You can implement functions in Python
-                instead of shell.
-                Both of these options are not seen in the majority of
-                recipes.</p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Keywords:</em></span>
-                BitBake recipes use only a few keywords.
-                You use keywords to include common
-                functions (<code class="filename">inherit</code>), load parts
-                of a recipe from other files
-                (<code class="filename">include</code> and
-                <code class="filename">require</code>) and export variables
-                to the environment (<code class="filename">export</code>).</p>
-<p>The following example shows the use of some of
-                these keywords:
-                </p>
-<pre class="literallayout">
-     export POSTCONF = "${STAGING_BINDIR}/postconf"
-     inherit autoconf
-     require otherfile.inc
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Comments:</em></span>
-                Any lines that begin with the hash character
-                (<code class="filename">#</code>) are treated as comment lines
-                and are ignored:
-                </p>
-<pre class="literallayout">
-     # This is a comment
-                </pre>
-<p>
-                </p>
-</li>
-</ul></div>
-<p>
-    </p>
-<p>
-        This next list summarizes the most important and most commonly
-        used parts of the recipe syntax.
-        For more information on these parts of the syntax, you can
-        reference the
-        <a class="link" href="../bitbake-user-manual/bitbake-user-manual-metadata.html" target="_self">Syntax and Operators</a>
-        chapter in the BitBake User Manual.
-        </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p><span class="emphasis"><em>Line Continuation: <code class="filename">\</code></em></span> -
-                Use the backward slash (<code class="filename">\</code>)
-                character to split a statement over multiple lines.
-                Place the slash character at the end of the line that
-                is to be continued on the next line:
-                </p>
-<pre class="literallayout">
-     VAR = "A really long \
-            line"
-                </pre>
-<p>
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    You cannot have any characters including spaces
-                    or tabs after the slash character.
-                </div>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p>
-                <span class="emphasis"><em>Using Variables: <code class="filename">${...}</code></em></span> -
-                Use the <code class="filename">${<em class="replaceable"><code>VARNAME</code></em>}</code> syntax to
-                access the contents of a variable:
-                </p>
-<pre class="literallayout">
-     SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
-                </pre>
-<p>
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    It is important to understand that the value of a
-                    variable expressed in this form does not get
-                    substituted automatically.
-                    The expansion of these expressions happens
-                    on-demand later (e.g. usually when a function that
-                    makes reference to the variable executes).
-                    This behavior ensures that the values are most
-                    appropriate for the context in which they are
-                    finally used.
-                    On the rare occasion that you do need the variable
-                    expression to be expanded immediately, you can use
-                    the <code class="filename">:=</code> operator instead of
-                    <code class="filename">=</code> when you make the
-                    assignment, but this is not generally needed.
-                </div>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Quote All Assignments: <code class="filename">"<em class="replaceable"><code>value</code></em>"</code></em></span> -
-                Use double quotes around the value in all variable
-                assignments.
-                </p>
-<pre class="literallayout">
-     VAR1 = "${OTHERVAR}"
-     VAR2 = "The version is ${PV}"
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Conditional Assignment: <code class="filename">?=</code></em></span> -
-                Conditional assignment is used to assign a value to
-                a variable, but only when the variable is currently
-                unset.
-                Use the question mark followed by the equal sign
-                (<code class="filename">?=</code>) to make a "soft" assignment
-                used for conditional assignment.
-                Typically, "soft" assignments are used in the
-                <code class="filename">local.conf</code> file for variables
-                that are allowed to come through from the external
-                environment.
-                </p>
-<p>Here is an example where
-                <code class="filename">VAR1</code> is set to "New value" if
-                it is currently empty.
-                However, if <code class="filename">VAR1</code> has already been
-                set, it remains unchanged:
-                </p>
-<pre class="literallayout">
-     VAR1 ?= "New value"
-                </pre>
-<p>
-                In this next example, <code class="filename">VAR1</code>
-                is left with the value "Original value":
-                </p>
-<pre class="literallayout">
-     VAR1 = "Original value"
-     VAR1 ?= "New value"
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Appending: <code class="filename">+=</code></em></span> -
-                Use the plus character followed by the equals sign
-                (<code class="filename">+=</code>) to append values to existing
-                variables.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    This operator adds a space between the existing
-                    content of the variable and the new content.
-                </div>
-<p>Here is an example:
-                </p>
-<pre class="literallayout">
-     SRC_URI += "file://fix-makefile.patch"
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Prepending: <code class="filename">=+</code></em></span> -
-                Use the equals sign followed by the plus character
-                (<code class="filename">=+</code>) to prepend values to existing
-                variables.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    This operator adds a space between the new content
-                    and the existing content of the variable.
-                </div>
-<p>Here is an example:
-                </p>
-<pre class="literallayout">
-     VAR =+ "Starts"
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Appending: <code class="filename">_append</code></em></span> -
-                Use the <code class="filename">_append</code> operator to
-                append values to existing variables.
-                This operator does not add any additional space.
-                Also, the operator is applied after all the
-                <code class="filename">+=</code>, and
-                <code class="filename">=+</code> operators have been applied and
-                after all <code class="filename">=</code> assignments have
-                occurred.
-                </p>
-<p>The following example shows the space being
-                explicitly added to the start to ensure the appended
-                value is not merged with the existing value:
-                </p>
-<pre class="literallayout">
-     SRC_URI_append = " file://fix-makefile.patch"
-                </pre>
-<p>
-                You can also use the <code class="filename">_append</code>
-                operator with overrides, which results in the actions
-                only being performed for the specified target or
-                machine:
-                </p>
-<pre class="literallayout">
-     SRC_URI_append_sh4 = " file://fix-makefile.patch"
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Prepending: <code class="filename">_prepend</code></em></span> -
-                Use the <code class="filename">_prepend</code> operator to
-                prepend values to existing variables.
-                This operator does not add any additional space.
-                Also, the operator is applied after all the
-                <code class="filename">+=</code>, and
-                <code class="filename">=+</code> operators have been applied and
-                after all <code class="filename">=</code> assignments have
-                occurred.
-                </p>
-<p>The following example shows the space being
-                explicitly added to the end to ensure the prepended
-                value is not merged with the existing value:
-                </p>
-<pre class="literallayout">
-     CFLAGS_prepend = "-I${S}/myincludes "
-                </pre>
-<p>
-                You can also use the <code class="filename">_prepend</code>
-                operator with overrides, which results in the actions
-                only being performed for the specified target or
-                machine:
-                </p>
-<pre class="literallayout">
-     CFLAGS_prepend_sh4 = "-I${S}/myincludes "
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem">
-<p><span class="emphasis"><em>Overrides:</em></span> -
-                You can use overrides to set a value conditionally,
-                typically based on how the recipe is being built.
-                For example, to set the
-                <a class="link" href="../ref-manual/var-KBRANCH.html" target="_self"><code class="filename">KBRANCH</code></a>
-                variable's value to "standard/base" for any target
-                <a class="link" href="../ref-manual/var-MACHINE.html" target="_self"><code class="filename">MACHINE</code></a>,
-                except for qemuarm where it should be set to
-                "standard/arm-versatile-926ejs", you would do the
-                following:
-                </p>
-<pre class="literallayout">
-     KBRANCH = "standard/base"
-     KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
-                </pre>
-<p>
-                Overrides are also used to separate alternate values
-                of a variable in other situations.
-                For example, when setting variables such as
-                <a class="link" href="../ref-manual/var-FILES.html" target="_self"><code class="filename">FILES</code></a>
-                and
-                <a class="link" href="../ref-manual/var-RDEPENDS.html" target="_self"><code class="filename">RDEPENDS</code></a>
-                that are specific to individual packages produced by
-                a recipe, you should always use an override that
-                specifies the name of the package.
-                </p>
-</li>
-<li class="listitem"><p><span class="emphasis"><em>Indentation:</em></span>
-                Use spaces for indentation rather than than tabs.
-                For shell functions, both currently work.
-                However, it is a policy decision of the Yocto Project
-                to use tabs in shell functions.
-                Realize that some layers have a policy to use spaces
-                for all indentation.
-                </p></li>
-<li class="listitem">
-<p><span class="emphasis"><em>Using Python for Complex Operations: <code class="filename">${@<em class="replaceable"><code>python_code</code></em>}</code></em></span> -
-                For more advanced processing, it is possible to use
-                Python code during variable assignments (e.g.
-                search and replacement on a variable).</p>
-<p>You indicate Python code using the
-                <code class="filename">${@<em class="replaceable"><code>python_code</code></em>}</code>
-                syntax for the variable assignment:
-                </p>
-<pre class="literallayout">
-     SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
-                </pre>
-<p>
-                </p>
-</li>
-<li class="listitem"><p><span class="emphasis"><em>Shell Function Syntax:</em></span>
-                Write shell functions as if you were writing a shell
-                script when you describe a list of actions to take.
-                You should ensure that your script works with a generic
-                <code class="filename">sh</code> and that it does not require
-                any <code class="filename">bash</code> or other shell-specific
-                functionality.
-                The same considerations apply to various system
-                utilities (e.g. <code class="filename">sed</code>,
-                <code class="filename">grep</code>, <code class="filename">awk</code>,
-                and so forth) that you might wish to use.
-                If in doubt, you should check with multiple
-                implementations - including those from BusyBox.
-                </p></li>
-</ul></div>
-<p>
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html b/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html
deleted file mode 100644
index d813948375..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html
+++ /dev/null
@@ -1,173 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.4.1.�Repositories, Tags, and Branches</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="git.html" title="2.4.�Git">
-<link rel="prev" href="git.html" title="2.4.�Git">
-<link rel="next" href="basic-commands.html" title="2.4.2.�Basic Commands">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.1.�Repositories, Tags, and Branches">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="repositories-tags-and-branches"></a>2.4.1.�Repositories, Tags, and Branches</h3></div></div></div>
-<p>
-            As mentioned briefly in the previous section and also in the
-            "<a class="link" href="workflows.html" title="2.3.�Workflows">Workflows</a>" section,
-            the Yocto Project maintains source repositories at
-            <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi" target="_self">http://git.yoctoproject.org/cgit.cgi</a>.
-            If you look at this web-interface of the repositories, each item
-            is a separate Git repository.
-        </p>
-<p>
-            Git repositories use branching techniques that track content
-            change (not files) within a project (e.g. a new feature or updated
-            documentation).
-            Creating a tree-like structure based on project divergence allows
-            for excellent historical information over the life of a project.
-            This methodology also allows for an environment from which you can
-            do lots of local experimentation on projects as you develop
-            changes or new features.
-        </p>
-<p>
-            A Git repository represents all development efforts for a given
-            project.
-            For example, the Git repository <code class="filename">poky</code> contains
-            all changes and developments for Poky over the course of its
-            entire life.
-            That means that all changes that make up all releases are captured.
-            The repository maintains a complete history of changes.
-        </p>
-<p>
-            You can create a local copy of any repository by "cloning" it
-            with the <code class="filename">git clone</code> command.
-            When you clone a Git repository, you end up with an identical
-            copy of the repository on your development system.
-            Once you have a local copy of a repository, you can take steps to
-            develop locally.
-            For examples on how to clone Git repositories, see the
-            "<a class="link" href="../dev-manual/working-with-yocto-project-source-files.html" target="_self">Working With Yocto Project Source Files</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p>
-<p>
-            It is important to understand that Git tracks content change and
-            not files.
-            Git uses "branches" to organize different development efforts.
-            For example, the <code class="filename">poky</code> repository has
-            several branches that include the current "sumo"
-            branch, the "master" branch, and many branches for past
-            Yocto Project releases.
-            You can see all the branches by going to
-            <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/" target="_self">http://git.yoctoproject.org/cgit.cgi/poky/</a> and
-            clicking on the
-            <code class="filename"><a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/refs/heads" target="_self">[...]</a></code>
-            link beneath the "Branch" heading.
-        </p>
-<p>
-            Each of these branches represents a specific area of development.
-            The "master" branch represents the current or most recent
-            development.
-            All other branches represent offshoots of the "master" branch.
-        </p>
-<p>
-            When you create a local copy of a Git repository, the copy has
-            the same set of branches as the original.
-            This means you can use Git to create a local working area
-            (also called a branch) that tracks a specific development branch
-            from the upstream source Git repository.
-            in other words, you can define your local Git environment to
-            work on any development branch in the repository.
-            To help illustrate, consider the following example Git commands:
-            </p>
-<pre class="literallayout">
-     $ cd ~
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git checkout -b sumo origin/sumo
-            </pre>
-<p>
-            In the previous example after moving to the home directory, the
-            <code class="filename">git clone</code> command creates a
-            local copy of the upstream <code class="filename">poky</code> Git repository.
-            By default, Git checks out the "master" branch for your work.
-            After changing the working directory to the new local repository
-            (i.e. <code class="filename">poky</code>), the
-            <code class="filename">git checkout</code> command creates
-            and checks out a local branch named "sumo", which
-            tracks the upstream "origin/sumo" branch.
-            Changes you make while in this branch would ultimately affect
-            the upstream "sumo" branch of the
-            <code class="filename">poky</code> repository.
-        </p>
-<p>
-            It is important to understand that when you create and checkout a
-            local working branch based on a branch name,
-            your local environment matches the "tip" of that particular
-            development branch at the time you created your local branch,
-            which could be different from the files in the "master" branch
-            of the upstream repository.
-            In other words, creating and checking out a local branch based on
-            the "sumo" branch name is not the same as
-            cloning and checking out the "master" branch if the repository.
-            Keep reading to see how you create a local snapshot of a Yocto
-            Project Release.
-        </p>
-<p>
-            Git uses "tags" to mark specific changes in a repository.
-            Typically, a tag is used to mark a special point such as the final
-            change before a project is released.
-            You can see the tags used with the <code class="filename">poky</code> Git
-            repository by going to
-            <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/" target="_self">http://git.yoctoproject.org/cgit.cgi/poky/</a> and
-            clicking on the
-            <code class="filename"><a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/refs/tags" target="_self">[...]</a></code>
-            link beneath the "Tag" heading.
-        </p>
-<p>
-            Some key tags for the <code class="filename">poky</code> are
-            <code class="filename">jethro-14.0.3</code>,
-            <code class="filename">morty-16.0.1</code>,
-            <code class="filename">pyro-17.0.0</code>, and
-            <code class="filename">sumo-20.0.0</code>.
-            These tags represent Yocto Project releases.
-        </p>
-<p>
-            When you create a local copy of the Git repository, you also
-            have access to all the tags in the upstream repository.
-            Similar to branches, you can create and checkout a local working
-            Git branch based on a tag name.
-            When you do this, you get a snapshot of the Git repository that
-            reflects the state of the files when the change was made associated
-            with that tag.
-            The most common use is to checkout a working branch that matches
-            a specific Yocto Project release.
-            Here is an example:
-            </p>
-<pre class="literallayout">
-     $ cd ~
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git fetch --all --tags --prune
-     $ git checkout tags/pyro-17.0.0 -b my-pyro-17.0.0
-            </pre>
-<p>
-            In this example, the name of the top-level directory of your
-            local Yocto Project repository is <code class="filename">poky</code>.
-            After moving to the <code class="filename">poky</code> directory, the
-            <code class="filename">git fetch</code> command makes all the upstream
-            tags available locally in your repository.
-            Finally, the <code class="filename">git checkout</code> command
-            creates and checks out a branch named "my-pyro-17.0.0" that is
-            based on the specific change upstream in the repository
-            associated with the "pyro-17.0.0" tag.
-            The files in your repository now exactly match that particular
-            Yocto Project release as it is tagged in the upstream Git
-            repository.
-            It is important to understand that when you create and
-            checkout a local working branch based on a tag, your environment
-            matches a specific point in time and not the entire development
-            branch (i.e. the "tip" of the branch).
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/running-weston.html b/documentation/getting-started/eclipse/html/getting-started/running-weston.html
deleted file mode 100644
index b68f574134..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/running-weston.html
+++ /dev/null
@@ -1,53 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.6.3.�Running Weston</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="wayland.html" title="3.6.�Wayland">
-<link rel="prev" href="enable-installation-in-an-image.html" title="3.6.2.2.�Installing">
-<link rel="next" href="overview-licenses.html" title="3.7.�Licenses">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.3.�Running Weston">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="running-weston"></a>3.6.3.�Running Weston</h3></div></div></div>
-<p>
-                To run Weston inside X11, enabling it as described earlier and
-                building a Sato image is sufficient.
-                If you are running your image under Sato, a Weston Launcher
-                appears in the "Utility" category.
-            </p>
-<p>
-                Alternatively, you can run Weston through the command-line
-                interpretor (CLI), which is better suited for development work.
-                To run Weston under the CLI, you need to do the following after
-                your image is built:
-                </p>
-<div class="orderedlist"><ol class="orderedlist" type="1">
-<li class="listitem">
-<p>
-                        Run these commands to export
-                        <code class="filename">XDG_RUNTIME_DIR</code>:
-                        </p>
-<pre class="literallayout">
-     mkdir -p /tmp/$USER-weston
-     chmod 0700 /tmp/$USER-weston
-     export XDG_RUNTIME_DIR=/tmp/$USER-weston
-                        </pre>
-<p>
-                        </p>
-</li>
-<li class="listitem">
-<p>
-                        Launch Weston in the shell:
-                        </p>
-<pre class="literallayout">
-     weston
-                        </pre>
-</li>
-</ol></div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/scms.html b/documentation/getting-started/eclipse/html/getting-started/scms.html
deleted file mode 100644
index f2ec54340c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/scms.html
+++ /dev/null
@@ -1,42 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.3.3.�Source Control Managers (Optional)</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="sources-dev-environment.html" title="2.8.3.�Sources">
-<link rel="prev" href="local-projects.html" title="2.8.3.2.�Local Projects">
-<link rel="next" href="source-mirrors.html" title="2.8.3.4.�Source Mirror(s)">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.3.�Source Control Managers (Optional)">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="scms"></a>2.8.3.3.�Source Control Managers (Optional)</h4></div></div></div>
-<p>
-                Another place the build system can get source files from is
-                through an SCM such as Git or Subversion.
-                In this case, a repository is cloned or checked out.
-                The
-                <a class="link" href="../ref-manual/ref-tasks-fetch.html" target="_self"><code class="filename">do_fetch</code></a>
-                task inside BitBake uses
-                the <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a>
-                variable and the argument's prefix to determine the correct
-                fetcher module.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                For information on how to have the OpenEmbedded build system
-                generate tarballs for Git repositories and place them in the
-                <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a>
-                directory, see the
-                <a class="link" href="../ref-manual/var-BB_GENERATE_MIRROR_TARBALLS.html" target="_self"><code class="filename">BB_GENERATE_MIRROR_TARBALLS</code></a>
-                variable.
-            </div>
-<p>
-                When fetching a repository, BitBake uses the
-                <a class="link" href="../ref-manual/var-SRCREV.html" target="_self"><code class="filename">SRCREV</code></a>
-                variable to determine the specific revision from which to
-                build.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html
deleted file mode 100644
index d2cd6a480e..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html
+++ /dev/null
@@ -1,150 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.7.�Application Development SDK</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="images-dev-environment.html" title="2.8.6.�Images">
-<link rel="next" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.7.�Application Development SDK">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="sdk-dev-environment"></a>2.8.7.�Application Development SDK</h3></div></div></div>
-<p>
-            In the
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>,
-            the output labeled "Application Development SDK" represents an
-            SDK.
-            The SDK generation process differs depending on whether you build
-            a standard SDK
-            (e.g. <code class="filename">bitbake -c populate_sdk</code> <em class="replaceable"><code>imagename</code></em>)
-            or an extensible SDK
-            (e.g. <code class="filename">bitbake -c populate_sdk_ext</code> <em class="replaceable"><code>imagename</code></em>).
-            This section is going to take a closer look at this output:
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="810"><tr style="height: 653px"><td align="center"><img src="figures/sdk.png" align="middle" width="810"></td></tr></table>
-<p>
-        </p>
-<p>
-            The specific form of this output is a self-extracting
-            SDK installer (<code class="filename">*.sh</code>) that, when run,
-            installs the SDK, which consists of a cross-development
-            toolchain, a set of libraries and headers, and an SDK
-            environment setup script.
-            Running this installer essentially sets up your
-            cross-development environment.
-            You can think of the cross-toolchain as the "host"
-            part because it runs on the SDK machine.
-            You can think of the libraries and headers as the "target"
-            part because they are built for the target hardware.
-            The environment setup script is added so that you can initialize
-            the environment before using the tools.
-        </p>
-<div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Notes</h3>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    The Yocto Project supports several methods by which you can
-                    set up this cross-development environment.
-                    These methods include downloading pre-built SDK installers
-                    or building and installing your own SDK installer.
-                    </p></li>
-<li class="listitem"><p>
-                    For background information on cross-development toolchains
-                    in the Yocto Project development environment, see the
-                    "<a class="link" href="cross-development-toolchain-generation.html" title="3.2.�Cross-Development Toolchain Generation">Cross-Development Toolchain Generation</a>"
-                    section.
-                    </p></li>
-<li class="listitem"><p>
-                    For information on setting up a cross-development
-                    environment, see the
-                    <a class="link" href="../sdk-manual/index.html" target="_self">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>
-                    manual.
-                    </p></li>
-</ul></div>
-</div>
-<p>
-            Once built, the SDK installers are written out to the
-            <code class="filename">deploy/sdk</code> folder inside the
-            <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>
-            as shown in the figure at the beginning of this section.
-            Depending on the type of SDK, several variables exist that help
-            configure these files.
-            The following list shows the variables associated with a standard
-            SDK:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>:
-                    Points to the <code class="filename">deploy</code>
-                    directory.</p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>:
-                    Specifies the architecture of the machine
-                    on which the cross-development tools are run to
-                    create packages for the target hardware.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDKIMAGE_FEATURES.html" target="_self"><code class="filename">SDKIMAGE_FEATURES</code></a>:
-                    Lists the features to include in the "target" part
-                    of the SDK.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-TOOLCHAIN_HOST_TASK.html" target="_self"><code class="filename">TOOLCHAIN_HOST_TASK</code></a>:
-                    Lists packages that make up the host
-                    part of the SDK (i.e. the part that runs on
-                    the <code class="filename">SDKMACHINE</code>).
-                    When you use
-                    <code class="filename">bitbake -c populate_sdk <em class="replaceable"><code>imagename</code></em></code>
-                    to create the SDK, a set of default packages
-                    apply.
-                    This variable allows you to add more packages.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-TOOLCHAIN_TARGET_TASK.html" target="_self"><code class="filename">TOOLCHAIN_TARGET_TASK</code></a>:
-                    Lists packages that make up the target part
-                    of the SDK (i.e. the part built for the
-                    target hardware).
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDKPATH.html" target="_self"><code class="filename">SDKPATH</code></a>:
-                    Defines the default SDK installation path offered by the
-                    installation script.
-                    </p></li>
-</ul></div>
-<p>
-            This next list, shows the variables associated with an extensible
-            SDK:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>:
-                    Points to the <code class="filename">deploy</code> directory.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_EXT_TYPE.html" target="_self"><code class="filename">SDK_EXT_TYPE</code></a>:
-                    Controls whether or not shared state artifacts are copied
-                    into the extensible SDK.
-                    By default, all required shared state artifacts are copied
-                    into the SDK.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_INCLUDE_PKGDATA.html" target="_self"><code class="filename">SDK_INCLUDE_PKGDATA</code></a>:
-                    Specifies whether or not packagedata will be included in
-                    the extensible SDK for all recipes in the "world" target.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_INCLUDE_TOOLCHAIN.html" target="_self"><code class="filename">SDK_INCLUDE_TOOLCHAIN</code></a>:
-                    Specifies whether or not the toolchain will be included
-                    when building the extensible SDK.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_LOCAL_CONF_WHITELIST.html" target="_self"><code class="filename">SDK_LOCAL_CONF_WHITELIST</code></a>:
-                    A list of variables allowed through from the build system
-                    configuration into the extensible SDK configuration.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_LOCAL_CONF_BLACKLIST.html" target="_self"><code class="filename">SDK_LOCAL_CONF_BLACKLIST</code></a>:
-                    A list of variables not allowed through from the build
-                    system configuration into the extensible SDK configuration.
-                    </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_INHERIT_BLACKLIST.html" target="_self"><code class="filename">SDK_INHERIT_BLACKLIST</code></a>:
-                    A list of classes to remove from the
-                    <a class="link" href="../ref-manual/var-INHERIT.html" target="_self"><code class="filename">INHERIT</code></a>
-                    value globally within the extensible SDK configuration.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html
deleted file mode 100644
index 1dfda5fab5..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html
+++ /dev/null
@@ -1,72 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.6.�SDK Generation</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="image-generation-dev-environment.html" title="2.8.5.5.�Image Generation">
-<link rel="next" href="stamp-files-and-the-rerunning-of-tasks.html" title="2.8.5.7.�Stamp Files and the Rerunning of Tasks">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.6.�SDK Generation">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="sdk-generation-dev-environment"></a>2.8.5.6.�SDK Generation</h4></div></div></div>
-<p>
-                The OpenEmbedded build system uses BitBake to generate the
-                Software Development Kit (SDK) installer script for both the
-                standard and extensible SDKs:
-                <img src="figures/sdk-generation.png" align="middle">
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                For more information on the cross-development toolchain
-                generation, see the
-                "<a class="link" href="cross-development-toolchain-generation.html" title="3.2.�Cross-Development Toolchain Generation">Cross-Development Toolchain Generation</a>"
-                section.
-                For information on advantages gained when building a
-                cross-development toolchain using the
-                <a class="link" href="../ref-manual/ref-tasks-populate_sdk.html" target="_self"><code class="filename">do_populate_sdk</code></a>
-                task, see the
-                "<a class="link" href="../sdk-manual/sdk-building-an-sdk-installer.html" target="_self">Building an SDK Installer</a>"
-                section in the Yocto Project Application Development and the
-                Extensible Software Development Kit (SDK) manual.
-            </div>
-<p>
-                Like image generation, the SDK script process consists of
-                several stages and depends on many variables.
-                The <code class="filename">do_populate_sdk</code> and
-                <code class="filename">do_populate_sdk_ext</code> tasks use these
-                key variables to help create the list of packages to actually
-                install.
-                For information on the variables listed in the figure, see the
-                "<a class="link" href="sdk-dev-environment.html" title="2.8.7.�Application Development SDK">Application Development SDK</a>"
-                section.
-            </p>
-<p>
-                The <code class="filename">do_populate_sdk</code> task helps create
-                the standard SDK and handles two parts: a target part and a
-                host part.
-                The target part is the part built for the target hardware and
-                includes libraries and headers.
-                The host part is the part of the SDK that runs on the
-                <a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>.
-            </p>
-<p>
-                The <code class="filename">do_populate_sdk_ext</code> task helps create
-                the extensible SDK and handles host and target parts
-                differently than its counter part does for the standard SDK.
-                For the extensible SDK, the task encapsulates the build system,
-                which includes everything needed (host and target) for the SDK.
-            </p>
-<p>
-                Regardless of the type of SDK being constructed, the
-                tasks perform some cleanup after which a cross-development
-                environment setup script and any needed configuration files
-                are created.
-                The final output is the Cross-development
-                toolchain installation script (<code class="filename">.sh</code> file),
-                which includes the environment setup script.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html b/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html
deleted file mode 100644
index 644e404b66..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html
+++ /dev/null
@@ -1,122 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.8.�Setscene Tasks and Shared State</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="stamp-files-and-the-rerunning-of-tasks.html" title="2.8.5.7.�Stamp Files and the Rerunning of Tasks">
-<link rel="next" href="images-dev-environment.html" title="2.8.6.�Images">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.8.�Setscene Tasks and Shared State">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="setscene-tasks-and-shared-state"></a>2.8.5.8.�Setscene Tasks and Shared State</h4></div></div></div>
-<p>
-                The description of tasks so far assumes that BitBake needs to
-                build everything and there are no prebuilt objects available.
-                BitBake does support skipping tasks if prebuilt objects are
-                available.
-                These objects are usually made available in the form of a
-                shared state (sstate) cache.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    For information on variables affecting sstate, see the
-                    <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a>
-                    and
-                    <a class="link" href="../ref-manual/var-SSTATE_MIRRORS.html" target="_self"><code class="filename">SSTATE_MIRRORS</code></a>
-                    variables.
-                </div>
-<p>
-            </p>
-<p>
-                The idea of a setscene task (i.e
-                <code class="filename">do_</code><em class="replaceable"><code>taskname</code></em><code class="filename">_setscene</code>)
-                is a version of the task where
-                instead of building something, BitBake can skip to the end
-                result and simply place a set of files into specific locations
-                as needed.
-                In some cases, it makes sense to have a setscene task variant
-                (e.g. generating package files in the
-                <code class="filename">do_package_write_*</code> task).
-                In other cases, it does not make sense, (e.g. a
-                <a class="link" href="../ref-manual/ref-tasks-patch.html" target="_self"><code class="filename">do_patch</code></a>
-                task or
-                <a class="link" href="../ref-manual/ref-tasks-unpack.html" target="_self"><code class="filename">do_unpack</code></a>
-                task) since the work involved would be equal to or greater than
-                the underlying task.
-            </p>
-<p>
-                In the OpenEmbedded build system, the common tasks that have
-                setscene variants are
-                <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>,
-                <code class="filename">do_package_write_*</code>,
-                <a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a>,
-                <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>,
-                and
-                <a class="link" href="../ref-manual/ref-tasks-populate_sysroot.html" target="_self"><code class="filename">do_populate_sysroot</code></a>.
-                Notice that these are most of the tasks whose output is an
-                end result.
-            </p>
-<p>
-                The OpenEmbedded build system has knowledge of the relationship
-                between these tasks and other tasks that precede them.
-                For example, if BitBake runs
-                <code class="filename">do_populate_sysroot_setscene</code> for
-                something, there is little point in running any of the
-                <code class="filename">do_fetch</code>, <code class="filename">do_unpack</code>,
-                <code class="filename">do_patch</code>,
-                <code class="filename">do_configure</code>,
-                <code class="filename">do_compile</code>, and
-                <code class="filename">do_install</code> tasks.
-                However, if <code class="filename">do_package</code> needs to be run,
-                BitBake would need to run those other tasks.
-            </p>
-<p>
-                It becomes more complicated if everything can come from an
-                sstate cache because some objects are simply not required at
-                all.
-                For example, you do not need a compiler or native tools, such
-                as quilt, if there is nothing to compile or patch.
-                If the <code class="filename">do_package_write_*</code> packages are
-                available from sstate, BitBake does not need the
-                <code class="filename">do_package</code> task data.
-            </p>
-<p>
-                To handle all these complexities, BitBake runs in two phases.
-                The first is the "setscene" stage.
-                During this stage, BitBake first checks the sstate cache for
-                any targets it is planning to build.
-                BitBake does a fast check to see if the object exists rather
-                than a complete download.
-                If nothing exists, the second phase, which is the setscene
-                stage, completes and the main build proceeds.
-            </p>
-<p>
-                If objects are found in the sstate cache, the OpenEmbedded
-                build system works backwards from the end targets specified
-                by the user.
-                For example, if an image is being built, the OpenEmbedded build
-                system first looks for the packages needed for that image and
-                the tools needed to construct an image.
-                If those are available, the compiler is not needed.
-                Thus, the compiler is not even downloaded.
-                If something was found to be unavailable, or the download or
-                setscene task fails, the OpenEmbedded build system then tries
-                to install dependencies, such as the compiler, from the cache.
-            </p>
-<p>
-                The availability of objects in the sstate cache is handled by
-                the function specified by the
-                <a class="link" href="../bitbake-user-manual/var-BB_HASHCHECK_FUNCTION.html" target="_self"><code class="filename">BB_HASHCHECK_FUNCTION</code></a>
-                variable and returns a list of the objects that are available.
-                The function specified by the
-                <a class="link" href="../bitbake-user-manual/var-BB_SETSCENE_DEPVALID.html" target="_self"><code class="filename">BB_SETSCENE_DEPVALID</code></a>
-                variable is the function that determines whether a given
-                dependency needs to be followed, and whether for any given
-                relationship the function needs to be passed.
-                The function returns a True or False value.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html b/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html
deleted file mode 100644
index c5c6be04a3..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html
+++ /dev/null
@@ -1,93 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.�Shared State Cache</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="cross-development-toolchain-generation.html" title="3.2.�Cross-Development Toolchain Generation">
-<link rel="next" href="overall-architecture.html" title="3.3.1.�Overall Architecture">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.�Shared State Cache">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="shared-state-cache"></a>3.3.�Shared State Cache</h2></div></div></div>
-<p>
-            By design, the OpenEmbedded build system builds everything from
-            scratch unless BitBake can determine that parts do not need to be
-            rebuilt.
-            Fundamentally, building from scratch is attractive as it means all
-            parts are built fresh and there is no possibility of stale data
-            causing problems.
-            When developers hit problems, they typically default back to
-            building from scratch so they know the state of things from the
-            start.
-        </p>
-<p>
-            Building an image from scratch is both an advantage and a
-            disadvantage to the process.
-            As mentioned in the previous paragraph, building from scratch
-            ensures that everything is current and starts from a known state.
-            However, building from scratch also takes much longer as it
-            generally means rebuilding things that do not necessarily need
-            to be rebuilt.
-        </p>
-<p>
-            The Yocto Project implements shared state code that supports
-            incremental builds.
-            The implementation of the shared state code answers the following
-            questions that were fundamental roadblocks within the OpenEmbedded
-            incremental build support system:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    What pieces of the system have changed and what pieces have
-                    not changed?
-                    </p></li>
-<li class="listitem"><p>
-                    How are changed pieces of software removed and replaced?
-                    </p></li>
-<li class="listitem"><p>
-                    How are pre-built components that do not need to be rebuilt
-                    from scratch used when they are available?
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            For the first question, the build system detects changes in the
-            "inputs" to a given task by creating a checksum (or signature) of
-            the task's inputs.
-            If the checksum changes, the system assumes the inputs have changed
-            and the task needs to be rerun.
-            For the second question, the shared state (sstate) code tracks
-            which tasks add which output to the build process.
-            This means the output from a given task can be removed, upgraded
-            or otherwise manipulated.
-            The third question is partly addressed by the solution for the
-            second question assuming the build system can fetch the sstate
-            objects from remote locations and install them if they are deemed
-            to be valid.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                The OpenEmbedded build system does not maintain
-                <a class="link" href="../ref-manual/var-PR.html" target="_self"><code class="filename">PR</code></a>
-                information as part of the shared state packages.
-                Consequently, considerations exist that affect maintaining
-                shared state feeds.
-                For information on how the OpenEmbedded build system
-                works with packages and can track incrementing
-                <code class="filename">PR</code> information, see the
-                "<a class="link" href="../dev-manual/automatically-incrementing-a-binary-package-revision-number.html" target="_self">Automatically Incrementing a Binary Package Revision Number</a>"
-                section in the Yocto Project Development Tasks Manual.
-            </div>
-<p>
-        </p>
-<p>
-            The rest of this section goes into detail about the overall
-            incremental build architecture, the checksums (signatures), shared
-            state, and some tips and tricks.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/shared-state.html b/documentation/getting-started/eclipse/html/getting-started/shared-state.html
deleted file mode 100644
index 4389684f3b..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/shared-state.html
+++ /dev/null
@@ -1,268 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.3.�Shared State</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="shared-state-cache.html" title="3.3.�Shared State Cache">
-<link rel="prev" href="overview-checksums.html" title="3.3.2.�Checksums (Signatures)">
-<link rel="next" href="tips-and-tricks.html" title="3.3.4.�Tips and Tricks">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.3.�Shared State">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="shared-state"></a>3.3.3.�Shared State</h3></div></div></div>
-<p>
-                Checksums and dependencies, as discussed in the previous
-                section, solve half the problem of supporting a shared state.
-                The other part of the problem is being able to use checksum
-                information during the build and being able to reuse or rebuild
-                specific components.
-            </p>
-<p>
-                The
-                <a class="link" href="../ref-manual/ref-classes-sstate.html" target="_self"><code class="filename">sstate</code></a>
-                class is a relatively generic implementation of how to
-                "capture" a snapshot of a given task.
-                The idea is that the build process does not care about the
-                source of a task's output.
-                Output could be freshly built or it could be downloaded and
-                unpacked from somewhere - the build process does not need to
-                worry about its origin.
-            </p>
-<p>
-                There are two types of output, one is just about creating a
-                directory in
-                <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>.
-                A good example is the output of either
-                <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a>
-                or
-                <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>.
-                The other type of output occurs when a set of data is merged
-                into a shared directory tree such as the sysroot.
-            </p>
-<p>
-                The Yocto Project team has tried to keep the details of the
-                implementation hidden in <code class="filename">sstate</code> class.
-                From a user's perspective, adding shared state wrapping to a task
-                is as simple as this
-                <a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a>
-                example taken from the
-                <a class="link" href="../ref-manual/ref-classes-deploy.html" target="_self"><code class="filename">deploy</code></a>
-                class:
-                </p>
-<pre class="literallayout">
-     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
-     SSTATETASKS += "do_deploy"
-     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
-     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
-
-     python do_deploy_setscene () {
-         sstate_setscene(d)
-     }
-     addtask do_deploy_setscene
-     do_deploy[dirs] = "${DEPLOYDIR} ${B}"
-                </pre>
-<p>
-                The following list explains the previous example:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                        Adding "do_deploy" to <code class="filename">SSTATETASKS</code>
-                        adds some required sstate-related processing, which is
-                        implemented in the
-                        <a class="link" href="../ref-manual/ref-classes-sstate.html" target="_self"><code class="filename">sstate</code></a>
-                        class, to before and after the
-                        <a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a>
-                        task.
-                        </p></li>
-<li class="listitem"><p>
-                        The
-                        <code class="filename">do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"</code>
-                        declares that <code class="filename">do_deploy</code> places its
-                        output in <code class="filename">${DEPLOYDIR}</code> when run
-                        normally (i.e. when not using the sstate cache).
-                        This output becomes the input to the shared state cache.
-                        </p></li>
-<li class="listitem">
-<p>
-                        The
-                        <code class="filename">do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"</code>
-                        line causes the contents of the shared state cache to be
-                        copied to <code class="filename">${DEPLOY_DIR_IMAGE}</code>.
-                        </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                            If <code class="filename">do_deploy</code> is not already in
-                            the shared state cache or if its input checksum
-                            (signature) has changed from when the output was
-                            cached, the task will be run to populate the shared
-                            state cache, after which the contents of the shared
-                            state cache is copied to
-                            <code class="filename">${DEPLOY_DIR_IMAGE}</code>.
-                            If <code class="filename">do_deploy</code> is in the shared
-                            state cache and its signature indicates that the
-                            cached output is still valid (i.e. if no
-                            relevant task inputs have changed), then the
-                            contents of the shared state cache will be copied
-                            directly to
-                            <code class="filename">${DEPLOY_DIR_IMAGE}</code> by the
-                            <code class="filename">do_deploy_setscene</code> task
-                            instead, skipping the
-                            <code class="filename">do_deploy</code> task.
-                        </div>
-<p>
-                        </p>
-</li>
-<li class="listitem">
-<p>
-                        The following task definition is glue logic needed to
-                        make the previous settings effective:
-                        </p>
-<pre class="literallayout">
-     python do_deploy_setscene () {
-         sstate_setscene(d)
-     }
-     addtask do_deploy_setscene
-                        </pre>
-<p>
-                        <code class="filename">sstate_setscene()</code> takes the flags
-                        above as input and accelerates the
-                        <code class="filename">do_deploy</code> task through the
-                        shared state cache if possible.
-                        If the task was accelerated,
-                        <code class="filename">sstate_setscene()</code> returns True.
-                        Otherwise, it returns False, and the normal
-                        <code class="filename">do_deploy</code> task runs.
-                        For more information, see the
-                        "<a class="link" href="../bitbake-user-manual/setscene.html" target="_self">setscene</a>"
-                        section in the BitBake User Manual.
-                        </p>
-</li>
-<li class="listitem">
-<p>
-                        The <code class="filename">do_deploy[dirs] = "${DEPLOYDIR} ${B}"</code>
-                        line creates <code class="filename">${DEPLOYDIR}</code> and
-                        <code class="filename">${B}</code> before the
-                        <code class="filename">do_deploy</code> task runs, and also sets
-                        the current working directory of
-                        <code class="filename">do_deploy</code> to
-                        <code class="filename">${B}</code>.
-                        For more information, see the
-                        "<a class="link" href="../bitbake-user-manual/variable-flags.html" target="_self">Variable Flags</a>"
-                        section in the BitBake User Manual.
-                        </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                            In cases where
-                            <code class="filename">sstate-inputdirs</code> and
-                            <code class="filename">sstate-outputdirs</code> would be the
-                            same, you can use
-                            <code class="filename">sstate-plaindirs</code>.
-                            For example, to preserve the
-                            <code class="filename">${PKGD}</code> and
-                            <code class="filename">${PKGDEST}</code> output from the
-                            <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>
-                            task, use the following:
-                            <pre class="literallayout">
-     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
-                            </pre>
-</div>
-<p>
-                        </p>
-</li>
-<li class="listitem">
-<p>
-                        <code class="filename">sstate-inputdirs</code> and
-                        <code class="filename">sstate-outputdirs</code> can also be used
-                        with multiple directories.
-                        For example, the following declares
-                        <code class="filename">PKGDESTWORK</code> and
-                        <code class="filename">SHLIBWORK</code> as shared state
-                        input directories, which populates the shared state
-                        cache, and <code class="filename">PKGDATA_DIR</code> and
-                        <code class="filename">SHLIBSDIR</code> as the corresponding
-                        shared state output directories:
-                        </p>
-<pre class="literallayout">
-     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
-     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
-                        </pre>
-<p>
-                        </p>
-</li>
-<li class="listitem">
-<p>
-                        These methods also include the ability to take a
-                        lockfile when manipulating shared state directory
-                        structures, for cases where file additions or removals
-                        are sensitive:
-                        </p>
-<pre class="literallayout">
-     do_package[sstate-lockfile] = "${PACKAGELOCK}"
-                        </pre>
-<p>
-                        </p>
-</li>
-</ul></div>
-<p>
-            </p>
-<p>
-                Behind the scenes, the shared state code works by looking in
-                <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a>
-                and
-                <a class="link" href="../ref-manual/var-SSTATE_MIRRORS.html" target="_self"><code class="filename">SSTATE_MIRRORS</code></a>
-                for shared state files.
-                Here is an example:
-                </p>
-<pre class="literallayout">
-     SSTATE_MIRRORS ?= "\
-     file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
-     file://.* file:///some/local/dir/sstate/PATH"
-                </pre>
-<p>
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    The shared state directory
-                    (<code class="filename">SSTATE_DIR</code>) is organized into
-                    two-character subdirectories, where the subdirectory
-                    names are based on the first two characters of the hash.
-                    If the shared state directory structure for a mirror has the
-                    same structure as <code class="filename">SSTATE_DIR</code>, you must
-                    specify "PATH" as part of the URI to enable the build system
-                    to map to the appropriate subdirectory.
-                </div>
-<p>
-            </p>
-<p>
-                The shared state package validity can be detected just by
-                looking at the filename since the filename contains the task
-                checksum (or signature) as described earlier in this section.
-                If a valid shared state package is found, the build process
-                downloads it and uses it to accelerate the task.
-            </p>
-<p>
-                The build processes use the <code class="filename">*_setscene</code>
-                tasks for the task acceleration phase.
-                BitBake goes through this phase before the main execution
-                code and tries to accelerate any tasks for which it can find
-                shared state packages.
-                If a shared state package for a task is available, the
-                shared state package is used.
-                This means the task and any tasks on which it is dependent
-                are not executed.
-            </p>
-<p>
-                As a real world example, the aim is when building an IPK-based
-                image, only the
-                <a class="link" href="../ref-manual/ref-tasks-package_write_ipk.html" target="_self"><code class="filename">do_package_write_ipk</code></a>
-                tasks would have their shared state packages fetched and
-                extracted.
-                Since the sysroot is not used, it would never get extracted.
-                This is another reason why a task-based approach is preferred
-                over a recipe-based approach, which would have to install the
-                output from every task.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/software-layer.html b/documentation/getting-started/eclipse/html/getting-started/software-layer.html
deleted file mode 100644
index 26e169a281..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/software-layer.html
+++ /dev/null
@@ -1,27 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.2.3.�Software Layer</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2.�Metadata, Machine Configuration, and Policy Configuration">
-<link rel="prev" href="bsp-layer.html" title="2.8.2.2.�BSP Layer">
-<link rel="next" href="sources-dev-environment.html" title="2.8.3.�Sources">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.3.�Software Layer">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="software-layer"></a>2.8.2.3.�Software Layer</h4></div></div></div>
-<p>
-                The software layer provides the Metadata for additional
-                software packages used during the build.
-                This layer does not include Metadata that is specific to the
-                distribution or the machine, which are found in their
-                respective layers.
-            </p>
-<p>
-                This layer contains any new recipes that your project needs
-                in the form of recipe files.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.html
deleted file mode 100644
index afcdafdc76..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.html
+++ /dev/null
@@ -1,93 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.1.�Source Fetching</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="next" href="patching-dev-environment.html" title="2.8.5.2.�Patching">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.1.�Source Fetching">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="source-fetching-dev-environment"></a>2.8.5.1.�Source Fetching</h4></div></div></div>
-<p>
-                The first stages of building a recipe are to fetch and unpack
-                the source code:
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="585"><tr style="height: 450px"><td align="center"><img src="figures/source-fetching.png" align="middle" width="585"></td></tr></table>
-<p>
-            </p>
-<p>
-                The
-                <a class="link" href="../ref-manual/ref-tasks-fetch.html" target="_self"><code class="filename">do_fetch</code></a>
-                and
-                <a class="link" href="../ref-manual/ref-tasks-unpack.html" target="_self"><code class="filename">do_unpack</code></a>
-                tasks fetch the source files and unpack them into the work
-                directory.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    For every local file (e.g. <code class="filename">file://</code>)
-                    that is part of a recipe's
-                    <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a>
-                    statement, the OpenEmbedded build system takes a checksum
-                    of the file for the recipe and inserts the checksum into
-                    the signature for the <code class="filename">do_fetch</code>.
-                    If any local file has been modified, the
-                    <code class="filename">do_fetch</code> task and all tasks that
-                    depend on it are re-executed.
-                </div>
-<p>
-                By default, everything is accomplished in the
-                <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>,
-                which has a defined structure.
-                For additional general information on the Build Directory,
-                see the
-                "<a class="link" href="../ref-manual/structure-core-build.html" target="_self"><code class="filename">build/</code></a>"
-                section in the Yocto Project Reference Manual.
-            </p>
-<p>
-                Unpacked source files are pointed to by the
-                <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a>
-                variable.
-                Each recipe has an area in the Build Directory where the
-                unpacked source code resides.
-                The name of that directory for any given recipe is defined from
-                several different variables.
-                You can see the variables that define these directories
-                by looking at the figure:
-                </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a> -
-                        The base directory where the OpenEmbedded build system
-                        performs all its work during the build.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_ARCH.html" target="_self"><code class="filename">PACKAGE_ARCH</code></a> -
-                        The architecture of the built package or packages.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-TARGET_OS.html" target="_self"><code class="filename">TARGET_OS</code></a> -
-                        The operating system of the target device.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PN.html" target="_self"><code class="filename">PN</code></a> -
-                        The name of the built package.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PV.html" target="_self"><code class="filename">PV</code></a> -
-                        The version of the recipe used to build the package.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-PR.html" target="_self"><code class="filename">PR</code></a> -
-                        The revision of the recipe used to build the package.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a> -
-                        The location within <code class="filename">TMPDIR</code> where
-                        a specific package is built.
-                        </p></li>
-<li class="listitem"><p><a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a> -
-                        Contains the unpacked source files for a given recipe.
-                        </p></li>
-</ul></div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html b/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html
deleted file mode 100644
index 178903c96e..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html
+++ /dev/null
@@ -1,37 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.3.4.�Source Mirror(s)</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="sources-dev-environment.html" title="2.8.3.�Sources">
-<link rel="prev" href="scms.html" title="2.8.3.3.�Source Control Managers (Optional)">
-<link rel="next" href="package-feeds-dev-environment.html" title="2.8.4.�Package Feeds">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.4.�Source Mirror(s)">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="source-mirrors"></a>2.8.3.4.�Source Mirror(s)</h4></div></div></div>
-<p>
-                Two kinds of mirrors exist: pre-mirrors and regular mirrors.
-                The
-                <a class="link" href="../ref-manual/var-PREMIRRORS.html" target="_self"><code class="filename">PREMIRRORS</code></a>
-                and
-                <a class="link" href="../ref-manual/var-MIRRORS.html" target="_self"><code class="filename">MIRRORS</code></a>
-                variables point to these, respectively.
-                BitBake checks pre-mirrors before looking upstream for any
-                source files.
-                Pre-mirrors are appropriate when you have a shared directory
-                that is not a directory defined by the
-                <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a>
-                variable.
-                A Pre-mirror typically points to a shared directory that is
-                local to your organization.
-            </p>
-<p>
-                Regular mirrors can be any site across the Internet that is
-                used as an alternative location for source code should the
-                primary site not be functioning for some reason or another.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html
deleted file mode 100644
index ab7718074f..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html
+++ /dev/null
@@ -1,80 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.3.�Sources</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="software-layer.html" title="2.8.2.3.�Software Layer">
-<link rel="next" href="upstream-project-releases.html" title="2.8.3.1.�Upstream Project Releases">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.�Sources">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="sources-dev-environment"></a>2.8.3.�Sources</h3></div></div></div>
-<p>
-            In order for the OpenEmbedded build system to create an image or
-            any target, it must be able to access source files.
-            The
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>
-            represents source files using the "Upstream Project Releases",
-            "Local Projects", and "SCMs (optional)" boxes.
-            The figure represents mirrors, which also play a role in locating
-            source files, with the "Source Mirror(s)" box.
-        </p>
-<p>
-            The method by which source files are ultimately organized is
-            a function of the project.
-            For example, for released software, projects tend to use tarballs
-            or other archived files that can capture the state of a release
-            guaranteeing that it is statically represented.
-            On the other hand, for a project that is more dynamic or
-            experimental in nature, a project might keep source files in a
-            repository controlled by a Source Control Manager (SCM) such as
-            Git.
-            Pulling source from a repository allows you to control
-            the point in the repository (the revision) from which you want to
-            build software.
-            Finally, a combination of the two might exist, which would give the
-            consumer a choice when deciding where to get source files.
-        </p>
-<p>
-            BitBake uses the
-            <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a>
-            variable to point to source files regardless of their location.
-            Each recipe must have a <code class="filename">SRC_URI</code> variable
-            that points to the source.
-        </p>
-<p>
-            Another area that plays a significant role in where source files
-            come from is pointed to by the
-            <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a>
-            variable.
-            This area is a cache that can hold previously downloaded source.
-            You can also instruct the OpenEmbedded build system to create
-            tarballs from Git repositories, which is not the default behavior,
-            and store them in the <code class="filename">DL_DIR</code> by using the
-            <a class="link" href="../ref-manual/var-BB_GENERATE_MIRROR_TARBALLS.html" target="_self"><code class="filename">BB_GENERATE_MIRROR_TARBALLS</code></a>
-            variable.
-        </p>
-<p>
-            Judicious use of a <code class="filename">DL_DIR</code> directory can
-            save the build system a trip across the Internet when looking
-            for files.
-            A good method for using a download directory is to have
-            <code class="filename">DL_DIR</code> point to an area outside of your
-            Build Directory.
-            Doing so allows you to safely delete the Build Directory
-            if needed without fear of removing any downloaded source file.
-        </p>
-<p>
-            The remainder of this section provides a deeper look into the
-            source files and the mirrors.
-            Here is a more detailed look at the source file area of the
-            base figure:
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 675px"><td align="center"><img src="figures/source-input.png" align="middle" width="630"></td></tr></table>
-<p>
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html b/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html
deleted file mode 100644
index b649c69b2b..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html
+++ /dev/null
@@ -1,83 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.5.7.�Stamp Files and the Rerunning of Tasks</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="bitbake-dev-environment.html" title="2.8.5.�BitBake">
-<link rel="prev" href="sdk-generation-dev-environment.html" title="2.8.5.6.�SDK Generation">
-<link rel="next" href="setscene-tasks-and-shared-state.html" title="2.8.5.8.�Setscene Tasks and Shared State">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.7.�Stamp Files and the Rerunning of Tasks">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="stamp-files-and-the-rerunning-of-tasks"></a>2.8.5.7.�Stamp Files and the Rerunning of Tasks</h4></div></div></div>
-<p>
-                For each task that completes successfully, BitBake writes a
-                stamp file into the
-                <a class="link" href="../ref-manual/var-STAMPS_DIR.html" target="_self"><code class="filename">STAMPS_DIR</code></a>
-                directory.
-                The beginning of the stamp file's filename is determined by the
-                <a class="link" href="../ref-manual/var-STAMP.html" target="_self"><code class="filename">STAMP</code></a>
-                variable, and the end of the name consists of the task's name
-                and current
-                <a class="link" href="overview-checksums.html" title="3.3.2.�Checksums (Signatures)">input checksum</a>.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    This naming scheme assumes that
-                    <a class="link" href="../bitbake-user-manual/var-BB_SIGNATURE_HANDLER.html" target="_self"><code class="filename">BB_SIGNATURE_HANDLER</code></a>
-                    is "OEBasicHash", which is almost always the case in
-                    current OpenEmbedded.
-                </div>
-<p>
-                To determine if a task needs to be rerun, BitBake checks if a
-                stamp file with a matching input checksum exists for the task.
-                If such a stamp file exists, the task's output is assumed to
-                exist and still be valid.
-                If the file does not exist, the task is rerun.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>The stamp mechanism is more general than the shared
-                    state (sstate) cache mechanism described in the
-                    "<a class="link" href="setscene-tasks-and-shared-state.html" title="2.8.5.8.�Setscene Tasks and Shared State">Setscene Tasks and Shared State</a>"
-                    section.
-                    BitBake avoids rerunning any task that has a valid
-                    stamp file, not just tasks that can be accelerated through
-                    the sstate cache.</p>
-<p>However, you should realize that stamp files only
-                    serve as a marker that some work has been done and that
-                    these files do not record task output.
-                    The actual task output would usually be somewhere in
-                    <a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a>
-                    (e.g. in some recipe's
-                    <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>.)
-                    What the sstate cache mechanism adds is a way to cache task
-                    output that can then be shared between build machines.
-                    </p>
-</div>
-<p>
-                Since <code class="filename">STAMPS_DIR</code> is usually a subdirectory
-                of <code class="filename">TMPDIR</code>, removing
-                <code class="filename">TMPDIR</code> will also remove
-                <code class="filename">STAMPS_DIR</code>, which means tasks will
-                properly be rerun to repopulate <code class="filename">TMPDIR</code>.
-            </p>
-<p>
-                If you want some task to always be considered "out of date",
-                you can mark it with the
-                <a class="link" href="../bitbake-user-manual/variable-flags.html" target="_self"><code class="filename">nostamp</code></a>
-                varflag.
-                If some other task depends on such a task, then that task will
-                also always be considered out of date, which might not be what
-                you want.
-            </p>
-<p>
-                For details on how to view information about a task's
-                signature, see the
-                "<a class="link" href="../dev-manual/dev-viewing-task-variable-dependencies.html" target="_self">Viewing Task Variable Dependencies</a>"
-                section in the Yocto Project Development Tasks Manual.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html b/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html
deleted file mode 100644
index d0c8522d95..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html
+++ /dev/null
@@ -1,22 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.3.4.�Tips and Tricks</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="shared-state-cache.html" title="3.3.�Shared State Cache">
-<link rel="prev" href="shared-state.html" title="3.3.3.�Shared State">
-<link rel="next" href="overview-debugging.html" title="3.3.4.1.�Debugging">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.4.�Tips and Tricks">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="tips-and-tricks"></a>3.3.4.�Tips and Tricks</h3></div></div></div>
-<p>
-                The code in the build system that supports incremental builds
-                is not simple code.
-                This section presents some tips and tricks that help you work
-                around issues related to shared state code.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html b/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html
deleted file mode 100644
index ef9bc18dde..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html
+++ /dev/null
@@ -1,25 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.3.1.�Upstream Project Releases</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="sources-dev-environment.html" title="2.8.3.�Sources">
-<link rel="prev" href="sources-dev-environment.html" title="2.8.3.�Sources">
-<link rel="next" href="local-projects.html" title="2.8.3.2.�Local Projects">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.1.�Upstream Project Releases">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="upstream-project-releases"></a>2.8.3.1.�Upstream Project Releases</h4></div></div></div>
-<p>
-                Upstream project releases exist anywhere in the form of an
-                archived file (e.g. tarball or zip file).
-                These files correspond to individual recipes.
-                For example, the figure uses specific releases each for
-                BusyBox, Qt, and Dbus.
-                An archive file can be for any released product that can be
-                built using a recipe.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/user-configuration.html b/documentation/getting-started/eclipse/html/getting-started/user-configuration.html
deleted file mode 100644
index 6f10791e7a..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/user-configuration.html
+++ /dev/null
@@ -1,232 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.8.1.�User Configuration</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="prev" href="development-concepts.html" title="2.8.�Development Concepts">
-<link rel="next" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2.�Metadata, Machine Configuration, and Policy Configuration">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.1.�User Configuration">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="user-configuration"></a>2.8.1.�User Configuration</h3></div></div></div>
-<p>
-            User configuration helps define the build.
-            Through user configuration, you can tell BitBake the
-            target architecture for which you are building the image,
-            where to store downloaded source, and other build properties.
-        </p>
-<p>
-            The following figure shows an expanded representation of the
-            "User Configuration" box of the
-            <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>:
-        </p>
-<p>
-            </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 405px"><td align="center"><img src="figures/user-configuration.png" align="middle" height="405"></td></tr></table>
-<p>
-        </p>
-<p>
-            BitBake needs some basic configuration files in order to complete
-            a build.
-            These files are <code class="filename">*.conf</code> files.
-            The minimally necessary ones reside as example files in the
-            <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>.
-            For simplicity, this section refers to the Source Directory as
-            the "Poky Directory."
-        </p>
-<p>
-            When you clone the <code class="filename">poky</code> Git repository or you
-            download and unpack a Yocto Project release, you can set up the
-            Source Directory to be named anything you want.
-            For this discussion, the cloned repository uses the default
-            name <code class="filename">poky</code>.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                The Poky repository is primarily an aggregation of existing
-                repositories.
-                It is not a canonical upstream source.
-            </div>
-<p>
-        </p>
-<p>
-            The <code class="filename">meta-poky</code> layer inside Poky contains
-            a <code class="filename">conf</code> directory that has example
-            configuration files.
-            These example files are used as a basis for creating actual
-            configuration files when you source the build environment
-            script
-            (i.e.
-            <a class="link" href="../ref-manual/structure-core-script.html" target="_self"><code class="filename">oe-init-build-env</code></a>).
-        </p>
-<p>
-            Sourcing the build environment script creates a
-            <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>
-            if one does not already exist.
-            BitBake uses the Build Directory for all its work during builds.
-            The Build Directory has a <code class="filename">conf</code> directory that
-            contains default versions of your <code class="filename">local.conf</code>
-            and <code class="filename">bblayers.conf</code> configuration files.
-            These default configuration files are created only if versions
-            do not already exist in the Build Directory at the time you
-            source the build environment setup script.
-        </p>
-<p>
-            Because the Poky repository is fundamentally an aggregation of
-            existing repositories, some users might be familiar with running
-            the <code class="filename">oe-init-build-env</code> script in the context
-            of separate OpenEmbedded-Core and BitBake repositories rather than a
-            single Poky repository.
-            This discussion assumes the script is executed from within a cloned
-            or unpacked version of Poky.
-        </p>
-<p>
-            Depending on where the script is sourced, different sub-scripts
-            are called to set up the Build Directory (Yocto or OpenEmbedded).
-            Specifically, the script
-            <code class="filename">scripts/oe-setup-builddir</code> inside the
-            poky directory sets up the Build Directory and seeds the directory
-            (if necessary) with configuration files appropriate for the
-            Yocto Project development environment.
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                The <code class="filename">scripts/oe-setup-builddir</code> script
-                uses the <code class="filename">$TEMPLATECONF</code> variable to
-                determine which sample configuration files to locate.
-            </div>
-<p>
-        </p>
-<p>
-            The <code class="filename">local.conf</code> file provides many
-            basic variables that define a build environment.
-            Here is a list of a few.
-            To see the default configurations in a <code class="filename">local.conf</code>
-            file created by the build environment script, see the
-            <code class="filename">local.conf.sample</code> in the
-            <code class="filename">meta-poky</code> layer:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p><span class="emphasis"><em>Parallelism Options:</em></span>
-                    Controlled by the
-                    <a class="link" href="../ref-manual/var-BB_NUMBER_THREADS.html" target="_self"><code class="filename">BB_NUMBER_THREADS</code></a>,
-                    <a class="link" href="../ref-manual/var-PARALLEL_MAKE.html" target="_self"><code class="filename">PARALLEL_MAKE</code></a>,
-                    and
-                    <a class="link" href="../bitbake-user-manual/var-BB_NUMBER_PARSE_THREADS.html" target="_self"><code class="filename">BB_NUMBER_PARSE_THREADS</code></a>
-                    variables.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Target Machine Selection:</em></span>
-                    Controlled by the
-                    <a class="link" href="../ref-manual/var-MACHINE.html" target="_self"><code class="filename">MACHINE</code></a>
-                    variable.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Download Directory:</em></span>
-                    Controlled by the
-                    <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a>
-                    variable.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Shared State Directory:</em></span>
-                    Controlled by the
-                    <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a>
-                    variable.</p></li>
-<li class="listitem"><p><span class="emphasis"><em>Build Output:</em></span>
-                    Controlled by the
-                    <a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a>
-                    variable.</p></li>
-</ul></div>
-<p>
-            </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                Configurations set in the <code class="filename">conf/local.conf</code>
-                file can also be set in the
-                <code class="filename">conf/site.conf</code> and
-                <code class="filename">conf/auto.conf</code> configuration files.
-            </div>
-<p>
-        </p>
-<p>
-            The <code class="filename">bblayers.conf</code> file tells BitBake what
-            layers you want considered during the build.
-            By default, the layers listed in this file include layers
-            minimally needed by the build system.
-            However, you must manually add any custom layers you have created.
-            You can find more information on working with the
-            <code class="filename">bblayers.conf</code> file in the
-            "<a class="link" href="../dev-manual/enabling-your-layer.html" target="_self">Enabling Your Layer</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p>
-<p>
-            The files <code class="filename">site.conf</code> and
-            <code class="filename">auto.conf</code> are not created by the environment
-            initialization script.
-            If you want the <code class="filename">site.conf</code> file, you need to
-            create that yourself.
-            The <code class="filename">auto.conf</code> file is typically created by
-            an autobuilder:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p><span class="emphasis"><em><code class="filename">site.conf</code>:</em></span>
-                    You can use the <code class="filename">conf/site.conf</code>
-                    configuration file to configure multiple build directories.
-                    For example, suppose you had several build environments and
-                    they shared some common features.
-                    You can set these default build properties here.
-                    A good example is perhaps the packaging format to use
-                    through the
-                    <a class="link" href="../ref-manual/var-PACKAGE_CLASSES.html" target="_self"><code class="filename">PACKAGE_CLASSES</code></a>
-                    variable.</p>
-<p>One useful scenario for using the
-                    <code class="filename">conf/site.conf</code> file is to extend your
-                    <a class="link" href="../ref-manual/var-BBPATH.html" target="_self"><code class="filename">BBPATH</code></a>
-                    variable to include the path to a
-                    <code class="filename">conf/site.conf</code>.
-                    Then, when BitBake looks for Metadata using
-                    <code class="filename">BBPATH</code>, it finds the
-                    <code class="filename">conf/site.conf</code> file and applies your
-                    common configurations found in the file.
-                    To override configurations in a particular build directory,
-                    alter the similar configurations within that build
-                    directory's <code class="filename">conf/local.conf</code> file.
-                    </p>
-</li>
-<li class="listitem"><p><span class="emphasis"><em><code class="filename">auto.conf</code>:</em></span>
-                    The file is usually created and written to by
-                    an autobuilder.
-                    The settings put into the file are typically the same as
-                    you would find in the <code class="filename">conf/local.conf</code>
-                    or the <code class="filename">conf/site.conf</code> files.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            You can edit all configuration files to further define
-            any particular build environment.
-            This process is represented by the "User Configuration Edits"
-            box in the figure.
-        </p>
-<p>
-            When you launch your build with the
-            <code class="filename">bitbake <em class="replaceable"><code>target</code></em></code>
-            command, BitBake sorts out the configurations to ultimately
-            define your build environment.
-            It is important to understand that the OpenEmbedded build system
-            reads the configuration files in a specific order:
-            <code class="filename">site.conf</code>, <code class="filename">auto.conf</code>,
-            and <code class="filename">local.conf</code>.
-            And, the build system applies the normal assignment statement
-            rules.
-            Because the files are parsed in a specific order, variable
-            assignments for the same variable could be affected.
-            For example, if the <code class="filename">auto.conf</code> file and
-            the <code class="filename">local.conf</code> set
-            <em class="replaceable"><code>variable1</code></em> to different values, because
-            the build system parses <code class="filename">local.conf</code> after
-            <code class="filename">auto.conf</code>,
-            <em class="replaceable"><code>variable1</code></em> is assigned the value from
-            the <code class="filename">local.conf</code> file.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html
deleted file mode 100644
index 7e43ebd923..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html
+++ /dev/null
@@ -1,76 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.1.2.�Explanation of Syntax</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1.�Tracking License Changes">
-<link rel="prev" href="usingpoky-specifying-LIC_FILES_CHKSUM.html" title="3.7.1.1.�Specifying the LIC_FILES_CHKSUM Variable">
-<link rel="next" href="enabling-commercially-licensed-recipes.html" title="3.7.2.�Enabling Commercially Licensed Recipes">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.1.2.�Explanation of Syntax">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax"></a>3.7.1.2.�Explanation of Syntax</h4></div></div></div>
-<p>
-                    As mentioned in the previous section, the
-                    <code class="filename">LIC_FILES_CHKSUM</code> variable lists all
-                    the important files that contain the license text for the
-                    source code.
-                    It is possible to specify a checksum for an entire file,
-                    or a specific section of a file (specified by beginning and
-                    ending line numbers with the "beginline" and "endline"
-                    parameters, respectively).
-                    The latter is useful for source files with a license
-                    notice header, README documents, and so forth.
-                    If you do not use the "beginline" parameter, then it is
-                    assumed that the text begins on the first line of the file.
-                    Similarly, if you do not use the "endline" parameter,
-                    it is assumed that the license text ends with the last
-                    line of the file.
-                </p>
-<p>
-                    The "md5" parameter stores the md5 checksum of the license
-                    text.
-                    If the license text changes in any way as compared to
-                    this parameter then a mismatch occurs.
-                    This mismatch triggers a build failure and notifies
-                    the developer.
-                    Notification allows the developer to review and address
-                    the license text changes.
-                    Also note that if a mismatch occurs during the build,
-                    the correct md5 checksum is placed in the build log and
-                    can be easily copied to the recipe.
-                </p>
-<p>
-                    There is no limit to how many files you can specify using
-                    the <code class="filename">LIC_FILES_CHKSUM</code> variable.
-                    Generally, however, every project requires a few
-                    specifications for license tracking.
-                    Many projects have a "COPYING" file that stores the
-                    license information for all the source code files.
-                    This practice allows you to just track the "COPYING"
-                    file as long as it is kept up to date.
-                    </p>
-<div class="note" title="Tips" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Tips</h3>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                                If you specify an empty or invalid "md5"
-                                parameter, BitBake returns an md5 mis-match
-                                error and displays the correct "md5" parameter
-                                value during the build.
-                                The correct parameter is also captured in
-                                the build log.
-                                </p></li>
-<li class="listitem"><p>
-                                If the whole file contains only license text,
-                                you do not need to use the "beginline" and
-                               "endline" parameters.
-                               </p></li>
-</ul></div>
-</div>
-<p>
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html
deleted file mode 100644
index 39fa32b154..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html
+++ /dev/null
@@ -1,82 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.1.1.�BitBake</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-<link rel="prev" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-<link rel="next" href="usingpoky-components-metadata.html" title="3.1.2.�Metadata (Recipes)">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.1.�BitBake">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="usingpoky-components-bitbake"></a>3.1.1.�BitBake</h3></div></div></div>
-<p>
-                BitBake is the tool at the heart of the OpenEmbedded build
-                system and is responsible for parsing the
-                <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>,
-                generating a list of tasks from it, and then executing those
-                tasks.
-            </p>
-<p>
-                This section briefly introduces BitBake.
-                If you want more information on BitBake, see the
-                <a class="link" href="../bitbake-user-manual/bitbake-user-manual.html" target="_self">BitBake User Manual</a>.
-            </p>
-<p>
-                To see a list of the options BitBake supports, use either of
-                the following commands:
-                </p>
-<pre class="literallayout">
-     $ bitbake -h
-     $ bitbake --help
-                </pre>
-<p>
-            </p>
-<p>
-                The most common usage for BitBake is
-                <code class="filename">bitbake <em class="replaceable"><code>packagename</code></em></code>,
-                where <code class="filename">packagename</code> 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
-                <code class="filename">foo_1.3.0-r0.bb</code>).
-                So, to process the
-                <code class="filename">matchbox-desktop_1.2.3.bb</code> recipe file, you
-                might type the following:
-                </p>
-<pre class="literallayout">
-     $ bitbake matchbox-desktop
-                </pre>
-<p>
-                Several different versions of
-                <code class="filename">matchbox-desktop</code> 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
-                "<a class="link" href="../bitbake-user-manual/bb-bitbake-preferences.html" target="_self">Preferences</a>"
-                section of the BitBake User Manual.
-            </p>
-<p>
-                BitBake also tries to execute any dependent tasks first.
-                So for example, before building
-                <code class="filename">matchbox-desktop</code>, BitBake would build a
-                cross compiler and <code class="filename">glibc</code> if they had not
-                already been built.
-            </p>
-<p>
-                A useful BitBake option to consider is the
-                <code class="filename">-k</code> or <code class="filename">--continue</code>
-                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.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html
deleted file mode 100644
index 809906c999..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html
+++ /dev/null
@@ -1,30 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.1.4.�Classes</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-<link rel="prev" href="metadata-virtual-providers.html" title="3.1.3.�Metadata (Virtual Providers)">
-<link rel="next" href="usingpoky-components-configuration.html" title="3.1.5.�Configuration">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.4.�Classes">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="usingpoky-components-classes"></a>3.1.4.�Classes</h3></div></div></div>
-<p>
-                Class files (<code class="filename">.bbclass</code>) contain information
-                that is useful to share between
-                <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>
-                files.
-                An example is the
-                <a class="link" href="../ref-manual/ref-classes-autotools.html" target="_self"><code class="filename">autotools</code></a>
-                class, which contains common settings for any application that
-                Autotools uses.
-                The
-                "<a class="link" href="../ref-manual/ref-classes.html" target="_self">Classes</a>"
-                chapter in the Yocto Project Reference Manual provides
-                details about classes and how to use them.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html
deleted file mode 100644
index a1ca039c9b..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html
+++ /dev/null
@@ -1,27 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.1.5.�Configuration</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-<link rel="prev" href="usingpoky-components-classes.html" title="3.1.4.�Classes">
-<link rel="next" href="cross-development-toolchain-generation.html" title="3.2.�Cross-Development Toolchain Generation">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.5.�Configuration">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="usingpoky-components-configuration"></a>3.1.5.�Configuration</h3></div></div></div>
-<p>
-                The configuration files (<code class="filename">.conf</code>) 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
-                <code class="filename">local.conf</code>, which is found in the
-                <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html
deleted file mode 100644
index b25324502e..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html
+++ /dev/null
@@ -1,35 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.1.2.�Metadata (Recipes)</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="yocto-project-components.html" title="3.1.�Yocto Project Components">
-<link rel="prev" href="usingpoky-components-bitbake.html" title="3.1.1.�BitBake">
-<link rel="next" href="metadata-virtual-providers.html" title="3.1.3.�Metadata (Virtual Providers)">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.2.�Metadata (Recipes)">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="usingpoky-components-metadata"></a>3.1.2.�Metadata (Recipes)</h3></div></div></div>
-<p>
-                Files that have the <code class="filename">.bb</code> 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.
-            </p>
-<p>
-                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.
-                <code class="filename">.ipk</code> or <code class="filename">.deb</code> files),
-                this document avoids using the term "package" when referring
-                to recipes.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html
deleted file mode 100644
index ee59e3bc10..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.1.�Tracking License Changes</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-licenses.html" title="3.7.�Licenses">
-<link rel="prev" href="overview-licenses.html" title="3.7.�Licenses">
-<link rel="next" href="usingpoky-specifying-LIC_FILES_CHKSUM.html" title="3.7.1.1.�Specifying the LIC_FILES_CHKSUM Variable">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.1.�Tracking License Changes">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="usingpoky-configuring-LIC_FILES_CHKSUM"></a>3.7.1.�Tracking License Changes</h3></div></div></div>
-<p>
-                The license of an upstream project might change in the future.
-                In order to prevent these changes going unnoticed, the
-                <a class="link" href="../ref-manual/var-LIC_FILES_CHKSUM.html" target="_self"><code class="filename">LIC_FILES_CHKSUM</code></a>
-                variable tracks changes to the license text. The checksums are
-                validated at the end of the configure step, and if the
-                checksums do not match, the build will fail.
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html
deleted file mode 100644
index ed9a3cc501..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html
+++ /dev/null
@@ -1,82 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.7.1.1.�Specifying the LIC_FILES_CHKSUM Variable</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1.�Tracking License Changes">
-<link rel="prev" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1.�Tracking License Changes">
-<link rel="next" href="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html" title="3.7.1.2.�Explanation of Syntax">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.1.1.�Specifying the LIC_FILES_CHKSUM Variable">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="usingpoky-specifying-LIC_FILES_CHKSUM"></a>3.7.1.1.�Specifying the <code class="filename">LIC_FILES_CHKSUM</code> Variable</h4></div></div></div>
-<p>
-                    The <code class="filename">LIC_FILES_CHKSUM</code>
-                    variable contains checksums of the license text in the
-                    source code for the recipe.
-                    Following is an example of how to specify
-                    <code class="filename">LIC_FILES_CHKSUM</code>:
-                    </p>
-<pre class="literallayout">
-     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
-                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
-                         file://licfile2.txt;endline=50;md5=zzzz \
-                         ..."
-                    </pre>
-<p>
-                    </p>
-<div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Notes</h3>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                                When using "beginline" and "endline", realize
-                                that line numbering begins with one and not
-                                zero.
-                                Also, the included lines are inclusive (i.e.
-                                lines five through and including 29 in the
-                                previous example for
-                                <code class="filename">licfile1.txt</code>).
-                                </p></li>
-<li class="listitem"><p>
-                                When a license check fails, the selected license
-                                text is included as part of the QA message.
-                                Using this output, you can determine the exact
-                                start and finish for the needed license text.
-                                </p></li>
-</ul></div>
-</div>
-<p>
-                </p>
-<p>
-                    The build system uses the
-                    <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a>
-                    variable as the default directory when searching files
-                    listed in <code class="filename">LIC_FILES_CHKSUM</code>.
-                    The previous example employs the default directory.
-                </p>
-<p>
-                    Consider this next example:
-                    </p>
-<pre class="literallayout">
-     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
-                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
-     LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
-                    </pre>
-<p>
-                </p>
-<p>
-                    The first line locates a file in
-                    <code class="filename">${S}/src/ls.c</code> and isolates lines five
-                    through 16 as license text.
-                    The second line refers to a file in
-                    <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>.
-                </p>
-<p>
-                    Note that <code class="filename">LIC_FILES_CHKSUM</code> variable is
-                    mandatory for all recipes, unless the
-                    <code class="filename">LICENSE</code> variable is set to "CLOSED".
-                </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/wayland-support.html b/documentation/getting-started/eclipse/html/getting-started/wayland-support.html
deleted file mode 100644
index da810a4439..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/wayland-support.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.6.1.�Support</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="wayland.html" title="3.6.�Wayland">
-<link rel="prev" href="wayland.html" title="3.6.�Wayland">
-<link rel="next" href="enabling-wayland-in-an-image.html" title="3.6.2.�Enabling Wayland in an Image">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.1.�Support">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="wayland-support"></a>3.6.1.�Support</h3></div></div></div>
-<p>
-                The Wayland protocol libraries and the reference Weston
-                compositor ship as integrated packages in the
-                <code class="filename">meta</code> layer of the
-                <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>.
-                Specifically, you can find the recipes that build both Wayland
-                and Weston at
-                <code class="filename">meta/recipes-graphics/wayland</code>.
-            </p>
-<p>
-                You can build both the Wayland and Weston packages for use only
-                with targets that accept the
-                <a class="ulink" href="https://en.wikipedia.org/wiki/Mesa_(computer_graphics)" target="_self">Mesa 3D and Direct Rendering Infrastructure</a>,
-                which is also known as Mesa DRI.
-                This implies that you cannot build and use the packages if your
-                target uses, for example, the
-                <span class="trademark">Intel</span>� Embedded Media
-                and Graphics Driver
-                (<span class="trademark">Intel</span>� EMGD) that
-                overrides Mesa DRI.
-                </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-                    Due to lack of EGL support, Weston 1.0.3 will not run
-                    directly on the emulated QEMU hardware.
-                    However, this version of Weston will run under X emulation
-                    without issues.
-                </div>
-<p>
-            </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/wayland.html b/documentation/getting-started/eclipse/html/getting-started/wayland.html
deleted file mode 100644
index 0747c9238c..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/wayland.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.6.�Wayland</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="fakeroot-and-pseudo.html" title="3.5.�Fakeroot and Pseudo">
-<link rel="next" href="wayland-support.html" title="3.6.1.�Support">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.�Wayland">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="wayland"></a>3.6.�Wayland</h2></div></div></div>
-<p>
-            <a class="ulink" href="http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)" target="_self">Wayland</a>
-            is a computer display server protocol that
-            provides a method for compositing window managers to communicate
-            directly with applications and video hardware and expects them to
-            communicate with input hardware using other libraries.
-            Using Wayland with supporting targets can result in better control
-            over graphics frame rendering than an application might otherwise
-            achieve.
-        </p>
-<p>
-            The Yocto Project provides the Wayland protocol libraries and the
-            reference
-            <a class="ulink" href="http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston" target="_self">Weston</a>
-            compositor as part of its release.
-            This section describes what you need to do to implement Wayland and
-            use the compositor when building an image for a supporting target.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/workflows.html b/documentation/getting-started/eclipse/html/getting-started/workflows.html
deleted file mode 100644
index 9d53975678..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/workflows.html
+++ /dev/null
@@ -1,207 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.3.�Workflows</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="open-source-philosophy.html" title="2.2.�Open Source Philosophy">
-<link rel="next" href="git.html" title="2.4.�Git">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.3.�Workflows">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="workflows"></a>2.3.�Workflows</h2></div></div></div>
-<p>
-        This section provides workflow concepts using the Yocto Project and
-        Git.
-        In particular, the information covers basic practices that describe
-        roles and actions in a collaborative development environment.
-        </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-            If you are familiar with this type of development environment, you
-            might not want to read this section.
-        </div>
-<p>
-    </p>
-<p>
-        The Yocto Project files are maintained using Git in "master"
-        branches whose Git histories track every change and whose structures
-        provides branches for all diverging functionality.
-        Although there is no need to use Git, many open source projects do so.
-    </p>
-<p>
-
-    </p>
-<p>
-        For the Yocto Project, a key individual called the "maintainer" is
-        responsible for the "master" branch of a given Git repository.
-        The "master" branch is the &#8220;upstream&#8221; repository from which final or
-        most recent builds of the project occur.
-        The maintainer is responsible for accepting changes from other
-        developers and for organizing the underlying branch structure to
-        reflect release strategies and so forth.
-        </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>For information on finding out who is responsible for (maintains)
-            a particular area of code, see the
-            "<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">Submitting a Change to the Yocto Project</a>"
-            section of the Yocto Project Development Tasks Manual.
-        </div>
-<p>
-    </p>
-<p>
-        The Yocto Project <code class="filename">poky</code> Git repository also has an
-        upstream contribution Git repository named
-        <code class="filename">poky-contrib</code>.
-        You can see all the branches in this repository using the web interface
-        of the
-        <a class="ulink" href="http://git.yoctoproject.org" target="_self">Source Repositories</a> organized
-        within the "Poky Support" area.
-        These branches temporarily hold changes to the project that have been
-        submitted or committed by the Yocto Project development team and by
-        community members who contribute to the project.
-        The maintainer determines if the changes are qualified to be moved
-        from the "contrib" branches into the "master" branch of the Git
-        repository.
-    </p>
-<p>
-        Developers (including contributing community members) create and
-        maintain cloned repositories of the upstream "master" branch.
-        The cloned repositories are local to their development platforms and
-        are used to develop changes.
-        When a developer is satisfied with a particular feature or change,
-        they "push" the changes to the appropriate "contrib" repository.
-    </p>
-<p>
-        Developers are responsible for keeping their local repository
-        up-to-date with "master".
-        They are also responsible for straightening out any conflicts that
-        might arise within files that are being worked on simultaneously by
-        more than one person.
-        All this work is done locally on the developer&#8217;s machine before
-        anything is pushed to a "contrib" area and examined at the maintainer&#8217;s
-        level.
-    </p>
-<p>
-        A somewhat formal method exists by which developers commit changes
-        and push them into the "contrib" area and subsequently request that
-        the maintainer include them into "master".
-        This process is called &#8220;submitting a patch&#8221; or "submitting a change."
-        For information on submitting patches and changes, see the
-        "<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">Submitting a Change to the Yocto Project</a>"
-        section in the Yocto Project Development Tasks Manual.
-    </p>
-<p>
-        To summarize the development workflow:  a single point of entry
-        exists for changes into the project&#8217;s "master" branch of the
-        Git repository, which is controlled by the project&#8217;s maintainer.
-        And, a set of developers exist who independently develop, test, and
-        submit changes to "contrib" areas for the maintainer to examine.
-        The maintainer then chooses which changes are going to become a
-        permanent part of the project.
-    </p>
-<p>
-        </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 270px"><td align="left"><img src="figures/git-workflow.png" align="left" height="270"></td></tr></table>
-<p>
-    </p>
-<p>
-        While each development environment is unique, there are some best
-        practices or methods that help development run smoothly.
-        The following list describes some of these practices.
-        For more information about Git workflows, see the workflow topics in
-        the
-        <a class="ulink" href="http://book.git-scm.com" target="_self">Git Community Book</a>.
-        </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p>
-                <span class="emphasis"><em>Make Small Changes:</em></span>
-                It is best to keep the changes you commit small as compared to
-                bundling many disparate changes into a single commit.
-                This practice not only keeps things manageable but also allows
-                the maintainer to more easily include or refuse changes.</p>
-<p>It is also good practice to leave the repository in a
-                state that allows you to still successfully build your project.
-                In other words, do not commit half of a feature,
-                then add the other half as a separate, later commit.
-                Each commit should take you from one buildable project state
-                to another buildable state.
-                </p>
-</li>
-<li class="listitem"><p>
-                <span class="emphasis"><em>Use Branches Liberally:</em></span>
-                It is very easy to create, use, and delete local branches in
-                your working Git repository.
-                You can name these branches anything you like.
-                It is helpful to give them names associated with the particular
-                feature or change on which you are working.
-                Once you are done with a feature or change and have merged it
-                into your local master branch, simply discard the temporary
-                branch.
-                </p></li>
-<li class="listitem"><p>
-                <span class="emphasis"><em>Merge Changes:</em></span>
-                The <code class="filename">git merge</code> command allows you to take
-                the changes from one branch and fold them into another branch.
-                This process is especially helpful when more than a single
-                developer might be working on different parts of the same
-                feature.
-                Merging changes also automatically identifies any collisions
-                or "conflicts" that might happen as a result of the same lines
-                of code being altered by two different developers.
-                </p></li>
-<li class="listitem"><p>
-                <span class="emphasis"><em>Manage Branches:</em></span>
-                Because branches are easy to use, you should use a system
-                where branches indicate varying levels of code readiness.
-                For example, you can have a "work" branch to develop in, a
-                "test" branch where the code or change is tested, a "stage"
-                branch where changes are ready to be committed, and so forth.
-                As your project develops, you can merge code across the
-                branches to reflect ever-increasing stable states of the
-                development.
-                </p></li>
-<li class="listitem"><p>
-                <span class="emphasis"><em>Use Push and Pull:</em></span>
-                The push-pull workflow is based on the concept of developers
-                "pushing" local commits to a remote repository, which is
-                usually a contribution repository.
-                This workflow is also based on developers "pulling" known
-                states of the project down into their local development
-                repositories.
-                The workflow easily allows you to pull changes submitted by
-                other developers from the upstream repository into your
-                work area ensuring that you have the most recent software
-                on which to develop.
-                The Yocto Project has two scripts named
-                <code class="filename">create-pull-request</code> and
-                <code class="filename">send-pull-request</code> that ship with the
-                release to facilitate this workflow.
-                You can find these scripts in the <code class="filename">scripts</code>
-                folder of the
-                <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>.
-                For information on how to use these scripts, see the
-                "<a class="link" href="../dev-manual/pushing-a-change-upstream.html" target="_self">Using Scripts to Push a Change Upstream and Request a Pull</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p></li>
-<li class="listitem"><p>
-                <span class="emphasis"><em>Patch Workflow:</em></span>
-                This workflow allows you to notify the maintainer through an
-                email that you have a change (or patch) you would like
-                considered for the "master" branch of the Git repository.
-                To send this type of change, you format the patch and then
-                send the email using the Git commands
-                <code class="filename">git format-patch</code> and
-                <code class="filename">git send-email</code>.
-                For information on how to use these scripts, see the
-                "<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">Submitting a Change to the Yocto Project</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p></li>
-</ul></div>
-<p>
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/x32.html b/documentation/getting-started/eclipse/html/getting-started/x32.html
deleted file mode 100644
index daffedbeea..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/x32.html
+++ /dev/null
@@ -1,75 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.8.�x32 psABI</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="other-variables-related-to-commercial-licenses.html" title="3.7.2.2.�Other Variables Related to Commercial Licenses">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.8.�x32 psABI">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="x32"></a>3.8.�x32 psABI</h2></div></div></div>
-<p>
-            x32 processor-specific Application Binary Interface
-            (<a class="ulink" href="https://software.intel.com/en-us/node/628948" target="_self">x32 psABI</a>)
-            is a native 32-bit processor-specific ABI for
-            <span class="trademark">Intel</span>� 64 (x86-64)
-            architectures.
-            An ABI defines the calling conventions between functions in a
-            processing environment.
-            The interface determines what registers are used and what the sizes are
-            for various C data types.
-        </p>
-<p>
-            Some processing environments prefer using 32-bit applications even
-            when running on Intel 64-bit platforms.
-            Consider the i386 psABI, which is a very old 32-bit ABI for Intel
-            64-bit platforms.
-            The i386 psABI does not provide efficient use and access of the
-            Intel 64-bit processor resources, leaving the system underutilized.
-            Now consider the x86_64 psABI.
-            This ABI is newer and uses 64-bits for data sizes and program
-            pointers.
-            The extra bits increase the footprint size of the programs,
-            libraries, and also increases the memory and file system size
-            requirements.
-            Executing under the x32 psABI enables user programs to utilize CPU
-            and system resources more efficiently while keeping the memory
-            footprint of the applications low.
-            Extra bits are used for registers but not for addressing mechanisms.
-        </p>
-<p>
-            The Yocto Project supports the final specifications of x32 psABI
-            as follows:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    You can create packages and images in x32 psABI format on
-                    x86_64 architecture targets.
-                    </p></li>
-<li class="listitem"><p>
-                    You can successfully build recipes with the x32 toolchain.
-                    </p></li>
-<li class="listitem"><p>
-                    You can create and boot
-                    <code class="filename">core-image-minimal</code> and
-                    <code class="filename">core-image-sato</code> images.
-                    </p></li>
-<li class="listitem"><p>
-                    RPM Package Manager (RPM) support exists for x32 binaries.
-                    </p></li>
-<li class="listitem"><p>
-                    Support for large images exists.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            For steps on how to use x32 psABI, see the
-            "<a class="link" href="../dev-manual/using-x32-psabi.html" target="_self">Using x32 psABI</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html b/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html
deleted file mode 100644
index 0ad63b2402..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html
+++ /dev/null
@@ -1,62 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>3.1.�Yocto Project Components</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="prev" href="overview-concepts.html" title="Chapter�3.�Yocto Project Concepts">
-<link rel="next" href="usingpoky-components-bitbake.html" title="3.1.1.�BitBake">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.�Yocto Project Components">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="yocto-project-components"></a>3.1.�Yocto Project Components</h2></div></div></div>
-<p>
-            The
-            <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a>
-            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.
-        </p>
-<p>
-            BitBake handles the parsing and execution of the data files.
-            The data itself is of various types:
-            </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Recipes:</em></span>
-                    Provides details about particular pieces of software.
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Class Data:</em></span>
-                    Abstracts common build information (e.g. how to build a
-                    Linux kernel).
-                    </p></li>
-<li class="listitem"><p>
-                    <span class="emphasis"><em>Configuration Data:</em></span>
-                    Defines machine-specific settings, policy decisions, and
-                    so forth.
-                    Configuration data acts as the glue to bind everything
-                    together.
-                    </p></li>
-</ul></div>
-<p>
-        </p>
-<p>
-            BitBake knows how to combine multiple data sources together and
-            refers to each data source as a layer.
-            For information on layers, see the
-            "<a class="link" href="../dev-manual/understanding-and-creating-layers.html" target="_self">Understanding and Creating Layers</a>"
-            section of the Yocto Project Development Tasks Manual.
-        </p>
-<p>
-            Following are some brief details on these core components.
-            For additional information on how these components interact during
-            a build, see the
-            "<a class="link" href="development-concepts.html" title="2.8.�Development Concepts">Development Concepts</a>"
-            section.
-        </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html b/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html
deleted file mode 100644
index 3dcc2af5eb..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html
+++ /dev/null
@@ -1,135 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.5.�Yocto Project Source Repositories</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="basic-commands.html" title="2.4.2.�Basic Commands">
-<link rel="next" href="licensing.html" title="2.6.�Licensing">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.5.�Yocto Project Source Repositories">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="yocto-project-repositories"></a>2.5.�Yocto Project Source Repositories</h2></div></div></div>
-<p>
-        The Yocto Project team maintains complete source repositories for all
-        Yocto Project files at
-        <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi" target="_self">http://git.yoctoproject.org/cgit/cgit.cgi</a>.
-        This web-based source code browser is organized into categories by
-        function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and
-        so forth.
-        From the interface, you can click on any particular item in the "Name"
-        column and see the URL at the bottom of the page that you need to clone
-        a Git repository for that particular item.
-        Having a local Git repository of the
-        <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>,
-        which is usually named "poky", allows
-        you to make changes, contribute to the history, and ultimately enhance
-        the Yocto Project's tools, Board Support Packages, and so forth.
-    </p>
-<p>
-        For any supported release of Yocto Project, you can also go to the
-        <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project Website</a> and
-        select the "Downloads" tab and get a released tarball of the
-        <code class="filename">poky</code> repository or any supported BSP tarballs.
-        Unpacking these tarballs gives you a snapshot of the released
-        files.
-        </p>
-<div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Notes</h3>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-                    The recommended method for setting up the Yocto Project
-                    <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>
-                    and the files for supported BSPs
-                    (e.g., <code class="filename">meta-intel</code>) is to use
-                    <a class="link" href="git.html" title="2.4.�Git">Git</a> to create a local copy of
-                    the upstream repositories.
-                    </p></li>
-<li class="listitem"><p>
-                    Be sure to always work in matching branches for both
-                    the selected BSP repository and the
-                    <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>
-                    (i.e. <code class="filename">poky</code>) repository.
-                    For example, if you have checked out the "master" branch
-                    of <code class="filename">poky</code> and you are going to use
-                    <code class="filename">meta-intel</code>, be sure to checkout the
-                    "master" branch of <code class="filename">meta-intel</code>.
-                    </p></li>
-</ul></div>
-</div>
-<p>
-    </p>
-<p>
-        In summary, here is where you can get the project files needed for
-        development:
-        </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p><a name="source-repositories"></a>
-                <span class="emphasis"><em>
-                <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi" target="_self">Source Repositories:</a>
-                </em></span>
-                This area contains IDE Plugins, Matchbox, Poky, Poky Support,
-                Tools, Yocto Linux Kernel, and Yocto Metadata Layers.
-                You can create local copies of Git repositories for each of
-                these areas.</p>
-<p>
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/source-repos.png" align="middle" width="540"></td></tr></table>
-<p>
-                For steps on how to view and access these upstream Git
-                repositories, see the
-                "<a class="link" href="../dev-manual/accessing-source-repositories.html" target="_self">Accessing Source Repositories</a>"
-                Section in the Yocto Project Development Tasks Manual.
-                </p>
-</li>
-<li class="listitem">
-<p><a name="index-downloads"></a>
-                <span class="emphasis"><em>
-                <a class="ulink" href="http://downloads.yoctoproject.org/releases/" target="_self">Index of /releases:</a>
-                </em></span>
-                This is an index of releases such as
-                the <span class="trademark">Eclipse</span>&#8482;
-                Yocto Plug-in, miscellaneous support, Poky, Pseudo, installers
-                for cross-development toolchains, and all released versions of
-                Yocto Project in the form of images or tarballs.
-                Downloading and extracting these files does not produce a local
-                copy of the Git repository but rather a snapshot of a
-                particular release or image.</p>
-<p>
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 315px"><td align="center"><img src="figures/index-downloads.png" align="middle" height="315"></td></tr></table>
-<p>
-                For steps on how to view and access these files, see the
-                "<a class="link" href="../dev-manual/accessing-index-of-releases.html" target="_self">Accessing Index of Releases</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p>
-</li>
-<li class="listitem">
-<p><a name="downloads-page"></a>
-                <span class="emphasis"><em>"Downloads" page for the
-                <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project Website</a>:
-                </em></span></p>
-<p class="writernotes">This section will change due to
-                reworking of the YP Website.</p>
-<p>The Yocto Project website includes a "Downloads" tab
-                that allows you to download any Yocto Project
-                release and Board Support Package (BSP) in tarball form.
-                The tarballs are similar to those found in the
-                <a class="ulink" href="http://downloads.yoctoproject.org/releases/" target="_self">Index of /releases:</a> area.</p>
-<p>
-                </p>
-<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/yp-download.png" align="middle" width="540"></td></tr></table>
-<p>
-                For steps on how to use the "Downloads" page, see the
-                "<a class="link" href="../dev-manual/using-the-downloads-page.html" target="_self">Using the Downloads Page</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p>
-</li>
-</ul></div>
-<p>
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/eclipse/html/getting-started/yp-intro.html b/documentation/getting-started/eclipse/html/getting-started/yp-intro.html
deleted file mode 100644
index 42ad0d3088..0000000000
--- a/documentation/getting-started/eclipse/html/getting-started/yp-intro.html
+++ /dev/null
@@ -1,119 +0,0 @@
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<title>2.1.�Introduction</title>
-<link rel="stylesheet" type="text/css" href="../book.css">
-<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
-<link rel="home" href="index.html" title="Getting Started With Yocto Project">
-<link rel="up" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="prev" href="overview-development-environment.html" title="Chapter�2.�The Yocto Project Development Environment">
-<link rel="next" href="open-source-philosophy.html" title="2.2.�Open Source Philosophy">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.1.�Introduction">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="yp-intro"></a>2.1.�Introduction</h2></div></div></div>
-<p>
-        The Yocto Project is an open-source collaboration project whose
-        focus is for developers of embedded Linux systems.
-        Among other things, the Yocto Project uses an
-        <a class="link" href="../ref-manual/build-system-term.html" target="_self">OpenEmbedded build system</a>.
-        The build system, which is based on the OpenEmbedded (OE) project and
-        uses the
-        <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a> tool,
-        constructs complete Linux images for architectures based on ARM, MIPS,
-        PowerPC, x86 and x86-64.
-        </p>
-<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-            Historically, the OpenEmbedded build system, which is the
-            combination of BitBake and OE components, formed a reference
-            build host that was known as
-            "<a class="link" href="../ref-manual/poky.html" target="_self">Poky</a>"
-            (<span class="emphasis"><em>Pah</em></span>-kee).
-            The term "Poky", as used throughout the Yocto Project Documentation
-            set, can have different meanings.
-        </div>
-<p>
-        The Yocto Project provides various ancillary tools for the embedded
-        developer and also features the Sato reference User Interface, which
-        is optimized for stylus-driven, low-resolution screens.
-    </p>
-<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr><td align="center"><img src="figures/YP-flow-diagram.png" align="middle" width="720"></td></tr></table></div>
-<p>
-        Here are some highlights for the Yocto Project:
-    </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-            Provides a recent Linux kernel along with a set of system
-            commands and libraries suitable for the embedded
-            environment.
-            </p></li>
-<li class="listitem"><p>
-            Makes available system components such as X11, GTK+, Qt,
-            Clutter, and SDL (among others) so you can create a rich user
-            experience on devices that have display hardware.
-            For devices that do not have a display or where you wish to
-            use alternative UI frameworks, these components need not be
-            installed.
-            </p></li>
-<li class="listitem"><p>
-            Creates a focused and stable core compatible with the
-            OpenEmbedded project with which you can easily and reliably
-            build and develop.
-            </p></li>
-<li class="listitem"><p>
-            Fully supports a wide range of hardware and device emulation
-            through the Quick EMUlator (QEMU).
-            </p></li>
-<li class="listitem"><p>
-            Provides a layer mechanism that allows you to easily extend
-            the system, make customizations, and keep them organized.
-            </p></li>
-</ul></div>
-<p>
-        You can use the Yocto Project to generate images for many kinds
-        of devices.
-        As mentioned earlier, the Yocto Project supports creation of
-        reference images that you can boot within and emulate using QEMU.
-        The standard example machines target QEMU full-system
-        emulation for 32-bit and 64-bit variants of x86, ARM, MIPS, and
-        PowerPC architectures.
-        Beyond emulation, you can use the layer mechanism to extend
-        support to just about any platform that Linux can run on and that
-        a toolchain can target.
-    </p>
-<p>
-        Another Yocto Project feature is the Sato reference User
-        Interface.
-        This optional UI that is based on GTK+ is intended for devices with
-        restricted screen sizes and is included as part of the
-        OpenEmbedded Core layer so that developers can test parts of the
-        software stack.
-    </p>
-<p>
-        While the Yocto Project does not provide a strict testing framework,
-        it does provide or generate for you artifacts that let you perform
-        target-level and emulated testing and debugging.
-        Additionally, if you are an
-        <span class="trademark">Eclipse</span>&#8482; IDE user, you can
-        install an Eclipse Yocto Plug-in to allow you to develop within that
-        familiar environment.
-    </p>
-<p>
-        By default, using the Yocto Project to build an image creates a Poky
-        distribution.
-        However, you can create your own distribution by providing key
-        <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>.
-        A good example is Angstrom, which has had a distribution
-        based on the Yocto Project since its inception.
-        Other examples include commercial distributions like
-        <a class="ulink" href="https://www.yoctoproject.org/organization/wind-river-systems" target="_self">Wind River Linux</a>,
-        <a class="ulink" href="https://www.yoctoproject.org/organization/mentor-graphics" target="_self">Mentor Embedded Linux</a>,
-        <a class="ulink" href="https://www.yoctoproject.org/organization/enea-ab" target="_self">ENEA Linux</a>
-        and <a class="ulink" href="https://www.yoctoproject.org/ecosystem/member-organizations" target="_self">others</a>.
-        See the "<a class="link" href="../dev-manual/creating-your-own-distribution.html" target="_self">Creating Your Own Distribution</a>"
-        section in the Yocto Project Development Tasks Manual for more
-        information.
-    </p>
-</div></body>
-</html>
diff --git a/documentation/getting-started/getting-started.html b/documentation/getting-started/getting-started.html
deleted file mode 100644
index 19c1384f8e..0000000000
--- a/documentation/getting-started/getting-started.html
+++ /dev/null
@@ -1,3900 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Getting Started With Yocto Project</title><link rel="stylesheet" type="text/css" href="getting-started-style.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div xml:lang="en" class="book" title="Getting Started With Yocto Project" id="getting-started-manual" lang="en"><div class="titlepage"><div><div><h1 class="title">
-            Getting Started With Yocto Project
-        </h1></div><div><div class="authorgroup">
-            <div class="author"><h3 class="author"><span class="firstname">Scott</span> <span class="surname">Rifenbark</span></h3><div class="affiliation">
-                    <span class="orgname">Scotty's Documentation Services, INC<br /></span>
-                </div><code class="email">&lt;<a class="email" href="mailto:srifenbark@gmail.com">srifenbark@gmail.com</a>&gt;</code></div>
-        </div></div><div><p class="copyright">Copyright © 2010-2018 Linux Foundation</p></div><div><div class="legalnotice" title="Legal Notice"><a id="idm45705112624512"></a>
-      <p>
-          Permission is granted to copy, distribute and/or modify this document under
-          the terms of the <a class="ulink" href="http://creativecommons.org/licenses/by-sa/2.0/uk/" target="_top">
-          Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</a> as published by
-          Creative Commons.
-      </p>
-           <div class="note" title="Manual Notes" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Manual Notes</h3>
-               <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                       This version of the
-                       <span class="emphasis"><em>Yocto Project Overview Manual</em></span>
-                       is for the 2.5 release of the
-                       Yocto Project.
-                       To be sure you have the latest version of the manual
-                       for this release, use the manual from the
-                       <a class="ulink" href="http://www.yoctoproject.org/documentation" target="_top">Yocto Project documentation page</a>.
-                       </p></li><li class="listitem"><p>
-                       For manuals associated with other releases of the Yocto
-                       Project, go to the
-                       <a class="ulink" href="http://www.yoctoproject.org/documentation" target="_top">Yocto Project documentation page</a>
-                       and use the drop-down "Active Releases" button
-                       and choose the manual associated with the desired
-                       Yocto Project.
-                       </p></li><li class="listitem"><p>
-                        To report any inaccuracies or problems with this
-                        manual, send an email to the Yocto Project
-                        discussion group at
-                        <code class="filename">yocto@yoctoproject.com</code> or log into
-                        the freenode <code class="filename">#yocto</code> channel.
-                        </p></li></ul></div>
-           </div>
-    </div></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="2"><strong>Revision History</strong></th></tr>
-            <tr><td align="left">Revision 2.5</td><td align="left">April 2018</td></tr><tr><td align="left" colspan="2">The initial document released with the Yocto Project 2.5 Release.</td></tr>
-        </table></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="chapter"><a href="#overview-manual-intro">1. The Yocto Project Overview Manual</a></span></dt><dd><dl><dt><span class="section"><a href="#overview-welcome">1.1. Welcome</a></span></dt><dt><span class="section"><a href="#overview-other-information">1.2. Other Information</a></span></dt></dl></dd><dt><span class="chapter"><a href="#overview-development-environment">2. The Yocto Project Development Environment</a></span></dt><dd><dl><dt><span class="section"><a href="#yp-intro">2.1. Introduction</a></span></dt><dt><span class="section"><a href="#open-source-philosophy">2.2. Open Source Philosophy</a></span></dt><dt><span class="section"><a href="#workflows">2.3. Workflows</a></span></dt><dt><span class="section"><a href="#git">2.4. Git</a></span></dt><dd><dl><dt><span class="section"><a href="#repositories-tags-and-branches">2.4.1. Repositories, Tags, and Branches</a></span></dt><dt><span class="section"><a href="#basic-commands">2.4.2. Basic Commands</a></span></dt></dl></dd><dt><span class="section"><a href="#yocto-project-repositories">2.5. Yocto Project Source Repositories</a></span></dt><dt><span class="section"><a href="#licensing">2.6. Licensing</a></span></dt><dt><span class="section"><a href="#recipe-syntax">2.7. Recipe Syntax</a></span></dt><dt><span class="section"><a href="#development-concepts">2.8. Development Concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#user-configuration">2.8.1. User Configuration</a></span></dt><dt><span class="section"><a href="#metadata-machine-configuration-and-policy-configuration">2.8.2. Metadata, Machine Configuration, and Policy Configuration</a></span></dt><dt><span class="section"><a href="#sources-dev-environment">2.8.3. Sources</a></span></dt><dt><span class="section"><a href="#package-feeds-dev-environment">2.8.4. Package Feeds</a></span></dt><dt><span class="section"><a href="#bitbake-dev-environment">2.8.5. BitBake</a></span></dt><dt><span class="section"><a href="#images-dev-environment">2.8.6. Images</a></span></dt><dt><span class="section"><a href="#sdk-dev-environment">2.8.7. Application Development SDK</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#overview-concepts">3. Yocto Project Concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#yocto-project-components">3.1. Yocto Project Components</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-components-bitbake">3.1.1. BitBake</a></span></dt><dt><span class="section"><a href="#usingpoky-components-metadata">3.1.2. Metadata (Recipes)</a></span></dt><dt><span class="section"><a href="#metadata-virtual-providers">3.1.3. Metadata (Virtual Providers)</a></span></dt><dt><span class="section"><a href="#usingpoky-components-classes">3.1.4. Classes</a></span></dt><dt><span class="section"><a href="#usingpoky-components-configuration">3.1.5. Configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#cross-development-toolchain-generation">3.2. Cross-Development Toolchain Generation</a></span></dt><dt><span class="section"><a href="#shared-state-cache">3.3. Shared State Cache</a></span></dt><dd><dl><dt><span class="section"><a href="#overall-architecture">3.3.1. Overall Architecture</a></span></dt><dt><span class="section"><a href="#overview-checksums">3.3.2. Checksums (Signatures)</a></span></dt><dt><span class="section"><a href="#shared-state">3.3.3. Shared State</a></span></dt><dt><span class="section"><a href="#tips-and-tricks">3.3.4. Tips and Tricks</a></span></dt></dl></dd><dt><span class="section"><a href="#automatically-added-runtime-dependencies">3.4. Automatically Added Runtime Dependencies</a></span></dt><dt><span class="section"><a href="#fakeroot-and-pseudo">3.5. Fakeroot and Pseudo</a></span></dt><dt><span class="section"><a href="#wayland">3.6. Wayland</a></span></dt><dd><dl><dt><span class="section"><a href="#wayland-support">3.6.1. Support</a></span></dt><dt><span class="section"><a href="#enabling-wayland-in-an-image">3.6.2. Enabling Wayland in an Image</a></span></dt><dt><span class="section"><a href="#running-weston">3.6.3. Running Weston</a></span></dt></dl></dd><dt><span class="section"><a href="#overview-licenses">3.7. Licenses</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-configuring-LIC_FILES_CHKSUM">3.7.1. Tracking License Changes</a></span></dt><dt><span class="section"><a href="#enabling-commercially-licensed-recipes">3.7.2. Enabling Commercially Licensed Recipes</a></span></dt></dl></dd><dt><span class="section"><a href="#x32">3.8. x32 psABI</a></span></dt></dl></dd></dl></div>
-    
-
-    <div class="chapter" title="Chapter 1. The Yocto Project Overview Manual" id="overview-manual-intro"><div class="titlepage"><div><div><h2 class="title">Chapter 1. The Yocto Project Overview Manual<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-manual-intro">¶</a></span></h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#overview-welcome">1.1. Welcome</a></span></dt><dt><span class="section"><a href="#overview-other-information">1.2. Other Information</a></span></dt></dl></div><div class="section" title="1.1. Welcome"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="overview-welcome">1.1. Welcome<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-welcome">¶</a></span></h2></div></div></div><p>
-            Welcome to the Yocto Project Overview Manual!
-            This manual introduces the Yocto Project by providing concepts,
-            software overviews, best-known-methods (BKMs), and any other
-            high-level introductory information suitable for a new Yocto
-            Project user.
-        </p><p>
-            The following list describes what you can get from this manual:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Major Topic:</em></span>
-                    Provide a high-level description of this major topic.
-                    </p></li></ul></div><p>
-        </p><p>
-            This manual does not give you the following:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <span class="emphasis"><em>Step-by-step Instructions for Development Tasks:</em></span>
-                    Instructional procedures reside in other manuals within
-                    the Yocto Project documentation set.
-                    For example, the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>
-                    provides examples on how to perform various development
-                    tasks.
-                    As another example, the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>
-                    manual contains detailed instructions on how to install an
-                    SDK, which is used to develop applications for target
-                    hardware.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Reference Material:</em></span>
-                    This type of material resides in an appropriate reference
-                    manual.
-                    For example, system variables are documented in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>.
-                    As another example, the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>
-                    contains reference information on BSPs.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Detailed Public Information Not Specific to the
-                    Yocto Project:</em></span>
-                    For example, exhaustive information on how to use the
-                    Source Control Manager Git is better covered with Internet
-                    searches and official Git Documentation than through the
-                    Yocto Project documentation.
-                    </p></li></ul></div><p>
-        </p></div><div class="section" title="1.2. Other Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="overview-other-information">1.2. Other Information<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-other-information">¶</a></span></h2></div></div></div><p>
-            Because this manual presents information for many different
-            topics, supplemental information is recommended for full
-            comprehension.
-            For additional introductory information on the Yocto Project, see
-            the <a class="ulink" href="http://www.yoctoproject.org" target="_top">Yocto Project Website</a>.
-            You can find an introductory to using the Yocto Project by working
-            through the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/yocto-project-qs/yocto-project-qs.html" target="_top">Yocto Project Quick Start</a>.
-        </p><p>
-            For a comprehensive list of links and other documentation, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#resources-links-and-related-documentation" target="_top">Links and Related Documentation</a>"
-            section in the Yocto Project Reference Manual.
-        </p></div></div>
-
-    <div class="chapter" title="Chapter 2. The Yocto Project Development Environment" id="overview-development-environment"><div class="titlepage"><div><div><h2 class="title">Chapter 2. The Yocto Project Development Environment<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-development-environment">¶</a></span></h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#yp-intro">2.1. Introduction</a></span></dt><dt><span class="section"><a href="#open-source-philosophy">2.2. Open Source Philosophy</a></span></dt><dt><span class="section"><a href="#workflows">2.3. Workflows</a></span></dt><dt><span class="section"><a href="#git">2.4. Git</a></span></dt><dd><dl><dt><span class="section"><a href="#repositories-tags-and-branches">2.4.1. Repositories, Tags, and Branches</a></span></dt><dt><span class="section"><a href="#basic-commands">2.4.2. Basic Commands</a></span></dt></dl></dd><dt><span class="section"><a href="#yocto-project-repositories">2.5. Yocto Project Source Repositories</a></span></dt><dt><span class="section"><a href="#licensing">2.6. Licensing</a></span></dt><dt><span class="section"><a href="#recipe-syntax">2.7. Recipe Syntax</a></span></dt><dt><span class="section"><a href="#development-concepts">2.8. Development Concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#user-configuration">2.8.1. User Configuration</a></span></dt><dt><span class="section"><a href="#metadata-machine-configuration-and-policy-configuration">2.8.2. Metadata, Machine Configuration, and Policy Configuration</a></span></dt><dt><span class="section"><a href="#sources-dev-environment">2.8.3. Sources</a></span></dt><dt><span class="section"><a href="#package-feeds-dev-environment">2.8.4. Package Feeds</a></span></dt><dt><span class="section"><a href="#bitbake-dev-environment">2.8.5. BitBake</a></span></dt><dt><span class="section"><a href="#images-dev-environment">2.8.6. Images</a></span></dt><dt><span class="section"><a href="#sdk-dev-environment">2.8.7. Application Development SDK</a></span></dt></dl></dd></dl></div><p>
-    This chapter takes a look at the Yocto Project development
-    environment and also provides a detailed look at what goes on during
-    development in that environment.
-    The chapter provides Yocto Project Development environment concepts that
-    help you understand how work is accomplished in an open source environment,
-    which is very different as compared to work accomplished in a closed,
-    proprietary environment.
-</p><p>
-    Specifically, this chapter addresses open source philosophy, workflows,
-    Git, source repositories, licensing, recipe syntax, and development
-    syntax.
-</p><div class="section" title="2.1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="yp-intro">2.1. Introduction<span class="permalink"><a alt="Permalink" title="Permalink" href="#yp-intro">¶</a></span></h2></div></div></div><p>
-        The Yocto Project is an open-source collaboration project whose
-        focus is for developers of embedded Linux systems.
-        Among other things, the Yocto Project uses an
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-system-term" target="_top">OpenEmbedded build system</a>.
-        The build system, which is based on the OpenEmbedded (OE) project and
-        uses the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#bitbake-term" target="_top">BitBake</a> tool,
-        constructs complete Linux images for architectures based on ARM, MIPS,
-        PowerPC, x86 and x86-64.
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            Historically, the OpenEmbedded build system, which is the
-            combination of BitBake and OE components, formed a reference
-            build host that was known as
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#poky" target="_top">Poky</a>"
-            (<span class="emphasis"><em>Pah</em></span>-kee).
-            The term "Poky", as used throughout the Yocto Project Documentation
-            set, can have different meanings.
-        </div><p>
-        The Yocto Project provides various ancillary tools for the embedded
-        developer and also features the Sato reference User Interface, which
-        is optimized for stylus-driven, low-resolution screens.
-    </p><div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr><td align="center"><img src="figures/YP-flow-diagram.png" align="middle" width="720" /></td></tr></table></div><p>
-        Here are some highlights for the Yocto Project:
-    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-            Provides a recent Linux kernel along with a set of system
-            commands and libraries suitable for the embedded
-            environment.
-            </p></li><li class="listitem"><p>
-            Makes available system components such as X11, GTK+, Qt,
-            Clutter, and SDL (among others) so you can create a rich user
-            experience on devices that have display hardware.
-            For devices that do not have a display or where you wish to
-            use alternative UI frameworks, these components need not be
-            installed.
-            </p></li><li class="listitem"><p>
-            Creates a focused and stable core compatible with the
-            OpenEmbedded project with which you can easily and reliably
-            build and develop.
-            </p></li><li class="listitem"><p>
-            Fully supports a wide range of hardware and device emulation
-            through the Quick EMUlator (QEMU).
-            </p></li><li class="listitem"><p>
-            Provides a layer mechanism that allows you to easily extend
-            the system, make customizations, and keep them organized.
-            </p></li></ul></div><p>
-        You can use the Yocto Project to generate images for many kinds
-        of devices.
-        As mentioned earlier, the Yocto Project supports creation of
-        reference images that you can boot within and emulate using QEMU.
-        The standard example machines target QEMU full-system
-        emulation for 32-bit and 64-bit variants of x86, ARM, MIPS, and
-        PowerPC architectures.
-        Beyond emulation, you can use the layer mechanism to extend
-        support to just about any platform that Linux can run on and that
-        a toolchain can target.
-    </p><p>
-        Another Yocto Project feature is the Sato reference User
-        Interface.
-        This optional UI that is based on GTK+ is intended for devices with
-        restricted screen sizes and is included as part of the
-        OpenEmbedded Core layer so that developers can test parts of the
-        software stack.
-    </p><p>
-        While the Yocto Project does not provide a strict testing framework,
-        it does provide or generate for you artifacts that let you perform
-        target-level and emulated testing and debugging.
-        Additionally, if you are an
-        <span class="trademark">Eclipse</span>™ IDE user, you can
-        install an Eclipse Yocto Plug-in to allow you to develop within that
-        familiar environment.
-    </p><p>
-        By default, using the Yocto Project to build an image creates a Poky
-        distribution.
-        However, you can create your own distribution by providing key
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#metadata" target="_top">Metadata</a>.
-        A good example is Angstrom, which has had a distribution
-        based on the Yocto Project since its inception.
-        Other examples include commercial distributions like
-        <a class="ulink" href="https://www.yoctoproject.org/organization/wind-river-systems" target="_top">Wind River Linux</a>,
-        <a class="ulink" href="https://www.yoctoproject.org/organization/mentor-graphics" target="_top">Mentor Embedded Linux</a>,
-        <a class="ulink" href="https://www.yoctoproject.org/organization/enea-ab" target="_top">ENEA Linux</a>
-        and <a class="ulink" href="https://www.yoctoproject.org/ecosystem/member-organizations" target="_top">others</a>.
-        See the "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-your-own-distribution" target="_top">Creating Your Own Distribution</a>"
-        section in the Yocto Project Development Tasks Manual for more
-        information.
-    </p></div><div class="section" title="2.2. Open Source Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="open-source-philosophy">2.2. Open Source Philosophy<span class="permalink"><a alt="Permalink" title="Permalink" href="#open-source-philosophy">¶</a></span></h2></div></div></div><p>
-        Open source philosophy is characterized by software development
-        directed by peer production and collaboration through an active
-        community of developers.
-        Contrast this to the more standard centralized development models
-        used by commercial software companies where a finite set of developers
-        produces a product for sale using a defined set of procedures that
-        ultimately result in an end product whose architecture and source
-        material are closed to the public.
-    </p><p>
-        Open source projects conceptually have differing concurrent agendas,
-        approaches, and production.
-        These facets of the development process can come from anyone in the
-        public (community) that has a stake in the software project.
-        The open source environment contains new copyright, licensing, domain,
-        and consumer issues that differ from the more traditional development
-        environment.
-        In an open source environment, the end product, source material,
-        and documentation are all available to the public at no cost.
-    </p><p>
-        A benchmark example of an open source project is the Linux kernel,
-        which was initially conceived and created by Finnish computer science
-        student Linus Torvalds in 1991.
-        Conversely, a good example of a non-open source project is the
-        <span class="trademark">Windows</span>® family of operating
-        systems developed by
-        <span class="trademark">Microsoft</span>® Corporation.
-    </p><p>
-        Wikipedia has a good historical description of the Open Source
-        Philosophy
-        <a class="ulink" href="http://en.wikipedia.org/wiki/Open_source" target="_top">here</a>.
-        You can also find helpful information on how to participate in the
-        Linux Community
-        <a class="ulink" href="http://ldn.linuxfoundation.org/book/how-participate-linux-community" target="_top">here</a>.
-    </p></div><div class="section" title="2.3. Workflows"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="workflows">2.3. Workflows<span class="permalink"><a alt="Permalink" title="Permalink" href="#workflows">¶</a></span></h2></div></div></div><p>
-        This section provides workflow concepts using the Yocto Project and
-        Git.
-        In particular, the information covers basic practices that describe
-        roles and actions in a collaborative development environment.
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            If you are familiar with this type of development environment, you
-            might not want to read this section.
-        </div><p>
-    </p><p>
-        The Yocto Project files are maintained using Git in "master"
-        branches whose Git histories track every change and whose structures
-        provides branches for all diverging functionality.
-        Although there is no need to use Git, many open source projects do so.
-    </p><p>
-
-    </p><p>
-        For the Yocto Project, a key individual called the "maintainer" is
-        responsible for the "master" branch of a given Git repository.
-        The "master" branch is the “upstream” repository from which final or
-        most recent builds of the project occur.
-        The maintainer is responsible for accepting changes from other
-        developers and for organizing the underlying branch structure to
-        reflect release strategies and so forth.
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>For information on finding out who is responsible for (maintains)
-            a particular area of code, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#how-to-submit-a-change" target="_top">Submitting a Change to the Yocto Project</a>"
-            section of the Yocto Project Development Tasks Manual.
-        </div><p>
-    </p><p>
-        The Yocto Project <code class="filename">poky</code> Git repository also has an
-        upstream contribution Git repository named
-        <code class="filename">poky-contrib</code>.
-        You can see all the branches in this repository using the web interface
-        of the
-        <a class="ulink" href="http://git.yoctoproject.org" target="_top">Source Repositories</a> organized
-        within the "Poky Support" area.
-        These branches temporarily hold changes to the project that have been
-        submitted or committed by the Yocto Project development team and by
-        community members who contribute to the project.
-        The maintainer determines if the changes are qualified to be moved
-        from the "contrib" branches into the "master" branch of the Git
-        repository.
-    </p><p>
-        Developers (including contributing community members) create and
-        maintain cloned repositories of the upstream "master" branch.
-        The cloned repositories are local to their development platforms and
-        are used to develop changes.
-        When a developer is satisfied with a particular feature or change,
-        they "push" the changes to the appropriate "contrib" repository.
-    </p><p>
-        Developers are responsible for keeping their local repository
-        up-to-date with "master".
-        They are also responsible for straightening out any conflicts that
-        might arise within files that are being worked on simultaneously by
-        more than one person.
-        All this work is done locally on the developer’s machine before
-        anything is pushed to a "contrib" area and examined at the maintainer’s
-        level.
-    </p><p>
-        A somewhat formal method exists by which developers commit changes
-        and push them into the "contrib" area and subsequently request that
-        the maintainer include them into "master".
-        This process is called “submitting a patch” or "submitting a change."
-        For information on submitting patches and changes, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#how-to-submit-a-change" target="_top">Submitting a Change to the Yocto Project</a>"
-        section in the Yocto Project Development Tasks Manual.
-    </p><p>
-        To summarize the development workflow:  a single point of entry
-        exists for changes into the project’s "master" branch of the
-        Git repository, which is controlled by the project’s maintainer.
-        And, a set of developers exist who independently develop, test, and
-        submit changes to "contrib" areas for the maintainer to examine.
-        The maintainer then chooses which changes are going to become a
-        permanent part of the project.
-    </p><p>
-        </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 270px"><td align="left"><img src="figures/git-workflow.png" align="left" height="270" /></td></tr></table><p>
-    </p><p>
-        While each development environment is unique, there are some best
-        practices or methods that help development run smoothly.
-        The following list describes some of these practices.
-        For more information about Git workflows, see the workflow topics in
-        the
-        <a class="ulink" href="http://book.git-scm.com" target="_top">Git Community Book</a>.
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                <span class="emphasis"><em>Make Small Changes:</em></span>
-                It is best to keep the changes you commit small as compared to
-                bundling many disparate changes into a single commit.
-                This practice not only keeps things manageable but also allows
-                the maintainer to more easily include or refuse changes.</p><p>It is also good practice to leave the repository in a
-                state that allows you to still successfully build your project.
-                In other words, do not commit half of a feature,
-                then add the other half as a separate, later commit.
-                Each commit should take you from one buildable project state
-                to another buildable state.
-                </p></li><li class="listitem"><p>
-                <span class="emphasis"><em>Use Branches Liberally:</em></span>
-                It is very easy to create, use, and delete local branches in
-                your working Git repository.
-                You can name these branches anything you like.
-                It is helpful to give them names associated with the particular
-                feature or change on which you are working.
-                Once you are done with a feature or change and have merged it
-                into your local master branch, simply discard the temporary
-                branch.
-                </p></li><li class="listitem"><p>
-                <span class="emphasis"><em>Merge Changes:</em></span>
-                The <code class="filename">git merge</code> command allows you to take
-                the changes from one branch and fold them into another branch.
-                This process is especially helpful when more than a single
-                developer might be working on different parts of the same
-                feature.
-                Merging changes also automatically identifies any collisions
-                or "conflicts" that might happen as a result of the same lines
-                of code being altered by two different developers.
-                </p></li><li class="listitem"><p>
-                <span class="emphasis"><em>Manage Branches:</em></span>
-                Because branches are easy to use, you should use a system
-                where branches indicate varying levels of code readiness.
-                For example, you can have a "work" branch to develop in, a
-                "test" branch where the code or change is tested, a "stage"
-                branch where changes are ready to be committed, and so forth.
-                As your project develops, you can merge code across the
-                branches to reflect ever-increasing stable states of the
-                development.
-                </p></li><li class="listitem"><p>
-                <span class="emphasis"><em>Use Push and Pull:</em></span>
-                The push-pull workflow is based on the concept of developers
-                "pushing" local commits to a remote repository, which is
-                usually a contribution repository.
-                This workflow is also based on developers "pulling" known
-                states of the project down into their local development
-                repositories.
-                The workflow easily allows you to pull changes submitted by
-                other developers from the upstream repository into your
-                work area ensuring that you have the most recent software
-                on which to develop.
-                The Yocto Project has two scripts named
-                <code class="filename">create-pull-request</code> and
-                <code class="filename">send-pull-request</code> that ship with the
-                release to facilitate this workflow.
-                You can find these scripts in the <code class="filename">scripts</code>
-                folder of the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>.
-                For information on how to use these scripts, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#pushing-a-change-upstream" target="_top">Using Scripts to Push a Change Upstream and Request a Pull</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p></li><li class="listitem"><p>
-                <span class="emphasis"><em>Patch Workflow:</em></span>
-                This workflow allows you to notify the maintainer through an
-                email that you have a change (or patch) you would like
-                considered for the "master" branch of the Git repository.
-                To send this type of change, you format the patch and then
-                send the email using the Git commands
-                <code class="filename">git format-patch</code> and
-                <code class="filename">git send-email</code>.
-                For information on how to use these scripts, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#how-to-submit-a-change" target="_top">Submitting a Change to the Yocto Project</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p></li></ul></div><p>
-    </p></div><div class="section" title="2.4. Git"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="git">2.4. Git<span class="permalink"><a alt="Permalink" title="Permalink" href="#git">¶</a></span></h2></div></div></div><p>
-        The Yocto Project makes extensive use of Git, which is a
-        free, open source distributed version control system.
-        Git supports distributed development, non-linear development,
-        and can handle large projects.
-        It is best that you have some fundamental understanding
-        of how Git tracks projects and how to work with Git if
-        you are going to use the Yocto Project for development.
-        This section provides a quick overview of how Git works and
-        provides you with a summary of some essential Git commands.
-        </p><div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Notes</h3><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    For more information on Git, see
-                    <a class="ulink" href="http://git-scm.com/documentation" target="_top">http://git-scm.com/documentation</a>.
-                    </p></li><li class="listitem"><p>
-                    If you need to download Git, it is recommended that you add
-                    Git to your system through your distribution's "software
-                    store" (e.g. for Ubuntu, use the Ubuntu Software feature).
-                    For the Git download page, see
-                    <a class="ulink" href="http://git-scm.com/download" target="_top">http://git-scm.com/download</a>.
-                    </p></li><li class="listitem"><p>
-                    For examples beyond the limited few in this section on how
-                    to use Git with the Yocto Project, see the
-                    "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#working-with-yocto-project-source-files" target="_top">Working With Yocto Project Source Files</a>"
-                    section in the Yocto Project Development Tasks Manual.
-                    </p></li></ul></div></div><p>
-    </p><div class="section" title="2.4.1. Repositories, Tags, and Branches"><div class="titlepage"><div><div><h3 class="title" id="repositories-tags-and-branches">2.4.1. Repositories, Tags, and Branches<span class="permalink"><a alt="Permalink" title="Permalink" href="#repositories-tags-and-branches">¶</a></span></h3></div></div></div><p>
-            As mentioned briefly in the previous section and also in the
-            "<a class="link" href="#workflows" title="2.3. Workflows">Workflows</a>" section,
-            the Yocto Project maintains source repositories at
-            <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi" target="_top">http://git.yoctoproject.org/cgit.cgi</a>.
-            If you look at this web-interface of the repositories, each item
-            is a separate Git repository.
-        </p><p>
-            Git repositories use branching techniques that track content
-            change (not files) within a project (e.g. a new feature or updated
-            documentation).
-            Creating a tree-like structure based on project divergence allows
-            for excellent historical information over the life of a project.
-            This methodology also allows for an environment from which you can
-            do lots of local experimentation on projects as you develop
-            changes or new features.
-        </p><p>
-            A Git repository represents all development efforts for a given
-            project.
-            For example, the Git repository <code class="filename">poky</code> contains
-            all changes and developments for Poky over the course of its
-            entire life.
-            That means that all changes that make up all releases are captured.
-            The repository maintains a complete history of changes.
-        </p><p>
-            You can create a local copy of any repository by "cloning" it
-            with the <code class="filename">git clone</code> command.
-            When you clone a Git repository, you end up with an identical
-            copy of the repository on your development system.
-            Once you have a local copy of a repository, you can take steps to
-            develop locally.
-            For examples on how to clone Git repositories, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#working-with-yocto-project-source-files" target="_top">Working With Yocto Project Source Files</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p><p>
-            It is important to understand that Git tracks content change and
-            not files.
-            Git uses "branches" to organize different development efforts.
-            For example, the <code class="filename">poky</code> repository has
-            several branches that include the current "sumo"
-            branch, the "master" branch, and many branches for past
-            Yocto Project releases.
-            You can see all the branches by going to
-            <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/" target="_top">http://git.yoctoproject.org/cgit.cgi/poky/</a> and
-            clicking on the
-            <code class="filename"><a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/refs/heads" target="_top">[...]</a></code>
-            link beneath the "Branch" heading.
-        </p><p>
-            Each of these branches represents a specific area of development.
-            The "master" branch represents the current or most recent
-            development.
-            All other branches represent offshoots of the "master" branch.
-        </p><p>
-            When you create a local copy of a Git repository, the copy has
-            the same set of branches as the original.
-            This means you can use Git to create a local working area
-            (also called a branch) that tracks a specific development branch
-            from the upstream source Git repository.
-            in other words, you can define your local Git environment to
-            work on any development branch in the repository.
-            To help illustrate, consider the following example Git commands:
-            </p><pre class="literallayout">
-     $ cd ~
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git checkout -b sumo origin/sumo
-            </pre><p>
-            In the previous example after moving to the home directory, the
-            <code class="filename">git clone</code> command creates a
-            local copy of the upstream <code class="filename">poky</code> Git repository.
-            By default, Git checks out the "master" branch for your work.
-            After changing the working directory to the new local repository
-            (i.e. <code class="filename">poky</code>), the
-            <code class="filename">git checkout</code> command creates
-            and checks out a local branch named "sumo", which
-            tracks the upstream "origin/sumo" branch.
-            Changes you make while in this branch would ultimately affect
-            the upstream "sumo" branch of the
-            <code class="filename">poky</code> repository.
-        </p><p>
-            It is important to understand that when you create and checkout a
-            local working branch based on a branch name,
-            your local environment matches the "tip" of that particular
-            development branch at the time you created your local branch,
-            which could be different from the files in the "master" branch
-            of the upstream repository.
-            In other words, creating and checking out a local branch based on
-            the "sumo" branch name is not the same as
-            cloning and checking out the "master" branch if the repository.
-            Keep reading to see how you create a local snapshot of a Yocto
-            Project Release.
-        </p><p>
-            Git uses "tags" to mark specific changes in a repository.
-            Typically, a tag is used to mark a special point such as the final
-            change before a project is released.
-            You can see the tags used with the <code class="filename">poky</code> Git
-            repository by going to
-            <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/" target="_top">http://git.yoctoproject.org/cgit.cgi/poky/</a> and
-            clicking on the
-            <code class="filename"><a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/refs/tags" target="_top">[...]</a></code>
-            link beneath the "Tag" heading.
-        </p><p>
-            Some key tags for the <code class="filename">poky</code> are
-            <code class="filename">jethro-14.0.3</code>,
-            <code class="filename">morty-16.0.1</code>,
-            <code class="filename">pyro-17.0.0</code>, and
-            <code class="filename">sumo-20.0.0</code>.
-            These tags represent Yocto Project releases.
-        </p><p>
-            When you create a local copy of the Git repository, you also
-            have access to all the tags in the upstream repository.
-            Similar to branches, you can create and checkout a local working
-            Git branch based on a tag name.
-            When you do this, you get a snapshot of the Git repository that
-            reflects the state of the files when the change was made associated
-            with that tag.
-            The most common use is to checkout a working branch that matches
-            a specific Yocto Project release.
-            Here is an example:
-            </p><pre class="literallayout">
-     $ cd ~
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git fetch --all --tags --prune
-     $ git checkout tags/pyro-17.0.0 -b my-pyro-17.0.0
-            </pre><p>
-            In this example, the name of the top-level directory of your
-            local Yocto Project repository is <code class="filename">poky</code>.
-            After moving to the <code class="filename">poky</code> directory, the
-            <code class="filename">git fetch</code> command makes all the upstream
-            tags available locally in your repository.
-            Finally, the <code class="filename">git checkout</code> command
-            creates and checks out a branch named "my-pyro-17.0.0" that is
-            based on the specific change upstream in the repository
-            associated with the "pyro-17.0.0" tag.
-            The files in your repository now exactly match that particular
-            Yocto Project release as it is tagged in the upstream Git
-            repository.
-            It is important to understand that when you create and
-            checkout a local working branch based on a tag, your environment
-            matches a specific point in time and not the entire development
-            branch (i.e. the "tip" of the branch).
-        </p></div><div class="section" title="2.4.2. Basic Commands"><div class="titlepage"><div><div><h3 class="title" id="basic-commands">2.4.2. Basic Commands<span class="permalink"><a alt="Permalink" title="Permalink" href="#basic-commands">¶</a></span></h3></div></div></div><p>
-            Git has an extensive set of commands that lets you manage changes
-            and perform collaboration over the life of a project.
-            Conveniently though, you can manage with a small set of basic
-            operations and workflows once you understand the basic
-            philosophy behind Git.
-            You do not have to be an expert in Git to be functional.
-            A good place to look for instruction on a minimal set of Git
-            commands is
-            <a class="ulink" href="http://git-scm.com/documentation" target="_top">here</a>.
-        </p><p>
-            If you do not know much about Git, you should educate
-            yourself by visiting the links previously mentioned.
-        </p><p>
-            The following list of Git commands briefly describes some basic
-            Git operations as a way to get started.
-            As with any set of commands, this list (in most cases) simply shows
-            the base command and omits the many arguments they support.
-            See the Git documentation for complete descriptions and strategies
-            on how to use these commands:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git init</code>:</em></span>
-                    Initializes an empty Git repository.
-                    You cannot use Git commands unless you have a
-                    <code class="filename">.git</code> repository.
-                    </p></li><li class="listitem"><p><a id="git-commands-clone"></a>
-                    <span class="emphasis"><em><code class="filename">git clone</code>:</em></span>
-                    Creates a local clone of a Git repository that is on
-                    equal footing with a fellow developer’s Git repository
-                    or an upstream repository.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git add</code>:</em></span>
-                    Locally stages updated file contents to the index that
-                    Git uses to track changes.
-                    You must stage all files that have changed before you
-                    can commit them.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git commit</code>:</em></span>
-                    Creates a local "commit" that documents the changes you
-                    made.
-                    Only changes that have been staged can be committed.
-                    Commits are used for historical purposes, for determining
-                    if a maintainer of a project will allow the change,
-                    and for ultimately pushing the change from your local
-                    Git repository into the project’s upstream repository.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git status</code>:</em></span>
-                    Reports any modified files that possibly need to be
-                    staged and gives you a status of where you stand regarding
-                    local commits as compared to the upstream repository.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git checkout</code> <em class="replaceable"><code>branch-name</code></em>:</em></span>
-                    Changes your working branch.
-                    This command is analogous to "cd".
-                    </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">git checkout –b</code> <em class="replaceable"><code>working-branch</code></em>:</em></span>
-                    Creates and checks out a working branch on your local
-                    machine that you can use to isolate your work.
-                    It is a good idea to use local branches when adding
-                    specific features or changes.
-                    Using isolated branches facilitates easy removal of
-                    changes if they do not work out.
-                    </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">git branch</code>:</em></span>
-                    Displays the existing local branches associated with your
-                    local repository.
-                    The branch that you have currently checked out is noted
-                    with an asterisk character.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git branch -D</code> <em class="replaceable"><code>branch-name</code></em>:</em></span>
-                    Deletes an existing local branch.
-                    You need to be in a local branch other than the one you
-                    are deleting in order to delete
-                    <em class="replaceable"><code>branch-name</code></em>.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git pull</code>:</em></span>
-                    Retrieves information from an upstream Git repository
-                    and places it in your local Git repository.
-                    You use this command to make sure you are synchronized with
-                    the repository from which you are basing changes
-                    (.e.g. the "master" branch).
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git push</code>:</em></span>
-                    Sends all your committed local changes to the upstream Git
-                    repository that your local repository is tracking
-                    (e.g. a contribution repository).
-                    The maintainer of the project draws from these repositories
-                    to merge changes (commits) into the appropriate branch
-                    of project's upstream repository.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git merge</code>:</em></span>
-                    Combines or adds changes from one
-                    local branch of your repository with another branch.
-                    When you create a local Git repository, the default branch
-                    is named "master".
-                    A typical workflow is to create a temporary branch that is
-                    based off "master" that you would use for isolated work.
-                    You would make your changes in that isolated branch,
-                    stage and commit them locally, switch to the "master"
-                    branch, and then use the <code class="filename">git merge</code>
-                    command to apply the changes from your isolated branch
-                    into the currently checked out branch (e.g. "master").
-                    After the merge is complete and if you are done with
-                    working in that isolated branch, you can safely delete
-                    the isolated branch.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git cherry-pick</code>:</em></span>
-                    Choose and apply specific commits from one branch
-                    into another branch.
-                    There are times when you might not be able to merge
-                    all the changes in one branch with
-                    another but need to pick out certain ones.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">gitk</code>:</em></span>
-                    Provides a GUI view of the branches and changes in your
-                    local Git repository.
-                    This command is a good way to graphically see where things
-                    have diverged in your local repository.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        You need to install the <code class="filename">gitk</code>
-                        package on your development system to use this
-                        command.
-                    </div><p>
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git log</code>:</em></span>
-                    Reports a history of your commits to the repository.
-                    This report lists all commits regardless of whether you
-                    have pushed them upstream or not.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em><code class="filename">git diff</code>:</em></span>
-                    Displays line-by-line differences between a local
-                    working file and the same file as understood by Git.
-                    This command is useful to see what you have changed
-                    in any given file.
-                    </p></li></ul></div><p>
-        </p></div></div><div class="section" title="2.5. Yocto Project Source Repositories"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="yocto-project-repositories">2.5. Yocto Project Source Repositories<span class="permalink"><a alt="Permalink" title="Permalink" href="#yocto-project-repositories">¶</a></span></h2></div></div></div><p>
-        The Yocto Project team maintains complete source repositories for all
-        Yocto Project files at
-        <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi" target="_top">http://git.yoctoproject.org/cgit/cgit.cgi</a>.
-        This web-based source code browser is organized into categories by
-        function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and
-        so forth.
-        From the interface, you can click on any particular item in the "Name"
-        column and see the URL at the bottom of the page that you need to clone
-        a Git repository for that particular item.
-        Having a local Git repository of the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>,
-        which is usually named "poky", allows
-        you to make changes, contribute to the history, and ultimately enhance
-        the Yocto Project's tools, Board Support Packages, and so forth.
-    </p><p>
-        For any supported release of Yocto Project, you can also go to the
-        <a class="ulink" href="http://www.yoctoproject.org" target="_top">Yocto Project Website</a> and
-        select the "Downloads" tab and get a released tarball of the
-        <code class="filename">poky</code> repository or any supported BSP tarballs.
-        Unpacking these tarballs gives you a snapshot of the released
-        files.
-        </p><div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Notes</h3><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    The recommended method for setting up the Yocto Project
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>
-                    and the files for supported BSPs
-                    (e.g., <code class="filename">meta-intel</code>) is to use
-                    <a class="link" href="#git" title="2.4. Git">Git</a> to create a local copy of
-                    the upstream repositories.
-                    </p></li><li class="listitem"><p>
-                    Be sure to always work in matching branches for both
-                    the selected BSP repository and the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>
-                    (i.e. <code class="filename">poky</code>) repository.
-                    For example, if you have checked out the "master" branch
-                    of <code class="filename">poky</code> and you are going to use
-                    <code class="filename">meta-intel</code>, be sure to checkout the
-                    "master" branch of <code class="filename">meta-intel</code>.
-                    </p></li></ul></div></div><p>
-    </p><p>
-        In summary, here is where you can get the project files needed for
-        development:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a id="source-repositories"></a>
-                <span class="emphasis"><em>
-                <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi" target="_top">Source Repositories:</a>
-                </em></span>
-                This area contains IDE Plugins, Matchbox, Poky, Poky Support,
-                Tools, Yocto Linux Kernel, and Yocto Metadata Layers.
-                You can create local copies of Git repositories for each of
-                these areas.</p><p>
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/source-repos.png" align="middle" width="540" /></td></tr></table><p>
-                For steps on how to view and access these upstream Git
-                repositories, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#accessing-source-repositories" target="_top">Accessing Source Repositories</a>"
-                Section in the Yocto Project Development Tasks Manual.
-                </p></li><li class="listitem"><p><a id="index-downloads"></a>
-                <span class="emphasis"><em>
-                <a class="ulink" href="http://downloads.yoctoproject.org/releases/" target="_top">Index of /releases:</a>
-                </em></span>
-                This is an index of releases such as
-                the <span class="trademark">Eclipse</span>™
-                Yocto Plug-in, miscellaneous support, Poky, Pseudo, installers
-                for cross-development toolchains, and all released versions of
-                Yocto Project in the form of images or tarballs.
-                Downloading and extracting these files does not produce a local
-                copy of the Git repository but rather a snapshot of a
-                particular release or image.</p><p>
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 315px"><td align="center"><img src="figures/index-downloads.png" align="middle" height="315" /></td></tr></table><p>
-                For steps on how to view and access these files, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#accessing-index-of-releases" target="_top">Accessing Index of Releases</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p></li><li class="listitem"><p><a id="downloads-page"></a>
-                <span class="emphasis"><em>"Downloads" page for the
-                <a class="ulink" href="http://www.yoctoproject.org" target="_top">Yocto Project Website</a>:
-                </em></span></p><p class="writernotes">This section will change due to
-                reworking of the YP Website.</p><p>The Yocto Project website includes a "Downloads" tab
-                that allows you to download any Yocto Project
-                release and Board Support Package (BSP) in tarball form.
-                The tarballs are similar to those found in the
-                <a class="ulink" href="http://downloads.yoctoproject.org/releases/" target="_top">Index of /releases:</a> area.</p><p>
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/yp-download.png" align="middle" width="540" /></td></tr></table><p>
-                For steps on how to use the "Downloads" page, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#using-the-downloads-page" target="_top">Using the Downloads Page</a>"
-                section in the Yocto Project Development Tasks Manual.
-                </p></li></ul></div><p>
-    </p></div><div class="section" title="2.6. Licensing"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="licensing">2.6. Licensing<span class="permalink"><a alt="Permalink" title="Permalink" href="#licensing">¶</a></span></h2></div></div></div><p>
-        Because open source projects are open to the public, they have
-        different licensing structures in place.
-        License evolution for both Open Source and Free Software has an
-        interesting history.
-        If you are interested in this history, you can find basic information
-        here:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                <a class="ulink" href="http://en.wikipedia.org/wiki/Open-source_license" target="_top">Open source license history</a>
-                </p></li><li class="listitem"><p>
-                <a class="ulink" href="http://en.wikipedia.org/wiki/Free_software_license" target="_top">Free software license history</a>
-                </p></li></ul></div><p>
-    </p><p>
-        In general, the Yocto Project is broadly licensed under the
-        Massachusetts Institute of Technology (MIT) License.
-        MIT licensing permits the reuse of software within proprietary
-        software as long as the license is distributed with that software.
-        MIT is also compatible with the GNU General Public License (GPL).
-        Patches to the Yocto Project follow the upstream licensing scheme.
-        You can find information on the MIT license
-        <a class="ulink" href="http://www.opensource.org/licenses/mit-license.php" target="_top">here</a>.
-        You can find information on the GNU GPL
-        <a class="ulink" href="http://www.opensource.org/licenses/LGPL-3.0" target="_top">here</a>.
-    </p><p>
-        When you build an image using the Yocto Project, the build process
-        uses a known list of licenses to ensure compliance.
-        You can find this list in the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>
-        at <code class="filename">meta/files/common-licenses</code>.
-        Once the build completes, the list of all licenses found and used
-        during that build are kept in the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>
-        at <code class="filename">tmp/deploy/licenses</code>.
-    </p><p>
-        If a module requires a license that is not in the base list, the
-        build process generates a warning during the build.
-        These tools make it easier for a developer to be certain of the
-        licenses with which their shipped products must comply.
-        However, even with these tools it is still up to the developer to
-        resolve potential licensing issues.
-    </p><p>
-        The base list of licenses used by the build process is a combination
-        of the Software Package Data Exchange (SPDX) list and the Open
-        Source Initiative (OSI) projects.
-        <a class="ulink" href="http://spdx.org" target="_top">SPDX Group</a> is a working group of
-        the Linux Foundation that maintains a specification for a standard
-        format for communicating the components, licenses, and copyrights
-        associated with a software package.
-        <a class="ulink" href="http://opensource.org" target="_top">OSI</a> is a corporation
-        dedicated to the Open Source Definition and the effort for reviewing
-        and approving licenses that conform to the Open Source Definition
-        (OSD).
-    </p><p>
-        You can find a list of the combined SPDX and OSI licenses that the
-        Yocto Project uses in the
-        <code class="filename">meta/files/common-licenses</code> directory in your
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>.
-    </p><p>
-        For information that can help you maintain compliance with various
-        open source licensing during the lifecycle of a product created using
-        the Yocto Project, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle" target="_top">Maintaining Open Source License Compliance During Your Product's Lifecycle</a>"
-        section in the Yocto Project Development Tasks Manual.
-    </p></div><div class="section" title="2.7. Recipe Syntax"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="recipe-syntax">2.7. Recipe Syntax<span class="permalink"><a alt="Permalink" title="Permalink" href="#recipe-syntax">¶</a></span></h2></div></div></div><p>
-        Understanding recipe file syntax is important for
-        writing recipes.
-        The following list overviews the basic items that make up a
-        BitBake recipe file.
-        For more complete BitBake syntax descriptions, see the
-        "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-metadata" target="_top">Syntax and Operators</a>"
-        chapter of the BitBake User Manual.
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Variable Assignments and Manipulations:</em></span>
-                Variable assignments allow a value to be assigned to a
-                variable.
-                The assignment can be static text or might include
-                the contents of other variables.
-                In addition to the assignment, appending and prepending
-                operations are also supported.</p><p>The following example shows some of the ways
-                you can use variables in recipes:
-                </p><pre class="literallayout">
-     S = "${WORKDIR}/postfix-${PV}"
-     CFLAGS += "-DNO_ASM"
-     SRC_URI_append = " file://fixup.patch"
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Functions:</em></span>
-                Functions provide a series of actions to be performed.
-                You usually use functions to override the default
-                implementation of a task function or to complement
-                a default function (i.e. append or prepend to an
-                existing function).
-                Standard functions use <code class="filename">sh</code> shell
-                syntax, although access to OpenEmbedded variables and
-                internal methods are also available.</p><p>The following is an example function from the
-                <code class="filename">sed</code> recipe:
-                </p><pre class="literallayout">
-     do_install () {
-         autotools_do_install
-         install -d ${D}${base_bindir}
-         mv ${D}${bindir}/sed ${D}${base_bindir}/sed
-         rmdir ${D}${bindir}/
-     }
-                </pre><p>
-                It is also possible to implement new functions that
-                are called between existing tasks as long as the
-                new functions are not replacing or complementing the
-                default functions.
-                You can implement functions in Python
-                instead of shell.
-                Both of these options are not seen in the majority of
-                recipes.</p></li><li class="listitem"><p><span class="emphasis"><em>Keywords:</em></span>
-                BitBake recipes use only a few keywords.
-                You use keywords to include common
-                functions (<code class="filename">inherit</code>), load parts
-                of a recipe from other files
-                (<code class="filename">include</code> and
-                <code class="filename">require</code>) and export variables
-                to the environment (<code class="filename">export</code>).</p><p>The following example shows the use of some of
-                these keywords:
-                </p><pre class="literallayout">
-     export POSTCONF = "${STAGING_BINDIR}/postconf"
-     inherit autoconf
-     require otherfile.inc
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Comments:</em></span>
-                Any lines that begin with the hash character
-                (<code class="filename">#</code>) are treated as comment lines
-                and are ignored:
-                </p><pre class="literallayout">
-     # This is a comment
-                </pre><p>
-                </p></li></ul></div><p>
-    </p><p>
-        This next list summarizes the most important and most commonly
-        used parts of the recipe syntax.
-        For more information on these parts of the syntax, you can
-        reference the
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-metadata" target="_top">Syntax and Operators</a>
-        chapter in the BitBake User Manual.
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Line Continuation: <code class="filename">\</code></em></span> -
-                Use the backward slash (<code class="filename">\</code>)
-                character to split a statement over multiple lines.
-                Place the slash character at the end of the line that
-                is to be continued on the next line:
-                </p><pre class="literallayout">
-     VAR = "A really long \
-            line"
-                </pre><p>
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    You cannot have any characters including spaces
-                    or tabs after the slash character.
-                </div><p>
-                </p></li><li class="listitem"><p>
-                <span class="emphasis"><em>Using Variables: <code class="filename">${...}</code></em></span> -
-                Use the <code class="filename">${<em class="replaceable"><code>VARNAME</code></em>}</code> syntax to
-                access the contents of a variable:
-                </p><pre class="literallayout">
-     SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
-                </pre><p>
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    It is important to understand that the value of a
-                    variable expressed in this form does not get
-                    substituted automatically.
-                    The expansion of these expressions happens
-                    on-demand later (e.g. usually when a function that
-                    makes reference to the variable executes).
-                    This behavior ensures that the values are most
-                    appropriate for the context in which they are
-                    finally used.
-                    On the rare occasion that you do need the variable
-                    expression to be expanded immediately, you can use
-                    the <code class="filename">:=</code> operator instead of
-                    <code class="filename">=</code> when you make the
-                    assignment, but this is not generally needed.
-                </div><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Quote All Assignments: <code class="filename">"<em class="replaceable"><code>value</code></em>"</code></em></span> -
-                Use double quotes around the value in all variable
-                assignments.
-                </p><pre class="literallayout">
-     VAR1 = "${OTHERVAR}"
-     VAR2 = "The version is ${PV}"
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Conditional Assignment: <code class="filename">?=</code></em></span> -
-                Conditional assignment is used to assign a value to
-                a variable, but only when the variable is currently
-                unset.
-                Use the question mark followed by the equal sign
-                (<code class="filename">?=</code>) to make a "soft" assignment
-                used for conditional assignment.
-                Typically, "soft" assignments are used in the
-                <code class="filename">local.conf</code> file for variables
-                that are allowed to come through from the external
-                environment.
-                </p><p>Here is an example where
-                <code class="filename">VAR1</code> is set to "New value" if
-                it is currently empty.
-                However, if <code class="filename">VAR1</code> has already been
-                set, it remains unchanged:
-                </p><pre class="literallayout">
-     VAR1 ?= "New value"
-                </pre><p>
-                In this next example, <code class="filename">VAR1</code>
-                is left with the value "Original value":
-                </p><pre class="literallayout">
-     VAR1 = "Original value"
-     VAR1 ?= "New value"
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Appending: <code class="filename">+=</code></em></span> -
-                Use the plus character followed by the equals sign
-                (<code class="filename">+=</code>) to append values to existing
-                variables.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    This operator adds a space between the existing
-                    content of the variable and the new content.
-                </div><p>Here is an example:
-                </p><pre class="literallayout">
-     SRC_URI += "file://fix-makefile.patch"
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Prepending: <code class="filename">=+</code></em></span> -
-                Use the equals sign followed by the plus character
-                (<code class="filename">=+</code>) to prepend values to existing
-                variables.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    This operator adds a space between the new content
-                    and the existing content of the variable.
-                </div><p>Here is an example:
-                </p><pre class="literallayout">
-     VAR =+ "Starts"
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Appending: <code class="filename">_append</code></em></span> -
-                Use the <code class="filename">_append</code> operator to
-                append values to existing variables.
-                This operator does not add any additional space.
-                Also, the operator is applied after all the
-                <code class="filename">+=</code>, and
-                <code class="filename">=+</code> operators have been applied and
-                after all <code class="filename">=</code> assignments have
-                occurred.
-                </p><p>The following example shows the space being
-                explicitly added to the start to ensure the appended
-                value is not merged with the existing value:
-                </p><pre class="literallayout">
-     SRC_URI_append = " file://fix-makefile.patch"
-                </pre><p>
-                You can also use the <code class="filename">_append</code>
-                operator with overrides, which results in the actions
-                only being performed for the specified target or
-                machine:
-                </p><pre class="literallayout">
-     SRC_URI_append_sh4 = " file://fix-makefile.patch"
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Prepending: <code class="filename">_prepend</code></em></span> -
-                Use the <code class="filename">_prepend</code> operator to
-                prepend values to existing variables.
-                This operator does not add any additional space.
-                Also, the operator is applied after all the
-                <code class="filename">+=</code>, and
-                <code class="filename">=+</code> operators have been applied and
-                after all <code class="filename">=</code> assignments have
-                occurred.
-                </p><p>The following example shows the space being
-                explicitly added to the end to ensure the prepended
-                value is not merged with the existing value:
-                </p><pre class="literallayout">
-     CFLAGS_prepend = "-I${S}/myincludes "
-                </pre><p>
-                You can also use the <code class="filename">_prepend</code>
-                operator with overrides, which results in the actions
-                only being performed for the specified target or
-                machine:
-                </p><pre class="literallayout">
-     CFLAGS_prepend_sh4 = "-I${S}/myincludes "
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Overrides:</em></span> -
-                You can use overrides to set a value conditionally,
-                typically based on how the recipe is being built.
-                For example, to set the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-KBRANCH" target="_top"><code class="filename">KBRANCH</code></a>
-                variable's value to "standard/base" for any target
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-MACHINE" target="_top"><code class="filename">MACHINE</code></a>,
-                except for qemuarm where it should be set to
-                "standard/arm-versatile-926ejs", you would do the
-                following:
-                </p><pre class="literallayout">
-     KBRANCH = "standard/base"
-     KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
-                </pre><p>
-                Overrides are also used to separate alternate values
-                of a variable in other situations.
-                For example, when setting variables such as
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-FILES" target="_top"><code class="filename">FILES</code></a>
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-RDEPENDS" target="_top"><code class="filename">RDEPENDS</code></a>
-                that are specific to individual packages produced by
-                a recipe, you should always use an override that
-                specifies the name of the package.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Indentation:</em></span>
-                Use spaces for indentation rather than than tabs.
-                For shell functions, both currently work.
-                However, it is a policy decision of the Yocto Project
-                to use tabs in shell functions.
-                Realize that some layers have a policy to use spaces
-                for all indentation.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Using Python for Complex Operations: <code class="filename">${@<em class="replaceable"><code>python_code</code></em>}</code></em></span> -
-                For more advanced processing, it is possible to use
-                Python code during variable assignments (e.g.
-                search and replacement on a variable).</p><p>You indicate Python code using the
-                <code class="filename">${@<em class="replaceable"><code>python_code</code></em>}</code>
-                syntax for the variable assignment:
-                </p><pre class="literallayout">
-     SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
-                </pre><p>
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Shell Function Syntax:</em></span>
-                Write shell functions as if you were writing a shell
-                script when you describe a list of actions to take.
-                You should ensure that your script works with a generic
-                <code class="filename">sh</code> and that it does not require
-                any <code class="filename">bash</code> or other shell-specific
-                functionality.
-                The same considerations apply to various system
-                utilities (e.g. <code class="filename">sed</code>,
-                <code class="filename">grep</code>, <code class="filename">awk</code>,
-                and so forth) that you might wish to use.
-                If in doubt, you should check with multiple
-                implementations - including those from BusyBox.
-                </p></li></ul></div><p>
-    </p></div><div class="section" title="2.8. Development Concepts"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="development-concepts">2.8. Development Concepts<span class="permalink"><a alt="Permalink" title="Permalink" href="#development-concepts">¶</a></span></h2></div></div></div><p>
-        This section takes a more detailed look inside the development
-        process.
-        The following diagram represents development at a high level.
-        The remainder of this chapter expands on the fundamental input, output,
-        process, and
-        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#metadata" target="_top">Metadata</a>) blocks
-        that make up development in the Yocto Project environment.
-    </p><p><a id="general-yocto-environment-figure"></a>
-        </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 383px"><td align="center"><img src="figures/yocto-environment-ref.png" align="middle" height="383" /></td></tr></table><p>
-    </p><p>
-        In general, development consists of several functional areas:
-        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>User Configuration:</em></span>
-                Metadata you can use to control the build process.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Metadata Layers:</em></span>
-                Various layers that provide software, machine, and
-                distro Metadata.</p></li><li class="listitem"><p><span class="emphasis"><em>Source Files:</em></span>
-                Upstream releases, local projects, and SCMs.</p></li><li class="listitem"><p><span class="emphasis"><em>Build System:</em></span>
-                Processes under the control of
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#bitbake-term" target="_top">BitBake</a>.
-                This block expands on how BitBake fetches source, applies
-                patches, completes compilation, analyzes output for package
-                generation, creates and tests packages, generates images, and
-                generates cross-development tools.</p></li><li class="listitem"><p><span class="emphasis"><em>Package Feeds:</em></span>
-                Directories containing output packages (RPM, DEB or IPK),
-                which are subsequently used in the construction of an image or
-                SDK, produced by the build system.
-                These feeds can also be copied and shared using a web server or
-                other means to facilitate extending or updating existing
-                images on devices at runtime if runtime package management is
-                enabled.</p></li><li class="listitem"><p><span class="emphasis"><em>Images:</em></span>
-                Images produced by the development process.
-                </p></li><li class="listitem"><p><span class="emphasis"><em>Application Development SDK:</em></span>
-                Cross-development tools that are produced along with an image
-                or separately with BitBake.</p></li></ul></div><p>
-    </p><div class="section" title="2.8.1. User Configuration"><div class="titlepage"><div><div><h3 class="title" id="user-configuration">2.8.1. User Configuration<span class="permalink"><a alt="Permalink" title="Permalink" href="#user-configuration">¶</a></span></h3></div></div></div><p>
-            User configuration helps define the build.
-            Through user configuration, you can tell BitBake the
-            target architecture for which you are building the image,
-            where to store downloaded source, and other build properties.
-        </p><p>
-            The following figure shows an expanded representation of the
-            "User Configuration" box of the
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>:
-        </p><p>
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 405px"><td align="center"><img src="figures/user-configuration.png" align="middle" height="405" /></td></tr></table><p>
-        </p><p>
-            BitBake needs some basic configuration files in order to complete
-            a build.
-            These files are <code class="filename">*.conf</code> files.
-            The minimally necessary ones reside as example files in the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>.
-            For simplicity, this section refers to the Source Directory as
-            the "Poky Directory."
-        </p><p>
-            When you clone the <code class="filename">poky</code> Git repository or you
-            download and unpack a Yocto Project release, you can set up the
-            Source Directory to be named anything you want.
-            For this discussion, the cloned repository uses the default
-            name <code class="filename">poky</code>.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The Poky repository is primarily an aggregation of existing
-                repositories.
-                It is not a canonical upstream source.
-            </div><p>
-        </p><p>
-            The <code class="filename">meta-poky</code> layer inside Poky contains
-            a <code class="filename">conf</code> directory that has example
-            configuration files.
-            These example files are used as a basis for creating actual
-            configuration files when you source the build environment
-            script
-            (i.e.
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#structure-core-script" target="_top"><code class="filename">oe-init-build-env</code></a>).
-        </p><p>
-            Sourcing the build environment script creates a
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>
-            if one does not already exist.
-            BitBake uses the Build Directory for all its work during builds.
-            The Build Directory has a <code class="filename">conf</code> directory that
-            contains default versions of your <code class="filename">local.conf</code>
-            and <code class="filename">bblayers.conf</code> configuration files.
-            These default configuration files are created only if versions
-            do not already exist in the Build Directory at the time you
-            source the build environment setup script.
-        </p><p>
-            Because the Poky repository is fundamentally an aggregation of
-            existing repositories, some users might be familiar with running
-            the <code class="filename">oe-init-build-env</code> script in the context
-            of separate OpenEmbedded-Core and BitBake repositories rather than a
-            single Poky repository.
-            This discussion assumes the script is executed from within a cloned
-            or unpacked version of Poky.
-        </p><p>
-            Depending on where the script is sourced, different sub-scripts
-            are called to set up the Build Directory (Yocto or OpenEmbedded).
-            Specifically, the script
-            <code class="filename">scripts/oe-setup-builddir</code> inside the
-            poky directory sets up the Build Directory and seeds the directory
-            (if necessary) with configuration files appropriate for the
-            Yocto Project development environment.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The <code class="filename">scripts/oe-setup-builddir</code> script
-                uses the <code class="filename">$TEMPLATECONF</code> variable to
-                determine which sample configuration files to locate.
-            </div><p>
-        </p><p>
-            The <code class="filename">local.conf</code> file provides many
-            basic variables that define a build environment.
-            Here is a list of a few.
-            To see the default configurations in a <code class="filename">local.conf</code>
-            file created by the build environment script, see the
-            <code class="filename">local.conf.sample</code> in the
-            <code class="filename">meta-poky</code> layer:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Parallelism Options:</em></span>
-                    Controlled by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BB_NUMBER_THREADS" target="_top"><code class="filename">BB_NUMBER_THREADS</code></a>,
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PARALLEL_MAKE" target="_top"><code class="filename">PARALLEL_MAKE</code></a>,
-                    and
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#var-BB_NUMBER_PARSE_THREADS" target="_top"><code class="filename">BB_NUMBER_PARSE_THREADS</code></a>
-                    variables.</p></li><li class="listitem"><p><span class="emphasis"><em>Target Machine Selection:</em></span>
-                    Controlled by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-MACHINE" target="_top"><code class="filename">MACHINE</code></a>
-                    variable.</p></li><li class="listitem"><p><span class="emphasis"><em>Download Directory:</em></span>
-                    Controlled by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DL_DIR" target="_top"><code class="filename">DL_DIR</code></a>
-                    variable.</p></li><li class="listitem"><p><span class="emphasis"><em>Shared State Directory:</em></span>
-                    Controlled by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SSTATE_DIR" target="_top"><code class="filename">SSTATE_DIR</code></a>
-                    variable.</p></li><li class="listitem"><p><span class="emphasis"><em>Build Output:</em></span>
-                    Controlled by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TMPDIR" target="_top"><code class="filename">TMPDIR</code></a>
-                    variable.</p></li></ul></div><p>
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                Configurations set in the <code class="filename">conf/local.conf</code>
-                file can also be set in the
-                <code class="filename">conf/site.conf</code> and
-                <code class="filename">conf/auto.conf</code> configuration files.
-            </div><p>
-        </p><p>
-            The <code class="filename">bblayers.conf</code> file tells BitBake what
-            layers you want considered during the build.
-            By default, the layers listed in this file include layers
-            minimally needed by the build system.
-            However, you must manually add any custom layers you have created.
-            You can find more information on working with the
-            <code class="filename">bblayers.conf</code> file in the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#enabling-your-layer" target="_top">Enabling Your Layer</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p><p>
-            The files <code class="filename">site.conf</code> and
-            <code class="filename">auto.conf</code> are not created by the environment
-            initialization script.
-            If you want the <code class="filename">site.conf</code> file, you need to
-            create that yourself.
-            The <code class="filename">auto.conf</code> file is typically created by
-            an autobuilder:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em><code class="filename">site.conf</code>:</em></span>
-                    You can use the <code class="filename">conf/site.conf</code>
-                    configuration file to configure multiple build directories.
-                    For example, suppose you had several build environments and
-                    they shared some common features.
-                    You can set these default build properties here.
-                    A good example is perhaps the packaging format to use
-                    through the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_CLASSES" target="_top"><code class="filename">PACKAGE_CLASSES</code></a>
-                    variable.</p><p>One useful scenario for using the
-                    <code class="filename">conf/site.conf</code> file is to extend your
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BBPATH" target="_top"><code class="filename">BBPATH</code></a>
-                    variable to include the path to a
-                    <code class="filename">conf/site.conf</code>.
-                    Then, when BitBake looks for Metadata using
-                    <code class="filename">BBPATH</code>, it finds the
-                    <code class="filename">conf/site.conf</code> file and applies your
-                    common configurations found in the file.
-                    To override configurations in a particular build directory,
-                    alter the similar configurations within that build
-                    directory's <code class="filename">conf/local.conf</code> file.
-                    </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">auto.conf</code>:</em></span>
-                    The file is usually created and written to by
-                    an autobuilder.
-                    The settings put into the file are typically the same as
-                    you would find in the <code class="filename">conf/local.conf</code>
-                    or the <code class="filename">conf/site.conf</code> files.
-                    </p></li></ul></div><p>
-        </p><p>
-            You can edit all configuration files to further define
-            any particular build environment.
-            This process is represented by the "User Configuration Edits"
-            box in the figure.
-        </p><p>
-            When you launch your build with the
-            <code class="filename">bitbake <em class="replaceable"><code>target</code></em></code>
-            command, BitBake sorts out the configurations to ultimately
-            define your build environment.
-            It is important to understand that the OpenEmbedded build system
-            reads the configuration files in a specific order:
-            <code class="filename">site.conf</code>, <code class="filename">auto.conf</code>,
-            and <code class="filename">local.conf</code>.
-            And, the build system applies the normal assignment statement
-            rules.
-            Because the files are parsed in a specific order, variable
-            assignments for the same variable could be affected.
-            For example, if the <code class="filename">auto.conf</code> file and
-            the <code class="filename">local.conf</code> set
-            <em class="replaceable"><code>variable1</code></em> to different values, because
-            the build system parses <code class="filename">local.conf</code> after
-            <code class="filename">auto.conf</code>,
-            <em class="replaceable"><code>variable1</code></em> is assigned the value from
-            the <code class="filename">local.conf</code> file.
-        </p></div><div class="section" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"><div class="titlepage"><div><div><h3 class="title" id="metadata-machine-configuration-and-policy-configuration">2.8.2. Metadata, Machine Configuration, and Policy Configuration<span class="permalink"><a alt="Permalink" title="Permalink" href="#metadata-machine-configuration-and-policy-configuration">¶</a></span></h3></div></div></div><p>
-            The previous section described the user configurations that
-            define BitBake's global behavior.
-            This section takes a closer look at the layers the build system
-            uses to further control the build.
-            These layers provide Metadata for the software, machine, and
-            policy.
-        </p><p>
-            In general, three types of layer input exist:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Policy Configuration:</em></span>
-                    Distribution Layers provide top-level or general
-                    policies for the image or SDK being built.
-                    For example, this layer would dictate whether BitBake
-                    produces RPM or IPK packages.</p></li><li class="listitem"><p><span class="emphasis"><em>Machine Configuration:</em></span>
-                    Board Support Package (BSP) layers provide machine
-                    configurations.
-                    This type of information is specific to a particular
-                    target architecture.</p></li><li class="listitem"><p><span class="emphasis"><em>Metadata:</em></span>
-                    Software layers contain user-supplied recipe files,
-                    patches, and append files.
-                    </p></li></ul></div><p>
-        </p><p>
-            The following figure shows an expanded representation of the
-            Metadata, Machine Configuration, and Policy Configuration input
-            (layers) boxes of the
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>:
-        </p><p>
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 675px"><td align="center"><img src="figures/layer-input.png" align="middle" width="720" /></td></tr></table><p>
-        </p><p>
-            In general, all layers have a similar structure.
-            They all contain a licensing file
-            (e.g. <code class="filename">COPYING</code>) if the layer is to be
-            distributed, a <code class="filename">README</code> file as good practice
-            and especially if the layer is to be distributed, a
-            configuration directory, and recipe directories.
-        </p><p>
-            The Yocto Project has many layers that can be used.
-            You can see a web-interface listing of them on the
-            <a class="ulink" href="http://git.yoctoproject.org/" target="_top">Source Repositories</a>
-            page.
-            The layers are shown at the bottom categorized under
-            "Yocto Metadata Layers."
-            These layers are fundamentally a subset of the
-            <a class="ulink" href="http://layers.openembedded.org/layerindex/layers/" target="_top">OpenEmbedded Metadata Index</a>,
-            which lists all layers provided by the OpenEmbedded community.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                Layers exist in the Yocto Project Source Repositories that
-                cannot be found in the OpenEmbedded Metadata Index.
-                These layers are either deprecated or experimental in nature.
-            </div><p>
-        </p><p>
-            BitBake uses the <code class="filename">conf/bblayers.conf</code> file,
-            which is part of the user configuration, to find what layers it
-            should be using as part of the build.
-        </p><p>
-            For more information on layers, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_top">Understanding and Creating Layers</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p><div class="section" title="2.8.2.1. Distro Layer"><div class="titlepage"><div><div><h4 class="title" id="distro-layer">2.8.2.1. Distro Layer<span class="permalink"><a alt="Permalink" title="Permalink" href="#distro-layer">¶</a></span></h4></div></div></div><p>
-                The distribution layer provides policy configurations for your
-                distribution.
-                Best practices dictate that you isolate these types of
-                configurations into their own layer.
-                Settings you provide in
-                <code class="filename">conf/distro/<em class="replaceable"><code>distro</code></em>.conf</code> override
-                similar
-                settings that BitBake finds in your
-                <code class="filename">conf/local.conf</code> file in the Build
-                Directory.
-            </p><p>
-                The following list provides some explanation and references
-                for what you typically find in the distribution layer:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>classes:</em></span>
-                        Class files (<code class="filename">.bbclass</code>) hold
-                        common functionality that can be shared among
-                        recipes in the distribution.
-                        When your recipes inherit a class, they take on the
-                        settings and functions for that class.
-                        You can read more about class files in the
-                        "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes" target="_top">Classes</a>"
-                        section of the Yocto Reference Manual.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em>conf:</em></span>
-                        This area holds configuration files for the
-                        layer (<code class="filename">conf/layer.conf</code>),
-                        the distribution
-                        (<code class="filename">conf/distro/<em class="replaceable"><code>distro</code></em>.conf</code>),
-                        and any distribution-wide include files.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em>recipes-*:</em></span>
-                        Recipes and append files that affect common
-                        functionality across the distribution.
-                        This area could include recipes and append files
-                        to add distribution-specific configuration,
-                        initialization scripts, custom image recipes,
-                        and so forth.</p></li></ul></div><p>
-            </p></div><div class="section" title="2.8.2.2. BSP Layer"><div class="titlepage"><div><div><h4 class="title" id="bsp-layer">2.8.2.2. BSP Layer<span class="permalink"><a alt="Permalink" title="Permalink" href="#bsp-layer">¶</a></span></h4></div></div></div><p>
-                The BSP Layer provides machine configurations.
-                Everything in this layer is specific to the machine for which
-                you are building the image or the SDK.
-                A common structure or form is defined for BSP layers.
-                You can learn more about this structure in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    In order for a BSP layer to be considered compliant with the
-                    Yocto Project, it must meet some structural requirements.
-                </div><p>
-            </p><p>
-                The BSP Layer's configuration directory contains
-                configuration files for the machine
-                (<code class="filename">conf/machine/<em class="replaceable"><code>machine</code></em>.conf</code>) and,
-                of course, the layer (<code class="filename">conf/layer.conf</code>).
-            </p><p>
-                The remainder of the layer is dedicated to specific recipes
-                by function: <code class="filename">recipes-bsp</code>,
-                <code class="filename">recipes-core</code>,
-                <code class="filename">recipes-graphics</code>, and
-                <code class="filename">recipes-kernel</code>.
-                Metadata can exist for multiple formfactors, graphics
-                support systems, and so forth.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    While the figure shows several <code class="filename">recipes-*</code>
-                    directories, not all these directories appear in all
-                    BSP layers.
-                </div><p>
-            </p></div><div class="section" title="2.8.2.3. Software Layer"><div class="titlepage"><div><div><h4 class="title" id="software-layer">2.8.2.3. Software Layer<span class="permalink"><a alt="Permalink" title="Permalink" href="#software-layer">¶</a></span></h4></div></div></div><p>
-                The software layer provides the Metadata for additional
-                software packages used during the build.
-                This layer does not include Metadata that is specific to the
-                distribution or the machine, which are found in their
-                respective layers.
-            </p><p>
-                This layer contains any new recipes that your project needs
-                in the form of recipe files.
-            </p></div></div><div class="section" title="2.8.3. Sources"><div class="titlepage"><div><div><h3 class="title" id="sources-dev-environment">2.8.3. Sources<span class="permalink"><a alt="Permalink" title="Permalink" href="#sources-dev-environment">¶</a></span></h3></div></div></div><p>
-            In order for the OpenEmbedded build system to create an image or
-            any target, it must be able to access source files.
-            The
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>
-            represents source files using the "Upstream Project Releases",
-            "Local Projects", and "SCMs (optional)" boxes.
-            The figure represents mirrors, which also play a role in locating
-            source files, with the "Source Mirror(s)" box.
-        </p><p>
-            The method by which source files are ultimately organized is
-            a function of the project.
-            For example, for released software, projects tend to use tarballs
-            or other archived files that can capture the state of a release
-            guaranteeing that it is statically represented.
-            On the other hand, for a project that is more dynamic or
-            experimental in nature, a project might keep source files in a
-            repository controlled by a Source Control Manager (SCM) such as
-            Git.
-            Pulling source from a repository allows you to control
-            the point in the repository (the revision) from which you want to
-            build software.
-            Finally, a combination of the two might exist, which would give the
-            consumer a choice when deciding where to get source files.
-        </p><p>
-            BitBake uses the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SRC_URI" target="_top"><code class="filename">SRC_URI</code></a>
-            variable to point to source files regardless of their location.
-            Each recipe must have a <code class="filename">SRC_URI</code> variable
-            that points to the source.
-        </p><p>
-            Another area that plays a significant role in where source files
-            come from is pointed to by the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DL_DIR" target="_top"><code class="filename">DL_DIR</code></a>
-            variable.
-            This area is a cache that can hold previously downloaded source.
-            You can also instruct the OpenEmbedded build system to create
-            tarballs from Git repositories, which is not the default behavior,
-            and store them in the <code class="filename">DL_DIR</code> by using the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BB_GENERATE_MIRROR_TARBALLS" target="_top"><code class="filename">BB_GENERATE_MIRROR_TARBALLS</code></a>
-            variable.
-        </p><p>
-            Judicious use of a <code class="filename">DL_DIR</code> directory can
-            save the build system a trip across the Internet when looking
-            for files.
-            A good method for using a download directory is to have
-            <code class="filename">DL_DIR</code> point to an area outside of your
-            Build Directory.
-            Doing so allows you to safely delete the Build Directory
-            if needed without fear of removing any downloaded source file.
-        </p><p>
-            The remainder of this section provides a deeper look into the
-            source files and the mirrors.
-            Here is a more detailed look at the source file area of the
-            base figure:
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 675px"><td align="center"><img src="figures/source-input.png" align="middle" width="630" /></td></tr></table><p>
-        </p><div class="section" title="2.8.3.1. Upstream Project Releases"><div class="titlepage"><div><div><h4 class="title" id="upstream-project-releases">2.8.3.1. Upstream Project Releases<span class="permalink"><a alt="Permalink" title="Permalink" href="#upstream-project-releases">¶</a></span></h4></div></div></div><p>
-                Upstream project releases exist anywhere in the form of an
-                archived file (e.g. tarball or zip file).
-                These files correspond to individual recipes.
-                For example, the figure uses specific releases each for
-                BusyBox, Qt, and Dbus.
-                An archive file can be for any released product that can be
-                built using a recipe.
-            </p></div><div class="section" title="2.8.3.2. Local Projects"><div class="titlepage"><div><div><h4 class="title" id="local-projects">2.8.3.2. Local Projects<span class="permalink"><a alt="Permalink" title="Permalink" href="#local-projects">¶</a></span></h4></div></div></div><p>
-                Local projects are custom bits of software the user provides.
-                These bits reside somewhere local to a project - perhaps
-                a directory into which the user checks in items (e.g.
-                a local directory containing a development source tree
-                used by the group).
-            </p><p>
-                The canonical method through which to include a local project
-                is to use the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-externalsrc" target="_top"><code class="filename">externalsrc</code></a>
-                class to include that local project.
-                You use either the <code class="filename">local.conf</code> or a
-                recipe's append file to override or set the
-                recipe to point to the local directory on your disk to pull
-                in the whole source tree.
-            </p><p>
-                For information on how to use the
-                <code class="filename">externalsrc</code> class, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-externalsrc" target="_top"><code class="filename">externalsrc.bbclass</code></a>"
-                section.
-            </p></div><div class="section" title="2.8.3.3. Source Control Managers (Optional)"><div class="titlepage"><div><div><h4 class="title" id="scms">2.8.3.3. Source Control Managers (Optional)<span class="permalink"><a alt="Permalink" title="Permalink" href="#scms">¶</a></span></h4></div></div></div><p>
-                Another place the build system can get source files from is
-                through an SCM such as Git or Subversion.
-                In this case, a repository is cloned or checked out.
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-fetch" target="_top"><code class="filename">do_fetch</code></a>
-                task inside BitBake uses
-                the <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SRC_URI" target="_top"><code class="filename">SRC_URI</code></a>
-                variable and the argument's prefix to determine the correct
-                fetcher module.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                For information on how to have the OpenEmbedded build system
-                generate tarballs for Git repositories and place them in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DL_DIR" target="_top"><code class="filename">DL_DIR</code></a>
-                directory, see the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BB_GENERATE_MIRROR_TARBALLS" target="_top"><code class="filename">BB_GENERATE_MIRROR_TARBALLS</code></a>
-                variable.
-            </div><p>
-                When fetching a repository, BitBake uses the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SRCREV" target="_top"><code class="filename">SRCREV</code></a>
-                variable to determine the specific revision from which to
-                build.
-            </p></div><div class="section" title="2.8.3.4. Source Mirror(s)"><div class="titlepage"><div><div><h4 class="title" id="source-mirrors">2.8.3.4. Source Mirror(s)<span class="permalink"><a alt="Permalink" title="Permalink" href="#source-mirrors">¶</a></span></h4></div></div></div><p>
-                Two kinds of mirrors exist: pre-mirrors and regular mirrors.
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PREMIRRORS" target="_top"><code class="filename">PREMIRRORS</code></a>
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-MIRRORS" target="_top"><code class="filename">MIRRORS</code></a>
-                variables point to these, respectively.
-                BitBake checks pre-mirrors before looking upstream for any
-                source files.
-                Pre-mirrors are appropriate when you have a shared directory
-                that is not a directory defined by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DL_DIR" target="_top"><code class="filename">DL_DIR</code></a>
-                variable.
-                A Pre-mirror typically points to a shared directory that is
-                local to your organization.
-            </p><p>
-                Regular mirrors can be any site across the Internet that is
-                used as an alternative location for source code should the
-                primary site not be functioning for some reason or another.
-            </p></div></div><div class="section" title="2.8.4. Package Feeds"><div class="titlepage"><div><div><h3 class="title" id="package-feeds-dev-environment">2.8.4. Package Feeds<span class="permalink"><a alt="Permalink" title="Permalink" href="#package-feeds-dev-environment">¶</a></span></h3></div></div></div><p>
-            When the OpenEmbedded build system generates an image or an SDK,
-            it gets the packages from a package feed area located in the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>.
-            The
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>
-            shows this package feeds area in the upper-right corner.
-        </p><p>
-            This section looks a little closer into the package feeds area used
-            by the build system.
-            Here is a more detailed look at the area:
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 540px"><td align="center"><img src="figures/package-feeds.png" align="middle" width="630" /></td></tr></table><p>
-        </p><p>
-            Package feeds are an intermediary step in the build process.
-            The OpenEmbedded build system provides classes to generate
-            different package types, and you specify which classes to enable
-            through the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_CLASSES" target="_top"><code class="filename">PACKAGE_CLASSES</code></a>
-            variable.
-            Before placing the packages into package feeds,
-            the build process validates them with generated output quality
-            assurance checks through the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-insane" target="_top"><code class="filename">insane</code></a>
-            class.
-        </p><p>
-            The package feed area resides in the Build Directory.
-            The directory the build system uses to temporarily store packages
-            is determined by a combination of variables and the particular
-            package manager in use.
-            See the "Package Feeds" box in the illustration and note the
-            information to the right of that area.
-            In particular, the following defines where package files are
-            kept:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR" target="_top"><code class="filename">DEPLOY_DIR</code></a>:
-                    Defined as <code class="filename">tmp/deploy</code> in the Build
-                    Directory.
-                    </p></li><li class="listitem"><p><code class="filename">DEPLOY_DIR_*</code>:
-                    Depending on the package manager used, the package type
-                    sub-folder.
-                    Given RPM, IPK, or DEB packaging and tarball creation, the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR_RPM" target="_top"><code class="filename">DEPLOY_DIR_RPM</code></a>,
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR_IPK" target="_top"><code class="filename">DEPLOY_DIR_IPK</code></a>,
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR_DEB" target="_top"><code class="filename">DEPLOY_DIR_DEB</code></a>,
-                    or
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR_TAR" target="_top"><code class="filename">DEPLOY_DIR_TAR</code></a>,
-                    variables are used, respectively.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_ARCH" target="_top"><code class="filename">PACKAGE_ARCH</code></a>:
-                    Defines architecture-specific sub-folders.
-                    For example, packages could exist for the i586 or qemux86
-                    architectures.
-                    </p></li></ul></div><p>
-        </p><p>
-            BitBake uses the <code class="filename">do_package_write_*</code> tasks to
-            generate packages and place them into the package holding area (e.g.
-            <code class="filename">do_package_write_ipk</code> for IPK packages).
-            See the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package_write_deb" target="_top"><code class="filename">do_package_write_deb</code></a>",
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package_write_ipk" target="_top"><code class="filename">do_package_write_ipk</code></a>",
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package_write_rpm" target="_top"><code class="filename">do_package_write_rpm</code></a>",
-            and
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package_write_tar" target="_top"><code class="filename">do_package_write_tar</code></a>"
-            sections for additional information.
-            As an example, consider a scenario where an IPK packaging manager
-            is being used and package architecture support for both i586
-            and qemux86 exist.
-            Packages for the i586 architecture are placed in
-            <code class="filename">build/tmp/deploy/ipk/i586</code>, while packages for
-            the qemux86 architecture are placed in
-            <code class="filename">build/tmp/deploy/ipk/qemux86</code>.
-        </p></div><div class="section" title="2.8.5. BitBake"><div class="titlepage"><div><div><h3 class="title" id="bitbake-dev-environment">2.8.5. BitBake<span class="permalink"><a alt="Permalink" title="Permalink" href="#bitbake-dev-environment">¶</a></span></h3></div></div></div><p>
-            The OpenEmbedded build system uses
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#bitbake-term" target="_top">BitBake</a>
-            to produce images.
-            You can see from the
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>,
-            the BitBake area consists of several functional areas.
-            This section takes a closer look at each of those areas.
-        </p><p>
-            Separate documentation exists for the BitBake tool.
-            See the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual" target="_top">BitBake User Manual</a>
-            for reference material on BitBake.
-        </p><div class="section" title="2.8.5.1. Source Fetching"><div class="titlepage"><div><div><h4 class="title" id="source-fetching-dev-environment">2.8.5.1. Source Fetching<span class="permalink"><a alt="Permalink" title="Permalink" href="#source-fetching-dev-environment">¶</a></span></h4></div></div></div><p>
-                The first stages of building a recipe are to fetch and unpack
-                the source code:
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="585"><tr style="height: 450px"><td align="center"><img src="figures/source-fetching.png" align="middle" width="585" /></td></tr></table><p>
-            </p><p>
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-fetch" target="_top"><code class="filename">do_fetch</code></a>
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-unpack" target="_top"><code class="filename">do_unpack</code></a>
-                tasks fetch the source files and unpack them into the work
-                directory.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    For every local file (e.g. <code class="filename">file://</code>)
-                    that is part of a recipe's
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SRC_URI" target="_top"><code class="filename">SRC_URI</code></a>
-                    statement, the OpenEmbedded build system takes a checksum
-                    of the file for the recipe and inserts the checksum into
-                    the signature for the <code class="filename">do_fetch</code>.
-                    If any local file has been modified, the
-                    <code class="filename">do_fetch</code> task and all tasks that
-                    depend on it are re-executed.
-                </div><p>
-                By default, everything is accomplished in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>,
-                which has a defined structure.
-                For additional general information on the Build Directory,
-                see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#structure-core-build" target="_top"><code class="filename">build/</code></a>"
-                section in the Yocto Project Reference Manual.
-            </p><p>
-                Unpacked source files are pointed to by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-S" target="_top"><code class="filename">S</code></a>
-                variable.
-                Each recipe has an area in the Build Directory where the
-                unpacked source code resides.
-                The name of that directory for any given recipe is defined from
-                several different variables.
-                You can see the variables that define these directories
-                by looking at the figure:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TMPDIR" target="_top"><code class="filename">TMPDIR</code></a> -
-                        The base directory where the OpenEmbedded build system
-                        performs all its work during the build.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_ARCH" target="_top"><code class="filename">PACKAGE_ARCH</code></a> -
-                        The architecture of the built package or packages.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TARGET_OS" target="_top"><code class="filename">TARGET_OS</code></a> -
-                        The operating system of the target device.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PN" target="_top"><code class="filename">PN</code></a> -
-                        The name of the built package.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PV" target="_top"><code class="filename">PV</code></a> -
-                        The version of the recipe used to build the package.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PR" target="_top"><code class="filename">PR</code></a> -
-                        The revision of the recipe used to build the package.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a> -
-                        The location within <code class="filename">TMPDIR</code> where
-                        a specific package is built.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-S" target="_top"><code class="filename">S</code></a> -
-                        Contains the unpacked source files for a given recipe.
-                        </p></li></ul></div><p>
-            </p></div><div class="section" title="2.8.5.2. Patching"><div class="titlepage"><div><div><h4 class="title" id="patching-dev-environment">2.8.5.2. Patching<span class="permalink"><a alt="Permalink" title="Permalink" href="#patching-dev-environment">¶</a></span></h4></div></div></div><p>
-                Once source code is fetched and unpacked, BitBake locates
-                patch files and applies them to the source files:
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 450px"><td align="center"><img src="figures/patching.png" align="middle" width="540" /></td></tr></table><p>
-            </p><p>
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-patch" target="_top"><code class="filename">do_patch</code></a>
-                task processes recipes by
-                using the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SRC_URI" target="_top"><code class="filename">SRC_URI</code></a>
-                variable to locate applicable patch files, which by default
-                are <code class="filename">*.patch</code> or
-                <code class="filename">*.diff</code> files, or any file if
-                "apply=yes" is specified for the file in
-                <code class="filename">SRC_URI</code>.
-            </p><p>
-                BitBake finds and applies multiple patches for a single recipe
-                in the order in which it finds the patches.
-                Patches are applied to the recipe's source files located in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-S" target="_top"><code class="filename">S</code></a>
-                directory.
-            </p><p>
-                For more information on how the source directories are
-                created, see the
-                "<a class="link" href="#source-fetching-dev-environment" title="2.8.5.1. Source Fetching">Source Fetching</a>"
-                section.
-            </p></div><div class="section" title="2.8.5.3. Configuration and Compilation"><div class="titlepage"><div><div><h4 class="title" id="configuration-and-compilation-dev-environment">2.8.5.3. Configuration and Compilation<span class="permalink"><a alt="Permalink" title="Permalink" href="#configuration-and-compilation-dev-environment">¶</a></span></h4></div></div></div><p>
-                After source code is patched, BitBake executes tasks that
-                configure and compile the source code:
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 450px"><td align="center"><img src="figures/configuration-compile-autoreconf.png" align="middle" width="630" /></td></tr></table><p>
-            </p><p>
-                This step in the build process consists of three tasks:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                        <span class="emphasis"><em><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-prepare_recipe_sysroot" target="_top"><code class="filename">do_prepare_recipe_sysroot</code></a>:</em></span>
-                        This task sets up the two sysroots in
-                        <code class="filename">${</code><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a><code class="filename">}</code>
-                        (i.e. <code class="filename">recipe-sysroot</code> and
-                        <code class="filename">recipe-sysroot-native</code>) so that
-                        the sysroots contain the contents of the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-populate_sysroot" target="_top"><code class="filename">do_populate_sysroot</code></a>
-                        tasks of the recipes on which the recipe
-                        containing the tasks depends.
-                        A sysroot exists for both the target and for the native
-                        binaries, which run on the host system.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">do_configure</code>:</em></span>
-                        This task configures the source by enabling and
-                        disabling any build-time and configuration options for
-                        the software being built.
-                        Configurations can come from the recipe itself as well
-                        as from an inherited class.
-                        Additionally, the software itself might configure itself
-                        depending on the target for which it is being built.
-                        </p><p>The configurations handled by the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-configure" target="_top"><code class="filename">do_configure</code></a>
-                        task are specific
-                        to source code configuration for the source code
-                        being built by the recipe.</p><p>If you are using the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-autotools" target="_top"><code class="filename">autotools</code></a>
-                        class,
-                        you can add additional configuration options by using
-                        the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-EXTRA_OECONF" target="_top"><code class="filename">EXTRA_OECONF</code></a>
-                        or
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGECONFIG_CONFARGS" target="_top"><code class="filename">PACKAGECONFIG_CONFARGS</code></a>
-                        variables.
-                        For information on how this variable works within
-                        that class, see the
-                        <code class="filename">meta/classes/autotools.bbclass</code> file.
-                        </p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">do_compile</code>:</em></span>
-                        Once a configuration task has been satisfied, BitBake
-                        compiles the source using the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-compile" target="_top"><code class="filename">do_compile</code></a>
-                        task.
-                        Compilation occurs in the directory pointed to by the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-B" target="_top"><code class="filename">B</code></a>
-                        variable.
-                        Realize that the <code class="filename">B</code> directory is, by
-                        default, the same as the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-S" target="_top"><code class="filename">S</code></a>
-                        directory.</p></li><li class="listitem"><p><span class="emphasis"><em><code class="filename">do_install</code>:</em></span>
-                        Once compilation is done, BitBake executes the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-install" target="_top"><code class="filename">do_install</code></a>
-                        task.
-                        This task copies files from the <code class="filename">B</code>
-                        directory and places them in a holding area pointed to
-                        by the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-D" target="_top"><code class="filename">D</code></a>
-                        variable.</p></li></ul></div><p>
-            </p></div><div class="section" title="2.8.5.4. Package Splitting"><div class="titlepage"><div><div><h4 class="title" id="package-splitting-dev-environment">2.8.5.4. Package Splitting<span class="permalink"><a alt="Permalink" title="Permalink" href="#package-splitting-dev-environment">¶</a></span></h4></div></div></div><p>
-                After source code is configured and compiled, the
-                OpenEmbedded build system analyzes
-                the results and splits the output into packages:
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 630px"><td align="center"><img src="figures/analysis-for-package-splitting.png" align="middle" width="630" /></td></tr></table><p>
-            </p><p>
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-packagedata" target="_top"><code class="filename">do_packagedata</code></a>
-                tasks combine to analyze
-                the files found in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-D" target="_top"><code class="filename">D</code></a> directory
-                and split them into subsets based on available packages and
-                files.
-                The analyzing process involves the following as well as other
-                items: splitting out debugging symbols,
-                looking at shared library dependencies between packages,
-                and looking at package relationships.
-                The <code class="filename">do_packagedata</code> task creates package
-                metadata based on the analysis such that the
-                OpenEmbedded build system can generate the final packages.
-                Working, staged, and intermediate results of the analysis
-                and package splitting process use these areas:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PKGD" target="_top"><code class="filename">PKGD</code></a> -
-                        The destination directory for packages before they are
-                        split.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PKGDATA_DIR" target="_top"><code class="filename">PKGDATA_DIR</code></a> -
-                        A shared, global-state directory that holds data
-                        generated during the packaging process.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PKGDESTWORK" target="_top"><code class="filename">PKGDESTWORK</code></a> -
-                        A temporary work area used by the
-                        <code class="filename">do_package</code> task.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PKGDEST" target="_top"><code class="filename">PKGDEST</code></a> -
-                        The parent directory for packages after they have
-                        been split.
-                        </p></li></ul></div><p>
-                The <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-FILES" target="_top"><code class="filename">FILES</code></a>
-                variable defines the files that go into each package in
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGES" target="_top"><code class="filename">PACKAGES</code></a>.
-                If you want details on how this is accomplished, you can
-                look at the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-package" target="_top"><code class="filename">package</code></a>
-                class.
-            </p><p>
-                Depending on the type of packages being created (RPM, DEB, or
-                IPK), the <code class="filename">do_package_write_*</code> task
-                creates the actual packages and places them in the
-                Package Feed area, which is
-                <code class="filename">${TMPDIR}/deploy</code>.
-                You can see the
-                "<a class="link" href="#package-feeds-dev-environment" title="2.8.4. Package Feeds">Package Feeds</a>"
-                section for more detail on that part of the build process.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    Support for creating feeds directly from the
-                    <code class="filename">deploy/*</code> directories does not exist.
-                    Creating such feeds usually requires some kind of feed
-                    maintenance mechanism that would upload the new packages
-                    into an official package feed (e.g. the
-                    Ångström distribution).
-                    This functionality is highly distribution-specific
-                    and thus is not provided out of the box.
-                </div><p>
-            </p></div><div class="section" title="2.8.5.5. Image Generation"><div class="titlepage"><div><div><h4 class="title" id="image-generation-dev-environment">2.8.5.5. Image Generation<span class="permalink"><a alt="Permalink" title="Permalink" href="#image-generation-dev-environment">¶</a></span></h4></div></div></div><p>
-                Once packages are split and stored in the Package Feeds area,
-                the OpenEmbedded build system uses BitBake to generate the
-                root filesystem image:
-                </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 630px"><td align="center"><img src="figures/image-generation.png" align="middle" width="540" /></td></tr></table><p>
-            </p><p>
-                The image generation process consists of several stages and
-                depends on several tasks and variables.
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-rootfs" target="_top"><code class="filename">do_rootfs</code></a>
-                task creates the root filesystem (file and directory structure)
-                for an image.
-                This task uses several key variables to help create the list
-                of packages to actually install:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL" target="_top"><code class="filename">IMAGE_INSTALL</code></a>:
-                        Lists out the base set of packages to install from
-                        the Package Feeds area.</p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE" target="_top"><code class="filename">PACKAGE_EXCLUDE</code></a>:
-                        Specifies packages that should not be installed.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_FEATURES" target="_top"><code class="filename">IMAGE_FEATURES</code></a>:
-                        Specifies features to include in the image.
-                        Most of these features map to additional packages for
-                        installation.</p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_CLASSES" target="_top"><code class="filename">PACKAGE_CLASSES</code></a>:
-                        Specifies the package backend to use and consequently
-                        helps determine where to locate packages within the
-                        Package Feeds area.</p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_LINGUAS" target="_top"><code class="filename">IMAGE_LINGUAS</code></a>:
-                        Determines the language(s) for which additional
-                        language support packages are installed.
-                        </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_INSTALL" target="_top"><code class="filename">PACKAGE_INSTALL</code></a>:
-                        The final list of packages passed to the package manager
-                        for installation into the image.
-                        </p></li></ul></div><p>
-            </p><p>
-                With
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_ROOTFS" target="_top"><code class="filename">IMAGE_ROOTFS</code></a>
-                pointing to the location of the filesystem under construction and
-                the <code class="filename">PACKAGE_INSTALL</code> variable providing the
-                final list of packages to install, the root file system is
-                created.
-            </p><p>
-                Package installation is under control of the package manager
-                (e.g. dnf/rpm, opkg, or apt/dpkg) regardless of whether or
-                not package management is enabled for the target.
-                At the end of the process, if package management is not
-                enabled for the target, the package manager's data files
-                are deleted from the root filesystem.
-                As part of the final stage of package installation, postinstall
-                scripts that are part of the packages are run.
-                Any scripts that fail to run
-                on the build host are run on the target when the target system
-                is first booted.
-                If you are using a
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-a-read-only-root-filesystem" target="_top">read-only root filesystem</a>,
-                all the post installation scripts must succeed during the
-                package installation phase since the root filesystem is
-                read-only.
-            </p><p>
-                The final stages of the <code class="filename">do_rootfs</code> task
-                handle post processing.
-                Post processing includes creation of a manifest file and
-                optimizations.
-            </p><p>
-                The manifest file (<code class="filename">.manifest</code>) resides
-                in the same directory as the root filesystem image.
-                This file lists out, line-by-line, the installed packages.
-                The manifest file is useful for the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-testimage*" target="_top"><code class="filename">testimage</code></a>
-                class, for example, to determine whether or not to run
-                specific tests.
-                See the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_MANIFEST" target="_top"><code class="filename">IMAGE_MANIFEST</code></a>
-                variable for additional information.
-            </p><p>
-                Optimizing processes run across the image include
-                <code class="filename">mklibs</code>, <code class="filename">prelink</code>,
-                and any other post-processing commands as defined by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-ROOTFS_POSTPROCESS_COMMAND" target="_top"><code class="filename">ROOTFS_POSTPROCESS_COMMAND</code></a>
-                variable.
-                The <code class="filename">mklibs</code> process optimizes the size
-                of the libraries, while the
-                <code class="filename">prelink</code> process optimizes the dynamic
-                linking of shared libraries to reduce start up time of
-                executables.
-            </p><p>
-                After the root filesystem is built, processing begins on
-                the image through the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-image" target="_top"><code class="filename">do_image</code></a>
-                task.
-                The build system runs any pre-processing commands as defined
-                by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_PREPROCESS_COMMAND" target="_top"><code class="filename">IMAGE_PREPROCESS_COMMAND</code></a>
-                variable.
-                This variable specifies a list of functions to call before
-                the OpenEmbedded build system creates the final image output
-                files.
-            </p><p>
-                The OpenEmbedded build system dynamically creates
-                <code class="filename">do_image_*</code> tasks as needed, based
-                on the image types specified in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_FSTYPES" target="_top"><code class="filename">IMAGE_FSTYPES</code></a>
-                variable.
-                The process turns everything into an image file or a set of
-                image files and compresses the root filesystem image to reduce
-                the overall size of the image.
-                The formats used for the root filesystem depend on the
-                <code class="filename">IMAGE_FSTYPES</code> variable.
-            </p><p>
-                As an example, a dynamically created task when creating a
-                particular image <em class="replaceable"><code>type</code></em> would take the
-                following form:
-                </p><pre class="literallayout">
-     do_image_<em class="replaceable"><code>type</code></em>[depends]
-                </pre><p>
-                So, if the <em class="replaceable"><code>type</code></em> as specified by the
-                <code class="filename">IMAGE_FSTYPES</code> were
-                <code class="filename">ext4</code>, the dynamically generated task
-                would be as follows:
-                </p><pre class="literallayout">
-     do_image_ext4[depends]
-                </pre><p>
-            </p><p>
-                The final task involved in image creation is the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-image-complete" target="_top"><code class="filename">do_image_complete</code></a>
-                task.
-                This task completes the image by applying any image
-                post processing as defined through the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_POSTPROCESS_COMMAND" target="_top"><code class="filename">IMAGE_POSTPROCESS_COMMAND</code></a>
-                variable.
-                The variable specifies a list of functions to call once the
-                OpenEmbedded build system has created the final image output
-                files.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The entire image generation process is run under Pseudo.
-                Running under Pseudo ensures that the files in the root
-                filesystem have correct ownership.
-            </div></div><div class="section" title="2.8.5.6. SDK Generation"><div class="titlepage"><div><div><h4 class="title" id="sdk-generation-dev-environment">2.8.5.6. SDK Generation<span class="permalink"><a alt="Permalink" title="Permalink" href="#sdk-generation-dev-environment">¶</a></span></h4></div></div></div><p>
-                The OpenEmbedded build system uses BitBake to generate the
-                Software Development Kit (SDK) installer script for both the
-                standard and extensible SDKs:
-                <img src="figures/sdk-generation.png" align="middle" />
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                For more information on the cross-development toolchain
-                generation, see the
-                "<a class="link" href="#cross-development-toolchain-generation" title="3.2. Cross-Development Toolchain Generation">Cross-Development Toolchain Generation</a>"
-                section.
-                For information on advantages gained when building a
-                cross-development toolchain using the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-populate_sdk" target="_top"><code class="filename">do_populate_sdk</code></a>
-                task, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer" target="_top">Building an SDK Installer</a>"
-                section in the Yocto Project Application Development and the
-                Extensible Software Development Kit (SDK) manual.
-            </div><p>
-                Like image generation, the SDK script process consists of
-                several stages and depends on many variables.
-                The <code class="filename">do_populate_sdk</code> and
-                <code class="filename">do_populate_sdk_ext</code> tasks use these
-                key variables to help create the list of packages to actually
-                install.
-                For information on the variables listed in the figure, see the
-                "<a class="link" href="#sdk-dev-environment" title="2.8.7. Application Development SDK">Application Development SDK</a>"
-                section.
-            </p><p>
-                The <code class="filename">do_populate_sdk</code> task helps create
-                the standard SDK and handles two parts: a target part and a
-                host part.
-                The target part is the part built for the target hardware and
-                includes libraries and headers.
-                The host part is the part of the SDK that runs on the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDKMACHINE" target="_top"><code class="filename">SDKMACHINE</code></a>.
-            </p><p>
-                The <code class="filename">do_populate_sdk_ext</code> task helps create
-                the extensible SDK and handles host and target parts
-                differently than its counter part does for the standard SDK.
-                For the extensible SDK, the task encapsulates the build system,
-                which includes everything needed (host and target) for the SDK.
-            </p><p>
-                Regardless of the type of SDK being constructed, the
-                tasks perform some cleanup after which a cross-development
-                environment setup script and any needed configuration files
-                are created.
-                The final output is the Cross-development
-                toolchain installation script (<code class="filename">.sh</code> file),
-                which includes the environment setup script.
-            </p></div><div class="section" title="2.8.5.7. Stamp Files and the Rerunning of Tasks"><div class="titlepage"><div><div><h4 class="title" id="stamp-files-and-the-rerunning-of-tasks">2.8.5.7. Stamp Files and the Rerunning of Tasks<span class="permalink"><a alt="Permalink" title="Permalink" href="#stamp-files-and-the-rerunning-of-tasks">¶</a></span></h4></div></div></div><p>
-                For each task that completes successfully, BitBake writes a
-                stamp file into the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-STAMPS_DIR" target="_top"><code class="filename">STAMPS_DIR</code></a>
-                directory.
-                The beginning of the stamp file's filename is determined by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-STAMP" target="_top"><code class="filename">STAMP</code></a>
-                variable, and the end of the name consists of the task's name
-                and current
-                <a class="link" href="#overview-checksums" title="3.3.2. Checksums (Signatures)">input checksum</a>.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    This naming scheme assumes that
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#var-BB_SIGNATURE_HANDLER" target="_top"><code class="filename">BB_SIGNATURE_HANDLER</code></a>
-                    is "OEBasicHash", which is almost always the case in
-                    current OpenEmbedded.
-                </div><p>
-                To determine if a task needs to be rerun, BitBake checks if a
-                stamp file with a matching input checksum exists for the task.
-                If such a stamp file exists, the task's output is assumed to
-                exist and still be valid.
-                If the file does not exist, the task is rerun.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The stamp mechanism is more general than the shared
-                    state (sstate) cache mechanism described in the
-                    "<a class="link" href="#setscene-tasks-and-shared-state" title="2.8.5.8. Setscene Tasks and Shared State">Setscene Tasks and Shared State</a>"
-                    section.
-                    BitBake avoids rerunning any task that has a valid
-                    stamp file, not just tasks that can be accelerated through
-                    the sstate cache.</p><p>However, you should realize that stamp files only
-                    serve as a marker that some work has been done and that
-                    these files do not record task output.
-                    The actual task output would usually be somewhere in
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TMPDIR" target="_top"><code class="filename">TMPDIR</code></a>
-                    (e.g. in some recipe's
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a>.)
-                    What the sstate cache mechanism adds is a way to cache task
-                    output that can then be shared between build machines.
-                    </p></div><p>
-                Since <code class="filename">STAMPS_DIR</code> is usually a subdirectory
-                of <code class="filename">TMPDIR</code>, removing
-                <code class="filename">TMPDIR</code> will also remove
-                <code class="filename">STAMPS_DIR</code>, which means tasks will
-                properly be rerun to repopulate <code class="filename">TMPDIR</code>.
-            </p><p>
-                If you want some task to always be considered "out of date",
-                you can mark it with the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#variable-flags" target="_top"><code class="filename">nostamp</code></a>
-                varflag.
-                If some other task depends on such a task, then that task will
-                also always be considered out of date, which might not be what
-                you want.
-            </p><p>
-                For details on how to view information about a task's
-                signature, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#dev-viewing-task-variable-dependencies" target="_top">Viewing Task Variable Dependencies</a>"
-                section in the Yocto Project Development Tasks Manual.
-            </p></div><div class="section" title="2.8.5.8. Setscene Tasks and Shared State"><div class="titlepage"><div><div><h4 class="title" id="setscene-tasks-and-shared-state">2.8.5.8. Setscene Tasks and Shared State<span class="permalink"><a alt="Permalink" title="Permalink" href="#setscene-tasks-and-shared-state">¶</a></span></h4></div></div></div><p>
-                The description of tasks so far assumes that BitBake needs to
-                build everything and there are no prebuilt objects available.
-                BitBake does support skipping tasks if prebuilt objects are
-                available.
-                These objects are usually made available in the form of a
-                shared state (sstate) cache.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    For information on variables affecting sstate, see the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SSTATE_DIR" target="_top"><code class="filename">SSTATE_DIR</code></a>
-                    and
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SSTATE_MIRRORS" target="_top"><code class="filename">SSTATE_MIRRORS</code></a>
-                    variables.
-                </div><p>
-            </p><p>
-                The idea of a setscene task (i.e
-                <code class="filename">do_</code><em class="replaceable"><code>taskname</code></em><code class="filename">_setscene</code>)
-                is a version of the task where
-                instead of building something, BitBake can skip to the end
-                result and simply place a set of files into specific locations
-                as needed.
-                In some cases, it makes sense to have a setscene task variant
-                (e.g. generating package files in the
-                <code class="filename">do_package_write_*</code> task).
-                In other cases, it does not make sense, (e.g. a
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-patch" target="_top"><code class="filename">do_patch</code></a>
-                task or
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-unpack" target="_top"><code class="filename">do_unpack</code></a>
-                task) since the work involved would be equal to or greater than
-                the underlying task.
-            </p><p>
-                In the OpenEmbedded build system, the common tasks that have
-                setscene variants are
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>,
-                <code class="filename">do_package_write_*</code>,
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-deploy" target="_top"><code class="filename">do_deploy</code></a>,
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-packagedata" target="_top"><code class="filename">do_packagedata</code></a>,
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-populate_sysroot" target="_top"><code class="filename">do_populate_sysroot</code></a>.
-                Notice that these are most of the tasks whose output is an
-                end result.
-            </p><p>
-                The OpenEmbedded build system has knowledge of the relationship
-                between these tasks and other tasks that precede them.
-                For example, if BitBake runs
-                <code class="filename">do_populate_sysroot_setscene</code> for
-                something, there is little point in running any of the
-                <code class="filename">do_fetch</code>, <code class="filename">do_unpack</code>,
-                <code class="filename">do_patch</code>,
-                <code class="filename">do_configure</code>,
-                <code class="filename">do_compile</code>, and
-                <code class="filename">do_install</code> tasks.
-                However, if <code class="filename">do_package</code> needs to be run,
-                BitBake would need to run those other tasks.
-            </p><p>
-                It becomes more complicated if everything can come from an
-                sstate cache because some objects are simply not required at
-                all.
-                For example, you do not need a compiler or native tools, such
-                as quilt, if there is nothing to compile or patch.
-                If the <code class="filename">do_package_write_*</code> packages are
-                available from sstate, BitBake does not need the
-                <code class="filename">do_package</code> task data.
-            </p><p>
-                To handle all these complexities, BitBake runs in two phases.
-                The first is the "setscene" stage.
-                During this stage, BitBake first checks the sstate cache for
-                any targets it is planning to build.
-                BitBake does a fast check to see if the object exists rather
-                than a complete download.
-                If nothing exists, the second phase, which is the setscene
-                stage, completes and the main build proceeds.
-            </p><p>
-                If objects are found in the sstate cache, the OpenEmbedded
-                build system works backwards from the end targets specified
-                by the user.
-                For example, if an image is being built, the OpenEmbedded build
-                system first looks for the packages needed for that image and
-                the tools needed to construct an image.
-                If those are available, the compiler is not needed.
-                Thus, the compiler is not even downloaded.
-                If something was found to be unavailable, or the download or
-                setscene task fails, the OpenEmbedded build system then tries
-                to install dependencies, such as the compiler, from the cache.
-            </p><p>
-                The availability of objects in the sstate cache is handled by
-                the function specified by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#var-BB_HASHCHECK_FUNCTION" target="_top"><code class="filename">BB_HASHCHECK_FUNCTION</code></a>
-                variable and returns a list of the objects that are available.
-                The function specified by the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#var-BB_SETSCENE_DEPVALID" target="_top"><code class="filename">BB_SETSCENE_DEPVALID</code></a>
-                variable is the function that determines whether a given
-                dependency needs to be followed, and whether for any given
-                relationship the function needs to be passed.
-                The function returns a True or False value.
-            </p></div></div><div class="section" title="2.8.6. Images"><div class="titlepage"><div><div><h3 class="title" id="images-dev-environment">2.8.6. Images<span class="permalink"><a alt="Permalink" title="Permalink" href="#images-dev-environment">¶</a></span></h3></div></div></div><p>
-            The images produced by the OpenEmbedded build system
-            are compressed forms of the
-            root filesystem that are ready to boot on a target device.
-            You can see from the
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>
-            that BitBake output, in part, consists of images.
-            This section is going to look more closely at this output:
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="495"><tr style="height: 495px"><td align="center"><img src="figures/images.png" align="middle" width="495" /></td></tr></table><p>
-        </p><p>
-            For a list of example images that the Yocto Project provides,
-            see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-images" target="_top">Images</a>"
-            chapter in the Yocto Project Reference Manual.
-        </p><p>
-            Images are written out to the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>
-            inside the
-            <code class="filename">tmp/deploy/images/<em class="replaceable"><code>machine</code></em>/</code>
-            folder as shown in the figure.
-            This folder contains any files expected to be loaded on the
-            target device.
-            The
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR" target="_top"><code class="filename">DEPLOY_DIR</code></a>
-            variable points to the <code class="filename">deploy</code> directory,
-            while the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR_IMAGE" target="_top"><code class="filename">DEPLOY_DIR_IMAGE</code></a>
-            variable points to the appropriate directory containing images for
-            the current configuration.
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="filename"><em class="replaceable"><code>kernel-image</code></em></code>:
-                    A kernel binary file.
-                    The
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-KERNEL_IMAGETYPE" target="_top"><code class="filename">KERNEL_IMAGETYPE</code></a>
-                    variable setting determines the naming scheme for the
-                    kernel image file.
-                    Depending on that variable, the file could begin with
-                    a variety of naming strings.
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple image files for the
-                    machine.</p></li><li class="listitem"><p><code class="filename"><em class="replaceable"><code>root-filesystem-image</code></em></code>:
-                    Root filesystems for the target device (e.g.
-                    <code class="filename">*.ext3</code> or <code class="filename">*.bz2</code>
-                    files).
-                    The
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-IMAGE_FSTYPES" target="_top"><code class="filename">IMAGE_FSTYPES</code></a>
-                    variable setting determines the root filesystem image
-                    type.
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple root filesystems for the
-                    machine.</p></li><li class="listitem"><p><code class="filename"><em class="replaceable"><code>kernel-modules</code></em></code>:
-                    Tarballs that contain all the modules built for the kernel.
-                    Kernel module tarballs exist for legacy purposes and
-                    can be suppressed by setting the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-MODULE_TARBALL_DEPLOY" target="_top"><code class="filename">MODULE_TARBALL_DEPLOY</code></a>
-                    variable to "0".
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple kernel module tarballs
-                    for the machine.</p></li><li class="listitem"><p><code class="filename"><em class="replaceable"><code>bootloaders</code></em></code>:
-                    Bootloaders supporting the image, if applicable to the
-                    target machine.
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    directory can contain multiple bootloaders for the
-                    machine.</p></li><li class="listitem"><p><code class="filename"><em class="replaceable"><code>symlinks</code></em></code>:
-                    The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code>
-                    folder contains
-                    a symbolic link that points to the most recently built file
-                    for each machine.
-                    These links might be useful for external scripts that
-                    need to obtain the latest version of each file.
-                    </p></li></ul></div><p>
-        </p></div><div class="section" title="2.8.7. Application Development SDK"><div class="titlepage"><div><div><h3 class="title" id="sdk-dev-environment">2.8.7. Application Development SDK<span class="permalink"><a alt="Permalink" title="Permalink" href="#sdk-dev-environment">¶</a></span></h3></div></div></div><p>
-            In the
-            <a class="link" href="#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>,
-            the output labeled "Application Development SDK" represents an
-            SDK.
-            The SDK generation process differs depending on whether you build
-            a standard SDK
-            (e.g. <code class="filename">bitbake -c populate_sdk</code> <em class="replaceable"><code>imagename</code></em>)
-            or an extensible SDK
-            (e.g. <code class="filename">bitbake -c populate_sdk_ext</code> <em class="replaceable"><code>imagename</code></em>).
-            This section is going to take a closer look at this output:
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="810"><tr style="height: 653px"><td align="center"><img src="figures/sdk.png" align="middle" width="810" /></td></tr></table><p>
-        </p><p>
-            The specific form of this output is a self-extracting
-            SDK installer (<code class="filename">*.sh</code>) that, when run,
-            installs the SDK, which consists of a cross-development
-            toolchain, a set of libraries and headers, and an SDK
-            environment setup script.
-            Running this installer essentially sets up your
-            cross-development environment.
-            You can think of the cross-toolchain as the "host"
-            part because it runs on the SDK machine.
-            You can think of the libraries and headers as the "target"
-            part because they are built for the target hardware.
-            The environment setup script is added so that you can initialize
-            the environment before using the tools.
-        </p><div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Notes</h3><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    The Yocto Project supports several methods by which you can
-                    set up this cross-development environment.
-                    These methods include downloading pre-built SDK installers
-                    or building and installing your own SDK installer.
-                    </p></li><li class="listitem"><p>
-                    For background information on cross-development toolchains
-                    in the Yocto Project development environment, see the
-                    "<a class="link" href="#cross-development-toolchain-generation" title="3.2. Cross-Development Toolchain Generation">Cross-Development Toolchain Generation</a>"
-                    section.
-                    </p></li><li class="listitem"><p>
-                    For information on setting up a cross-development
-                    environment, see the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>
-                    manual.
-                    </p></li></ul></div></div><p>
-            Once built, the SDK installers are written out to the
-            <code class="filename">deploy/sdk</code> folder inside the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>
-            as shown in the figure at the beginning of this section.
-            Depending on the type of SDK, several variables exist that help
-            configure these files.
-            The following list shows the variables associated with a standard
-            SDK:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR" target="_top"><code class="filename">DEPLOY_DIR</code></a>:
-                    Points to the <code class="filename">deploy</code>
-                    directory.</p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDKMACHINE" target="_top"><code class="filename">SDKMACHINE</code></a>:
-                    Specifies the architecture of the machine
-                    on which the cross-development tools are run to
-                    create packages for the target hardware.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDKIMAGE_FEATURES" target="_top"><code class="filename">SDKIMAGE_FEATURES</code></a>:
-                    Lists the features to include in the "target" part
-                    of the SDK.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TOOLCHAIN_HOST_TASK" target="_top"><code class="filename">TOOLCHAIN_HOST_TASK</code></a>:
-                    Lists packages that make up the host
-                    part of the SDK (i.e. the part that runs on
-                    the <code class="filename">SDKMACHINE</code>).
-                    When you use
-                    <code class="filename">bitbake -c populate_sdk <em class="replaceable"><code>imagename</code></em></code>
-                    to create the SDK, a set of default packages
-                    apply.
-                    This variable allows you to add more packages.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TOOLCHAIN_TARGET_TASK" target="_top"><code class="filename">TOOLCHAIN_TARGET_TASK</code></a>:
-                    Lists packages that make up the target part
-                    of the SDK (i.e. the part built for the
-                    target hardware).
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDKPATH" target="_top"><code class="filename">SDKPATH</code></a>:
-                    Defines the default SDK installation path offered by the
-                    installation script.
-                    </p></li></ul></div><p>
-            This next list, shows the variables associated with an extensible
-            SDK:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPLOY_DIR" target="_top"><code class="filename">DEPLOY_DIR</code></a>:
-                    Points to the <code class="filename">deploy</code> directory.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_EXT_TYPE" target="_top"><code class="filename">SDK_EXT_TYPE</code></a>:
-                    Controls whether or not shared state artifacts are copied
-                    into the extensible SDK.
-                    By default, all required shared state artifacts are copied
-                    into the SDK.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_INCLUDE_PKGDATA" target="_top"><code class="filename">SDK_INCLUDE_PKGDATA</code></a>:
-                    Specifies whether or not packagedata will be included in
-                    the extensible SDK for all recipes in the "world" target.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_INCLUDE_TOOLCHAIN" target="_top"><code class="filename">SDK_INCLUDE_TOOLCHAIN</code></a>:
-                    Specifies whether or not the toolchain will be included
-                    when building the extensible SDK.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_LOCAL_CONF_WHITELIST" target="_top"><code class="filename">SDK_LOCAL_CONF_WHITELIST</code></a>:
-                    A list of variables allowed through from the build system
-                    configuration into the extensible SDK configuration.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_LOCAL_CONF_BLACKLIST" target="_top"><code class="filename">SDK_LOCAL_CONF_BLACKLIST</code></a>:
-                    A list of variables not allowed through from the build
-                    system configuration into the extensible SDK configuration.
-                    </p></li><li class="listitem"><p><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_INHERIT_BLACKLIST" target="_top"><code class="filename">SDK_INHERIT_BLACKLIST</code></a>:
-                    A list of classes to remove from the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-INHERIT" target="_top"><code class="filename">INHERIT</code></a>
-                    value globally within the extensible SDK configuration.
-                    </p></li></ul></div><p>
-        </p></div></div></div>
-
-    <div class="chapter" title="Chapter 3. Yocto Project Concepts" id="overview-concepts"><div class="titlepage"><div><div><h2 class="title">Chapter 3. Yocto Project Concepts<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-concepts">¶</a></span></h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#yocto-project-components">3.1. Yocto Project Components</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-components-bitbake">3.1.1. BitBake</a></span></dt><dt><span class="section"><a href="#usingpoky-components-metadata">3.1.2. Metadata (Recipes)</a></span></dt><dt><span class="section"><a href="#metadata-virtual-providers">3.1.3. Metadata (Virtual Providers)</a></span></dt><dt><span class="section"><a href="#usingpoky-components-classes">3.1.4. Classes</a></span></dt><dt><span class="section"><a href="#usingpoky-components-configuration">3.1.5. Configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#cross-development-toolchain-generation">3.2. Cross-Development Toolchain Generation</a></span></dt><dt><span class="section"><a href="#shared-state-cache">3.3. Shared State Cache</a></span></dt><dd><dl><dt><span class="section"><a href="#overall-architecture">3.3.1. Overall Architecture</a></span></dt><dt><span class="section"><a href="#overview-checksums">3.3.2. Checksums (Signatures)</a></span></dt><dt><span class="section"><a href="#shared-state">3.3.3. Shared State</a></span></dt><dt><span class="section"><a href="#tips-and-tricks">3.3.4. Tips and Tricks</a></span></dt></dl></dd><dt><span class="section"><a href="#automatically-added-runtime-dependencies">3.4. Automatically Added Runtime Dependencies</a></span></dt><dt><span class="section"><a href="#fakeroot-and-pseudo">3.5. Fakeroot and Pseudo</a></span></dt><dt><span class="section"><a href="#wayland">3.6. Wayland</a></span></dt><dd><dl><dt><span class="section"><a href="#wayland-support">3.6.1. Support</a></span></dt><dt><span class="section"><a href="#enabling-wayland-in-an-image">3.6.2. Enabling Wayland in an Image</a></span></dt><dt><span class="section"><a href="#running-weston">3.6.3. Running Weston</a></span></dt></dl></dd><dt><span class="section"><a href="#overview-licenses">3.7. Licenses</a></span></dt><dd><dl><dt><span class="section"><a href="#usingpoky-configuring-LIC_FILES_CHKSUM">3.7.1. Tracking License Changes</a></span></dt><dt><span class="section"><a href="#enabling-commercially-licensed-recipes">3.7.2. Enabling Commercially Licensed Recipes</a></span></dt></dl></dd><dt><span class="section"><a href="#x32">3.8. x32 psABI</a></span></dt></dl></div><p>
-        This chapter describes concepts for various areas of the Yocto Project.
-        Currently, topics include Yocto Project components, cross-development
-        generation, shared state (sstate) cache, runtime dependencies,
-        Pseudo and Fakeroot, x32 psABI, Wayland support, and Licenses.
-    </p><div class="section" title="3.1. Yocto Project Components"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="yocto-project-components">3.1. Yocto Project Components<span class="permalink"><a alt="Permalink" title="Permalink" href="#yocto-project-components">¶</a></span></h2></div></div></div><p>
-            The
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#bitbake-term" target="_top">BitBake</a>
-            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.
-        </p><p>
-            BitBake handles the parsing and execution of the data files.
-            The data itself is of various types:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <span class="emphasis"><em>Recipes:</em></span>
-                    Provides details about particular pieces of software.
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Class Data:</em></span>
-                    Abstracts common build information (e.g. how to build a
-                    Linux kernel).
-                    </p></li><li class="listitem"><p>
-                    <span class="emphasis"><em>Configuration Data:</em></span>
-                    Defines machine-specific settings, policy decisions, and
-                    so forth.
-                    Configuration data acts as the glue to bind everything
-                    together.
-                    </p></li></ul></div><p>
-        </p><p>
-            BitBake knows how to combine multiple data sources together and
-            refers to each data source as a layer.
-            For information on layers, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_top">Understanding and Creating Layers</a>"
-            section of the Yocto Project Development Tasks Manual.
-        </p><p>
-            Following are some brief details on these core components.
-            For additional information on how these components interact during
-            a build, see the
-            "<a class="link" href="#development-concepts" title="2.8. Development Concepts">Development Concepts</a>"
-            section.
-        </p><div class="section" title="3.1.1. BitBake"><div class="titlepage"><div><div><h3 class="title" id="usingpoky-components-bitbake">3.1.1. BitBake<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-components-bitbake">¶</a></span></h3></div></div></div><p>
-                BitBake is the tool at the heart of the OpenEmbedded build
-                system and is responsible for parsing the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#metadata" target="_top">Metadata</a>,
-                generating a list of tasks from it, and then executing those
-                tasks.
-            </p><p>
-                This section briefly introduces BitBake.
-                If you want more information on BitBake, see the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual" target="_top">BitBake User Manual</a>.
-            </p><p>
-                To see a list of the options BitBake supports, use either of
-                the following commands:
-                </p><pre class="literallayout">
-     $ bitbake -h
-     $ bitbake --help
-                </pre><p>
-            </p><p>
-                The most common usage for BitBake is
-                <code class="filename">bitbake <em class="replaceable"><code>packagename</code></em></code>,
-                where <code class="filename">packagename</code> 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
-                <code class="filename">foo_1.3.0-r0.bb</code>).
-                So, to process the
-                <code class="filename">matchbox-desktop_1.2.3.bb</code> recipe file, you
-                might type the following:
-                </p><pre class="literallayout">
-     $ bitbake matchbox-desktop
-                </pre><p>
-                Several different versions of
-                <code class="filename">matchbox-desktop</code> 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
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#bb-bitbake-preferences" target="_top">Preferences</a>"
-                section of the BitBake User Manual.
-            </p><p>
-                BitBake also tries to execute any dependent tasks first.
-                So for example, before building
-                <code class="filename">matchbox-desktop</code>, BitBake would build a
-                cross compiler and <code class="filename">glibc</code> if they had not
-                already been built.
-            </p><p>
-                A useful BitBake option to consider is the
-                <code class="filename">-k</code> or <code class="filename">--continue</code>
-                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.
-            </p></div><div class="section" title="3.1.2. Metadata (Recipes)"><div class="titlepage"><div><div><h3 class="title" id="usingpoky-components-metadata">3.1.2. Metadata (Recipes)<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-components-metadata">¶</a></span></h3></div></div></div><p>
-                Files that have the <code class="filename">.bb</code> 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.
-            </p><p>
-                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.
-                <code class="filename">.ipk</code> or <code class="filename">.deb</code> files),
-                this document avoids using the term "package" when referring
-                to recipes.
-            </p></div><div class="section" title="3.1.3. Metadata (Virtual Providers)"><div class="titlepage"><div><div><h3 class="title" id="metadata-virtual-providers">3.1.3. Metadata (Virtual Providers)<span class="permalink"><a alt="Permalink" title="Permalink" href="#metadata-virtual-providers">¶</a></span></h3></div></div></div><p>
-                Prior to the build, if you know that several different recipes
-                provide the same functionality, you can use a virtual provider
-                (i.e. <code class="filename">virtual/*</code>) as a placeholder for the
-                actual provider.
-                The actual provider would be determined at build time.
-                In this case, you should add <code class="filename">virtual/*</code>
-                to
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPENDS" target="_top"><code class="filename">DEPENDS</code></a>,
-                rather than listing the specified provider.
-                You would select the actual provider by setting the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PREFERRED_PROVIDER" target="_top"><code class="filename">PREFERRED_PROVIDER</code></a>
-                variable (i.e.
-                <code class="filename">PREFERRED_PROVIDER_virtual/*</code>)
-                in the build's configuration file (e.g.
-                <code class="filename">poky/build/conf/local.conf</code>).
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    Any recipe that PROVIDES a <code class="filename">virtual/*</code>
-                    item that is ultimately not selected through
-                    <code class="filename">PREFERRED_PROVIDER</code> 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.
-                </div><p>
-            </p><p>
-                The following lists specific examples of virtual providers:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                        <code class="filename">virtual/mesa</code>:
-                        Provides <code class="filename">gbm.pc</code>.
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">virtual/egl</code>:
-                        Provides <code class="filename">egl.pc</code> and possibly
-                        <code class="filename">wayland-egl.pc</code>.
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">virtual/libgl</code>:
-                        Provides <code class="filename">gl.pc</code> (i.e. libGL).
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">virtual/libgles1</code>:
-                        Provides <code class="filename">glesv1_cm.pc</code>
-                        (i.e. libGLESv1_CM).
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">virtual/libgles2</code>:
-                        Provides <code class="filename">glesv2.pc</code>
-                        (i.e. libGLESv2).
-                        </p></li></ul></div><p>
-            </p></div><div class="section" title="3.1.4. Classes"><div class="titlepage"><div><div><h3 class="title" id="usingpoky-components-classes">3.1.4. Classes<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-components-classes">¶</a></span></h3></div></div></div><p>
-                Class files (<code class="filename">.bbclass</code>) contain information
-                that is useful to share between
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#metadata" target="_top">Metadata</a>
-                files.
-                An example is the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-autotools" target="_top"><code class="filename">autotools</code></a>
-                class, which contains common settings for any application that
-                Autotools uses.
-                The
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes" target="_top">Classes</a>"
-                chapter in the Yocto Project Reference Manual provides
-                details about classes and how to use them.
-            </p></div><div class="section" title="3.1.5. Configuration"><div class="titlepage"><div><div><h3 class="title" id="usingpoky-components-configuration">3.1.5. Configuration<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-components-configuration">¶</a></span></h3></div></div></div><p>
-                The configuration files (<code class="filename">.conf</code>) 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
-                <code class="filename">local.conf</code>, which is found in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>.
-            </p></div></div><div class="section" title="3.2. Cross-Development Toolchain Generation"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="cross-development-toolchain-generation">3.2. Cross-Development Toolchain Generation<span class="permalink"><a alt="Permalink" title="Permalink" href="#cross-development-toolchain-generation">¶</a></span></h2></div></div></div><p>
-            The Yocto Project does most of the work for you when it comes to
-            creating
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#cross-development-toolchain" target="_top">cross-development toolchains</a>.
-            This section provides some technical background on how
-            cross-development toolchains are created and used.
-            For more information on toolchains, you can also see the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>
-            manual.
-        </p><p>
-            In the Yocto Project development environment, cross-development
-            toolchains are used to build the image and applications that run
-            on the target hardware.
-            With just a few commands, the OpenEmbedded build system creates
-            these necessary toolchains for you.
-        </p><p>
-            The following figure shows a high-level build environment regarding
-            toolchain construction and use.
-        </p><p>
-            </p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 540px"><td align="center"><img src="figures/cross-development-toolchains.png" align="middle" width="720" /></td></tr></table><p>
-        </p><p>
-            Most of the work occurs on the Build Host.
-            This is the machine used to build images and generally work within the
-            the Yocto Project environment.
-            When you run BitBake to create an image, the OpenEmbedded build system
-            uses the host <code class="filename">gcc</code> compiler to bootstrap a
-            cross-compiler named <code class="filename">gcc-cross</code>.
-            The <code class="filename">gcc-cross</code> compiler is what BitBake uses to
-            compile source files when creating the target image.
-            You can think of <code class="filename">gcc-cross</code> simply as an
-            automatically generated cross-compiler that is used internally within
-            BitBake only.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The extensible SDK does not use
-                <code class="filename">gcc-cross-canadian</code> since this SDK
-                ships a copy of the OpenEmbedded build system and the sysroot
-                within it contains <code class="filename">gcc-cross</code>.
-            </div><p>
-        </p><p>
-            The chain of events that occurs when <code class="filename">gcc-cross</code> is
-            bootstrapped is as follows:
-            </p><pre class="literallayout">
-     gcc -&gt; binutils-cross -&gt; gcc-cross-initial -&gt; linux-libc-headers -&gt; glibc-initial -&gt; glibc -&gt; gcc-cross -&gt; gcc-runtime
-            </pre><p>
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <code class="filename">gcc</code>:
-                    The build host's GNU Compiler Collection (GCC).
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">binutils-cross</code>:
-                    The bare minimum binary utilities needed in order to run
-                    the <code class="filename">gcc-cross-initial</code> phase of the
-                    bootstrap operation.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">gcc-cross-initial</code>:
-                    An early stage of the bootstrap process for creating
-                    the cross-compiler.
-                    This stage builds enough of the <code class="filename">gcc-cross</code>,
-                    the C library, and other pieces needed to finish building the
-                    final cross-compiler in later stages.
-                    This tool is a "native" package (i.e. it is designed to run on
-                    the build host).
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">linux-libc-headers</code>:
-                    Headers needed for the cross-compiler.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">glibc-initial</code>:
-                    An initial version of the Embedded GLIBC needed to bootstrap
-                    <code class="filename">glibc</code>.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">gcc-cross</code>:
-                    The final stage of the bootstrap process for the
-                    cross-compiler.
-                    This stage results in the actual cross-compiler that
-                    BitBake uses when it builds an image for a targeted
-                    device.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        If you are replacing this cross compiler toolchain
-                        with a custom version, you must replace
-                        <code class="filename">gcc-cross</code>.
-                    </div><p>
-                    This tool is also a "native" package (i.e. it is
-                    designed to run on the build host).
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">gcc-runtime</code>:
-                    Runtime libraries resulting from the toolchain bootstrapping
-                    process.
-                    This tool produces a binary that consists of the
-                    runtime libraries need for the targeted device.
-                    </p></li></ul></div><p>
-        </p><p>
-            You can use the OpenEmbedded build system to build an installer for
-            the relocatable SDK used to develop applications.
-            When you run the installer, it installs the toolchain, which contains
-            the development tools (e.g., the
-            <code class="filename">gcc-cross-canadian</code>),
-            <code class="filename">binutils-cross-canadian</code>, and other
-            <code class="filename">nativesdk-*</code> tools,
-            which are tools native to the SDK (i.e. native to
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDK_ARCH" target="_top"><code class="filename">SDK_ARCH</code></a>),
-            you need to cross-compile and test your software.
-            The figure shows the commands you use to easily build out this
-            toolchain.
-            This cross-development toolchain is built to execute on the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDKMACHINE" target="_top"><code class="filename">SDKMACHINE</code></a>,
-            which might or might not be the same
-            machine as the Build Host.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                If your target architecture is supported by the Yocto Project,
-                you can take advantage of pre-built images that ship with the
-                Yocto Project and already contain cross-development toolchain
-                installers.
-            </div><p>
-        </p><p>
-            Here is the bootstrap process for the relocatable toolchain:
-            </p><pre class="literallayout">
-     gcc -&gt; binutils-crosssdk -&gt; gcc-crosssdk-initial -&gt; linux-libc-headers -&gt;
-        glibc-initial -&gt; nativesdk-glibc -&gt; gcc-crosssdk -&gt; gcc-cross-canadian
-            </pre><p>
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <code class="filename">gcc</code>:
-                    The build host's GNU Compiler Collection (GCC).
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">binutils-crosssdk</code>:
-                    The bare minimum binary utilities needed in order to run
-                    the <code class="filename">gcc-crosssdk-initial</code> phase of the
-                    bootstrap operation.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">gcc-crosssdk-initial</code>:
-                    An early stage of the bootstrap process for creating
-                    the cross-compiler.
-                    This stage builds enough of the
-                    <code class="filename">gcc-crosssdk</code> and supporting pieces so that
-                    the final stage of the bootstrap process can produce the
-                    finished cross-compiler.
-                    This tool is a "native" binary that runs on the build host.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">linux-libc-headers</code>:
-                    Headers needed for the cross-compiler.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">glibc-initial</code>:
-                    An initial version of the Embedded GLIBC needed to bootstrap
-                    <code class="filename">nativesdk-glibc</code>.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">nativesdk-glibc</code>:
-                    The Embedded GLIBC needed to bootstrap the
-                    <code class="filename">gcc-crosssdk</code>.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">gcc-crosssdk</code>:
-                    The final stage of the bootstrap process for the
-                    relocatable cross-compiler.
-                    The <code class="filename">gcc-crosssdk</code> is a transitory compiler
-                    and never leaves the build host.
-                    Its purpose is to help in the bootstrap process to create the
-                    eventual relocatable <code class="filename">gcc-cross-canadian</code>
-                    compiler, which is relocatable.
-                    This tool is also a "native" package (i.e. it is
-                    designed to run on the build host).
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">gcc-cross-canadian</code>:
-                    The final relocatable cross-compiler.
-                    When run on the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SDKMACHINE" target="_top"><code class="filename">SDKMACHINE</code></a>,
-                    this tool
-                    produces executable code that runs on the target device.
-                    Only one cross-canadian compiler is produced per architecture
-                    since they can be targeted at different processor optimizations
-                    using configurations passed to the compiler through the
-                    compile commands.
-                    This circumvents the need for multiple compilers and thus
-                    reduces the size of the toolchains.
-                    </p></li></ul></div><p>
-        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-            For information on advantages gained when building a
-            cross-development toolchain installer, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer" target="_top">Building an SDK Installer</a>"
-            section in the Yocto Project Application Development and the
-            Extensible Software Development Kit (eSDK) manual.
-        </div></div><div class="section" title="3.3. Shared State Cache"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="shared-state-cache">3.3. Shared State Cache<span class="permalink"><a alt="Permalink" title="Permalink" href="#shared-state-cache">¶</a></span></h2></div></div></div><p>
-            By design, the OpenEmbedded build system builds everything from
-            scratch unless BitBake can determine that parts do not need to be
-            rebuilt.
-            Fundamentally, building from scratch is attractive as it means all
-            parts are built fresh and there is no possibility of stale data
-            causing problems.
-            When developers hit problems, they typically default back to
-            building from scratch so they know the state of things from the
-            start.
-        </p><p>
-            Building an image from scratch is both an advantage and a
-            disadvantage to the process.
-            As mentioned in the previous paragraph, building from scratch
-            ensures that everything is current and starts from a known state.
-            However, building from scratch also takes much longer as it
-            generally means rebuilding things that do not necessarily need
-            to be rebuilt.
-        </p><p>
-            The Yocto Project implements shared state code that supports
-            incremental builds.
-            The implementation of the shared state code answers the following
-            questions that were fundamental roadblocks within the OpenEmbedded
-            incremental build support system:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    What pieces of the system have changed and what pieces have
-                    not changed?
-                    </p></li><li class="listitem"><p>
-                    How are changed pieces of software removed and replaced?
-                    </p></li><li class="listitem"><p>
-                    How are pre-built components that do not need to be rebuilt
-                    from scratch used when they are available?
-                    </p></li></ul></div><p>
-        </p><p>
-            For the first question, the build system detects changes in the
-            "inputs" to a given task by creating a checksum (or signature) of
-            the task's inputs.
-            If the checksum changes, the system assumes the inputs have changed
-            and the task needs to be rerun.
-            For the second question, the shared state (sstate) code tracks
-            which tasks add which output to the build process.
-            This means the output from a given task can be removed, upgraded
-            or otherwise manipulated.
-            The third question is partly addressed by the solution for the
-            second question assuming the build system can fetch the sstate
-            objects from remote locations and install them if they are deemed
-            to be valid.
-            </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                The OpenEmbedded build system does not maintain
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PR" target="_top"><code class="filename">PR</code></a>
-                information as part of the shared state packages.
-                Consequently, considerations exist that affect maintaining
-                shared state feeds.
-                For information on how the OpenEmbedded build system
-                works with packages and can track incrementing
-                <code class="filename">PR</code> information, see the
-                "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#automatically-incrementing-a-binary-package-revision-number" target="_top">Automatically Incrementing a Binary Package Revision Number</a>"
-                section in the Yocto Project Development Tasks Manual.
-            </div><p>
-        </p><p>
-            The rest of this section goes into detail about the overall
-            incremental build architecture, the checksums (signatures), shared
-            state, and some tips and tricks.
-        </p><div class="section" title="3.3.1. Overall Architecture"><div class="titlepage"><div><div><h3 class="title" id="overall-architecture">3.3.1. Overall Architecture<span class="permalink"><a alt="Permalink" title="Permalink" href="#overall-architecture">¶</a></span></h3></div></div></div><p>
-                When determining what parts of the system need to be built,
-                BitBake works on a per-task basis rather than a per-recipe
-                basis.
-                You might wonder why using a per-task basis is preferred over
-                a per-recipe basis.
-                To help explain, consider having the IPK packaging backend
-                enabled and then switching to DEB.
-                In this case, the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-install" target="_top"><code class="filename">do_install</code></a>
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>
-                task outputs are still valid.
-                However, with a per-recipe approach, the build would not
-                include the <code class="filename">.deb</code> files.
-                Consequently, you would have to invalidate the whole build and
-                rerun it.
-                Rerunning everything is not the best solution.
-                Also, in this case, the core must be "taught" much about
-                specific tasks.
-                This methodology does not scale well and does not allow users
-                to easily add new tasks in layers or as external recipes
-                without touching the packaged-staging core.
-            </p></div><div class="section" title="3.3.2. Checksums (Signatures)"><div class="titlepage"><div><div><h3 class="title" id="overview-checksums">3.3.2. Checksums (Signatures)<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-checksums">¶</a></span></h3></div></div></div><p>
-                The shared state code uses a checksum, which is a unique
-                signature of a task's inputs, to determine if a task needs to
-                be run again.
-                Because it is a change in a task's inputs that triggers a
-                rerun, the process needs to detect all the inputs to a given
-                task.
-                For shell tasks, this turns out to be fairly easy because
-                the build process generates a "run" shell script for each task
-                and it is possible to create a checksum that gives you a good
-                idea of when the task's data changes.
-            </p><p>
-                To complicate the problem, there are things that should not be
-                included in the checksum.
-                First, there is the actual specific build path of a given
-                task - the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a>.
-                It does not matter if the work directory changes because it
-                should not affect the output for target packages.
-                Also, the build process has the objective of making native
-                or cross packages relocatable.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    Both native and cross packages run on the build host.
-                    However, cross packages generate output for the target
-                    architecture.
-                </div><p>
-                The checksum therefore needs to exclude
-                <code class="filename">WORKDIR</code>.
-                The simplistic approach for excluding the work directory is to
-                set <code class="filename">WORKDIR</code> to some fixed value and
-                create the checksum for the "run" script.
-            </p><p>
-                Another problem results from the "run" scripts containing
-                functions that might or might not get called.
-                The incremental build solution contains code that figures out
-                dependencies between shell functions.
-                This code is used to prune the "run" scripts down to the
-                minimum set, thereby alleviating this problem and making the
-                "run" scripts much more readable as a bonus.
-            </p><p>
-                So far we have solutions for shell scripts.
-                What about Python tasks?
-                The same approach applies even though these tasks are more
-                difficult.
-                The process needs to figure out what variables a Python
-                function accesses and what functions it calls.
-                Again, the incremental build solution contains code that first
-                figures out the variable and function dependencies, and then
-                creates a checksum for the data used as the input to the task.
-            </p><p>
-                Like the <code class="filename">WORKDIR</code> case, situations exist
-                where dependencies should be ignored.
-                For these cases, you can instruct the build process to
-                ignore a dependency by using a line like the following:
-                </p><pre class="literallayout">
-     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
-                </pre><p>
-                This example ensures that the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PACKAGE_ARCHS" target="_top"><code class="filename">PACKAGE_ARCHS</code></a>
-                variable does not depend on the value of
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-MACHINE" target="_top"><code class="filename">MACHINE</code></a>,
-                even if it does reference it.
-            </p><p>
-                Equally, there are cases where we need to add dependencies
-                BitBake is not able to find.
-                You can accomplish this by using a line like the following:
-                </p><pre class="literallayout">
-      PACKAGE_ARCHS[vardeps] = "MACHINE"
-                </pre><p>
-                This example explicitly adds the <code class="filename">MACHINE</code>
-                variable as a dependency for
-                <code class="filename">PACKAGE_ARCHS</code>.
-            </p><p>
-                Consider a case with in-line Python, for example, where
-                BitBake is not able to figure out dependencies.
-                When running in debug mode (i.e. using
-                <code class="filename">-DDD</code>), BitBake produces output when it
-                discovers something for which it cannot figure out dependencies.
-                The Yocto Project team has currently not managed to cover
-                those dependencies in detail and is aware of the need to fix
-                this situation.
-            </p><p>
-                Thus far, this section has limited discussion to the direct
-                inputs into a task.
-                Information based on direct inputs is referred to as the
-                "basehash" in the code.
-                However, there is still the question of a task's indirect
-                inputs - the things that were already built and present in the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#build-directory" target="_top">Build Directory</a>.
-                The checksum (or signature) for a particular task needs to add
-                the hashes of all the tasks on which the particular task
-                depends.
-                Choosing which dependencies to add is a policy decision.
-                However, the effect is to generate a master checksum that
-                combines the basehash and the hashes of the task's
-                dependencies.
-            </p><p>
-                At the code level, there are a variety of ways both the
-                basehash and the dependent task hashes can be influenced.
-                Within the BitBake configuration file, we can give BitBake
-                some extra information to help it construct the basehash.
-                The following statement effectively results in a list of
-                global variable dependency excludes - variables never
-                included in any checksum:
-                </p><pre class="literallayout">
-     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
-         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
-         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
-         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
-         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
-                </pre><p>
-                The previous example excludes
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a>
-                since that variable is actually constructed as a path within
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-TMPDIR" target="_top"><code class="filename">TMPDIR</code></a>,
-                which is on the whitelist.
-            </p><p>
-                The rules for deciding which hashes of dependent tasks to
-                include through dependency chains are more complex and are
-                generally accomplished with a Python function.
-                The code in <code class="filename">meta/lib/oe/sstatesig.py</code> shows
-                two examples of this and also illustrates how you can insert
-                your own policy into the system if so desired.
-                This file defines the two basic signature generators
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#oe-core" target="_top">OE-Core</a>
-                uses:  "OEBasic" and "OEBasicHash".
-                By default, there is a dummy "noop" signature handler enabled
-                in BitBake.
-                This means that behavior is unchanged from previous versions.
-                OE-Core uses the "OEBasicHash" signature handler by default
-                through this setting in the <code class="filename">bitbake.conf</code>
-                file:
-                </p><pre class="literallayout">
-     BB_SIGNATURE_HANDLER ?= "OEBasicHash"
-                </pre><p>
-                The "OEBasicHash" <code class="filename">BB_SIGNATURE_HANDLER</code>
-                is the same as the "OEBasic" version but adds the task hash to
-                the stamp files.
-                This results in any
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#metadata" target="_top">Metadata</a>
-                change that changes the task hash, automatically
-                causing the task to be run again.
-                This removes the need to bump
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PR" target="_top"><code class="filename">PR</code></a>
-                values, and changes to Metadata automatically ripple across
-                the build.
-            </p><p>
-                It is also worth noting that the end result of these
-                signature generators is to make some dependency and hash
-                information available to the build.
-                This information includes:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                        <code class="filename">BB_BASEHASH_task-</code><em class="replaceable"><code>taskname</code></em>:
-                        The base hashes for each task in the recipe.
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">BB_BASEHASH_</code><em class="replaceable"><code>filename</code></em><code class="filename">:</code><em class="replaceable"><code>taskname</code></em>:
-                        The base hashes for each dependent task.
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">BBHASHDEPS_</code><em class="replaceable"><code>filename</code></em><code class="filename">:</code><em class="replaceable"><code>taskname</code></em>:
-                        The task dependencies for each task.
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">BB_TASKHASH</code>:
-                        The hash of the currently running task.
-                        </p></li></ul></div><p>
-            </p></div><div class="section" title="3.3.3. Shared State"><div class="titlepage"><div><div><h3 class="title" id="shared-state">3.3.3. Shared State<span class="permalink"><a alt="Permalink" title="Permalink" href="#shared-state">¶</a></span></h3></div></div></div><p>
-                Checksums and dependencies, as discussed in the previous
-                section, solve half the problem of supporting a shared state.
-                The other part of the problem is being able to use checksum
-                information during the build and being able to reuse or rebuild
-                specific components.
-            </p><p>
-                The
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-sstate" target="_top"><code class="filename">sstate</code></a>
-                class is a relatively generic implementation of how to
-                "capture" a snapshot of a given task.
-                The idea is that the build process does not care about the
-                source of a task's output.
-                Output could be freshly built or it could be downloaded and
-                unpacked from somewhere - the build process does not need to
-                worry about its origin.
-            </p><p>
-                There are two types of output, one is just about creating a
-                directory in
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a>.
-                A good example is the output of either
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-install" target="_top"><code class="filename">do_install</code></a>
-                or
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>.
-                The other type of output occurs when a set of data is merged
-                into a shared directory tree such as the sysroot.
-            </p><p>
-                The Yocto Project team has tried to keep the details of the
-                implementation hidden in <code class="filename">sstate</code> class.
-                From a user's perspective, adding shared state wrapping to a task
-                is as simple as this
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-deploy" target="_top"><code class="filename">do_deploy</code></a>
-                example taken from the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-deploy" target="_top"><code class="filename">deploy</code></a>
-                class:
-                </p><pre class="literallayout">
-     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
-     SSTATETASKS += "do_deploy"
-     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
-     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
-
-     python do_deploy_setscene () {
-         sstate_setscene(d)
-     }
-     addtask do_deploy_setscene
-     do_deploy[dirs] = "${DEPLOYDIR} ${B}"
-                </pre><p>
-                The following list explains the previous example:
-                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                        Adding "do_deploy" to <code class="filename">SSTATETASKS</code>
-                        adds some required sstate-related processing, which is
-                        implemented in the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-sstate" target="_top"><code class="filename">sstate</code></a>
-                        class, to before and after the
-                        <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-deploy" target="_top"><code class="filename">do_deploy</code></a>
-                        task.
-                        </p></li><li class="listitem"><p>
-                        The
-                        <code class="filename">do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"</code>
-                        declares that <code class="filename">do_deploy</code> places its
-                        output in <code class="filename">${DEPLOYDIR}</code> when run
-                        normally (i.e. when not using the sstate cache).
-                        This output becomes the input to the shared state cache.
-                        </p></li><li class="listitem"><p>
-                        The
-                        <code class="filename">do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"</code>
-                        line causes the contents of the shared state cache to be
-                        copied to <code class="filename">${DEPLOY_DIR_IMAGE}</code>.
-                        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                            If <code class="filename">do_deploy</code> is not already in
-                            the shared state cache or if its input checksum
-                            (signature) has changed from when the output was
-                            cached, the task will be run to populate the shared
-                            state cache, after which the contents of the shared
-                            state cache is copied to
-                            <code class="filename">${DEPLOY_DIR_IMAGE}</code>.
-                            If <code class="filename">do_deploy</code> is in the shared
-                            state cache and its signature indicates that the
-                            cached output is still valid (i.e. if no
-                            relevant task inputs have changed), then the
-                            contents of the shared state cache will be copied
-                            directly to
-                            <code class="filename">${DEPLOY_DIR_IMAGE}</code> by the
-                            <code class="filename">do_deploy_setscene</code> task
-                            instead, skipping the
-                            <code class="filename">do_deploy</code> task.
-                        </div><p>
-                        </p></li><li class="listitem"><p>
-                        The following task definition is glue logic needed to
-                        make the previous settings effective:
-                        </p><pre class="literallayout">
-     python do_deploy_setscene () {
-         sstate_setscene(d)
-     }
-     addtask do_deploy_setscene
-                        </pre><p>
-                        <code class="filename">sstate_setscene()</code> takes the flags
-                        above as input and accelerates the
-                        <code class="filename">do_deploy</code> task through the
-                        shared state cache if possible.
-                        If the task was accelerated,
-                        <code class="filename">sstate_setscene()</code> returns True.
-                        Otherwise, it returns False, and the normal
-                        <code class="filename">do_deploy</code> task runs.
-                        For more information, see the
-                        "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#setscene" target="_top">setscene</a>"
-                        section in the BitBake User Manual.
-                        </p></li><li class="listitem"><p>
-                        The <code class="filename">do_deploy[dirs] = "${DEPLOYDIR} ${B}"</code>
-                        line creates <code class="filename">${DEPLOYDIR}</code> and
-                        <code class="filename">${B}</code> before the
-                        <code class="filename">do_deploy</code> task runs, and also sets
-                        the current working directory of
-                        <code class="filename">do_deploy</code> to
-                        <code class="filename">${B}</code>.
-                        For more information, see the
-                        "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#variable-flags" target="_top">Variable Flags</a>"
-                        section in the BitBake User Manual.
-                        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                            In cases where
-                            <code class="filename">sstate-inputdirs</code> and
-                            <code class="filename">sstate-outputdirs</code> would be the
-                            same, you can use
-                            <code class="filename">sstate-plaindirs</code>.
-                            For example, to preserve the
-                            <code class="filename">${PKGD}</code> and
-                            <code class="filename">${PKGDEST}</code> output from the
-                            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>
-                            task, use the following:
-                            <pre class="literallayout">
-     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
-                            </pre></div><p>
-                        </p></li><li class="listitem"><p>
-                        <code class="filename">sstate-inputdirs</code> and
-                        <code class="filename">sstate-outputdirs</code> can also be used
-                        with multiple directories.
-                        For example, the following declares
-                        <code class="filename">PKGDESTWORK</code> and
-                        <code class="filename">SHLIBWORK</code> as shared state
-                        input directories, which populates the shared state
-                        cache, and <code class="filename">PKGDATA_DIR</code> and
-                        <code class="filename">SHLIBSDIR</code> as the corresponding
-                        shared state output directories:
-                        </p><pre class="literallayout">
-     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
-     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
-                        </pre><p>
-                        </p></li><li class="listitem"><p>
-                        These methods also include the ability to take a
-                        lockfile when manipulating shared state directory
-                        structures, for cases where file additions or removals
-                        are sensitive:
-                        </p><pre class="literallayout">
-     do_package[sstate-lockfile] = "${PACKAGELOCK}"
-                        </pre><p>
-                        </p></li></ul></div><p>
-            </p><p>
-                Behind the scenes, the shared state code works by looking in
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SSTATE_DIR" target="_top"><code class="filename">SSTATE_DIR</code></a>
-                and
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SSTATE_MIRRORS" target="_top"><code class="filename">SSTATE_MIRRORS</code></a>
-                for shared state files.
-                Here is an example:
-                </p><pre class="literallayout">
-     SSTATE_MIRRORS ?= "\
-     file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
-     file://.* file:///some/local/dir/sstate/PATH"
-                </pre><p>
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    The shared state directory
-                    (<code class="filename">SSTATE_DIR</code>) is organized into
-                    two-character subdirectories, where the subdirectory
-                    names are based on the first two characters of the hash.
-                    If the shared state directory structure for a mirror has the
-                    same structure as <code class="filename">SSTATE_DIR</code>, you must
-                    specify "PATH" as part of the URI to enable the build system
-                    to map to the appropriate subdirectory.
-                </div><p>
-            </p><p>
-                The shared state package validity can be detected just by
-                looking at the filename since the filename contains the task
-                checksum (or signature) as described earlier in this section.
-                If a valid shared state package is found, the build process
-                downloads it and uses it to accelerate the task.
-            </p><p>
-                The build processes use the <code class="filename">*_setscene</code>
-                tasks for the task acceleration phase.
-                BitBake goes through this phase before the main execution
-                code and tries to accelerate any tasks for which it can find
-                shared state packages.
-                If a shared state package for a task is available, the
-                shared state package is used.
-                This means the task and any tasks on which it is dependent
-                are not executed.
-            </p><p>
-                As a real world example, the aim is when building an IPK-based
-                image, only the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package_write_ipk" target="_top"><code class="filename">do_package_write_ipk</code></a>
-                tasks would have their shared state packages fetched and
-                extracted.
-                Since the sysroot is not used, it would never get extracted.
-                This is another reason why a task-based approach is preferred
-                over a recipe-based approach, which would have to install the
-                output from every task.
-            </p></div><div class="section" title="3.3.4. Tips and Tricks"><div class="titlepage"><div><div><h3 class="title" id="tips-and-tricks">3.3.4. Tips and Tricks<span class="permalink"><a alt="Permalink" title="Permalink" href="#tips-and-tricks">¶</a></span></h3></div></div></div><p>
-                The code in the build system that supports incremental builds
-                is not simple code.
-                This section presents some tips and tricks that help you work
-                around issues related to shared state code.
-            </p><div class="section" title="3.3.4.1. Debugging"><div class="titlepage"><div><div><h4 class="title" id="overview-debugging">3.3.4.1. Debugging<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-debugging">¶</a></span></h4></div></div></div><p>
-                    Seeing what metadata went into creating the input signature
-                    of a shared state (sstate) task can be a useful debugging
-                    aid.
-                    This information is available in signature information
-                    (<code class="filename">siginfo</code>) files in
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-SSTATE_DIR" target="_top"><code class="filename">SSTATE_DIR</code></a>.
-                    For information on how to view and interpret information in
-                    <code class="filename">siginfo</code> files, see the
-                    "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#dev-viewing-task-variable-dependencies" target="_top">Viewing Task Variable Dependencies</a>"
-                    section in the Yocto Project Development Tasks Manual.
-                </p></div><div class="section" title="3.3.4.2. Invalidating Shared State"><div class="titlepage"><div><div><h4 class="title" id="invalidating-shared-state">3.3.4.2. Invalidating Shared State<span class="permalink"><a alt="Permalink" title="Permalink" href="#invalidating-shared-state">¶</a></span></h4></div></div></div><p>
-                    The OpenEmbedded build system uses checksums and shared
-                    state cache to avoid unnecessarily rebuilding tasks.
-                    Collectively, this scheme is known as "shared state code."
-                </p><p>
-                    As with all schemes, this one has some drawbacks.
-                    It is possible that you could make implicit changes to your
-                    code that the checksum calculations do not take into
-                    account.
-                    These implicit changes affect a task's output but do not
-                    trigger the shared state code into rebuilding a recipe.
-                    Consider an example during which a tool changes its output.
-                    Assume that the output of <code class="filename">rpmdeps</code>
-                    changes.
-                    The result of the change should be that all the
-                    <code class="filename">package</code> and
-                    <code class="filename">package_write_rpm</code> shared state cache
-                    items become invalid.
-                    However, because the change to the output is
-                    external to the code and therefore implicit,
-                    the associated shared state cache items do not become
-                    invalidated.
-                    In this case, the build process uses the cached items
-                    rather than running the task again.
-                    Obviously, these types of implicit changes can cause
-                    problems.
-                </p><p>
-                    To avoid these problems during the build, you need to
-                    understand the effects of any changes you make.
-                    Realize that changes you make directly to a function
-                    are automatically factored into the checksum calculation.
-                    Thus, these explicit changes invalidate the associated
-                    area of shared state cache.
-                    However, you need to be aware of any implicit changes that
-                    are not obvious changes to the code and could affect
-                    the output of a given task.
-                </p><p>
-                    When you identify an implicit change, you can easily
-                    take steps to invalidate the cache and force the tasks
-                    to run.
-                    The steps you can take are as simple as changing a
-                    function's comments in the source code.
-                    For example, to invalidate package shared state files,
-                    change the comment statements of
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>
-                    or the comments of one of the functions it calls.
-                    Even though the change is purely cosmetic, it causes the
-                    checksum to be recalculated and forces the OpenEmbedded
-                    build system to run the task again.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        For an example of a commit that makes a cosmetic
-                        change to invalidate shared state, see this
-                        <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54" target="_top">commit</a>.
-                    </div><p>
-                </p></div></div></div><div class="section" title="3.4. Automatically Added Runtime Dependencies"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="automatically-added-runtime-dependencies">3.4. Automatically Added Runtime Dependencies<span class="permalink"><a alt="Permalink" title="Permalink" href="#automatically-added-runtime-dependencies">¶</a></span></h2></div></div></div><p>
-            The OpenEmbedded build system automatically adds common types of
-            runtime dependencies between packages, which means that you do not
-            need to explicitly declare the packages using
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-RDEPENDS" target="_top"><code class="filename">RDEPENDS</code></a>.
-            Three automatic mechanisms exist (<code class="filename">shlibdeps</code>,
-            <code class="filename">pcdeps</code>, and <code class="filename">depchains</code>)
-            that handle shared libraries, package configuration (pkg-config)
-            modules, and <code class="filename">-dev</code> and
-            <code class="filename">-dbg</code> packages, respectively.
-            For other types of runtime dependencies, you must manually declare
-            the dependencies.
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    <code class="filename">shlibdeps</code>:
-                    During the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>
-                    task of each recipe, all shared libraries installed by the
-                    recipe are located.
-                    For each shared library, the package that contains the
-                    shared library is registered as providing the shared
-                    library.
-                    More specifically, the package is registered as providing
-                    the
-                    <a class="ulink" href="https://en.wikipedia.org/wiki/Soname" target="_top">soname</a>
-                    of the library.
-                    The resulting shared-library-to-package mapping
-                    is saved globally in
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PKGDATA_DIR" target="_top"><code class="filename">PKGDATA_DIR</code></a>
-                    by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-packagedata" target="_top"><code class="filename">do_packagedata</code></a>
-                    task.</p><p>Simultaneously, all executables and shared libraries
-                    installed by the recipe are inspected to see what shared
-                    libraries they link against.
-                    For each shared library dependency that is found,
-                    <code class="filename">PKGDATA_DIR</code> is queried to
-                    see if some package (likely from a different recipe)
-                    contains the shared library.
-                    If such a package is found, a runtime dependency is added
-                    from the package that depends on the shared library to the
-                    package that contains the library.</p><p>The automatically added runtime dependency also
-                    includes a version restriction.
-                    This version restriction specifies that at least the
-                    current version of the package that provides the shared
-                    library must be used, as if
-                    "<em class="replaceable"><code>package</code></em> (&gt;= <em class="replaceable"><code>version</code></em>)"
-                    had been added to
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-RDEPENDS" target="_top"><code class="filename">RDEPENDS</code></a>.
-                    This forces an upgrade of the package containing the shared
-                    library when installing the package that depends on the
-                    library, if needed.</p><p>If you want to avoid a package being registered as
-                    providing a particular shared library (e.g. because the library
-                    is for internal use only), then add the library to
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PRIVATE_LIBS" target="_top"><code class="filename">PRIVATE_LIBS</code></a>
-                    inside the package's recipe.
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">pcdeps</code>:
-                    During the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package" target="_top"><code class="filename">do_package</code></a>
-                    task of each recipe, all pkg-config modules
-                    (<code class="filename">*.pc</code> files) installed by the recipe
-                    are located.
-                    For each module, the package that contains the module is
-                    registered as providing the module.
-                    The resulting module-to-package mapping is saved globally in
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PKGDATA_DIR" target="_top"><code class="filename">PKGDATA_DIR</code></a>
-                    by the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-packagedata" target="_top"><code class="filename">do_packagedata</code></a>
-                    task.</p><p>Simultaneously, all pkg-config modules installed by
-                    the recipe are inspected to see what other pkg-config
-                    modules they depend on.
-                    A module is seen as depending on another module if it
-                    contains a "Requires:" line that specifies the other module.
-                    For each module dependency,
-                    <code class="filename">PKGDATA_DIR</code> is queried to see if some
-                    package contains the module.
-                    If such a package is found, a runtime dependency is added
-                    from the package that depends on the module to the package
-                    that contains the module.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        The <code class="filename">pcdeps</code> mechanism most often
-                        infers dependencies between <code class="filename">-dev</code>
-                        packages.
-                    </div><p>
-                    </p></li><li class="listitem"><p>
-                    <code class="filename">depchains</code>:
-                    If a package <code class="filename">foo</code> depends on a package
-                    <code class="filename">bar</code>, then <code class="filename">foo-dev</code>
-                    and <code class="filename">foo-dbg</code> are also made to depend on
-                    <code class="filename">bar-dev</code> and
-                    <code class="filename">bar-dbg</code>, respectively.
-                    Taking the <code class="filename">-dev</code> packages as an
-                    example, the <code class="filename">bar-dev</code> package might
-                    provide headers and shared library symlinks needed by
-                    <code class="filename">foo-dev</code>, which shows the need
-                    for a dependency between the packages.</p><p>The dependencies added by
-                    <code class="filename">depchains</code> are in the form of
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-RRECOMMENDS" target="_top"><code class="filename">RRECOMMENDS</code></a>.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        By default, <code class="filename">foo-dev</code> also has an
-                        <code class="filename">RDEPENDS</code>-style dependency on
-                        <code class="filename">foo</code>, because the default value of
-                        <code class="filename">RDEPENDS_${PN}-dev</code> (set in
-                        <code class="filename">bitbake.conf</code>) includes
-                        "${PN}".
-                    </div><p>To ensure that the dependency chain is never broken,
-                    <code class="filename">-dev</code> and <code class="filename">-dbg</code>
-                    packages are always generated by default, even if the
-                    packages turn out to be empty.
-                    See the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-ALLOW_EMPTY" target="_top"><code class="filename">ALLOW_EMPTY</code></a>
-                    variable for more information.
-                    </p></li></ul></div><p>
-        </p><p>
-            The <code class="filename">do_package</code> task depends on the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-packagedata" target="_top"><code class="filename">do_packagedata</code></a>
-            task of each recipe in
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DEPENDS" target="_top"><code class="filename">DEPENDS</code></a>
-            through use of a
-            <code class="filename">[</code><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#variable-flags" target="_top"><code class="filename">deptask</code></a><code class="filename">]</code>
-            declaration, which guarantees that the required
-            shared-library/module-to-package mapping information will be available
-            when needed as long as <code class="filename">DEPENDS</code> has been
-            correctly set.
-        </p></div><div class="section" title="3.5. Fakeroot and Pseudo"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="fakeroot-and-pseudo">3.5. Fakeroot and Pseudo<span class="permalink"><a alt="Permalink" title="Permalink" href="#fakeroot-and-pseudo">¶</a></span></h2></div></div></div><p>
-            Some tasks are easier to implement when allowed to perform certain
-            operations that are normally reserved for the root user (e.g.
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-install" target="_top"><code class="filename">do_install</code></a>,
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-package_write_deb" target="_top"><code class="filename">do_package_write*</code></a>,
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-rootfs" target="_top"><code class="filename">do_rootfs</code></a>,
-            and
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-tasks-image" target="_top"><code class="filename">do_image*</code></a>).
-            For example, the <code class="filename">do_install</code> task benefits
-            from being able to set the UID and GID of installed files to
-            arbitrary values.
-        </p><p>
-            One approach to allowing tasks to perform root-only operations
-            would be to require BitBake to run as root.
-            However, this method is cumbersome and has security issues.
-            The approach that is actually used is to run tasks that benefit
-            from root privileges in a "fake" root environment.
-            Within this environment, the task and its child processes believe
-            that they are running as the root user, and see an internally
-            consistent view of the filesystem.
-            As long as generating the final output (e.g. a package or an image)
-            does not require root privileges, the fact that some earlier
-            steps ran in a fake root environment does not cause problems.
-        </p><p>
-            The capability to run tasks in a fake root environment is known as
-            "<a class="ulink" href="http://man.he.net/man1/fakeroot" target="_top">fakeroot</a>",
-            which is derived from the BitBake keyword/variable
-            flag that requests a fake root environment for a task.
-        </p><p>
-            In the OpenEmbedded build system, the program that implements
-            fakeroot is known as Pseudo.
-            Pseudo overrides system calls by using the environment variable
-            <code class="filename">LD_PRELOAD</code>, which results in the illusion
-            of running as root.
-            To keep track of "fake" file ownership and permissions resulting
-            from operations that require root permissions, Pseudo uses
-            an SQLite 3 database.
-            This database is stored in
-            <code class="filename">${</code><a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a><code class="filename">}/pseudo/files.db</code>
-            for individual recipes.
-            Storing the database in a file as opposed to in memory
-            gives persistence between tasks and builds, which is not
-            accomplished using fakeroot.
-            </p><div class="note" title="Caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3>
-                If you add your own task that manipulates the same files or
-                directories as a fakeroot task, then that task also needs to
-                run under fakeroot.
-                Otherwise, the task cannot run root-only operations, and
-                cannot see the fake file ownership and permissions set by the
-                other task.
-                You need to also add a dependency on
-                <code class="filename">virtual/fakeroot-native:do_populate_sysroot</code>,
-                giving the following:
-                <pre class="literallayout">
-       fakeroot do_mytask () {
-           ...
-       }
-       do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"
-                </pre></div><p>
-            For more information, see the
-            <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#var-FAKEROOT" target="_top"><code class="filename">FAKEROOT*</code></a>
-            variables in the BitBake User Manual.
-            You can also reference the
-            "<a class="ulink" href="http://www.ibm.com/developerworks/opensource/library/os-aapseudo1/index.html" target="_top">Pseudo</a>"
-            and
-            "<a class="ulink" href="https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot" target="_top">Why Not Fakeroot?</a>"
-            articles for background information on Pseudo.
-        </p></div><div class="section" title="3.6. Wayland"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="wayland">3.6. Wayland<span class="permalink"><a alt="Permalink" title="Permalink" href="#wayland">¶</a></span></h2></div></div></div><p>
-            <a class="ulink" href="http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)" target="_top">Wayland</a>
-            is a computer display server protocol that
-            provides a method for compositing window managers to communicate
-            directly with applications and video hardware and expects them to
-            communicate with input hardware using other libraries.
-            Using Wayland with supporting targets can result in better control
-            over graphics frame rendering than an application might otherwise
-            achieve.
-        </p><p>
-            The Yocto Project provides the Wayland protocol libraries and the
-            reference
-            <a class="ulink" href="http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston" target="_top">Weston</a>
-            compositor as part of its release.
-            This section describes what you need to do to implement Wayland and
-            use the compositor when building an image for a supporting target.
-        </p><div class="section" title="3.6.1. Support"><div class="titlepage"><div><div><h3 class="title" id="wayland-support">3.6.1. Support<span class="permalink"><a alt="Permalink" title="Permalink" href="#wayland-support">¶</a></span></h3></div></div></div><p>
-                The Wayland protocol libraries and the reference Weston
-                compositor ship as integrated packages in the
-                <code class="filename">meta</code> layer of the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#source-directory" target="_top">Source Directory</a>.
-                Specifically, you can find the recipes that build both Wayland
-                and Weston at
-                <code class="filename">meta/recipes-graphics/wayland</code>.
-            </p><p>
-                You can build both the Wayland and Weston packages for use only
-                with targets that accept the
-                <a class="ulink" href="https://en.wikipedia.org/wiki/Mesa_(computer_graphics)" target="_top">Mesa 3D and Direct Rendering Infrastructure</a>,
-                which is also known as Mesa DRI.
-                This implies that you cannot build and use the packages if your
-                target uses, for example, the
-                <span class="trademark">Intel</span>® Embedded Media
-                and Graphics Driver
-                (<span class="trademark">Intel</span>® EMGD) that
-                overrides Mesa DRI.
-                </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                    Due to lack of EGL support, Weston 1.0.3 will not run
-                    directly on the emulated QEMU hardware.
-                    However, this version of Weston will run under X emulation
-                    without issues.
-                </div><p>
-            </p></div><div class="section" title="3.6.2. Enabling Wayland in an Image"><div class="titlepage"><div><div><h3 class="title" id="enabling-wayland-in-an-image">3.6.2. Enabling Wayland in an Image<span class="permalink"><a alt="Permalink" title="Permalink" href="#enabling-wayland-in-an-image">¶</a></span></h3></div></div></div><p>
-                To enable Wayland, you need to enable it to be built and enable
-                it to be included in the image.
-            </p><div class="section" title="3.6.2.1. Building"><div class="titlepage"><div><div><h4 class="title" id="enable-building">3.6.2.1. Building<span class="permalink"><a alt="Permalink" title="Permalink" href="#enable-building">¶</a></span></h4></div></div></div><p>
-                    To cause Mesa to build the <code class="filename">wayland-egl</code>
-                    platform and Weston to build Wayland with Kernel Mode
-                    Setting
-                    (<a class="ulink" href="https://wiki.archlinux.org/index.php/Kernel_Mode_Setting" target="_top">KMS</a>)
-                    support, include the "wayland" flag in the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-DISTRO_FEATURES" target="_top"><code class="filename">DISTRO_FEATURES</code></a>
-                    statement in your <code class="filename">local.conf</code> file:
-                    </p><pre class="literallayout">
-     DISTRO_FEATURES_append = " wayland"
-                    </pre><p>
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        If X11 has been enabled elsewhere, Weston will build
-                        Wayland with X11 support
-                    </div><p>
-                </p></div><div class="section" title="3.6.2.2. Installing"><div class="titlepage"><div><div><h4 class="title" id="enable-installation-in-an-image">3.6.2.2. Installing<span class="permalink"><a alt="Permalink" title="Permalink" href="#enable-installation-in-an-image">¶</a></span></h4></div></div></div><p>
-                    To install the Wayland feature into an image, you must
-                    include the following
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-CORE_IMAGE_EXTRA_INSTALL" target="_top"><code class="filename">CORE_IMAGE_EXTRA_INSTALL</code></a>
-                    statement in your <code class="filename">local.conf</code> file:
-                    </p><pre class="literallayout">
-     CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
-                    </pre><p>
-                </p></div></div><div class="section" title="3.6.3. Running Weston"><div class="titlepage"><div><div><h3 class="title" id="running-weston">3.6.3. Running Weston<span class="permalink"><a alt="Permalink" title="Permalink" href="#running-weston">¶</a></span></h3></div></div></div><p>
-                To run Weston inside X11, enabling it as described earlier and
-                building a Sato image is sufficient.
-                If you are running your image under Sato, a Weston Launcher
-                appears in the "Utility" category.
-            </p><p>
-                Alternatively, you can run Weston through the command-line
-                interpretor (CLI), which is better suited for development work.
-                To run Weston under the CLI, you need to do the following after
-                your image is built:
-                </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
-                        Run these commands to export
-                        <code class="filename">XDG_RUNTIME_DIR</code>:
-                        </p><pre class="literallayout">
-     mkdir -p /tmp/$USER-weston
-     chmod 0700 /tmp/$USER-weston
-     export XDG_RUNTIME_DIR=/tmp/$USER-weston
-                        </pre><p>
-                        </p></li><li class="listitem"><p>
-                        Launch Weston in the shell:
-                        </p><pre class="literallayout">
-     weston
-                        </pre></li></ol></div><p>
-            </p></div></div><div class="section" title="3.7. Licenses"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="overview-licenses">3.7. Licenses<span class="permalink"><a alt="Permalink" title="Permalink" href="#overview-licenses">¶</a></span></h2></div></div></div><p>
-            This section describes the mechanism by which the OpenEmbedded
-            build system tracks changes to licensing text.
-            The section also describes how to enable commercially licensed
-            recipes, which by default are disabled.
-        </p><p>
-            For information that can help you maintain compliance with
-            various open source licensing during the lifecycle of the product,
-            see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle" target="_top">Maintaining Open Source License Compliance During Your Project's Lifecycle</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p><div class="section" title="3.7.1. Tracking License Changes"><div class="titlepage"><div><div><h3 class="title" id="usingpoky-configuring-LIC_FILES_CHKSUM">3.7.1. Tracking License Changes<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-configuring-LIC_FILES_CHKSUM">¶</a></span></h3></div></div></div><p>
-                The license of an upstream project might change in the future.
-                In order to prevent these changes going unnoticed, the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LIC_FILES_CHKSUM" target="_top"><code class="filename">LIC_FILES_CHKSUM</code></a>
-                variable tracks changes to the license text. The checksums are
-                validated at the end of the configure step, and if the
-                checksums do not match, the build will fail.
-            </p><div class="section" title="3.7.1.1. Specifying the LIC_FILES_CHKSUM Variable"><div class="titlepage"><div><div><h4 class="title" id="usingpoky-specifying-LIC_FILES_CHKSUM">3.7.1.1. Specifying the <code class="filename">LIC_FILES_CHKSUM</code> Variable<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-specifying-LIC_FILES_CHKSUM">¶</a></span></h4></div></div></div><p>
-                    The <code class="filename">LIC_FILES_CHKSUM</code>
-                    variable contains checksums of the license text in the
-                    source code for the recipe.
-                    Following is an example of how to specify
-                    <code class="filename">LIC_FILES_CHKSUM</code>:
-                    </p><pre class="literallayout">
-     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
-                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
-                         file://licfile2.txt;endline=50;md5=zzzz \
-                         ..."
-                    </pre><p>
-                    </p><div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Notes</h3><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                                When using "beginline" and "endline", realize
-                                that line numbering begins with one and not
-                                zero.
-                                Also, the included lines are inclusive (i.e.
-                                lines five through and including 29 in the
-                                previous example for
-                                <code class="filename">licfile1.txt</code>).
-                                </p></li><li class="listitem"><p>
-                                When a license check fails, the selected license
-                                text is included as part of the QA message.
-                                Using this output, you can determine the exact
-                                start and finish for the needed license text.
-                                </p></li></ul></div></div><p>
-                </p><p>
-                    The build system uses the
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-S" target="_top"><code class="filename">S</code></a>
-                    variable as the default directory when searching files
-                    listed in <code class="filename">LIC_FILES_CHKSUM</code>.
-                    The previous example employs the default directory.
-                </p><p>
-                    Consider this next example:
-                    </p><pre class="literallayout">
-     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
-                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
-     LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
-                    </pre><p>
-                </p><p>
-                    The first line locates a file in
-                    <code class="filename">${S}/src/ls.c</code> and isolates lines five
-                    through 16 as license text.
-                    The second line refers to a file in
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-WORKDIR" target="_top"><code class="filename">WORKDIR</code></a>.
-                </p><p>
-                    Note that <code class="filename">LIC_FILES_CHKSUM</code> variable is
-                    mandatory for all recipes, unless the
-                    <code class="filename">LICENSE</code> variable is set to "CLOSED".
-                </p></div><div class="section" title="3.7.1.2. Explanation of Syntax"><div class="titlepage"><div><div><h4 class="title" id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">3.7.1.2. Explanation of Syntax<span class="permalink"><a alt="Permalink" title="Permalink" href="#usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">¶</a></span></h4></div></div></div><p>
-                    As mentioned in the previous section, the
-                    <code class="filename">LIC_FILES_CHKSUM</code> variable lists all
-                    the important files that contain the license text for the
-                    source code.
-                    It is possible to specify a checksum for an entire file,
-                    or a specific section of a file (specified by beginning and
-                    ending line numbers with the "beginline" and "endline"
-                    parameters, respectively).
-                    The latter is useful for source files with a license
-                    notice header, README documents, and so forth.
-                    If you do not use the "beginline" parameter, then it is
-                    assumed that the text begins on the first line of the file.
-                    Similarly, if you do not use the "endline" parameter,
-                    it is assumed that the license text ends with the last
-                    line of the file.
-                </p><p>
-                    The "md5" parameter stores the md5 checksum of the license
-                    text.
-                    If the license text changes in any way as compared to
-                    this parameter then a mismatch occurs.
-                    This mismatch triggers a build failure and notifies
-                    the developer.
-                    Notification allows the developer to review and address
-                    the license text changes.
-                    Also note that if a mismatch occurs during the build,
-                    the correct md5 checksum is placed in the build log and
-                    can be easily copied to the recipe.
-                </p><p>
-                    There is no limit to how many files you can specify using
-                    the <code class="filename">LIC_FILES_CHKSUM</code> variable.
-                    Generally, however, every project requires a few
-                    specifications for license tracking.
-                    Many projects have a "COPYING" file that stores the
-                    license information for all the source code files.
-                    This practice allows you to just track the "COPYING"
-                    file as long as it is kept up to date.
-                    </p><div class="note" title="Tips" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tips</h3><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                                If you specify an empty or invalid "md5"
-                                parameter, BitBake returns an md5 mis-match
-                                error and displays the correct "md5" parameter
-                                value during the build.
-                                The correct parameter is also captured in
-                                the build log.
-                                </p></li><li class="listitem"><p>
-                                If the whole file contains only license text,
-                                you do not need to use the "beginline" and
-                               "endline" parameters.
-                               </p></li></ul></div></div><p>
-                </p></div></div><div class="section" title="3.7.2. Enabling Commercially Licensed Recipes"><div class="titlepage"><div><div><h3 class="title" id="enabling-commercially-licensed-recipes">3.7.2. Enabling Commercially Licensed Recipes<span class="permalink"><a alt="Permalink" title="Permalink" href="#enabling-commercially-licensed-recipes">¶</a></span></h3></div></div></div><p>
-                By default, the OpenEmbedded build system disables
-                components that have commercial or other special licensing
-                requirements.
-                Such requirements are defined on a
-                recipe-by-recipe basis through the
-                <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LICENSE_FLAGS" target="_top"><code class="filename">LICENSE_FLAGS</code></a>
-                variable definition in the affected recipe.
-                For instance, the
-                <code class="filename">poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
-                recipe contains the following statement:
-                </p><pre class="literallayout">
-     LICENSE_FLAGS = "commercial"
-                </pre><p>
-                Here is a slightly more complicated example that contains both
-                an explicit recipe name and version (after variable expansion):
-                </p><pre class="literallayout">
-     LICENSE_FLAGS = "license_${PN}_${PV}"
-                </pre><p>
-                    In order for a component restricted by a
-                <code class="filename">LICENSE_FLAGS</code> definition to be enabled and
-                included in an image, it needs to have a matching entry in the
-                global
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LICENSE_FLAGS_WHITELIST" target="_top"><code class="filename">LICENSE_FLAGS_WHITELIST</code></a>
-                variable, which is a variable typically defined in your
-                <code class="filename">local.conf</code> file.
-                For example, to enable the
-                <code class="filename">poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
-                    package, you could add either the string
-                    "commercial_gst-plugins-ugly" or the more general string
-                    "commercial" to <code class="filename">LICENSE_FLAGS_WHITELIST</code>.
-                See the
-                "<a class="link" href="#license-flag-matching" title="3.7.2.1. License Flag Matching">License Flag Matching</a>"
-                section for a full
-                explanation of how <code class="filename">LICENSE_FLAGS</code> matching
-                works.
-                Here is the example:
-                </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
-                </pre><p>
-                    Likewise, to additionally enable the package built from the
-                recipe containing
-                    <code class="filename">LICENSE_FLAGS = "license_${PN}_${PV}"</code>,
-                and assuming that the actual recipe name was
-                <code class="filename">emgd_1.10.bb</code>, the following string would
-                enable that package as well as the original
-                <code class="filename">gst-plugins-ugly</code> package:
-                </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
-                </pre><p>
-                    As a convenience, you do not need to specify the complete
-                license string in the whitelist for every package.
-                You can use an abbreviated form, which consists
-                of just the first portion or portions of the license
-                string before the initial underscore character or characters.
-                A partial string will match any license that contains the
-                given string as the first portion of its license.
-                For example, the following whitelist string will also match
-                both of the packages previously mentioned as well as any other
-                packages that have licenses starting with "commercial" or
-                "license".
-                </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial license"
-                </pre><p>
-            </p><div class="section" title="3.7.2.1. License Flag Matching"><div class="titlepage"><div><div><h4 class="title" id="license-flag-matching">3.7.2.1. License Flag Matching<span class="permalink"><a alt="Permalink" title="Permalink" href="#license-flag-matching">¶</a></span></h4></div></div></div><p>
-                            License flag matching allows you to control what recipes
-                    the OpenEmbedded build system includes in the build.
-                    Fundamentally, the build system attempts to match
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LICENSE_FLAGS" target="_top"><code class="filename">LICENSE_FLAGS</code></a>
-                    strings found in recipes against
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LICENSE_FLAGS_WHITELIST" target="_top"><code class="filename">LICENSE_FLAGS_WHITELIST</code></a>
-                    strings found in the whitelist.
-                    A match causes the build system to include a recipe in the
-                    build, while failure to find a match causes the build
-                    system to exclude a recipe.
-                </p><p>
-                    In general, license flag matching is simple.
-                    However, understanding some concepts will help you
-                    correctly and effectively use matching.
-                </p><p>
-                    Before a flag
-                    defined by a particular recipe is tested against the
-                    contents of the whitelist, the expanded string
-                    <code class="filename">_${PN}</code> is appended to the flag.
-                    This expansion makes each
-                    <code class="filename">LICENSE_FLAGS</code> value recipe-specific.
-                    After expansion, the string is then matched against the
-                    whitelist.
-                    Thus, specifying
-                    <code class="filename">LICENSE_FLAGS = "commercial"</code>
-                    in recipe "foo", for example, results in the string
-                    <code class="filename">"commercial_foo"</code>.
-                    And, to create a match, that string must appear in the
-                    whitelist.
-                </p><p>
-                    Judicious use of the <code class="filename">LICENSE_FLAGS</code>
-                    strings and the contents of the
-                    <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable
-                    allows you a lot of flexibility for including or excluding
-                    recipes based on licensing.
-                    For example, you can broaden the matching capabilities by
-                    using license flags string subsets in the whitelist.
-                    </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
-                        When using a string subset, be sure to use the part of
-                        the expanded string that precedes the appended
-                        underscore character (e.g.
-                        <code class="filename">usethispart_1.3</code>,
-                        <code class="filename">usethispart_1.4</code>, and so forth).
-                    </div><p>
-                    For example, simply specifying the string "commercial" in
-                    the whitelist matches any expanded
-                    <code class="filename">LICENSE_FLAGS</code> definition that starts
-                    with the string "commercial" such as "commercial_foo" and
-                    "commercial_bar", which are the strings the build system
-                    automatically generates for hypothetical recipes named
-                    "foo" and "bar" assuming those recipes simply specify the
-                    following:
-                    </p><pre class="literallayout">
-     LICENSE_FLAGS = "commercial"
-                    </pre><p>
-                    Thus, you can choose to exhaustively
-                    enumerate each license flag in the whitelist and
-                    allow only specific recipes into the image, or
-                    you can use a string subset that causes a broader range of
-                    matches to allow a range of recipes into the image.
-                </p><p>
-                    This scheme works even if the
-                    <code class="filename">LICENSE_FLAGS</code> string already
-                    has <code class="filename">_${PN}</code> appended.
-                    For example, the build system turns the license flag
-                    "commercial_1.2_foo" into "commercial_1.2_foo_foo" and
-                    would match both the general "commercial" and the specific
-                    "commercial_1.2_foo" strings found in the whitelist, as
-                    expected.
-                </p><p>
-                    Here are some other scenarios:
-                    </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                            You can specify a versioned string in the recipe
-                            such as "commercial_foo_1.2" in a "foo" recipe.
-                            The build system expands this string to
-                            "commercial_foo_1.2_foo".
-                            Combine this license flag with a whitelist that has
-                            the string "commercial" and you match the flag
-                            along with any other flag that starts with the
-                            string "commercial".
-                            </p></li><li class="listitem"><p>
-                            Under the same circumstances, you can use
-                            "commercial_foo" in the whitelist and the build
-                            system not only matches "commercial_foo_1.2" but
-                            also matches any license flag with the string
-                            "commercial_foo", regardless of the version.
-                            </p></li><li class="listitem"><p>
-                            You can be very specific and use both the
-                            package and version parts in the whitelist (e.g.
-                            "commercial_foo_1.2") to specifically match a
-                            versioned recipe.
-                            </p></li></ul></div><p>
-                </p></div><div class="section" title="3.7.2.2. Other Variables Related to Commercial Licenses"><div class="titlepage"><div><div><h4 class="title" id="other-variables-related-to-commercial-licenses">3.7.2.2. Other Variables Related to Commercial Licenses<span class="permalink"><a alt="Permalink" title="Permalink" href="#other-variables-related-to-commercial-licenses">¶</a></span></h4></div></div></div><p>
-                    Other helpful variables related to commercial
-                    license handling exist and are defined in the
-                    <code class="filename">poky/meta/conf/distro/include/default-distrovars.inc</code> file:
-                    </p><pre class="literallayout">
-     COMMERCIAL_AUDIO_PLUGINS ?= ""
-     COMMERCIAL_VIDEO_PLUGINS ?= ""
-                    </pre><p>
-                    If you want to enable these components, you can do so by
-                    making sure you have statements similar to the following
-                    in your <code class="filename">local.conf</code> configuration file:
-                    </p><pre class="literallayout">
-     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
-        gst-plugins-ugly-mpegaudioparse"
-     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
-        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
-     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
-                    </pre><p>
-                    Of course, you could also create a matching whitelist
-                    for those components using the more general "commercial"
-                    in the whitelist, but that would also enable all the
-                    other packages with
-                    <a class="ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-LICENSE_FLAGS" target="_top"><code class="filename">LICENSE_FLAGS</code></a>
-                    containing "commercial", which you may or may not want:
-                    </p><pre class="literallayout">
-     LICENSE_FLAGS_WHITELIST = "commercial"
-                    </pre><p>
-                </p><p>
-                    Specifying audio and video plug-ins as part of the
-                    <code class="filename">COMMERCIAL_AUDIO_PLUGINS</code> and
-                    <code class="filename">COMMERCIAL_VIDEO_PLUGINS</code> statements
-                    (along with the enabling
-                    <code class="filename">LICENSE_FLAGS_WHITELIST</code>) includes the
-                    plug-ins or components into built images, thus adding
-                    support for media formats or components.
-                </p></div></div></div><div class="section" title="3.8. x32 psABI"><div class="titlepage"><div><div><h2 class="title" style="clear: both" id="x32">3.8. x32 psABI<span class="permalink"><a alt="Permalink" title="Permalink" href="#x32">¶</a></span></h2></div></div></div><p>
-            x32 processor-specific Application Binary Interface
-            (<a class="ulink" href="https://software.intel.com/en-us/node/628948" target="_top">x32 psABI</a>)
-            is a native 32-bit processor-specific ABI for
-            <span class="trademark">Intel</span>® 64 (x86-64)
-            architectures.
-            An ABI defines the calling conventions between functions in a
-            processing environment.
-            The interface determines what registers are used and what the sizes are
-            for various C data types.
-        </p><p>
-            Some processing environments prefer using 32-bit applications even
-            when running on Intel 64-bit platforms.
-            Consider the i386 psABI, which is a very old 32-bit ABI for Intel
-            64-bit platforms.
-            The i386 psABI does not provide efficient use and access of the
-            Intel 64-bit processor resources, leaving the system underutilized.
-            Now consider the x86_64 psABI.
-            This ABI is newer and uses 64-bits for data sizes and program
-            pointers.
-            The extra bits increase the footprint size of the programs,
-            libraries, and also increases the memory and file system size
-            requirements.
-            Executing under the x32 psABI enables user programs to utilize CPU
-            and system resources more efficiently while keeping the memory
-            footprint of the applications low.
-            Extra bits are used for registers but not for addressing mechanisms.
-        </p><p>
-            The Yocto Project supports the final specifications of x32 psABI
-            as follows:
-            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
-                    You can create packages and images in x32 psABI format on
-                    x86_64 architecture targets.
-                    </p></li><li class="listitem"><p>
-                    You can successfully build recipes with the x32 toolchain.
-                    </p></li><li class="listitem"><p>
-                    You can create and boot
-                    <code class="filename">core-image-minimal</code> and
-                    <code class="filename">core-image-sato</code> images.
-                    </p></li><li class="listitem"><p>
-                    RPM Package Manager (RPM) support exists for x32 binaries.
-                    </p></li><li class="listitem"><p>
-                    Support for large images exists.
-                    </p></li></ul></div><p>
-        </p><p>
-            For steps on how to use x32 psABI, see the
-            "<a class="ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#using-x32-psabi" target="_top">Using x32 psABI</a>"
-            section in the Yocto Project Development Tasks Manual.
-        </p></div></div>
-
-</div></body></html>
\ No newline at end of file
diff --git a/documentation/getting-started/getting-started.tgz b/documentation/getting-started/getting-started.tgz
deleted file mode 100644
index 829706d5d3..0000000000
--- a/documentation/getting-started/getting-started.tgz
+++ /dev/null