--- /dev/null
+<!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; ] >
+
+<chapter id='closer-look'>
+<title>A Closer Look at the Yocto Project Development Environment</title>
+
+ <para>
+ This chapter takes a more detailed look at the Yocto Project
+ development environment.
+ The following diagram represents the development environment at a
+ high level.
+ The remainder of this chapter expands on the fundamental input, output,
+ process, and
+ <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>) blocks
+ in the Yocto Project development environment.
+ </para>
+
+ <para id='general-yocto-environment-figure'>
+ <imagedata fileref="figures/yocto-environment-ref.png" align="center" width="8in" depth="4.25in" />
+ </para>
+
+ <para>
+ The generalized Yocto Project Development Environment consists of
+ several functional areas:
+ <itemizedlist>
+ <listitem><para><emphasis>User Configuration:</emphasis>
+ Metadata you can use to control the build process.
+ </para></listitem>
+ <listitem><para><emphasis>Metadata Layers:</emphasis>
+ Various layers that provide software, machine, and
+ distro Metadata.</para></listitem>
+ <listitem><para><emphasis>Source Files:</emphasis>
+ Upstream releases, local projects, and SCMs.</para></listitem>
+ <listitem><para><emphasis>Build System:</emphasis>
+ Processes under the control of BitBake.
+ This block expands on how BitBake fetches source, applies
+ patches, completes compilation, analyzes output for package
+ generation, creates and tests packages, generates images, and
+ generates cross-development tools.</para></listitem>
+ <listitem><para><emphasis>Package Feeds:</emphasis>
+ Directories containing output packages (rpm, deb or ipk),
+ which are subsequently used in the construction of an image or
+ SDK, produced by the build system.
+ These feeds can also be copied and shared using a web server or
+ other means to facilitate extending or updating existing
+ images on devices at runtime if runtime package management is
+ enabled.</para></listitem>
+ <listitem><para><emphasis>Images:</emphasis>
+ Images produced by the development process.
+ Where do they go?
+ Can you mess with them (i.e. freely delete them or move them?).
+ </para></listitem>
+ <listitem><para><emphasis>Application Development SDK:</emphasis>
+ Cross-development tools that are produced along with an image
+ or separately with BitBake.</para></listitem>
+ </itemizedlist>
+ </para>
+
+ <section id="user-configuration">
+ <title>User Configuration</title>
+
+ <para>
+ User configuration helps define the build.
+ Through user configuration, you can tell BitBake the
+ target architecture for which you are building the image,
+ where to store downloaded source, and other build properties.
+ </para>
+
+ <para>
+ The following figure shows an expanded representation of the
+ "User Configuration" box of the
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
+ </para>
+
+ <para>
+ <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
+ </para>
+
+ <para>
+ BitBake needs some basic configuration files in order to complete
+ a build.
+ These files are <filename>*.conf</filename> files.
+ The minimally necessary ones reside as example files in the
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+ For simplicity, this section refers to the Source Directory as
+ the "Poky Directory."
+ </para>
+
+ <para>
+ When you clone the <filename>poky</filename> Git repository or you
+ download and unpack a Yocto Project release, you can set up the
+ Source Directory to be named anything you want.
+ For this discussion, the cloned repository uses the default
+ name <filename>poky</filename>.
+ <note>
+ The Poky repository is primarily an aggregation of existing
+ repositories.
+ It is not a canonical upstream source.
+ </note>
+ </para>
+
+ <para>
+ The <filename>meta-yocto</filename> layer inside Poky contains
+ a <filename>conf</filename> directory that has example
+ configuration files.
+ These example files are used as a basis for creating actual
+ configuration files when you source the build environment
+ script <filename>oe-init-build-env</filename>.
+ </para>
+
+ <para>
+ Sourcing the build environment script creates a
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+ if one does not already exist.
+ BitBake uses the Build Directory for all its work during builds.
+ The Build Directory has a <filename>conf</filename> directory that
+ contains default versions of your <filename>local.conf</filename>
+ and <filename>bblayers.conf</filename> configuration files.
+ These default configuration files are created only if versions
+ do not already exist in the Build Directory at the time you
+ source the <filename>oe-init-build-env</filename> script.
+ </para>
+
+ <para>
+ Because the Poky repository is fundamentally an aggregation of
+ existing repositories, some users might be familiar with running
+ the <filename>oe-init-build-env</filename> script in the context of
+ separate OpenEmbedded-Core and BitBake repositories rather than a
+ single Poky repository.
+ This discussion assumes the script is executed from within a cloned
+ or unpacked version of Poky.
+ </para>
+
+ <para>
+ Depending on where the script is sourced, different sub-scripts
+ are called to set up the Build Directory (Yocto or OpenEmbedded).
+ Specifically, the script
+ <filename>scripts/oe-setup-builddir</filename> inside the
+ poky directory sets up the Build Directory and seeds the directory
+ (if necessary) with configuration files appropriate for the
+ Yocto Project development environment.
+ <note>
+ The <filename>scripts/oe-setup-builddir</filename> script
+ uses the <filename>$TEMPLATECONF</filename> variable to
+ determine which sample configuration files to locate.
+ </note>
+ </para>
+
+ <para>
+ The <filename>local.conf</filename> file provides many
+ basic variables that define a build environment.
+ Here is a list of a few.
+ To see the default configurations in a <filename>local.conf</filename>
+ file created by the build environment script, see the
+ <filename>local.conf.sample</filename> in the
+ <filename>meta-yocto</filename> layer:
+ <itemizedlist>
+ <listitem><para><emphasis>Parallelism Options:</emphasis>
+ Controlled by the
+ <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+ and
+ <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+ variables.</para></listitem>
+ <listitem><para><emphasis>Target Machine Selection:</emphasis>
+ Controlled by the
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variable.</para></listitem>
+ <listitem><para><emphasis>Download Directory:</emphasis>
+ Controlled by the
+ <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+ variable.</para></listitem>
+ <listitem><para><emphasis>Shared State Directory:</emphasis>
+ Controlled by the
+ <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
+ variable.</para></listitem>
+ <listitem><para><emphasis>Build Output:</emphasis>
+ Controlled by the
+ <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+ variable.</para></listitem>
+ </itemizedlist>
+ <note>
+ Configurations set in the <filename>conf/local.conf</filename>
+ file can also be set in the
+ <filename>conf/site.conf</filename> and
+ <filename>conf/auto.conf</filename> configuration files.
+ </note>
+ </para>
+
+ <para>
+ The <filename>bblayers.conf</filename> file tells BitBake what
+ layers you want considered during the build.
+ By default, the layers listed in this file include layers
+ minimally needed by the build system.
+ However, you must manually add any custom layers you have created.
+ You can find more information on working with the
+ <filename>bblayers.conf</filename> file in the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
+ section in the Yocto Project Development Manual.
+ </para>
+
+ <para>
+ The files <filename>site.conf</filename> and
+ <filename>auto.conf</filename> are not created by the environment
+ initialization script.
+ If you want these configuration files, you must create them
+ yourself:
+ <itemizedlist>
+ <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
+ You can use the <filename>conf/site.conf</filename>
+ configuration file to configure multiple build directories.
+ For example, suppose you had several build environments and
+ they shared some common features.
+ You can set these default build properties here.
+ A good example is perhaps the level of parallelism you want
+ to use through the
+ <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+ and
+ <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+ variables.</para>
+ <para>One useful scenario for using the
+ <filename>conf/site.conf</filename> file is to extend your
+ <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+ variable to include the path to a
+ <filename>conf/site.conf</filename>.
+ Then, when BitBake looks for Metadata using
+ <filename>BBPATH</filename>, it finds the
+ <filename>conf/site.conf</filename> file and applies your
+ common configurations found in the file.
+ To override configurations in a particular build directory,
+ alter the similar configurations within that build
+ directory's <filename>conf/local.conf</filename> file.
+ </para></listitem>
+ <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
+ This file is not hand-created.
+ Rather, the file is usually created and written to by
+ an autobuilder.
+ The settings put into the file are typically the same as
+ you would find in the <filename>conf/local.conf</filename>
+ or the <filename>conf/site.conf</filename> files.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ You can edit all configuration files to further define
+ any particular build environment.
+ This process is represented by the "User Configuration Edits"
+ box in the figure.
+ </para>
+
+ <para>
+ When you launch your build with the
+ <filename>bitbake <target></filename> command, BitBake
+ sorts out the configurations to ultimately define your build
+ environment.
+ </para>
+ </section>
+
+ <section id="metadata-machine-configuration-and-policy-configuration">
+ <title>Metadata, Machine Configuration, and Policy Configuration</title>
+
+ <para>
+ The previous section described the user configurations that
+ define the BitBake's global behavior.
+ This section takes a closer look at the layers the build system
+ uses to further control the build.
+ These layers provide Metadata for the software, machine, and
+ policy.
+ </para>
+
+ <para>
+ In general, three types of layer input exist:
+ <itemizedlist>
+ <listitem><para><emphasis>Policy Configuration:</emphasis>
+ Distribution Layers provide top-level or general
+ policies for the image or SDK being built.
+ For example, this layer would dictate whether BitBake
+ produces RPM or IPK packages.</para></listitem>
+ <listitem><para><emphasis>Machine Configuration:</emphasis>
+ Board Support Package (BSP) layers provide machine
+ configurations.
+ This type of information is specific to a particular
+ target architecture.</para></listitem>
+ <listitem><para><emphasis>Metadata:</emphasis>
+ Software layers contain user-supplied recipe files,
+ patches, and append files.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The following figure shows an expanded representation of the
+ Metadata, Machine Configuration, and Policy Configuration input
+ (layers) boxes of the
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
+ </para>
+
+ <para>
+ <imagedata fileref="figures/layer-input.png" align="center" width="8in" depth="7.5in" />
+ </para>
+
+ <para>
+ In general, all layers have a similar structure.
+ They all contain a licensing file
+ (e.g. <filename>COPYING</filename>) if the layer is to be
+ distributed, a <filename>README</filename> file as good practice
+ and especially if the layer is to be distributed, a
+ configuration directory, and recipe directories.
+ </para>
+
+ <para>
+ The Yocto Project has many layers that can be used.
+ You can see a web-interface listing of them on the
+ <ulink url="http://git.yoctoproject.org/">Source Repositories</ulink>
+ page.
+ The layers are shown at the bottom categorized under
+ "Yocto Metadata Layers."
+ These layers are fundamentally a subset of the
+ <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Metadata Index</ulink>,
+ which lists all layers provided by the OpenEmbedded community.
+ <note>
+ Layers exist in the Yocto Project Source Repositories that
+ cannot be found in the OpenEmbedded Metadata Index.
+ These layers are either deprecated or experimental in nature.
+ </note>
+ </para>
+
+ <para>
+ BitBake uses the <filename>conf/bblayers.conf</filename> file,
+ which is part of the user configuration, to find what layers it
+ should be using as part of the build.
+ </para>
+
+ <para>
+ For more 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 Manual.
+ </para>
+
+ <section id="distro-layer">
+ <title>Distro Layer</title>
+
+ <para>
+ The distribution layer provides policy configurations for your
+ distribution.
+ Best practices dictate that you isolate these types of
+ configurations into their own layer.
+ Settings you provide in
+ <filename>conf/<distro>.conf</filename> override similar
+ settings that BitBake finds in your
+ <filename>conf/local.conf</filename> file in the Build
+ Directory.
+ </para>
+
+ <para>
+ The following list provides some explanation and references
+ for what you typically find in the distribution layer:
+ <itemizedlist>
+ <listitem><para><emphasis>classes:</emphasis>
+ Class files (<filename>.bbclass</filename>) holds
+ common functionality that can be shared among
+ recipes in the distribution.
+ When your recipes inherit a class, they take on the
+ settings and functions for that class.
+ You can read more about class files in the
+ "<link linkend='ref-classes'>Classes</link>" section.
+ </para></listitem>
+ <listitem><para><emphasis>conf:</emphasis>
+ This area holds configuration files for the
+ layer (<filename>conf/layer.conf</filename>),
+ the distribution
+ (<filename>conf/distro/<distro>.conf</filename>),
+ and any distribution-wide include files.
+ </para></listitem>
+ <listitem><para><emphasis>recipes-*:</emphasis>
+ Recipes and append files that affect common
+ functionality across the distribution.
+ This area could include recipes and append files to
+ to add distribution-specific configuration,
+ initialization scripts, custom image recipes,
+ and so forth.</para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id="bsp-layer">
+ <title>BSP Layer</title>
+
+ <para>
+ The BSP Layer provides machine configurations.
+ Everything in this layer is specific to the machine for which
+ you are building the image or the SDK.
+ A common structure or form is defined for BSP layers.
+ You can learn more about this structure in the
+ <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+ <note>
+ In order for a BSP layer to be considered compliant with the
+ Yocto Project, it must meet some structural requirements.
+ </note>
+ </para>
+
+ <para>
+ The BSP Layer's configuration directory contains
+ configuration files for the machine
+ (<filename>conf/machine/<machine>.conf</filename>) and,
+ of course, the layer (<filename>conf/layer.conf</filename>).
+ </para>
+
+ <para>
+ The remainder of the layer is dedicated to specific recipes
+ by function: <filename>recipes-bsp</filename>,
+ <filename>recipes-core</filename>,
+ <filename>recipes-graphics</filename>, and
+ <filename>recipes-kernel</filename>.
+ Metadata can exist for multiple formfactors, graphics
+ support systems, and so forth.
+ <note>
+ While the figure shows several <filename>recipe-*</filename>
+ directories, not all these directories appear in all
+ BSP layers.
+ </note>
+ </para>
+ </section>
+
+ <section id="software-layer">
+ <title>Software Layer</title>
+
+ <para>
+ The software layer provides the Metadata for additional
+ software packages used during the build.
+ This layer does not include Metadata that is specific to the
+ distribution or the machine, which are found in their
+ respective layers.
+ </para>
+
+ <para>
+ This layer contains any new recipes that your project needs
+ in the form of recipe files.
+ </para>
+ </section>
+ </section>
+
+ <section id="sources-dev-environment">
+ <title>Sources</title>
+
+ <para>
+ In order for the OpenEmbedded build system to create an image or
+ any target, it must be able to access source files.
+ The
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+ represents source files using the "Upstream Project Releases",
+ "Local Projects", and "SCMs (optional)" boxes.
+ The figure represents mirrors, which also play a role in locating
+ source files, with the "Source Mirror(s)" box.
+ </para>
+
+ <para>
+ The method by which source files are ultimately organized is
+ a function of the project.
+ For example, for released software, projects tend to use tarballs
+ or other archived files that can capture the state of a release
+ guaranteeing that it is statically represented.
+ On the other hand, for a project that is more dynamic or
+ experimental in nature, a project might keep source files in a
+ repository controlled by a Source Control Manager (SCM) such as
+ Git.
+ Pulling source from a repository allows you to control
+ the point in the repository (the revision) from which you want to
+ build software.
+ Finally, a combination of the two might exist, which would give the
+ consumer a choice when deciding where to get source files.
+ </para>
+
+ <para>
+ BitBake uses the
+ <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+ variable to point to source files regardless of their location.
+ Each recipe must have a <filename>SRC_URI</filename> variable
+ that points to the source.
+ </para>
+
+ <para>
+ Another area that plays a significant role in where source files
+ comes from is pointed to by the
+ <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+ variable.
+ This area is a cache that can hold previously downloaded source.
+ Judicious use of a <filename>DL_DIR</filename> directory can
+ save the build system a trip across the Internet when looking
+ for files.
+ A good method for using a download directory is to have
+ <filename>DL_DIR</filename> point to an area outside of your
+ Build Directory.
+ Doing so allows you to safely delete the Build Directory
+ if needed without fear of removing any downloaded source file.
+ </para>
+
+ <para>
+ The remainder of this section provides a deeper look into the
+ source files and the mirrors.
+ Here is a more detailed look at the source file area of the
+ base figure:
+ <imagedata fileref="figures/source-input.png" align="center" width="7in" depth="7.5in" />
+ </para>
+
+ <section id='upstream-project-releases'>
+ <title>Upstream Project Releases</title>
+
+ <para>
+ Upstream project releases exist anywhere in the form of an
+ archived file (e.g. tarball or zip file).
+ These files correspond to individual recipes.
+ For example, the figure uses specific releases each for
+ BusyBox, Qt, and Dbus.
+ An archive file can be for any released product that can be
+ built using a recipe.
+ </para>
+ </section>
+
+ <section id='local-projects'>
+ <title>Local Projects</title>
+
+ <para>
+ Local projects are custom bits of software the user provides.
+ These bits reside somewhere local to a project - perhaps
+ a directory into which the user checks in items (e.g.
+ a local directory containing a development source tree
+ used by the group).
+ </para>
+
+ <para>
+ The canonical method through which to include a local project
+ is to use the
+ <link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>
+ class to include local project.
+ You use either the <filename>local.conf</filename> or a
+ recipe's append file to override or set the
+ recipe to point to the local directory on your disk to pull
+ in the whole source tree.
+ </para>
+
+ <para>
+ For information on how to use the
+ <filename>externalsrc.bbclass</filename>, see the
+ "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+ section.
+ </para>
+ </section>
+
+ <section id='scms'>
+ <title>Source Control Managers (Optional)</title>
+
+ <para>
+ Another place the build system can get source files from is
+ through an SCM such as Git or Subversion.
+ In this case, a repository is cloned or checked out.
+ The <filename>do_fetch</filename> task inside BitBake uses
+ the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+ variable and the argument's prefix to determine the correct
+ fetcher module.
+ </para>
+
+ <para>
+ When fetching a repository, BitBake uses the
+ <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+ variable to determine the specific revision from which to
+ build.
+ </para>
+ </section>
+
+ <section id='source-mirrors'>
+ <title>Source Mirror(s)</title>
+
+ <para>
+ Two kinds of mirrors exist: pre-mirrors and regular mirrors.
+ The <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+ and
+ <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+ variables point to these, respectively.
+ BitBake checks pre-mirrors before looking upstream for any
+ source files.
+ Pre-mirrors are appropriate when you have a shared directory
+ that is not a directory defined by the
+ <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+ variable.
+ A Pre-mirror typically points to a shared directory that is
+ local to your organization.
+ </para>
+
+ <para>
+ Regular mirrors can be any site across the Internet that is
+ used as an alternative location for source code should the
+ primary site not be functioning for some reason or another.
+ </para>
+ </section>
+ </section>
+
+ <section id='bitbake-dev-environment'>
+ <title>BitBake</title>
+
+ <para>
+ The OpenEmbedded build system uses BitBake to produce images.
+ You can see from the
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
+ the BitBake area consists of several functional areas.
+ This section takes a closer look at each of those areas.
+ </para>
+
+ <section id='source-fetching-dev-environment'>
+ <title>Source Fetching</title>
+
+ <para>
+ The first stages of building a recipe are to fetch and unpack
+ the source code:
+ <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="4in" />
+ </para>
+
+ <para>
+ The <filename>do_fetch</filename> and
+ <filename>do_unpack</filename> tasks fetch the source files
+ and unpack them into a working directory.
+ By default, everything is accomplished in the
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+ which has a defined structure.
+ For additional general information on the Build Directory,
+ see the
+ "<link linkend='structure-core-build'><filename>build/</filename></link>"
+ section.
+ </para>
+
+ <para>
+ Unpacked source source files are pointed to by the
+ <link linkend='var-S'><filename>S</filename></link> variable.
+ Each recipe has an area in the Build Directory where the
+ unpacked source code resides.
+ The name of directory for any given recipe is defined from
+ several different variables.
+ You can see the variables that define these directories
+ by looking at the figure:
+ <itemizedlist>
+ <listitem><para><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PN'><filename>PN</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PV'><filename>PV</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PR'><filename>PR</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-S'><filename>S</filename></link>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Briefly, the <filename>S</filename> directory contains the
+ unpacked source files for a recipe.
+ The <filename>WORKDIR</filename> directory is where all the
+ building goes on for a given recipe.
+ </para>
+ </section>
+
+ <section id='patching-dev-environment'>
+ <title>Patching</title>
+
+ <para>
+ Once source code is fetched and unpacked, BitBake locates
+ patch files and applies them to the source files:
+ <imagedata fileref="figures/patching.png" align="center" width="6in" depth="5in" />
+ </para>
+
+ <para>
+ The <filename>do_patch</filename> task processes recipes by
+ using the
+ <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+ variable to locate applicable patch files, which by default
+ are <filename>*.patch</filename> or
+ <filename>*.diff</filename> files, or any file if
+ "apply=yes" is specified for the file in
+ <filename>SRC_URI</filename>.
+ </para>
+
+ <para>
+ BitBake finds and applies multiple patches for a single recipe
+ in the order in which it finds the patches.
+ Patches are applied to the recipe's source files located in the
+ <link linkend='var-S'><filename>S</filename></link> directory.
+ </para>
+
+ <para>
+ For more information on how the source directories are
+ created, see the
+ "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
+ section.
+ </para>
+ </section>
+
+ <section id='configuration-and-compilation-dev-environment'>
+ <title>Configuration and Compilation</title>
+
+ <para>
+ After source code is patched, BitBake executes tasks that
+ configure and compile the source code:
+ <imagedata fileref="figures/configuration-compile-autoreconf.png" align="center" width="7in" depth="5in" />
+ </para>
+
+ <para>
+ This step in the build process consists of three tasks:
+ <itemizedlist>
+ <listitem><para><emphasis><filename>do_configure</filename>:</emphasis>
+ This task configures the source by enabling and
+ disabling any build-time and configuration options for
+ the software being built.
+ Configurations can come from the recipe itself as well
+ as from an inherited class.
+ Additionally, the software itself might configure itself
+ depending on the target for which it is being built.
+ </para>
+
+ <para>The configurations handled by the
+ <filename>do_configure</filename> task are specific
+ to source code configuration for the source code
+ being built by the recipe.</para>
+
+ <para>If you are using
+ <link linkend='ref-classes-autotools'><filename>autotools.bbclass</filename></link>,
+ you can add additional configuration options by using
+ the <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
+ variable.
+ For information on how this variable works within
+ that class, see the
+ <filename>meta/classes/autotools.bbclass</filename>.
+ </para></listitem>
+ <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
+ Once a configuration task has been satisfied, BitBake
+ compiles the source using the
+ <filename>do_compile</filename> task.
+ Compilation occurs in the directory pointed to by the
+ <link linkend='var-B'><filename>B</filename></link>
+ variable.
+ Realize that the <filename>B</filename> directory, by
+ default, is the same as the
+ <link linkend='var-S'><filename>S</filename></link>
+ directory.</para></listitem>
+ <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
+ Once compilation is done, BitBake executes the
+ <filename>do_install</filename> task.
+ This task copies files from the <filename>B</filename>
+ directory and places them in a holding area pointed to
+ by the
+ <link linkend='var-D'><filename>D</filename></link>
+ variable.</para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='package-splitting-dev-environment'>
+ <title>Package Splitting</title>
+
+ <para>
+ After source code is configured and compiled, the
+ OpenEmbedded build system analyzes
+ the results and splits the output into packages:
+ <imagedata fileref="figures/analysis-for-package-splitting.png" align="center" width="7in" depth="7in" />
+ </para>
+
+ <para>
+ The <filename>do_package</filename> and
+ <filename>do_packagedata</filename> tasks combine to analyze
+ the files found in the
+ <link linkend='var-D'><filename>D</filename></link> directory
+ and split them into subsets based on available packages and
+ files.
+ The analyzing process involves the following as well as other
+ items: splitting out debugging symbols,
+ looking at shared library dependencies between packages,
+ and looking at package relationships.
+ The <filename>do_packagedata</filename> task creates package
+ metadata based on the analysis such that the
+ OpenEmbedded build system can generate the final packages.
+ Working, staged, and intermediate results of the analysis
+ and package splitting process use these areas:
+ <itemizedlist>
+ <listitem><para><link linkend='var-PKGD'><filename>PKGD</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link>
+ </para></listitem>
+ <listitem><para><link linkend='var-PKGDEST'><filename>PKGDEST</filename></link>
+ </para></listitem>
+ </itemizedlist>
+ The <link linkend='var-FILES'><filename>FILES</filename></link>
+ variable defines the files that go into each package in
+ <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
+ If you want details on how this is accomplished, you can
+ look at
+ <link linkend='ref-classes-package'><filename>package.bbclass</filename></link>.
+ </para>
+
+ <para>
+ Depending on the type of packages being created (RPM, DEB, or
+ IPK), the <filename>do_package_write_*</filename> task
+ creates the actual packages and places them in the
+ Package Feed area, which is
+ <filename>${TMPDIR}/deploy</filename>.
+ You can see the
+ "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
+ section for more detail on that part of the build process.
+ <note>
+ Support for creating feeds directly from the
+ <filename>deploy/*</filename> directories does not exist.
+ Creating such feeds usually requires some kind of feed
+ maintenance mechanism that would upload the new packages
+ into an official package feed (e.g. the
+ Ångström distribution).
+ This functionality is highly distribution-specific
+ and thus is not provided out of the box.
+ </note>
+ </para>
+ </section>
+ </section>
+
+ <section id="package-feeds-dev-environment">
+ <title>Package Feeds</title>
+
+ <para>
+ When the OpenEmbedded build system generates an image or an SDK,
+ it gets the packages from a package feed area located in the
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+ The
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+ shows this package feeds area in the upper-right corner.
+ </para>
+
+ <para>
+ This section looks a little closer into the package feeds area used
+ by the build system.
+ Here is a more detailed look at the area:
+ <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
+ </para>
+
+ <para>
+ Package feeds are an intermediary step in the build process.
+ BitBake generates packages whose type is defined by the
+ <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+ variable.
+ Before placing the packages into package feeds,
+ the build process validates them with generated output quality
+ assurance checks through the
+ <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
+ class.
+ </para>
+
+ <para>
+ The package feed area resides in
+ <filename>tmp/deploy</filename> of the Build Directory.
+ Folders are created that correspond to the package type
+ (IPK, DEB, or RPM) created.
+ Further organization is derived through the value of the
+ <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
+ variable for each package.
+ For example, packages can exist for the i586 or qemux86
+ architectures.
+ The package files themselves reside within the appropriate
+ architecture folder.
+ </para>
+
+ <para>
+ BitBake uses the <filename>do_package_write_*</filename> task to
+ place generated packages into the package holding area (e.g.
+ <filename>do_package_write_ipk</filename> for IPK packages).
+ </para>
+ </section>
+
+ <section id='images-dev-environment'>
+ <title>Images</title>
+
+ <para>
+ The images produced by the OpenEmbedded build system
+ are compressed forms of the
+ root filesystems that are ready to boot on a target device.
+ You can see from the
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+ that BitBake output in part consists of images.
+ This section is going to look more closely at this output:
+ <imagedata fileref="figures/images.png" align="center" width="5.5in" depth="5.5in" />
+ </para>
+
+ <para>
+ For a list of example images that the Yocto Project provides,
+ the
+ "<link linkend='ref-images'>Images</link>" chapter.
+ </para>
+
+ <para>
+ Images are written out to the
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+ inside the <filename>deploy/images</filename> folder as shown
+ in the figure.
+ This folder contains any files expected to be loaded on the
+ target device.
+ The
+ <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+ variable points to the <filename>deploy</filename> directory.
+ <itemizedlist>
+ <listitem><para><filename><kernel-image></filename>:
+ A kernel binary file.
+ The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
+ variable setting determines the naming scheme for the
+ kernel image file.
+ Depending on that variable, the file could begin with
+ a variety of naming strings.
+ The <filename>deploy/images</filename> directory can
+ contain multiple image files.</para></listitem>
+ <listitem><para><filename><root-filesystem-image></filename>:
+ Root filesystems for the target device (e.g.
+ <filename>*.ext3</filename> or <filename>*.bz2</filename>
+ files).
+ The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+ variable setting determines the root filesystem image
+ type.
+ The <filename>deploy/images</filename> directory can
+ contain multiple root filesystems.</para></listitem>
+ <listitem><para><filename><kernel-modules></filename>:
+ Tarballs that contain all the modules built for the kernel.
+ Kernel module tarballs exist for legacy purposes and
+ can be suppressed by setting the
+ <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
+ variable to "0".
+ The <filename>deploy/images</filename> directory can
+ contain multiple kernel module tarballs.
+ </para></listitem>
+ <listitem><para><filename><bootloaders></filename>:
+ Bootloaders supporting the image, if applicable to the
+ target machine.
+ The <filename>deploy/images</filename> directory can
+ contain multiple bootloaders.
+ </para></listitem>
+ <listitem><para><filename><symlinks></filename>:
+ The <filename>deploy/images</filename> folder contains
+ a symbolic link that points to the most recently built file
+ for each machine.
+ These links might be useful for external scripts that
+ need to obtain the latest version of each file.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='sdk-dev-environment'>
+ <title>Application Development SDK</title>
+
+ <para>
+ In the
+ <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
+ the output labeled "Application Development SDK" represents an
+ SDK.
+ This section is going to take a closer look at this output:
+ <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
+ </para>
+
+ <para>
+ The specific form of this output is a self-extracting
+ SDK installer (<filename>*.sh</filename>) that, when run,
+ installs the SDK, which consists of a cross-development
+ toolchain, a set of libraries and headers, and an SDK
+ environment setup script.
+ Running this installer essentially sets up your
+ cross-development environment.
+ You can think of the cross-toolchain as the "host"
+ part because it runs on the SDK machine.
+ You can think of the libraries and headers as the "target"
+ part because they are built for the target hardware.
+ The setup script is added so that you can initialize the
+ environment before using the tools.
+ </para>
+
+ <note>
+ <para>
+ The Yocto Project supports several methods by which you can
+ set up this cross-development environment.
+ These methods include downloading pre-built SDK installers,
+ building and installing your own SDK installer, or running
+ an Application Development Toolkit (ADT) installer to
+ install not just cross-development toolchains
+ but also additional tools to help in this type of
+ development.
+ </para>
+
+ <para>
+ For background information on cross-development toolchains
+ in the Yocto Project development environment, see the
+ "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+ section.
+ For information on setting up a cross-development
+ environment, see the
+ "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+ section in the Yocto Project Application Developer's Guide.
+ </para>
+ </note>
+
+ <para>
+ Once built, the SDK installers are written out to the
+ <filename>deploy/sdk</filename> folder inside the
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+ as shown in the figure at the beginning of this section.
+ Several variables exist that help configure these files:
+ <itemizedlist>
+ <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
+ Points to the <filename>deploy</filename>
+ directory.</para></listitem>
+ <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
+ Specifies the architecture of the machine
+ on which the cross-development tools are run to
+ create packages for the target hardware.
+ </para></listitem>
+ <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
+ Lists the features to include in the "target" part
+ of the SDK.
+ </para></listitem>
+ <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
+ Lists packages that make up the host
+ part of the SDK (i.e. the part that runs on
+ the <filename>SDKMACHINE</filename>).
+ When you use
+ <filename>bitbake -c populate_sdk <imagename></filename>
+ to create the SDK, a set of default packages
+ apply.
+ This variable allows you to add more packages.
+ </para></listitem>
+ <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
+ Lists packages that make up the target part
+ of the SDK (i.e. the part built for the
+ target hardware).
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
</section>
</section>
-<section id="a-closer-look-at-the-yocto-project-development-environment">
- <title>A Closer Look at the Yocto Project Development Environment</title>
-
- <para>
- This section takes a more detailed look at the Yocto Project
- development environment.
- The following diagram represents the development environment at a
- high level.
- The remainder of this section expands on the fundamental input, output,
- process, and
- <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>) blocks
- in the Yocto Project development environment.
- </para>
-
- <para>
- <imagedata fileref="figures/yocto-environment-ref.png" align="center" width="8in" depth="4.25in" />
- </para>
-
- <para>
- The generalized Yocto Project Development Environment consists of
- several functional areas:
- <itemizedlist>
- <listitem><para><emphasis>User Configuration:</emphasis>
- Metadata you can use to control the build process.
- </para></listitem>
- <listitem><para><emphasis>Metadata Layers:</emphasis>
- Various layers that provide software, machine, and
- distro Metadata.</para></listitem>
- <listitem><para><emphasis>Source Files:</emphasis>
- Upstream releases, local projects, and SCMs.</para></listitem>
- <listitem><para><emphasis>Build System:</emphasis>
- Processes under the control of BitBake.
- This block expands on how BitBake fetches source, applies
- patches, completes compilation, analyzes output for package
- generation, creates and tests packages, generates images, and
- generates cross-development tools.</para></listitem>
- <listitem><para><emphasis>Package Feeds:</emphasis>
- Directories containing output packages (rpm, deb or ipk),
- which are subsequently used in the construction of an image or
- SDK, produced by the build system.
- These feeds can also be copied and shared using a web server or
- other means to facilitate extending or updating existing
- images on devices at runtime if runtime package management is
- enabled.</para></listitem>
- <listitem><para><emphasis>Images:</emphasis>
- Images produced by the development process.
- Where do they go?
- Can you mess with them (i.e. freely delete them or move them?).
- </para></listitem>
- <listitem><para><emphasis>Application Development SDK:</emphasis>
- Cross-development tools that are produced along with an image
- or separately with BitBake.</para></listitem>
- </itemizedlist>
- </para>
-
- <section id="user-configuration">
- <title>User Configuration</title>
-
- <para>
- User configuration helps define the build.
- Through user configuration, you can tell BitBake the
- target architecture for which you are building the image,
- where to store downloaded source, and other build properties.
- The following figure shows an expanded representation of the
- user configuration box of the Yocto Project development
- environment:
- </para>
-
- <para>
- <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
- </para>
-
- <para>
- BitBake needs some basic configuration files in order to complete
- a build.
- These files are <filename>*.conf</filename> files.
- The minimally necessary ones reside as example files in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
- For simplicity, this section refers to the Source Directory as
- the "Poky Directory."
- </para>
-
- <para>
- When you clone the <filename>poky</filename> Git repository or you
- download and unpack a Yocto Project release, you can set up the
- Source Directory to be named anything you want.
- For this discussion, the cloned repository uses the default
- name <filename>poky</filename>.
- <note>
- The Poky repository is primarily an aggregation of existing
- repositories.
- It is not a canonical upstream source.
- </note>
- </para>
-
- <para>
- The <filename>meta-yocto</filename> layer inside Poky contains
- a <filename>conf</filename> directory that has example
- configuration files.
- These example files are used as a basis for creating actual
- configuration files when you source the build environment
- script <filename>oe-init-build-env</filename>.
- </para>
-
- <para>
- Sourcing the build environment script creates a
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
- if one does not already exist.
- BitBake uses the Build Directory for all its work during builds.
- The Build Directory has a <filename>conf</filename> directory that
- contains default versions of your <filename>local.conf</filename>
- and <filename>bblayers.conf</filename> configuration files.
- These default configuration files are created only if versions
- do not already exist in the Build Directory at the time you
- source the <filename>oe-init-build-env</filename> script.
- </para>
-
- <para>
- Because the Poky repository is fundamentally an aggregation of
- existing repositories, some users might be familiar with running
- the <filename>oe-init-build-env</filename> script in the context of
- separate OpenEmbedded-Core and BitBake repositories rather than a
- single Poky repository.
- This discussion assumes the script is executed from within a cloned
- or unpacked version of Poky.
- </para>
-
- <para>
- Depending on where the script is sourced, different sub-scripts
- are called to set up the Build Directory (Yocto or OpenEmbedded).
- Specifically, the script
- <filename>scripts/oe-setup-builddir</filename> inside the
- poky directory sets up the Build Directory and seeds the directory
- (if necessary) with configuration files appropriate for the
- Yocto Project development environment.
- <note>
- The <filename>scripts/oe-setup-builddir</filename> script
- uses the <filename>$TEMPLATECONF</filename> variable to
- determine which sample configuration files to locate.
- </note>
- </para>
-
- <para>
- The <filename>local.conf</filename> file provides many
- basic variables that define a build environment.
- Here is a list of a few.
- To see the default configurations in a <filename>local.conf</filename>
- file created by the build environment script, see the
- <filename>local.conf.sample</filename> in the
- <filename>meta-yocto</filename> layer:
- <itemizedlist>
- <listitem><para><emphasis>Parallelism Options:</emphasis>
- Controlled by the
- <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
- and
- <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
- variables.</para></listitem>
- <listitem><para><emphasis>Target Machine Selection:</emphasis>
- Controlled by the
- <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
- variable.</para></listitem>
- <listitem><para><emphasis>Download Directory:</emphasis>
- Controlled by the
- <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
- variable.</para></listitem>
- <listitem><para><emphasis>Shared State Directory:</emphasis>
- Controlled by the
- <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
- variable.</para></listitem>
- <listitem><para><emphasis>Build Output:</emphasis>
- Controlled by the
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
- variable.</para></listitem>
- </itemizedlist>
- <note>
- Configurations set in the <filename>conf/local.conf</filename>
- file can also be set in the
- <filename>conf/site.conf</filename> and
- <filename>conf/auto.conf</filename> configuration files.
- </note>
- </para>
-
- <para>
- The <filename>bblayers.conf</filename> file tells BitBake what
- layers you want considered during the build.
- By default, the layers listed in this file include layers
- minimally needed by the build system.
- However, you must manually add any custom layers you have created.
- You can find more information on working with the
- <filename>bblayers.conf</filename> file in the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
- section in the Yocto Project Development Manual.
- </para>
-
- <para>
- The files <filename>site.conf</filename> and
- <filename>auto.conf</filename> are not created by the environment
- initialization script.
- If you want these configuration files, you must create them
- yourself:
- <itemizedlist>
- <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
- You can use the <filename>conf/site.conf</filename>
- configuration file to configure multiple build directories.
- For example, suppose you had several build environments and
- they shared some common features.
- You can set these default build properties here.
- A good example is perhaps the level of parallelism you want
- to use through the
- <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
- and
- <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
- variables.</para>
- <para>One useful scenario for using the
- <filename>conf/site.conf</filename> file is to extend your
- <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
- variable to include the path to a
- <filename>conf/site.conf</filename>.
- Then, when BitBake looks for Metadata using
- <filename>BBPATH</filename>, it finds the
- <filename>conf/site.conf</filename> file and applies your
- common configurations found in the file.
- To override configurations in a particular build directory,
- alter the similar configurations within that build
- directory's <filename>conf/local.conf</filename> file.
- </para></listitem>
- <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
- This file is not hand-created.
- Rather, the file is usually created and written to by
- an autobuilder.
- The settings put into the file are typically the same as
- you would find in the <filename>conf/local.conf</filename>
- or the <filename>conf/site.conf</filename> files.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- You can edit all configuration files to further define
- any particular build environment.
- This process is represented by the "User Configuration Edits"
- box in the figure.
- </para>
-
- <para>
- When you launch your build with the
- <filename>bitbake <target></filename> command, BitBake
- sorts out the configurations to ultimately define your build
- environment.
- </para>
- </section>
-
- <section id="metadata-machine-configuration-and-policy-configuration">
- <title>Metadata, Machine Configuration, and Policy Configuration</title>
-
- <para>
- The previous section described the user configurations that
- define the BitBake's global behavior.
- This section takes a closer look at the layers the build system
- uses to further control the build.
- These layers provide Metadata for the software, machine, and
- policy.
- </para>
-
- <para>
- In general, three types of layer input exist:
- <itemizedlist>
- <listitem><para><emphasis>Policy Configuration:</emphasis>
- Distribution Layers provide top-level or general
- policies for the image or SDK being built.
- For example, this layer would dictate whether BitBake
- produces RPM or IPK packages.</para></listitem>
- <listitem><para><emphasis>Machine Configuration:</emphasis>
- Board Support Package (BSP) layers provide machine
- configurations.
- This type of information is specific to a particular
- target architecture.</para></listitem>
- <listitem><para><emphasis>Metadata:</emphasis>
- Software layers contain user-supplied recipe files,
- patches, and append files.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- The following figure shows an expanded representation of the
- Metadata, Machine Configuration, and Policy Configuration input
- (layers) boxes of the Yocto Project development environment:
- </para>
-
- <para>
- <imagedata fileref="figures/layer-input.png" align="center" width="8in" depth="7.5in" />
- </para>
-
- <para>
- In general, all layers have a similar structure.
- They all contain a licensing file
- (e.g. <filename>COPYING</filename>) if the layer is to be
- distributed, a <filename>README</filename> file as good practice
- and especially if the layer is to be distributed, a
- configuration directory, and recipe directories.
- </para>
-
- <para>
- The Yocto Project has many layers that can be used.
- You can see a web-interface listing of them on the
- <ulink url="http://git.yoctoproject.org/">Source Repositories</ulink>
- page.
- The layers are shown at the bottom categorized under
- "Yocto Metadata Layers."
- These layers are fundamentally a subset of the
- <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Metadata Index</ulink>,
- which lists all layers provided by the OpenEmbedded community.
- <note>
- Layers exist in the Yocto Project Source Repositories that
- cannot be found in the OpenEmbedded Metadata Index.
- These layers are either deprecated or experimental in nature.
- </note>
- </para>
-
- <para>
- BitBake uses the <filename>conf/bblayers.conf</filename> file,
- which is part of the user configuration, to find what layers it
- should be using as part of the build.
- </para>
-
- <para>
- For more 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 Manual.
- </para>
-
- <section id="distro-layer">
- <title>Distro Layer</title>
-
- <para>
- The distribution layer provides policy configurations for your
- distribution.
- Best practices dictate that you isolate these types of
- configurations into their own layer.
- Settings you provide in
- <filename>conf/<distro>.conf</filename> override similar
- settings that BitBake finds in your
- <filename>conf/local.conf</filename> file in the Build
- Directory.
- </para>
-
- <para>
- The following list provides some explanation and references
- for what you typically find in the distribution layer:
- <itemizedlist>
- <listitem><para><emphasis>classes:</emphasis>
- Class files (<filename>.bbclass</filename>) holds
- common functionality that can be shared among
- recipes in the distribution.
- When your recipes inherit a class, they take on the
- settings and functions for that class.
- You can read more about class files in the
- "<link linkend='ref-classes'>Classes</link>" section.
- </para></listitem>
- <listitem><para><emphasis>conf:</emphasis>
- This area holds configuration files for the
- layer (<filename>conf/layer.conf</filename>),
- the distribution
- (<filename>conf/distro/<distro>.conf</filename>),
- and any distribution-wide include files.
- </para></listitem>
- <listitem><para><emphasis>recipes-*:</emphasis>
- Recipes and append files that affect common
- functionality across the distribution.
- This area could include recipes and append files to
- to add distribution-specific configuration,
- initialization scripts, custom image recipes,
- and so forth.</para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id="bsp-layer">
- <title>BSP Layer</title>
-
- <para>
- The BSP Layer provides machine configurations.
- Everything in this layer is specific to the machine for which
- you are building the image or the SDK.
- A common structure or form is defined for BSP layers.
- You can learn more about this structure in the
- <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
- <note>
- In order for a BSP layer to be considered compliant with the
- Yocto Project, it must meet some structural requirements.
- </note>
- </para>
-
- <para>
- The BSP Layer's configuration directory contains
- configuration files for the machine
- (<filename>conf/machine/<machine>.conf</filename>) and,
- of course, the layer (<filename>conf/layer.conf</filename>).
- </para>
-
- <para>
- The remainder of the layer is dedicated to specific recipes
- by function: <filename>recipes-bsp</filename>,
- <filename>recipes-core</filename>,
- <filename>recipes-graphics</filename>, and
- <filename>recipes-kernel</filename>.
- Metadata can exist for multiple formfactors, graphics
- support systems, and so forth.
- <note>
- While the figure shows several <filename>recipe-*</filename>
- directories, not all these directories appear in all
- BSP layers.
- </note>
- </para>
- </section>
-
- <section id="software-layer">
- <title>Software Layer</title>
-
- <para>
- The software layer provides the Metadata for additional
- software packages used during the build.
- This layer does not include Metadata that is specific to the
- distribution or the machine, which are found in their
- respective layers.
- </para>
-
- <para>
- This layer contains any new recipes that your project needs
- in the form of recipe files.
- </para>
- </section>
- </section>
-
- <section id="sources-dev-environment">
- <title>Sources</title>
-
- <para>
- In order for the OpenEmbedded build system to create an image or
- any target, it must be able to access source files.
- The main
- <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment figure</link>
- represents source files using the "Upstream Project Releases",
- "Local Projects", and "SCMs (optional)" boxes.
- The figure represents mirrors, which also play a role in locating
- source files, with the "Source Mirror(s)" box.
- </para>
-
- <para>
- The method by which source files are ultimately organized is
- a function of the project.
- For example, for released software, projects tend to use tarballs
- or other archived files that can capture the state of a release
- guaranteeing that it is statically represented.
- On the other hand, for a project that is more dynamic or
- experimental in nature, a project might keep source files in a
- repository controlled by a Source Control Manager (SCM) such as
- Git.
- Pulling source from a repository allows you to control
- the point in the repository (the revision) from which you want to
- build software.
- Finally, a combination of the two might exist, which would give the
- consumer a choice when deciding where to get source files.
- </para>
-
- <para>
- BitBake uses the
- <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
- variable to point to source files regardless of their location.
- Each recipe must have a <filename>SRC_URI</filename> variable
- that points to the source.
- </para>
-
- <para>
- Another area that plays a significant role in where source files
- comes from is pointed to by the
- <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
- variable.
- This area is a cache that can hold previously downloaded source.
- Judicious use of a <filename>DL_DIR</filename> directory can
- save the build system a trip across the Internet when looking
- for files.
- A good method for using a download directory is to have
- <filename>DL_DIR</filename> point to an area outside of your
- Build Directory.
- Doing so allows you to safely delete the Build Directory
- if needed without fear of removing any downloaded source file.
- </para>
-
- <para>
- The remainder of this section provides a deeper look into the
- source files and the mirrors.
- Here is a more detailed look at the source file area of the
- base figure:
- <imagedata fileref="figures/source-input.png" align="center" width="7in" depth="7.5in" />
- </para>
-
- <section id='upstream-project-releases'>
- <title>Upstream Project Releases</title>
-
- <para>
- Upstream project releases exist anywhere in the form of an
- archived file (e.g. tarball or zip file).
- These files correspond to individual recipes.
- For example, the figure uses specific releases each for
- BusyBox, Qt, and Dbus.
- An archive file can be for any released product that can be
- built using a recipe.
- </para>
- </section>
-
- <section id='local-projects'>
- <title>Local Projects</title>
-
- <para>
- Local projects are custom bits of software the user provides.
- These bits reside somewhere local to a project - perhaps
- a directory into which the user checks in items (e.g.
- a local directory containing a development source tree
- used by the group).
- </para>
-
- <para>
- The canonical method through which to include a local project
- is to use the
- <link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>
- class to include local project.
- You use either the <filename>local.conf</filename> or a
- recipe's append file to override or set the
- recipe to point to the local directory on your disk to pull
- in the whole source tree.
- </para>
-
- <para>
- For information on how to use the
- <filename>externalsrc.bbclass</filename>, see the
- "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
- section.
- </para>
- </section>
-
- <section id='scms'>
- <title>Source Control Managers (Optional)</title>
-
- <para>
- Another place the build system can get source files from is
- through an SCM such as Git or Subversion.
- In this case, a repository is cloned or checked out.
- The <filename>do_fetch</filename> task inside BitBake uses
- the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
- variable and the argument's prefix to determine the correct
- fetcher module.
- </para>
-
- <para>
- When fetching a repository, BitBake uses the
- <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
- variable to determine the specific revision from which to
- build.
- </para>
- </section>
-
- <section id='source-mirrors'>
- <title>Source Mirror(s)</title>
-
- <para>
- Two kinds of mirrors exist: pre-mirrors and regular mirrors.
- The <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
- and
- <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
- variables point to these, respectively.
- BitBake checks pre-mirrors before looking upstream for any
- source files.
- Pre-mirrors are appropriate when you have a shared directory
- that is not a directory defined by the
- <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
- variable.
- A Pre-mirror typically points to a shared directory that is
- local to your organization.
- </para>
-
- <para>
- Regular mirrors can be any site across the Internet that is
- used as an alternative location for source code should the
- primary site not be functioning for some reason or another.
- </para>
- </section>
- </section>
-
- <section id='bitbake-dev-environment'>
- <title>BitBake</title>
-
- <para>
- The OpenEmbedded build system uses BitBake to produce images.
- You can see from the
- <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
- figure, the BitBake area consists of several functional areas.
- This section takes a closer look at each of those areas.
- </para>
-
- <section id='source-fetching-dev-environment'>
- <title>Source Fetching</title>
-
- <para>
- The first stages of building a recipe are to fetch and unpack
- the source code:
- <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="4in" />
- </para>
-
- <para>
- The <filename>do_fetch</filename> and
- <filename>do_unpack</filename> tasks fetch the source files
- and unpack them into a working directory.
- By default, everything is accomplished in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
- which has a defined structure.
- For additional general information on the Build Directory,
- see the
- "<link linkend='structure-core-build'><filename>build/</filename></link>"
- section.
- </para>
-
- <para>
- Unpacked source source files are pointed to by the
- <link linkend='var-S'><filename>S</filename></link> variable.
- Each recipe has an area in the Build Directory where the
- unpacked source code resides.
- The name of directory for any given recipe is defined from
- several different variables.
- You can see the variables that define these directories
- by looking at the figure:
- <itemizedlist>
- <listitem><para><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PN'><filename>PN</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PV'><filename>PV</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PR'><filename>PR</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-S'><filename>S</filename></link>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Briefly, the <filename>S</filename> directory contains the
- unpacked source files for a recipe.
- The <filename>WORKDIR</filename> directory is where all the
- building goes on for a given recipe.
- </para>
- </section>
-
- <section id='patching-dev-environment'>
- <title>Patching</title>
-
- <para>
- Once source code is fetched and unpacked, BitBake locates
- patch files and applies them to the source files:
- <imagedata fileref="figures/patching.png" align="center" width="6in" depth="5in" />
- </para>
-
- <para>
- The <filename>do_patch</filename> task processes recipes by
- using the
- <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
- variable to locate applicable patch files, which by default
- are <filename>*.patch</filename> or
- <filename>*.diff</filename> files, or any file if
- "apply=yes" is specified for the file in
- <filename>SRC_URI</filename>.
- </para>
-
- <para>
- BitBake finds and applies multiple patches for a single recipe
- in the order in which it finds the patches.
- Patches are applied to the recipe's source files located in the
- <link linkend='var-S'><filename>S</filename></link> directory.
- </para>
-
- <para>
- For more information on how the source directories are
- created, see the
- "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
- section.
- </para>
- </section>
-
- <section id='configuration-and-compilation-dev-environment'>
- <title>Configuration and Compilation</title>
-
- <para>
- After source code is patched, BitBake executes tasks that
- configure and compile the source code:
- <imagedata fileref="figures/configuration-compile-autoreconf.png" align="center" width="7in" depth="5in" />
- </para>
-
- <para>
- This step in the build process consists of three tasks:
- <itemizedlist>
- <listitem><para><emphasis><filename>do_configure</filename>:</emphasis>
- This task configures the source by enabling and
- disabling any build-time and configuration options for
- the software being built.
- Configurations can come from the recipe itself as well
- as from an inherited class.
- Additionally, the software itself might configure itself
- depending on the target for which it is being built.
- </para>
-
- <para>The configurations handled by the
- <filename>do_configure</filename> task are specific
- to source code configuration for the source code
- being built by the recipe.</para>
-
- <para>If you are using
- <link linkend='ref-classes-autotools'><filename>autotools.bbclass</filename></link>,
- you can add additional configuration options by using
- the <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
- variable.
- For information on how this variable works within
- that class, see the
- <filename>meta/classes/autotools.bbclass</filename>.
- </para></listitem>
- <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
- Once a configuration task has been satisfied, BitBake
- compiles the source using the
- <filename>do_compile</filename> task.
- Compilation occurs in the directory pointed to by the
- <link linkend='var-B'><filename>B</filename></link>
- variable.
- Realize that the <filename>B</filename> directory, by
- default, is the same as the
- <link linkend='var-S'><filename>S</filename></link>
- directory.</para></listitem>
- <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
- Once compilation is done, BitBake executes the
- <filename>do_install</filename> task.
- This task copies files from the <filename>B</filename>
- directory and places them in a holding area pointed to
- by the
- <link linkend='var-D'><filename>D</filename></link>
- variable.</para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='package-splitting-dev-environment'>
- <title>Package Splitting</title>
-
- <para>
- After source code is configured and compiled, the
- OpenEmbedded build system analyzes
- the results and splits the output into packages:
- <imagedata fileref="figures/analysis-for-package-splitting.png" align="center" width="7in" depth="7in" />
- </para>
-
- <para>
- The <filename>do_package</filename> and
- <filename>do_packagedata</filename> tasks combine to analyze
- the files found in the
- <link linkend='var-D'><filename>D</filename></link> directory
- and split them into subsets based on available packages and
- files.
- The analyzing process involves the following as well as other
- items: splitting out debugging symbols,
- looking at shared library dependencies between packages,
- and looking at package relationships.
- The <filename>do_packagedata</filename> task creates package
- metadata based on the analysis such that the
- OpenEmbedded build system can generate the final packages.
- Working, staged, and intermediate results of the analysis
- and package splitting process use these areas:
- <itemizedlist>
- <listitem><para><link linkend='var-PKGD'><filename>PKGD</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link>
- </para></listitem>
- <listitem><para><link linkend='var-PKGDEST'><filename>PKGDEST</filename></link>
- </para></listitem>
- </itemizedlist>
- The <link linkend='var-FILES'><filename>FILES</filename></link>
- variable defines the files that go into each package in
- <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
- If you want details on how this is accomplished, you can
- look at
- <link linkend='ref-classes-package'><filename>package.bbclass</filename></link>.
- </para>
-
- <para>
- Depending on the type of packages being created (RPM, DEB, or
- IPK), the <filename>do_package_write_*</filename> task
- creates the actual packages and places them in the
- Package Feed area, which is
- <filename>${TMPDIR}/deploy</filename>.
- You can see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section for more detail on that part of the build process.
- <note>
- Support for creating feeds directly from the
- <filename>deploy/*</filename> directories does not exist.
- Creating such feeds usually requires some kind of feed
- maintenance mechanism that would upload the new packages
- into an official package feed (e.g. the
- Ångström distribution).
- This functionality is highly distribution-specific
- and thus is not provided out of the box.
- </note>
- </para>
- </section>
- </section>
-
- <section id="package-feeds-dev-environment">
- <title>Package Feeds</title>
-
- <para>
- When the OpenEmbedded build system generates an image or an SDK,
- it gets the packages from a package feed area located in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
- The main
- <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
- figure shows this package feeds area in the upper-right corner.
- </para>
-
- <para>
- This section looks a little closer into the package feeds area used
- by the build system.
- Here is a more detailed look at the area:
- <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
- </para>
-
- <para>
- Package feeds are an intermediary step in the build process.
- BitBake generates packages whose type is defined by the
- <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
- variable.
- Before placing the packages into package feeds,
- the build process validates them with generated output quality
- assurance checks through the
- <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
- class.
- </para>
-
- <para>
- The package feed area resides in
- <filename>tmp/deploy</filename> of the Build Directory.
- Folders are created that correspond to the package type
- (IPK, DEB, or RPM) created.
- Further organization is derived through the value of the
- <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
- variable for each package.
- For example, packages can exist for the i586 or qemux86
- architectures.
- The package files themselves reside within the appropriate
- architecture folder.
- </para>
-
- <para>
- BitBake uses the <filename>do_package_write_*</filename> task to
- place generated packages into the package holding area (e.g.
- <filename>do_package_write_ipk</filename> for IPK packages).
- </para>
- </section>
-
- <section id='images-dev-environment'>
- <title>Images</title>
-
- <para>
- The images produced by the OpenEmbedded build system
- are compressed forms of the
- root filesystems that are ready to boot on a target device.
- You can see from the main
- <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
- figure that BitBake output in part consists of images.
- This section is going to look more closely at this output:
- <imagedata fileref="figures/images.png" align="center" width="6in" depth="5in" />
- </para>
-
- <para>
- For a list of example images that the Yocto Project provides,
- the
- "<link linkend='ref-images'>Images</link>" chapter.
- </para>
-
- <para>
- Images are written out to the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
- inside the <filename>deploy/images</filename> folder as shown
- in the figure.
- This folder contains any files expected to be loaded on the
- target device.
- The
- <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
- variable points to the <filename>deploy</filename> directory.
- <itemizedlist>
- <listitem><para><filename><kernel-image></filename>:
- A kernel binary file.
- The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
- variable setting determines the naming scheme for the
- kernel image file.
- Depending on that variable, the file could begin with
- a variety of naming strings.
- The <filename>deploy/images</filename> directory can
- contain multiple image files.</para></listitem>
- <listitem><para><filename><root-filesystem-image></filename>:
- Root filesystems for the target device (e.g.
- <filename>*.ext3</filename> or <filename>*.bz2</filename>
- files).
- The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
- variable setting determines the root filesystem image
- type.
- The <filename>deploy/images</filename> directory can
- contain multiple root filesystems.</para></listitem>
- <listitem><para><filename><kernel-modules></filename>:
- Tarballs that contain all the modules built for the kernel.
- Kernel module tarballs exist for legacy purposes and
- can be suppressed by setting the
- <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
- variable to "0".
- The <filename>deploy/images</filename> directory can
- contain multiple kernel module tarballs.
- </para></listitem>
- <listitem><para><filename><bootloaders></filename>:
- Bootloaders supporting the image, if applicable to the
- target machine.
- The <filename>deploy/images</filename> directory can
- contain multiple bootloaders.
- </para></listitem>
- <listitem><para><filename><symlinks></filename>:
- The <filename>deploy/images</filename> folder contains
- a symbolic link that points to the most recently built file
- for each machine.
- These links might be useful for external scripts that
- need to obtain the latest version of each file.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='sdk-dev-environment'>
- <title>Application Development SDK</title>
-
- <para>
- In the overview figure of the
- <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
- the output labeled "Application Development SDK" represents an
- SDK.
- This section is going to take a closer look at this output:
- <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
- </para>
-
- <para>
- The specific form of this output is a self-extracting
- SDK installer (<filename>*.sh</filename>) that, when run,
- installs the SDK, which consists of a cross-development
- toolchain, a set of libraries and headers, and an SDK
- environment setup script.
- Running this installer essentially sets up your
- cross-development environment.
- You can think of the cross-toolchain as the "host"
- part because it runs on the SDK machine.
- You can think of the libraries and headers as the "target"
- part because they are built for the target hardware.
- The setup script is added so that you can initialize the
- environment before using the tools.
- </para>
-
- <note>
- <para>
- The Yocto Project supports several methods by which you can
- set up this cross-development environment.
- These methods include downloading pre-built SDK installers,
- building and installing your own SDK installer, or running
- an Application Development Toolkit (ADT) installer to
- install not just cross-development toolchains
- but also additional tools to help in this type of
- development.
- </para>
-
- <para>
- For background information on cross-development toolchains
- in the Yocto Project development environment, see the
- "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
- section.
- For information on setting up a cross-development
- environment, see the
- "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
- section in the Yocto Project Application Developer's Guide.
- </para>
- </note>
-
- <para>
- Once built, the SDK installers are written out to the
- <filename>deploy/sdk</filename> folder inside the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
- as shown in the figure at the beginning of this section.
- Several variables exist that help configure these files:
- <itemizedlist>
- <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
- Points to the <filename>deploy</filename>
- directory.</para></listitem>
- <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
- Specifies the architecture of the machine
- on which the cross-development tools are run to
- create packages for the target hardware.
- </para></listitem>
- <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
- Lists the features to include in the "target" part
- of the SDK.
- </para></listitem>
- <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
- Lists packages that make up the host
- part of the SDK (i.e. the part that runs on
- the <filename>SDKMACHINE</filename>).
- When you use
- <filename>bitbake -c populate_sdk <imagename></filename>
- to create the SDK, a set of default packages
- apply.
- This variable allows you to add more packages.
- </para></listitem>
- <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
- Lists packages that make up the target part
- of the SDK (i.e. the part built for the
- target hardware).
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-</section>
-
<section id="cross-development-toolchain-generation">
<title>Cross-Development Toolchain Generation</title>
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
