sphinx: initial sphinx support

This commit is autogenerated pandoc to generate an inital set
of reST files based on DocBook XML files.

A .rst file is generated for each .xml files in all manuals with this
command:

cd <manual>
for i in *.xml; do \
  pandoc -f docbook -t rst --shift-heading-level-by=-1 \
  $i -o $(basename $i .xml).rst \
done

The conversion was done with: pandoc 2.9.2.1-91 (Arch Linux).

Also created an initial top level index file for each document, and
added all 'books' to the top leve index.rst file.

The YP manuals layout is organized as:

Book
  Chapter
    Section
      Section
        Section

Sphinx uses section headers to create the document structure.
ReStructuredText defines sections headers like that:

   To break longer text up into sections, you use section headers. These
   are a single line of text (one or more words) with adornment: an
   underline alone, or an underline and an overline together, in dashes
   "-----", equals "======", tildes "~~~~~~" or any of the
   non-alphanumeric characters = - ` : ' " ~ ^ _ * + # < > that you feel
   comfortable with. An underline-only adornment is distinct from an
   overline-and-underline adornment using the same character. The
   underline/overline must be at least as long as the title text. Be
   consistent, since all sections marked with the same adornment style
   are deemed to be at the same level:

Let's define the following convention when converting from Docbook:

Book                => overline ===   (Title)
  Chapter           => overline ***   (1.)
    Section         => ====           (1.1)
      Section       => ----           (1.1.1)
        Section     => ~~~~           (1.1.1.1)
          Section   => ^^^^           (1.1.1.1.1)

During the conversion with pandoc, we used --shift-heading-level=-1 to
convert most of DocBook headings automatically. However with this
setting, the Chapter header was removed, so I added it back
manually. Without this setting all headings were off by one, which was
more difficult to manually fix.

At least with this change, we now have the same TOC with Sphinx and
DocBook.

(From yocto-docs rev: 3c73d64a476d4423ee4c6808c685fa94d88d7df8)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 941 insertions, 0 deletions

diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
new file mode 100644
index 0000000000..62257c26b9
--- /dev/null
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -0,0 +1,941 @@
+*****************************
+Introducing the Yocto Project
+*****************************
+
+What is the Yocto Project?
+==========================
+
+The Yocto Project is an open source collaboration project that helps
+developers create custom Linux-based systems that are designed for
+embedded products regardless of the product's hardware architecture.
+Yocto Project provides a flexible toolset and a development environment
+that allows embedded device developers across the world to collaborate
+through shared technologies, software stacks, configurations, and best
+practices used to create these tailored Linux images.
+
+Thousands of developers worldwide have discovered that Yocto Project
+provides advantages in both systems and applications development,
+archival and management benefits, and customizations used for speed,
+footprint, and memory utilization. The project is a standard when it
+comes to delivering embedded software stacks. The project allows
+software customizations and build interchange for multiple hardware
+platforms as well as software stacks that can be maintained and scaled.
+
+For further introductory information on the Yocto Project, you might be
+interested in this
+`article <https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project->`__
+by Drew Moseley and in this short introductory
+`video <https://www.youtube.com/watch?v=utZpKM7i5Z4>`__.
+
+The remainder of this section overviews advantages and challenges tied
+to the Yocto Project.
+
+.. _gs-features:
+
+Features
+--------
+
+The following list describes features and advantages of the Yocto
+Project:
+
+-  *Widely Adopted Across the Industry:* Semiconductor, operating
+   system, software, and service vendors exist whose products and
+   services adopt and support the Yocto Project. For a look at the Yocto
+   Project community and the companies involved with the Yocto Project,
+   see the "COMMUNITY" and "ECOSYSTEM" tabs on the `Yocto
+   Project <&YOCTO_HOME_URL;>`__ home page.
+
+-  *Architecture Agnostic:* Yocto Project supports Intel, ARM, MIPS,
+   AMD, PPC and other architectures. Most ODMs, OSVs, and chip vendors
+   create and supply BSPs that support their hardware. If you have
+   custom silicon, you can create a BSP that supports that architecture.
+
+   Aside from lots of architecture support, the Yocto Project fully
+   supports a wide range of device emulation through the Quick EMUlator
+   (QEMU).
+
+-  *Images and Code Transfer Easily:* Yocto Project output can easily
+   move between architectures without moving to new development
+   environments. Additionally, if you have used the Yocto Project to
+   create an image or application and you find yourself not able to
+   support it, commercial Linux vendors such as Wind River, Mentor
+   Graphics, Timesys, and ENEA could take it and provide ongoing
+   support. These vendors have offerings that are built using the Yocto
+   Project.
+
+-  *Flexibility:* Corporations use the Yocto Project many different
+   ways. One example is to create an internal Linux distribution as a
+   code base the corporation can use across multiple product groups.
+   Through customization and layering, a project group can leverage the
+   base Linux distribution to create a distribution that works for their
+   product needs.
+
+-  *Ideal for Constrained Embedded and IoT devices:* Unlike a full Linux
+   distribution, you can use the Yocto Project to create exactly what
+   you need for embedded devices. You only add the feature support or
+   packages that you absolutely need for the device. For devices that
+   have display hardware, you can use available system components such
+   as X11, GTK+, Qt, Clutter, and SDL (among others) to create a rich
+   user experience. For devices that do not have a display or where you
+   want to use alternative UI frameworks, you can choose to not install
+   these components.
+
+-  *Comprehensive Toolchain Capabilities:* Toolchains for supported
+   architectures satisfy most use cases. However, if your hardware
+   supports features that are not part of a standard toolchain, you can
+   easily customize that toolchain through specification of
+   platform-specific tuning parameters. And, should you need to use a
+   third-party toolchain, mechanisms built into the Yocto Project allow
+   for that.
+
+-  *Mechanism Rules Over Policy:* Focusing on mechanism rather than
+   policy ensures that you are free to set policies based on the needs
+   of your design instead of adopting decisions enforced by some system
+   software provider.
+
+-  *Uses a Layer Model:* The Yocto Project `layer
+   infrastructure <#the-yocto-project-layer-model>`__ groups related
+   functionality into separate bundles. You can incrementally add these
+   grouped functionalities to your project as needed. Using layers to
+   isolate and group functionality reduces project complexity and
+   redundancy, allows you to easily extend the system, make
+   customizations, and keep functionality organized.
+
+-  *Supports Partial Builds:* You can build and rebuild individual
+   packages as needed. Yocto Project accomplishes this through its
+   `shared-state cache <#shared-state-cache>`__ (sstate) scheme. Being
+   able to build and debug components individually eases project
+   development.
+
+-  *Releases According to a Strict Schedule:* Major releases occur on a
+   `six-month cycle <&YOCTO_DOCS_REF_URL;#ref-release-process>`__
+   predictably in October and April. The most recent two releases
+   support point releases to address common vulnerabilities and
+   exposures. This predictability is crucial for projects based on the
+   Yocto Project and allows development teams to plan activities.
+
+-  *Rich Ecosystem of Individuals and Organizations:* For open source
+   projects, the value of community is very important. Support forums,
+   expertise, and active developers who continue to push the Yocto
+   Project forward are readily available.
+
+-  *Binary Reproducibility:* The Yocto Project allows you to be very
+   specific about dependencies and achieves very high percentages of
+   binary reproducibility (e.g. 99.8% for ``core-image-minimal``). When
+   distributions are not specific about which packages are pulled in and
+   in what order to support dependencies, other build systems can
+   arbitrarily include packages.
+
+-  *License Manifest:* The Yocto Project provides a `license
+   manifest <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__
+   for review by people who need to track the use of open source
+   licenses (e.g.legal teams).
+
+.. _gs-challenges:
+
+Challenges
+----------
+
+The following list presents challenges you might encounter when
+developing using the Yocto Project:
+
+-  *Steep Learning Curve:* The Yocto Project has a steep learning curve
+   and has many different ways to accomplish similar tasks. It can be
+   difficult to choose how to proceed when varying methods exist by
+   which to accomplish a given task.
+
+-  *Understanding What Changes You Need to Make For Your Design Requires
+   Some Research:* Beyond the simple tutorial stage, understanding what
+   changes need to be made for your particular design can require a
+   significant amount of research and investigation. For information
+   that helps you transition from trying out the Yocto Project to using
+   it for your project, see the "`What I wish I'd
+   Known <&YOCTO_DOCS_URL;/what-i-wish-id-known/>`__" and
+   "`Transitioning to a Custom Environment for Systems
+   Development <&YOCTO_DOCS_URL;/transitioning-to-a-custom-environment/>`__"
+   documents on the Yocto Project website.
+
+-  *Project Workflow Could Be Confusing:* The `Yocto Project
+   workflow <#overview-development-environment>`__ could be confusing if
+   you are used to traditional desktop and server software development.
+   In a desktop development environment, mechanisms exist to easily pull
+   and install new packages, which are typically pre-compiled binaries
+   from servers accessible over the Internet. Using the Yocto Project,
+   you must modify your configuration and rebuild to add additional
+   packages.
+
+-  *Working in a Cross-Build Environment Can Feel Unfamiliar:* When
+   developing code to run on a target, compilation, execution, and
+   testing done on the actual target can be faster than running a
+   BitBake build on a development host and then deploying binaries to
+   the target for test. While the Yocto Project does support development
+   tools on the target, the additional step of integrating your changes
+   back into the Yocto Project build environment would be required.
+   Yocto Project supports an intermediate approach that involves making
+   changes on the development system within the BitBake environment and
+   then deploying only the updated packages to the target.
+
+   The Yocto Project `OpenEmbedded build
+   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ produces packages
+   in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy
+   these packages into the running system on the target by using
+   utilities on the target such as ``rpm`` or ``ipk``.
+
+-  *Initial Build Times Can be Significant:* Long initial build times
+   are unfortunately unavoidable due to the large number of packages
+   initially built from scratch for a fully functioning Linux system.
+   Once that initial build is completed, however, the shared-state
+   (sstate) cache mechanism Yocto Project uses keeps the system from
+   rebuilding packages that have not been "touched" since the last
+   build. The sstate mechanism significantly reduces times for
+   successive builds.
+
+The Yocto Project Layer Model
+=============================
+
+The Yocto Project's "Layer Model" is a development model for embedded
+and IoT Linux creation that distinguishes the Yocto Project from other
+simple build systems. The Layer Model simultaneously supports
+collaboration and customization. Layers are repositories that contain
+related sets of instructions that tell the `OpenEmbedded build
+system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to do. You can
+collaborate, share, and reuse layers.
+
+Layers can contain changes to previous instructions or settings at any
+time. This powerful override capability is what allows you to customize
+previously supplied collaborative or community layers to suit your
+product requirements.
+
+You use different layers to logically separate information in your
+build. As an example, you could have BSP, GUI, distro configuration,
+middleware, or application layers. Putting your entire build into one
+layer limits and complicates future customization and reuse. Isolating
+information into layers, on the other hand, helps simplify future
+customizations and reuse. You might find it tempting to keep everything
+in one layer when working on a single project. However, the more modular
+your Metadata, the easier it is to cope with future changes.
+
+.. note::
+
+   -  Use Board Support Package (BSP) layers from silicon vendors when
+      possible.
+
+   -  Familiarize yourself with the `Yocto Project curated layer
+      index <https://caffelli-staging.yoctoproject.org/software-overview/layers/>`__
+      or the `OpenEmbedded layer
+      index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__.
+      The latter contains more layers but they are less universally
+      validated.
+
+   -  Layers support the inclusion of technologies, hardware components,
+      and software components. The `Yocto Project
+      Compatible <&YOCTO_DOCS_DEV_URL;#making-sure-your-layer-is-compatible-with-yocto-project>`__
+      designation provides a minimum level of standardization that
+      contributes to a strong ecosystem. "YP Compatible" is applied to
+      appropriate products and software components such as BSPs, other
+      OE-compatible layers, and related open-source projects, allowing
+      the producer to use Yocto Project badges and branding assets.
+
+To illustrate how layers are used to keep things modular, consider
+machine customizations. These types of customizations typically reside
+in a special layer, rather than a general layer, called a BSP Layer.
+Furthermore, the machine customizations should be isolated from recipes
+and Metadata that support a new GUI environment, for example. This
+situation gives you a couple of layers: one for the machine
+configurations, and one for the GUI environment. It is important to
+understand, however, that the BSP layer can still make machine-specific
+additions to recipes within the GUI environment layer without polluting
+the GUI layer itself with those machine-specific changes. You can
+accomplish this through a recipe that is a BitBake append
+(``.bbappend``) file, which is described later in this section.
+
+.. note::
+
+   For general information on BSP layer structure, see the
+   Yocto Project Board Support Packages (BSP) Developer's Guide
+   .
+
+The `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__
+contains both general layers and BSP layers right out of the box. You
+can easily identify layers that ship with a Yocto Project release in the
+Source Directory by their names. Layers typically have names that begin
+with the string ``meta-``.
+
+.. note::
+
+   It is not a requirement that a layer name begin with the prefix
+   meta-
+   , but it is a commonly accepted standard in the Yocto Project
+   community.
+
+For example, if you were to examine the `tree
+view <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/>`__ of the
+``poky`` repository, you will see several layers: ``meta``,
+``meta-skeleton``, ``meta-selftest``, ``meta-poky``, and
+``meta-yocto-bsp``. Each of these repositories represents a distinct
+layer.
+
+For procedures on how to create layers, see the "`Understanding and
+Creating
+Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__"
+section in the Yocto Project Development Tasks Manual.
+
+Components and Tools
+====================
+
+The Yocto Project employs a collection of components and tools used by
+the project itself, by project developers, and by those using the Yocto
+Project. These components and tools are open source projects and
+metadata that are separate from the reference distribution
+(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the `OpenEmbedded build
+system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. Most of the
+components and tools are downloaded separately.
+
+This section provides brief overviews of the components and tools
+associated with the Yocto Project.
+
+.. _gs-development-tools:
+
+Development Tools
+-----------------
+
+The following list consists of tools that help you develop images and
+applications using the Yocto Project:
+
+-  *CROPS:* `CROPS <https://github.com/crops/poky-container/>`__ is an
+   open source, cross-platform development framework that leverages
+   `Docker Containers <https://www.docker.com/>`__. CROPS provides an
+   easily managed, extensible environment that allows you to build
+   binaries for a variety of architectures on Windows, Linux and Mac OS
+   X hosts.
+
+-  *``devtool``:* This command-line tool is available as part of the
+   extensible SDK (eSDK) and is its cornerstone. You can use ``devtool``
+   to help build, test, and package software within the eSDK. You can
+   use the tool to optionally integrate what you build into an image
+   built by the OpenEmbedded build system.
+
+   The ``devtool`` command employs a number of sub-commands that allow
+   you to add, modify, and upgrade recipes. As with the OpenEmbedded
+   build system, “recipes” represent software packages within
+   ``devtool``. When you use ``devtool add``, a recipe is automatically
+   created. When you use ``devtool modify``, the specified existing
+   recipe is used in order to determine where to get the source code and
+   how to patch it. In both cases, an environment is set up so that when
+   you build the recipe a source tree that is under your control is used
+   in order to allow you to make changes to the source as desired. By
+   default, both new recipes and the source go into a “workspace”
+   directory under the eSDK. The ``devtool upgrade`` command updates an
+   existing recipe so that you can build it for an updated set of source
+   files.
+
+   You can read about the ``devtool`` workflow in the Yocto Project
+   Application Development and Extensible Software Development Kit
+   (eSDK) Manual in the "`Using ``devtool`` in Your SDK
+   Workflow' <&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow>`__"
+   section.
+
+-  *Extensible Software Development Kit (eSDK):* The eSDK provides a
+   cross-development toolchain and libraries tailored to the contents of
+   a specific image. The eSDK makes it easy to add new applications and
+   libraries to an image, modify the source for an existing component,
+   test changes on the target hardware, and integrate into the rest of
+   the OpenEmbedded build system. The eSDK gives you a toolchain
+   experience supplemented with the powerful set of ``devtool`` commands
+   tailored for the Yocto Project environment.
+
+   For information on the eSDK, see the `Yocto Project Application
+   Development and the Extensible Software Development Kit
+   (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ Manual.
+
+-  *Toaster:* Toaster is a web interface to the Yocto Project
+   OpenEmbedded build system. Toaster allows you to configure, run, and
+   view information about builds. For information on Toaster, see the
+   `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__.
+
+.. _gs-production-tools:
+
+Production Tools
+----------------
+
+The following list consists of tools that help production related
+activities using the Yocto Project:
+
+-  *Auto Upgrade Helper:* This utility when used in conjunction with the
+   `OpenEmbedded build
+   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ (BitBake and
+   OE-Core) automatically generates upgrades for recipes that are based
+   on new versions of the recipes published upstream.
+
+-  *Recipe Reporting System:* The Recipe Reporting System tracks recipe
+   versions available for Yocto Project. The main purpose of the system
+   is to help you manage the recipes you maintain and to offer a dynamic
+   overview of the project. The Recipe Reporting System is built on top
+   of the `OpenEmbedded Layer
+   Index <http://layers.openembedded.org/layerindex/layers/>`__, which
+   is a website that indexes OpenEmbedded-Core layers.
+
+-  *Patchwork:* `Patchwork <http://jk.ozlabs.org/projects/patchwork/>`__
+   is a fork of a project originally started by
+   `OzLabs <http://ozlabs.org/>`__. The project is a web-based tracking
+   system designed to streamline the process of bringing contributions
+   into a project. The Yocto Project uses Patchwork as an organizational
+   tool to handle patches, which number in the thousands for every
+   release.
+
+-  *AutoBuilder:* AutoBuilder is a project that automates build tests
+   and quality assurance (QA). By using the public AutoBuilder, anyone
+   can determine the status of the current "master" branch of Poky.
+
+   .. note::
+
+      AutoBuilder is based on
+      buildbot
+      .
+
+   A goal of the Yocto Project is to lead the open source industry with
+   a project that automates testing and QA procedures. In doing so, the
+   project encourages a development community that publishes QA and test
+   plans, publicly demonstrates QA and test plans, and encourages
+   development of tools that automate and test and QA procedures for the
+   benefit of the development community.
+
+   You can learn more about the AutoBuilder used by the Yocto Project
+   `here <&YOCTO_AB_URL;>`__.
+
+-  *Cross-Prelink:* Prelinking is the process of pre-computing the load
+   addresses and link tables generated by the dynamic linker as compared
+   to doing this at runtime. Doing this ahead of time results in
+   performance improvements when the application is launched and reduced
+   memory usage for libraries shared by many applications.
+
+   Historically, cross-prelink is a variant of prelink, which was
+   conceived by `Jakub
+   Jelínek <http://people.redhat.com/jakub/prelink.pdf>`__ a number of
+   years ago. Both prelink and cross-prelink are maintained in the same
+   repository albeit on separate branches. By providing an emulated
+   runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation),
+   the cross-prelink project extends the prelink software’s ability to
+   prelink a sysroot environment. Additionally, the cross-prelink
+   software enables the ability to work in sysroot style environments.
+
+   The dynamic linker determines standard load address calculations
+   based on a variety of factors such as mapping addresses, library
+   usage, and library function conflicts. The prelink tool uses this
+   information, from the dynamic linker, to determine unique load
+   addresses for executable and linkable format (ELF) binaries that are
+   shared libraries and dynamically linked. The prelink tool modifies
+   these ELF binaries with the pre-computed information. The result is
+   faster loading and often lower memory consumption because more of the
+   library code can be re-used from shared Copy-On-Write (COW) pages.
+
+   The original upstream prelink project only supports running prelink
+   on the end target device due to the reliance on the target device’s
+   dynamic linker. This restriction causes issues when developing a
+   cross-compiled system. The cross-prelink adds a synthesized dynamic
+   loader that runs on the host, thus permitting cross-prelinking
+   without ever having to run on a read-write target filesystem.
+
+-  *Pseudo:* Pseudo is the Yocto Project implementation of
+   `fakeroot <http://man.he.net/man1/fakeroot>`__, which is used to run
+   commands in an environment that seemingly has root privileges.
+
+   During a build, it can be necessary to perform operations that
+   require system administrator privileges. For example, file ownership
+   or permissions might need definition. Pseudo is a tool that you can
+   either use directly or through the environment variable
+   ``LD_PRELOAD``. Either method allows these operations to succeed as
+   if system administrator privileges exist even when they do not.
+
+   You can read more about Pseudo in the "`Fakeroot and
+   Pseudo <#fakeroot-and-pseudo>`__" section.
+
+.. _gs-openembedded-build-system:
+
+Open-Embedded Build System Components
+-------------------------------------
+
+The following list consists of components associated with the
+`OpenEmbedded build system <&YOCTO_DOCS_REF_URL;#build-system-term>`__:
+
+-  *BitBake:* BitBake is a core component of the Yocto Project and is
+   used by the OpenEmbedded build system to build images. While BitBake
+   is key to the build system, BitBake is maintained separately from the
+   Yocto Project.
+
+   BitBake is a generic task execution engine that allows shell and
+   Python tasks to be run efficiently and in parallel while working
+   within complex inter-task dependency constraints. In short, BitBake
+   is a build engine that works through recipes written in a specific
+   format in order to perform sets of tasks.
+
+   You can learn more about BitBake in the `BitBake User
+   Manual <&YOCTO_DOCS_BB_URL;>`__.
+
+-  *OpenEmbedded-Core:* OpenEmbedded-Core (OE-Core) is a common layer of
+   metadata (i.e. recipes, classes, and associated files) used by
+   OpenEmbedded-derived systems, which includes the Yocto Project. The
+   Yocto Project and the OpenEmbedded Project both maintain the
+   OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto
+   Project `Source
+   Repositories <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta>`__.
+
+   Historically, the Yocto Project integrated the OE-Core metadata
+   throughout the Yocto Project source repository reference system
+   (Poky). After Yocto Project Version 1.0, the Yocto Project and
+   OpenEmbedded agreed to work together and share a common core set of
+   metadata (OE-Core), which contained much of the functionality
+   previously found in Poky. This collaboration achieved a long-standing
+   OpenEmbedded objective for having a more tightly controlled and
+   quality-assured core. The results also fit well with the Yocto
+   Project objective of achieving a smaller number of fully featured
+   tools as compared to many different ones.
+
+   Sharing a core set of metadata results in Poky as an integration
+   layer on top of OE-Core. You can see that in this
+   `figure <#yp-key-dev-elements>`__. The Yocto Project combines various
+   components such as BitBake, OE-Core, script “glue”, and documentation
+   for its build system.
+
+.. _gs-reference-distribution-poky:
+
+Reference Distribution (Poky)
+-----------------------------
+
+Poky is the Yocto Project reference distribution. It contains the
+`Open-Embedded build system <&YOCTO_DOCS_REF_URL;#build-system-term>`__
+(BitBake and OE-Core) as well as a set of metadata to get you started
+building your own distribution. See the
+`figure <#what-is-the-yocto-project>`__ in "What is the Yocto Project?"
+section for an illustration that shows Poky and its relationship with
+other parts of the Yocto Project.
+
+To use the Yocto Project tools and components, you can download
+(``clone``) Poky and use it to bootstrap your own distribution.
+
+.. note::
+
+   Poky does not contain binary files. It is a working example of how to
+   build your own custom Linux distribution from source.
+
+You can read more about Poky in the "`Reference Embedded Distribution
+(Poky) <#reference-embedded-distribution>`__" section.
+
+.. _gs-packages-for-finished-targets:
+
+Packages for Finished Targets
+-----------------------------
+
+The following lists components associated with packages for finished
+targets:
+
+-  *Matchbox:* Matchbox is an Open Source, base environment for the X
+   Window System running on non-desktop, embedded platforms such as
+   handhelds, set-top boxes, kiosks, and anything else for which screen
+   space, input mechanisms, or system resources are limited.
+
+   Matchbox consists of a number of interchangeable and optional
+   applications that you can tailor to a specific, non-desktop platform
+   to enhance usability in constrained environments.
+
+   You can find the Matchbox source in the Yocto Project `Source
+   Repositories <&YOCTO_GIT_URL;>`__.
+
+-  *Opkg* Open PacKaGe management (opkg) is a lightweight package
+   management system based on the itsy package (ipkg) management system.
+   Opkg is written in C and resembles Advanced Package Tool (APT) and
+   Debian Package (dpkg) in operation.
+
+   Opkg is intended for use on embedded Linux devices and is used in
+   this capacity in the
+   `OpenEmbedded <http://www.openembedded.org/wiki/Main_Page>`__ and
+   `OpenWrt <https://openwrt.org/>`__ projects, as well as the Yocto
+   Project.
+
+   .. note::
+
+      As best it can, opkg maintains backwards compatibility with ipkg
+      and conforms to a subset of Debian’s policy manual regarding
+      control files.
+
+.. _gs-archived-components:
+
+Archived Components
+-------------------
+
+The Build Appliance is a virtual machine image that enables you to build
+and boot a custom embedded Linux image with the Yocto Project using a
+non-Linux development system.
+
+Historically, the Build Appliance was the second of three methods by
+which you could use the Yocto Project on a system that was not native to
+Linux.
+
+1. *Hob:* Hob, which is now deprecated and is no longer available since
+   the 2.1 release of the Yocto Project provided a rudimentary,
+   GUI-based interface to the Yocto Project. Toaster has fully replaced
+   Hob.
+
+2. *Build Appliance:* Post Hob, the Build Appliance became available. It
+   was never recommended that you use the Build Appliance as a
+   day-to-day production development environment with the Yocto Project.
+   Build Appliance was useful as a way to try out development in the
+   Yocto Project environment.
+
+3. *CROPS:* The final and best solution available now for developing
+   using the Yocto Project on a system not native to Linux is with
+   `CROPS <#gs-crops-overview>`__.
+
+.. _gs-development-methods:
+
+Development Methods
+===================
+
+The Yocto Project development environment usually involves a `Build
+Host <&YOCTO_DOCS_REF_URL;#hardware-build-system-term>`__ and target
+hardware. You use the Build Host to build images and develop
+applications, while you use the target hardware to test deployed
+software.
+
+This section provides an introduction to the choices or development
+methods you have when setting up your Build Host. Depending on the your
+particular workflow preference and the type of operating system your
+Build Host runs, several choices exist that allow you to use the Yocto
+Project.
+
+.. note::
+
+   For additional detail about the Yocto Project development
+   environment, see the "
+   The Yocto Project Development Environment
+   " chapter.
+
+-  *Native Linux Host:* By far the best option for a Build Host. A
+   system running Linux as its native operating system allows you to
+   develop software by directly using the
+   `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ tool. You can
+   accomplish all aspects of development from a familiar shell of a
+   supported Linux distribution.
+
+   For information on how to set up a Build Host on a system running
+   Linux as its native operating system, see the "`Setting Up a Native
+   Linux Host <&YOCTO_DOCS_DEV_URL;#setting-up-a-native-linux-host>`__"
+   section in the Yocto Project Development Tasks Manual.
+
+-  *CROss PlatformS (CROPS):* Typically, you use
+   `CROPS <https://github.com/crops/poky-container/>`__, which leverages
+   `Docker Containers <https://www.docker.com/>`__, to set up a Build
+   Host that is not running Linux (e.g. Microsoft Windows or macOS).
+
+   .. note::
+
+      You can, however, use CROPS on a Linux-based system.
+
+   CROPS is an open source, cross-platform development framework that
+   provides an easily managed, extensible environment for building
+   binaries targeted for a variety of architectures on Windows, macOS,
+   or Linux hosts. Once the Build Host is set up using CROPS, you can
+   prepare a shell environment to mimic that of a shell being used on a
+   system natively running Linux.
+
+   For information on how to set up a Build Host with CROPS, see the
+   "`Setting Up to Use CROss PlatformS
+   (CROPS) <&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops>`__" section in
+   the Yocto Project Development Tasks Manual.
+
+-  *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem
+   For Linux v2 to set up a build host using Windows 10.
+
+   .. note::
+
+      The Yocto Project is not compatible with WSLv1, it is compatible
+      but not officially supported nor validated with WSLv2, if you
+      still decide to use WSL please upgrade to WSLv2.
+
+   The Windows Subsystem For Linux allows Windows 10 to run a real Linux
+   kernel inside of a lightweight utility virtual machine (VM) using
+   virtualization technology.
+
+   For information on how to set up a Build Host with WSLv2, see the
+   "`Setting Up to Use Windows Subsystem For
+   Linux <&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl>`__" section in the
+   Yocto Project Development Tasks Manual.
+
+-  *Toaster:* Regardless of what your Build Host is running, you can use
+   Toaster to develop software using the Yocto Project. Toaster is a web
+   interface to the Yocto Project's `Open-Embedded build
+   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface
+   enables you to configure and run your builds. Information about
+   builds is collected and stored in a database. You can use Toaster to
+   configure and start builds on multiple remote build servers.
+
+   For information about and how to use Toaster, see the `Toaster User
+   Manual <&YOCTO_DOCS_TOAST_URL;>`__.
+
+.. _reference-embedded-distribution:
+
+Reference Embedded Distribution (Poky)
+======================================
+
+"Poky", which is pronounced *Pock*-ee, is the name of the Yocto
+Project's reference distribution or Reference OS Kit. Poky contains the
+`OpenEmbedded Build System <&YOCTO_DOCS_REF_URL;#build-system-term>`__
+(`BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__ and
+`OpenEmbedded-Core <&YOCTO_DOCS_REF_URL;#oe-core>`__) as well as a set
+of `metadata <&YOCTO_DOCS_REF_URL;#metadata>`__ to get you started
+building your own distro. In other words, Poky is a base specification
+of the functionality needed for a typical embedded system as well as the
+components from the Yocto Project that allow you to build a distribution
+into a usable binary image.
+
+Poky is a combined repository of BitBake, OpenEmbedded-Core (which is
+found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation
+provided all together and known to work well together. You can view
+these items that make up the Poky repository in the `Source
+Repositories <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/>`__.
+
+.. note::
+
+   If you are interested in all the contents of the
+   poky
+   Git repository, see the "
+   Top-Level Core Components
+   " section in the Yocto Project Reference Manual.
+
+The following figure illustrates what generally comprises Poky:
+
+-  BitBake is a task executor and scheduler that is the heart of the
+   OpenEmbedded build system.
+
+-  ``meta-poky``, which is Poky-specific metadata.
+
+-  ``meta-yocto-bsp``, which are Yocto Project-specific Board Support
+   Packages (BSPs).
+
+-  OpenEmbedded-Core (OE-Core) metadata, which includes shared
+   configurations, global variable definitions, shared classes,
+   packaging, and recipes. Classes define the encapsulation and
+   inheritance of build logic. Recipes are the logical units of software
+   and images to be built.
+
+-  Documentation, which contains the Yocto Project source files used to
+   make the set of user manuals.
+
+.. note::
+
+   While Poky is a "complete" distribution specification and is tested
+   and put through QA, you cannot use it as a product "out of the box"
+   in its current form.
+
+To use the Yocto Project tools, you can use Git to clone (download) the
+Poky repository then use your local copy of the reference distribution
+to bootstrap your own distribution.
+
+.. note::
+
+   Poky does not contain binary files. It is a working example of how to
+   build your own custom Linux distribution from source.
+
+Poky has a regular, well established, six-month release cycle under its
+own version. Major releases occur at the same time major releases (point
+releases) occur for the Yocto Project, which are typically in the Spring
+and Fall. For more information on the Yocto Project release schedule and
+cadence, see the "`Yocto Project Releases and the Stable Release
+Process <&YOCTO_DOCS_REF_URL;#ref-release-process>`__" chapter in the
+Yocto Project Reference Manual.
+
+Much has been said about Poky being a "default configuration." A default
+configuration provides a starting image footprint. You can use Poky out
+of the box to create an image ranging from a shell-accessible minimal
+image all the way up to a Linux Standard Base-compliant image that uses
+a GNOME Mobile and Embedded (GMAE) based reference user interface called
+Sato.
+
+One of the most powerful properties of Poky is that every aspect of a
+build is controlled by the metadata. You can use metadata to augment
+these base image types by adding metadata
+`layers <#the-yocto-project-layer-model>`__ that extend functionality.
+These layers can provide, for example, an additional software stack for
+an image type, add a board support package (BSP) for additional
+hardware, or even create a new image type.
+
+Metadata is loosely grouped into configuration files or package recipes.
+A recipe is a collection of non-executable metadata used by BitBake to
+set variables or define additional build-time tasks. A recipe contains
+fields such as the recipe description, the recipe version, the license
+of the package and the upstream source repository. A recipe might also
+indicate that the build process uses autotools, make, distutils or any
+other build process, in which case the basic functionality can be
+defined by the classes it inherits from the OE-Core layer's class
+definitions in ``./meta/classes``. Within a recipe you can also define
+additional tasks as well as task prerequisites. Recipe syntax through
+BitBake also supports both ``_prepend`` and ``_append`` operators as a
+method of extending task functionality. These operators inject code into
+the beginning or end of a task. For information on these BitBake
+operators, see the "`Appending and Prepending (Override Style
+Syntax) <&YOCTO_DOCS_BB_URL;#appending-and-prepending-override-style-syntax>`__"
+section in the BitBake User's Manual.
+
+.. _openembedded-build-system-workflow:
+
+The OpenEmbedded Build System Workflow
+======================================
+
+The `OpenEmbedded build
+system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to
+accomplish image and SDK generation. The following figure overviews that
+workflow: Following is a brief summary of the "workflow":
+
+1. Developers specify architecture, policies, patches and configuration
+   details.
+
+2. The build system fetches and downloads the source code from the
+   specified location. The build system supports standard methods such
+   as tarballs or source code repositories systems such as Git.
+
+3. Once source code is downloaded, the build system extracts the sources
+   into a local work area where patches are applied and common steps for
+   configuring and compiling the software are run.
+
+4. The build system then installs the software into a temporary staging
+   area where the binary package format you select (DEB, RPM, or IPK) is
+   used to roll up the software.
+
+5. Different QA and sanity checks run throughout entire build process.
+
+6. After the binaries are created, the build system generates a binary
+   package feed that is used to create the final root file image.
+
+7. The build system generates the file system image and a customized
+   Extensible SDK (eSDK) for application development in parallel.
+
+For a very detailed look at this workflow, see the "`OpenEmbedded Build
+System Concepts <#openembedded-build-system-build-concepts>`__" section.
+
+Some Basic Terms
+================
+
+It helps to understand some basic fundamental terms when learning the
+Yocto Project. Although a list of terms exists in the "`Yocto Project
+Terms <&YOCTO_DOCS_REF_URL;#ref-terms>`__" section of the Yocto Project
+Reference Manual, this section provides the definitions of some terms
+helpful for getting started:
+
+-  *Configuration Files:* Files that hold global definitions of
+   variables, user-defined variables, and hardware configuration
+   information. These files tell the `Open-Embedded build
+   system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to build and
+   what to put into the image to support a particular platform.
+
+-  *Extensible Software Development Kit (eSDK):* A custom SDK for
+   application developers. This eSDK allows developers to incorporate
+   their library and programming changes back into the image to make
+   their code available to other application developers. For information
+   on the eSDK, see the `Yocto Project Application Development and the
+   Extensible Software Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__
+   manual.
+
+-  *Layer:* A collection of related recipes. Layers allow you to
+   consolidate related metadata to customize your build. Layers also
+   isolate information used when building for multiple architectures.
+   Layers are hierarchical in their ability to override previous
+   specifications. You can include any number of available layers from
+   the Yocto Project and customize the build by adding your layers after
+   them. You can search the Layer Index for layers used within Yocto
+   Project.
+
+   For more detailed information on layers, see the "`Understanding and
+   Creating
+   Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__"
+   section in the Yocto Project Development Tasks Manual. For a
+   discussion specifically on BSP Layers, see the "`BSP
+   Layers <&YOCTO_DOCS_BSP_URL;#bsp-layers>`__" section in the Yocto
+   Project Board Support Packages (BSP) Developer's Guide.
+
+-  *Metadata:* A key element of the Yocto Project is the Metadata that
+   is used to construct a Linux distribution and is contained in the
+   files that the OpenEmbedded build system parses when building an
+   image. In general, Metadata includes recipes, configuration files,
+   and other information that refers to the build instructions
+   themselves, as well as the data used to control what things get built
+   and the effects of the build. Metadata also includes commands and
+   data used to indicate what versions of software are used, from where
+   they are obtained, and changes or additions to the software itself
+   (patches or auxiliary files) that are used to fix bugs or customize
+   the software for use in a particular situation. OpenEmbedded-Core is
+   an important set of validated metadata.
+
+-  *OpenEmbedded Build System:* The terms "BitBake" and "build system"
+   are sometimes used for the OpenEmbedded Build System.
+
+   BitBake is a task scheduler and execution engine that parses
+   instructions (i.e. recipes) and configuration data. After a parsing
+   phase, BitBake creates a dependency tree to order the compilation,
+   schedules the compilation of the included code, and finally executes
+   the building of the specified custom Linux image (distribution).
+   BitBake is similar to the ``make`` tool.
+
+   During a build process, the build system tracks dependencies and
+   performs a native or cross-compilation of the package. As a first
+   step in a cross-build setup, the framework attempts to create a
+   cross-compiler toolchain (i.e. Extensible SDK) suited for the target
+   platform.
+
+-  *OpenEmbedded-Core (OE-Core):* OE-Core is metadata comprised of
+   foundation recipes, classes, and associated files that are meant to
+   be common among many different OpenEmbedded-derived systems,
+   including the Yocto Project. OE-Core is a curated subset of an
+   original repository developed by the OpenEmbedded community that has
+   been pared down into a smaller, core set of continuously validated
+   recipes. The result is a tightly controlled and quality-assured core
+   set of recipes.
+
+   You can see the Metadata in the ``meta`` directory of the Yocto
+   Project `Source
+   Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__.
+
+-  *Packages:* In the context of the Yocto Project, this term refers to
+   a recipe's packaged output produced by BitBake (i.e. a "baked
+   recipe"). A package is generally the compiled binaries produced from
+   the recipe's sources. You "bake" something by running it through
+   BitBake.
+
+   It is worth noting that the term "package" can, in general, have
+   subtle meanings. For example, the packages referred to in the
+   "`Required Packages for the Build
+   Host <&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host>`__"
+   section in the Yocto Project Reference Manual are compiled binaries
+   that, when installed, add functionality to your Linux distribution.
+
+   Another point worth noting is that historically within the Yocto
+   Project, recipes were referred to as packages - thus, the existence
+   of several BitBake variables that are seemingly mis-named, (e.g.
+   ```PR`` <&YOCTO_DOCS_REF_URL;#var-PR>`__,
+   ```PV`` <&YOCTO_DOCS_REF_URL;#var-PV>`__, and
+   ```PE`` <&YOCTO_DOCS_REF_URL;#var-PE>`__).
+
+-  *Poky:* Poky is a reference embedded distribution and a reference
+   test configuration. Poky provides the following:
+
+   -  A base-level functional distro used to illustrate how to customize
+      a distribution.
+
+   -  A means by which to test the Yocto Project components (i.e. Poky
+      is used to validate the Yocto Project).
+
+   -  A vehicle through which you can download the Yocto Project.
+
+   Poky is not a product level distro. Rather, it is a good starting
+   point for customization.
+
+   .. note::
+
+      Poky is an integration layer on top of OE-Core.
+
+-  *Recipe:* The most common form of metadata. A recipe contains a list
+   of settings and tasks (i.e. instructions) for building packages that
+   are then used to build the binary image. A recipe describes where you
+   get source code and which patches to apply. Recipes describe
+   dependencies for libraries or for other recipes as well as
+   configuration and compilation options. Related recipes are
+   consolidated into a layer.