90 files changed, 6121 insertions, 0 deletions

diff --git a/documentation/getting-started/eclipse/getting-started-toc.xml b/documentation/getting-started/eclipse/getting-started-toc.xml
new file mode 100644
index 0000000000..6f1c29af30
--- /dev/null
+++ b/documentation/getting-started/eclipse/getting-started-toc.xml
@@ -0,0 +1,86 @@
+<?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
new file mode 100644
index 0000000000..885ee089e1
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html
@@ -0,0 +1,164 @@
+<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
new file mode 100644
index 0000000000..b145086974
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/basic-commands.html
@@ -0,0 +1,176 @@
+<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
new file mode 100644
index 0000000000..eda2c3370f
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html
@@ -0,0 +1,31 @@
+<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
new file mode 100644
index 0000000000..2d009d5720
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html
@@ -0,0 +1,54 @@
+<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
new file mode 100644
index 0000000000..9a94cc47da
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.html
@@ -0,0 +1,93 @@
+<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
new file mode 100644
index 0000000000..a1aef9119d
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html
@@ -0,0 +1,241 @@
+<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
new file mode 100644
index 0000000000..ccfb73189a
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/development-concepts.html
@@ -0,0 +1,66 @@
+<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
new file mode 100644
index 0000000000..da6da55986
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/distro-layer.html
@@ -0,0 +1,60 @@
+<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
new file mode 100644
index 0000000000..af70491f97
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/enable-building.html
@@ -0,0 +1,37 @@
+<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
new file mode 100644
index 0000000000..490f1d1036
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html
@@ -0,0 +1,27 @@
+<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
new file mode 100644
index 0000000000..1a31d0e6b1
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html
@@ -0,0 +1,91 @@
+<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
new file mode 100644
index 0000000000..6a325dbfd2
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html
@@ -0,0 +1,20 @@
+<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
new file mode 100644
index 0000000000..8354ad6730
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html
@@ -0,0 +1,91 @@
+<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
new file mode 100644
index 0000000000..8264410504
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png
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
new file mode 100644
index 0000000000..04f2794ea9
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png
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
new file mode 100644
index 0000000000..a07464f04c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png
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
new file mode 100644
index 0000000000..d36670a198
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png
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
new file mode 100644
index 0000000000..f38b078ab7
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png
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
new file mode 100644
index 0000000000..e401330a12
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png
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
new file mode 100644
index 0000000000..71a48dc6f4
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/images.png b/documentation/getting-started/eclipse/html/getting-started/figures/images.png
new file mode 100644
index 0000000000..d99eac1fbf
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/images.png
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
new file mode 100644
index 0000000000..96303b8781
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png
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
new file mode 100644
index 0000000000..0a4f2e74f3
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png
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
new file mode 100644
index 0000000000..37c9c32506
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/patching.png b/documentation/getting-started/eclipse/html/getting-started/figures/patching.png
new file mode 100644
index 0000000000..8ecd018502
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/patching.png
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
new file mode 100755
index 0000000000..adbe1f4acf
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png b/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png
new file mode 100644
index 0000000000..5c36b7548b
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png
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
new file mode 100644
index 0000000000..26aefb50c2
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png
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
new file mode 100644
index 0000000000..f7515058ef
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png
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
new file mode 100644
index 0000000000..603300b6d2
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png
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
new file mode 100644
index 0000000000..c298401fc3
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png
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
new file mode 100644
index 0000000000..650c6c8030
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png
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
new file mode 100644
index 0000000000..5770be6883
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png
diff --git a/documentation/getting-started/eclipse/html/getting-started/git.html b/documentation/getting-started/eclipse/html/getting-started/git.html
new file mode 100644
index 0000000000..7e652a4efa
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/git.html
@@ -0,0 +1,51 @@
+<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
new file mode 100644
index 0000000000..9f682d082c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html
@@ -0,0 +1,178 @@
+<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
new file mode 100644
index 0000000000..2561f1f4a6
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html
@@ -0,0 +1,99 @@
+<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
new file mode 100644
index 0000000000..94826ce0c6
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/index.html
@@ -0,0 +1,154 @@
+<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
new file mode 100644
index 0000000000..9edb4b92ac
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/index.xml
@@ -0,0 +1,2 @@
+<?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
new file mode 100644
index 0000000000..ef4a2aac5e
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html
@@ -0,0 +1,77 @@
+<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
new file mode 100644
index 0000000000..1e08bafad1
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html
@@ -0,0 +1,126 @@
+<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
new file mode 100644
index 0000000000..ade868705c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/licensing.html
@@ -0,0 +1,91 @@
+<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
new file mode 100644
index 0000000000..9ed618701c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/local-projects.html
@@ -0,0 +1,39 @@
+<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
new file mode 100644
index 0000000000..24f32f394f
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.html
@@ -0,0 +1,93 @@
+<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
new file mode 100644
index 0000000000..ebbae37990
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html
@@ -0,0 +1,74 @@
+<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
new file mode 100644
index 0000000000..bd9467e001
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html
@@ -0,0 +1,54 @@
+<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
new file mode 100644
index 0000000000..73d152bb40
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html
@@ -0,0 +1,59 @@
+<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
new file mode 100644
index 0000000000..974b05792a
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html
@@ -0,0 +1,40 @@
+<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
new file mode 100644
index 0000000000..09ad110f71
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html
@@ -0,0 +1,209 @@
+<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
new file mode 100644
index 0000000000..855d22e109
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html
@@ -0,0 +1,57 @@
+<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
new file mode 100644
index 0000000000..b8b4c880e7
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html
@@ -0,0 +1,28 @@
+<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
new file mode 100644
index 0000000000..c8030fee19
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html
@@ -0,0 +1,56 @@
+<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
new file mode 100644
index 0000000000..eca1f71d2d
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html
@@ -0,0 +1,29 @@
+<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
new file mode 100644
index 0000000000..ab4e1f338f
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html
@@ -0,0 +1,23 @@
+<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
new file mode 100644
index 0000000000..03210c6ebf
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html
@@ -0,0 +1,31 @@
+<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
new file mode 100644
index 0000000000..1bc34e081c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html
@@ -0,0 +1,85 @@
+<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
new file mode 100644
index 0000000000..ad3d67f660
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html
@@ -0,0 +1,98 @@
+<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
new file mode 100644
index 0000000000..882d66c31c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html
@@ -0,0 +1,94 @@
+<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
new file mode 100644
index 0000000000..60ae6b020b
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html
@@ -0,0 +1,48 @@
+<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
new file mode 100644
index 0000000000..fcf46d9d35
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html
@@ -0,0 +1,383 @@
+<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
new file mode 100644
index 0000000000..d813948375
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html
@@ -0,0 +1,173 @@
+<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
new file mode 100644
index 0000000000..b68f574134
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/running-weston.html
@@ -0,0 +1,53 @@
+<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
new file mode 100644
index 0000000000..f2ec54340c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/scms.html
@@ -0,0 +1,42 @@
+<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
new file mode 100644
index 0000000000..d2cd6a480e
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html
@@ -0,0 +1,150 @@
+<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
new file mode 100644
index 0000000000..1dfda5fab5
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html
@@ -0,0 +1,72 @@
+<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
new file mode 100644
index 0000000000..644e404b66
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html
@@ -0,0 +1,122 @@
+<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
new file mode 100644
index 0000000000..c5c6be04a3
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html
@@ -0,0 +1,93 @@
+<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
new file mode 100644
index 0000000000..4389684f3b
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/shared-state.html
@@ -0,0 +1,268 @@
+<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
new file mode 100644
index 0000000000..26e169a281
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/software-layer.html
@@ -0,0 +1,27 @@
+<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
new file mode 100644
index 0000000000..afcdafdc76
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.html
@@ -0,0 +1,93 @@
+<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
new file mode 100644
index 0000000000..178903c96e
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html
@@ -0,0 +1,37 @@
+<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
new file mode 100644
index 0000000000..ab7718074f
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html
@@ -0,0 +1,80 @@
+<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
new file mode 100644
index 0000000000..b649c69b2b
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html
@@ -0,0 +1,83 @@
+<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
new file mode 100644
index 0000000000..d0c8522d95
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html
@@ -0,0 +1,22 @@
+<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
new file mode 100644
index 0000000000..ef9bc18dde
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html
@@ -0,0 +1,25 @@
+<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
new file mode 100644
index 0000000000..6f10791e7a
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/user-configuration.html
@@ -0,0 +1,232 @@
+<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
new file mode 100644
index 0000000000..7e43ebd923
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html
@@ -0,0 +1,76 @@
+<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
new file mode 100644
index 0000000000..39fa32b154
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html
@@ -0,0 +1,82 @@
+<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
new file mode 100644
index 0000000000..809906c999
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html
@@ -0,0 +1,30 @@
+<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
new file mode 100644
index 0000000000..a1ca039c9b
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html
@@ -0,0 +1,27 @@
+<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
new file mode 100644
index 0000000000..b25324502e
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html
@@ -0,0 +1,35 @@
+<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
new file mode 100644
index 0000000000..ee59e3bc10
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html
@@ -0,0 +1,24 @@
+<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
new file mode 100644
index 0000000000..ed9a3cc501
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html
@@ -0,0 +1,82 @@
+<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
new file mode 100644
index 0000000000..da810a4439
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/wayland-support.html
@@ -0,0 +1,46 @@
+<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
new file mode 100644
index 0000000000..0747c9238c
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/wayland.html
@@ -0,0 +1,34 @@
+<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
new file mode 100644
index 0000000000..9d53975678
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/workflows.html
@@ -0,0 +1,207 @@
+<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
new file mode 100644
index 0000000000..daffedbeea
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/x32.html
@@ -0,0 +1,75 @@
+<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
new file mode 100644
index 0000000000..0ad63b2402
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html
@@ -0,0 +1,62 @@
+<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
new file mode 100644
index 0000000000..3dcc2af5eb
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html
@@ -0,0 +1,135 @@
+<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
new file mode 100644
index 0000000000..42ad0d3088
--- /dev/null
+++ b/documentation/getting-started/eclipse/html/getting-started/yp-intro.html
@@ -0,0 +1,119 @@
+<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>