<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->

<chapter id='overview-yp'>
    <title>Introducing the Yocto Project</title>

    <section id='what-is-the-yocto-project'>
        <title>What is the Yocto Project?</title>

        <para>
            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.
        </para>

        <para>
            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.
        </para>

        <para id='yp-key-dev-elements'>
                <imagedata fileref="figures/key-dev-elements.png" format="PNG" align='center' width="8in"/>
        </para>

        <para>
            For further introductory information on the Yocto Project, you
            might be interested in this
            <ulink url='https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project-'>article</ulink>
            by Drew Moseley and in this short introductory
            <ulink url='https://www.youtube.com/watch?v=utZpKM7i5Z4'>video</ulink>.
        </para>

        <para>
            The remainder of this section overviews advantages and challenges
            tied to the Yocto Project.
        </para>

        <section id='gs-features'>
            <title>Features</title>

            <para>
                The following list describes features and advantages of the
                Yocto Project:
                <itemizedlist>
                    <listitem><para>
                        <emphasis>Widely Adopted Across the Industry:</emphasis>
                        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
                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink>
                        home page.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Architecture Agnostic:</emphasis>
                        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.</para>

                        <para>Aside from lots of architecture support, the
                        Yocto Project fully supports a wide range of device
                        emulation through the Quick EMUlator (QEMU).
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Images and Code Transfer Easily:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Flexibility:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Ideal for Constrained Embedded and IoT devices:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Comprehensive Toolchain Capabilities:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Mechanism Rules Over Policy:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Uses a Layer Model:</emphasis>
                        The Yocto Project
                        <link linkend='the-yocto-project-layer-model'>layer infrastructure</link>
                        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.
                        </para></listitem>
                     <listitem><para>
                        <emphasis>Supports Partial Builds:</emphasis>
                        You can build and rebuild individual packages as
                        needed.
                        Yocto Project accomplishes this through its
                        <link linkend='shared-state-cache'>shared-state cache</link>
                        (sstate) scheme.
                        Being able to build and debug components individually
                        eases project development.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Releases According to a Strict Schedule:</emphasis>
                        Major releases occur on a
                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>six-month cycle</ulink>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Rich Ecosystem of Individuals and Organizations:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Binary Reproducibility:</emphasis>
                        The Yocto Project allows you to be very specific about
                        dependencies and achieves very high percentages of
                        binary reproducibility (e.g. 99.8% for
                        <filename>core-image-minimal</filename>).
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>License Manifest:</emphasis>
                        The Yocto Project provides a
                        <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>license manifest</ulink>
                        for review by people who need to track the use of open
                        source licenses (e.g.legal teams).
                        </para></listitem>
                </itemizedlist>
            </para>
        </section>

        <section id='gs-challenges'>
            <title>Challenges</title>

            <para>
                The following list presents challenges you might encounter
                when developing using the Yocto Project:
                <itemizedlist>
                    <listitem><para>
                        <emphasis>Steep Learning Curve:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Understanding What Changes You Need to Make
                        For Your Design Requires Some Research:</emphasis>
                        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
                        "<ulink url='&YOCTO_DOCS_URL;/what-i-wish-id-known/'>What I wish I'd Known</ulink>"
                        and
                        "<ulink url='&YOCTO_DOCS_URL;/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>"
                        documents on the Yocto Project website.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Project Workflow Could Be Confusing:</emphasis>
                        The
                        <link linkend='overview-development-environment'>Yocto Project workflow</link>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Working in a Cross-Build Environment Can
                        Feel Unfamiliar:</emphasis>
                        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.</para>

                        <para>The Yocto Project
                        <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
                        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 <filename>rpm</filename> or
                        <filename>ipk</filename>.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Initial Build Times Can be Significant:</emphasis>
                        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.
                        </para></listitem>
                </itemizedlist>
            </para>
        </section>
    </section>

    <section id='the-yocto-project-layer-model'>
        <title>The Yocto Project Layer Model</title>

        <para>
            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
            <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
            what to do.
            You can collaborate, share, and reuse layers.
        </para>

        <para>
            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.
        </para>

        <para>
            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><title>Notes</title>
                <itemizedlist>
                    <listitem><para>
                        Use Board Support Package (BSP) layers from silicon
                        vendors when possible.
                        </para></listitem>
                    <listitem><para>
                        Familiarize yourself with the
                        <ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project curated layer index</ulink>
                        or the
                        <ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded layer index</ulink>.
                        The latter contains more layers but they are less
                        universally validated.
                        </para></listitem>
                    <listitem><para>
                        Layers support the inclusion of technologies, hardware
                        components, and software components.
                        The
                        <ulink url='&YOCTO_DOCS_DEV_URL;#making-sure-your-layer-is-compatible-with-yocto-project'>Yocto Project Compatible</ulink>
                        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.
                        </para></listitem>
                </itemizedlist>
            </note>
        </para>

        <para>
            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
            (<filename>.bbappend</filename>) file, which is described later
            in this section.
            <note>
                For general information on BSP layer structure, see the
                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Packages (BSP) Developer's Guide</ulink>.
            </note>
        </para>

        <para>
            The
            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
            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
            <filename>meta-</filename>.
            <note>
                It is not a requirement that a layer name begin with the
                prefix <filename>meta-</filename>, but it is a commonly
                accepted standard in the Yocto Project community.
            </note>
            For example, if you were to examine the
            <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/'>tree view</ulink>
            of the <filename>poky</filename> repository, you will see several
            layers: <filename>meta</filename>,
            <filename>meta-skeleton</filename>,
            <filename>meta-selftest</filename>,
            <filename>meta-poky</filename>, and
            <filename>meta-yocto-bsp</filename>.
            Each of these repositories represents a distinct layer.
        </para>

        <para>
            For procedures on how to create layers, see the
            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
            section in the Yocto Project Development Tasks Manual.
        </para>
    </section>

    <section id='components-and-tools'>
        <title>Components and Tools</title>

        <para>
            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
            (<ulink url='&YOCTO_DOCS_REF_URL;#poky'>Poky</ulink>)
            and the
            <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
            Most of the components and tools are downloaded separately.
        </para>

        <para>
            This section provides brief overviews of the components and
            tools associated with the Yocto Project.
        </para>

        <section id='gs-development-tools'>
            <title>Development Tools</title>

            <para>
                The following list consists of tools that help you develop
                images and applications using the Yocto Project:
                <itemizedlist>
                    <listitem><para id='gs-crops-overview'>
                        <emphasis>CROPS:</emphasis>
                        <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>
                        is an open source, cross-platform development framework
                        that leverages
                        <ulink url='https://www.docker.com/'>Docker Containers</ulink>.
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis><filename>devtool</filename>:</emphasis>
                        This command-line tool is available as part of the
                        extensible SDK (eSDK) and is its cornerstone.
                        You can use <filename>devtool</filename> 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.</para>

                        <para>The <filename>devtool</filename> 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
                        <filename>devtool</filename>.
                        When you use <filename>devtool add</filename>, a recipe
                        is automatically created.
                        When you use <filename>devtool modify</filename>, 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 <filename>devtool upgrade</filename> command
                        updates an existing recipe so that you can build it
                        for an updated set of source files.</para>

                        <para>You can read about the
                        <filename>devtool</filename> workflow in the Yocto
                        Project Application Development and Extensible
                        Software Development Kit (eSDK) Manual in the
                        "<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'>Using <filename>devtool</filename> in Your SDK Workflow'</ulink>"
                        section.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Extensible Software Development Kit (eSDK):</emphasis>
                        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 <filename>devtool</filename>
                        commands tailored for the Yocto Project environment.
                        </para>

                        <para>For information on the eSDK, see the
                        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
                        Manual.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Toaster:</emphasis>
                        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
                        <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>.
                        </para></listitem>
                </itemizedlist>
            </para>
        </section>

        <section id='gs-production-tools'>
            <title>Production Tools</title>

            <para>
                The following list consists of tools that help production
                related activities using the Yocto Project:
                <itemizedlist>
                    <listitem><para>
                        <emphasis>Auto Upgrade Helper:</emphasis>
                        This utility when used in conjunction with the
                        <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
                        (BitBake and OE-Core) automatically generates upgrades
                        for recipes that are based on new versions of the
                        recipes published upstream.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Recipe Reporting System:</emphasis>
                        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
                        <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Layer Index</ulink>,
                        which is a website that indexes OpenEmbedded-Core
                        layers.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Patchwork:</emphasis>
                        <ulink url='http://jk.ozlabs.org/projects/patchwork/'>Patchwork</ulink>
                        is a fork of a project originally started by
                        <ulink url='http://ozlabs.org/'>OzLabs</ulink>.
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>AutoBuilder:</emphasis>
                        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
                            <ulink url='https://buildbot.net/'>buildbot</ulink>.
                        </note></para>

                        <para>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.</para>

                        <para>You can learn more about the AutoBuilder used
                        by the Yocto Project
                        <ulink url='&YOCTO_AB_URL;'>here</ulink>.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Cross-Prelink:</emphasis>
                        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.</para>

                        <para>Historically, cross-prelink is a variant of
                        prelink, which was conceived by
                        <ulink url='http://people.redhat.com/jakub/prelink.pdf'>Jakub Jel&iacute;nek</ulink>
                        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. <filename>glibc</filename>-derived
                        <filename>ld.so</filename> 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.</para>

                        <para>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.
                        </para>

                        <para>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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Pseudo:</emphasis>
                        Pseudo is the Yocto Project implementation of
                        <ulink url='http://man.he.net/man1/fakeroot'>fakeroot</ulink>,
                        which is used to run commands in an environment
                        that seemingly has root privileges.</para>

                        <para>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
                        <filename>LD_PRELOAD</filename>.
                        Either method allows these operations to succeed as
                        if system administrator privileges exist even
                        when they do not.</para>

                        <para>You can read more about Pseudo in the
                        "<link linkend='fakeroot-and-pseudo'>Fakeroot and Pseudo</link>"
                        section.
                        </para></listitem>
                </itemizedlist>
            </para>
        </section>

        <section id='gs-openembedded-build-system'>
            <title>Open-Embedded Build System Components</title>

            <para>
                The following list consists of components associated with the
                <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>:
                <itemizedlist>
                    <listitem><para>
                        <emphasis>BitBake:</emphasis>
                        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.</para>

                        <para>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.</para>

                        <para>You can learn more about BitBake in the
                        <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>OpenEmbedded-Core:</emphasis>
                        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
                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta'>Source Repositories</ulink>.
                        </para>

                        <para>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.
                        </para>

                        <para>Sharing a core set of metadata results in Poky
                        as an integration layer on top of OE-Core.
                        You can see that in this
                        <link linkend='yp-key-dev-elements'>figure</link>.
                        The Yocto Project combines various components such as
                        BitBake, OE-Core, script “glue”, and documentation
                        for its build system.
                        </para></listitem>
                </itemizedlist>
            </para>
        </section>

        <section id='gs-reference-distribution-poky'>
            <title>Reference Distribution (Poky)</title>

            <para>
                Poky is the Yocto Project reference distribution.
                It contains the
                <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>
                (BitBake and OE-Core) as well as a set of metadata to get you
                started building your own distribution.
                See the
                <link linkend='what-is-the-yocto-project'>figure</link> in
                "What is the Yocto Project?" section for an illustration
                that shows Poky and its relationship with other parts of the
                Yocto Project.</para>

                <para>To use the Yocto Project tools and components, you
                can download (<filename>clone</filename>) 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.
                </note>
                You can read more about Poky in the
                "<link linkend='reference-embedded-distribution'>Reference Embedded Distribution (Poky)</link>"
                section.
            </para>
        </section>

        <section id='gs-packages-for-finished-targets'>
            <title>Packages for Finished Targets</title>

            <para>
                The following lists components associated with packages
                for finished targets:
                <itemizedlist>
                    <listitem><para>
                        <emphasis>Matchbox:</emphasis>
                        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.</para>

                        <para>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.</para>

                        <para>You can find the Matchbox source in the Yocto
                        Project
                        <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Opkg</emphasis>
                        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.
                        </para>

                        <para>Opkg is intended for use on embedded Linux
                        devices and is used in this capacity in the
                        <ulink url='http://www.openembedded.org/wiki/Main_Page'>OpenEmbedded</ulink>
                        and
                        <ulink url='https://openwrt.org/'>OpenWrt</ulink>
                        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.
                        </note>
                        </para></listitem>
                </itemizedlist>
            </para>
        </section>

        <section id='gs-archived-components'>
            <title>Archived Components</title>

            <para>
                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.
            </para>

            <para>
                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.
                <orderedlist>
                    <listitem><para>
                        <emphasis>Hob:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>Build Appliance:</emphasis>
                        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.
                        </para></listitem>
                    <listitem><para>
                        <emphasis>CROPS:</emphasis>
                        The final and best solution available now for
                        developing using the Yocto Project on a system
                        not native to Linux is with
                        <link linkend='gs-crops-overview'>CROPS</link>.
                        </para></listitem>
                </orderedlist>
            </para>
        </section>
    </section>

    <section id='gs-development-methods'>
        <title>Development Methods</title>

        <para>
            The Yocto Project development environment usually involves a
            <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink>
            and target hardware.
            You use the Build Host to build images and develop applications,
            while you use the target hardware to test deployed software.
        </para>

        <para>
            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
                "<link linkend='overview-development-environment'>The Yocto Project Development Environment</link>"
                chapter.
            </note>
            <itemizedlist>
                <listitem><para>
                    <emphasis>Native Linux Host:</emphasis>
                    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
                    <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
                    tool.
                    You can accomplish all aspects of development from a
                    familiar shell of a supported Linux distribution.</para>

                    <para>For information on how to set up a Build Host on
                    a system running Linux as its native operating system,
                    see the
                    "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-a-native-linux-host'>Setting Up a Native Linux Host</ulink>"
                    section in the Yocto Project Development Tasks Manual.
                    </para></listitem>
                <listitem><para>
                    <emphasis>CROss PlatformS (CROPS):</emphasis>
                    Typically, you use
                    <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>,
                    which leverages
                    <ulink url='https://www.docker.com/'>Docker Containers</ulink>,
                    to set up a Build Host that is not running Linux (e.g.
                    <trademark class='registered'>Microsoft</trademark>
                    <trademark class='trademark'>Windows</trademark>
                    or
                    <trademark class='registered'>macOS</trademark>).
                    <note>
                        You can, however, use CROPS on a Linux-based system.
                    </note>
                    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.</para>

                    <para>For information on how to set up a Build Host with
                    CROPS, see the
                    "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>"
                    section in the Yocto Project Development Tasks Manual.
                    </para></listitem>
                <listitem><para>
                    <emphasis>Windows Subsystem For Linux (WSLv2):</emphasis>
                    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.
                    </note>
                    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.</para>
                    <para>For information on how to set up a Build Host with
                    WSLv2, see the
                    "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>"
                    section in the Yocto Project Development Tasks Manual.
                    </para></listitem>
                <listitem><para>
                    <emphasis>Toaster:</emphasis>
                    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
                    <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>.
                    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.</para>

                    <para>For information about and how to use Toaster,
                    see the
                    <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>.
                    </para></listitem>
            </itemizedlist>
        </para>
    </section>

    <section id='reference-embedded-distribution'>
        <title>Reference Embedded Distribution (Poky)</title>

        <para>
            "Poky", which is pronounced <emphasis>Pock</emphasis>-ee, is the
            name of the Yocto Project's reference distribution or Reference OS
            Kit.
            Poky contains the
            <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded Build System</ulink>
            (<ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> and
            <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core</ulink>)
            as well as a set of
            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>metadata</ulink> 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.
        </para>

        <para>
            Poky is a combined repository of BitBake, OpenEmbedded-Core
            (which is found in <filename>meta</filename>),
            <filename>meta-poky</filename>,
            <filename>meta-yocto-bsp</filename>, and documentation provided
            all together and known to work well together.
            You can view these items that make up the Poky repository in the
            <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/'>Source Repositories</ulink>.
            <note>
                If you are interested in all the contents of the
                <filename>poky</filename> Git repository, see the
                "<ulink url='&YOCTO_DOCS_REF_URL;#structure-core'>Top-Level Core Components</ulink>"
                section in the Yocto Project Reference Manual.
            </note>
        </para>

        <para id='gs-poky-reference-distribution'>
            The following figure illustrates what generally comprises Poky:
            <imagedata fileref="figures/poky-reference-distribution.png" format="PNG" align='center' width="8in"/>
            <itemizedlist>
                <listitem><para>
                    BitBake is a task executor and scheduler that is the heart of
                    the OpenEmbedded build system.
                    </para></listitem>
                <listitem><para>
                    <filename>meta-poky</filename>, which is Poky-specific
                    metadata.
                    </para></listitem>
                <listitem><para>
                    <filename>meta-yocto-bsp</filename>, which are Yocto
                    Project-specific Board Support Packages (BSPs).
                    </para></listitem>
                <listitem><para>
                    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.
                    </para></listitem>
                <listitem><para>
                    Documentation, which contains the Yocto Project source
                    files used to make the set of user manuals.
                    </para></listitem>
            </itemizedlist>
            <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.
            </note>
        </para>

        <para>
            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.
            </note>
        </para>

        <para>
            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
            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>Yocto Project Releases and the Stable Release Process</ulink>"
            chapter in the Yocto Project Reference Manual.
        </para>

        <para>
            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.
        </para>

        <para>
            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
            <link linkend='the-yocto-project-layer-model'>layers</link>
            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.
        </para>

        <para>
            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
            <filename>./meta/classes</filename>.
            Within a recipe you can also define additional tasks as well as
            task prerequisites.
            Recipe syntax through BitBake also supports both
            <filename>_prepend</filename> and <filename>_append</filename>
            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
            "<ulink url='&YOCTO_DOCS_BB_URL;#appending-and-prepending-override-style-syntax'>Appending and Prepending (Override Style Syntax)</ulink>"
            section in the BitBake User's Manual.
        </para>
    </section>

    <section id='openembedded-build-system-workflow'>
        <title>The OpenEmbedded Build System Workflow</title>

        <para>
            The
            <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
            uses a "workflow" to accomplish image and SDK generation.
            The following figure overviews that workflow:
            <imagedata fileref="figures/YP-flow-diagram.png"
                format="PNG" align='center' width="8in"/>
            Following is a brief summary of the "workflow":
            <orderedlist>
                <listitem><para>
                    Developers specify architecture, policies, patches and
                    configuration details.
                    </para></listitem>
                <listitem><para>
                    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.
                    </para></listitem>
                <listitem><para>
                    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.
                    </para></listitem>
                <listitem><para>
                    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.
                    </para></listitem>
                <listitem><para>
                    Different QA and sanity checks run throughout entire
                    build process.
                    </para></listitem>
                <listitem><para>
                    After the binaries are created, the build system
                    generates a binary package feed that is used to create
                    the final root file image.
                    </para></listitem>
                <listitem><para>
                    The build system generates the file system image and a
                    customized Extensible SDK (eSDK) for application
                    development in parallel.
                    </para></listitem>
            </orderedlist>
        </para>

        <para>
            For a very detailed look at this workflow, see the
            "<link linkend='openembedded-build-system-build-concepts'>OpenEmbedded Build System Concepts</link>"
            section.
        </para>
    </section>


    <section id='some-basic-terms'>
        <title>Some Basic Terms</title>

        <para>
            It helps to understand some basic fundamental terms when
            learning the Yocto Project.
            Although a list of terms exists in the
            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-terms'>Yocto Project Terms</ulink>"
            section of the Yocto Project Reference Manual, this section
            provides the definitions of some terms helpful for getting started:
            <itemizedlist>
                <listitem><para>
                    <emphasis>Configuration Files:</emphasis>
                    Files that hold global definitions of variables,
                    user-defined variables, and hardware configuration
                    information.
                    These files tell the
                    <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>
                    what to build and what to put into the image to support a
                    particular platform.
                    </para></listitem>
                <listitem><para>
                    <emphasis>Extensible Software Development Kit (eSDK):</emphasis>
                    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
                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
                    manual.
                    </para></listitem>
                <listitem><para>
                    <emphasis>Layer:</emphasis>
                    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.</para>

                    <para>For more detailed information on layers, see the
                    "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
                    section in the Yocto Project Development Tasks Manual.
                    For a discussion specifically on BSP Layers, see the
                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                    section in the Yocto Project Board Support Packages (BSP)
                    Developer's Guide.
                    </para></listitem>
                <listitem><para>
                    <emphasis>Metadata:</emphasis>
                    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.
                    </para></listitem>
                <listitem><para id='gs-term-openembedded-build-system'>
                    <emphasis>OpenEmbedded Build System:</emphasis>
                    The terms "BitBake" and "build system" are sometimes
                    used for the OpenEmbedded Build System.</para>

                    <para>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 <filename>make</filename>
                    tool.</para>

                    <para>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.
                    </para></listitem>
                <listitem><para>
                    <emphasis>OpenEmbedded-Core (OE-Core):</emphasis>
                    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.</para>

                    <para>You can see the Metadata in the
                    <filename>meta</filename> directory of the Yocto Project
                    <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories</ulink>.
                    </para></listitem>
                <listitem><para>
                    <emphasis>Packages:</emphasis>
                    In the context of the Yocto Project, this term refers to a
                    recipe's packaged output produced by BitBake (i.e. a
                    "baked recipe").
                    A package is generally the compiled binaries produced from the
                    recipe's sources.
                    You "bake" something by running it through BitBake.</para>

                    <para>It is worth noting that the term "package" can,
                    in general, have subtle meanings.
                    For example, the packages referred to in the
                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host'>Required Packages for the Build Host</ulink>"
                    section in the Yocto Project Reference Manual are compiled
                    binaries that, when installed, add functionality to your
                    Linux distribution.</para>

                    <para>Another point worth noting is that historically within
                    the Yocto Project, recipes were referred to as packages - thus,
                    the existence of several BitBake variables that are seemingly
                    mis-named,
                    (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>,
                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>,
                    and
                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
                    </para></listitem>
                <listitem><para>
                    <emphasis>Poky:</emphasis>
                    Poky is a reference embedded distribution and a reference
                    test configuration.
                    Poky provides the following:
                    <itemizedlist>
                        <listitem><para>
                            A base-level functional distro used to illustrate
                            how to customize a distribution.
                            </para></listitem>
                        <listitem><para>
                            A means by which to test the Yocto Project
                            components (i.e. Poky is used to validate
                            the Yocto Project).
                            </para></listitem>
                        <listitem><para>
                            A vehicle through which you can download
                            the Yocto Project.
                            </para></listitem>
                    </itemizedlist>
                    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.
                    </note>
                    </para></listitem>
                <listitem><para>
                    <emphasis>Recipe:</emphasis>
                    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.
                    </para></listitem>
            </itemizedlist>
        </para>
    </section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->