Yocto 2.5
Move OpenBMC to Yocto 2.5(sumo)
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Change-Id: I5c5ad6904a16e14c1c397f0baf10c9d465594a78
diff --git a/import-layers/yocto-poky/documentation/ref-manual/faq.xml b/import-layers/yocto-poky/documentation/ref-manual/faq.xml
index 11dfc5b..49ff862 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/faq.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/faq.xml
@@ -143,7 +143,7 @@
To add a package, you need to create a BitBake recipe.
For information on how to create a BitBake recipe, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe'>Writing a New Recipe</ulink>"
- in the Yocto Project Development Tasks Manual.
+ section in the Yocto Project Development Tasks Manual.
</para>
</answer>
</qandaentry>
@@ -417,10 +417,11 @@
<para>
You can find more information on licensing in the
- "<link linkend='licensing'>Licensing</link>" section and in the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#licensing'>Licensing</ulink>"
+ section in the Yocto Project Overview and Concepts Manual
+ and also in the
"<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
- section, which is in the Yocto Project Development Tasks
- Manual.
+ section in the Yocto Project Development Tasks Manual.
</para>
</answer>
</qandaentry>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/YP-flow-diagram.png b/import-layers/yocto-poky/documentation/ref-manual/figures/YP-flow-diagram.png
deleted file mode 100644
index 8264410..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/YP-flow-diagram.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/analysis-for-package-splitting.png b/import-layers/yocto-poky/documentation/ref-manual/figures/analysis-for-package-splitting.png
deleted file mode 100644
index 04f2794..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/analysis-for-package-splitting.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/buildhistory-web.png b/import-layers/yocto-poky/documentation/ref-manual/figures/buildhistory-web.png
deleted file mode 100644
index f6db86c..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/buildhistory-web.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/buildhistory.png b/import-layers/yocto-poky/documentation/ref-manual/figures/buildhistory.png
deleted file mode 100644
index bd5f8a4..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/buildhistory.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/building-an-image.png b/import-layers/yocto-poky/documentation/ref-manual/figures/building-an-image.png
deleted file mode 100755
index 1fbea5a..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/building-an-image.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/configuration-compile-autoreconf.png b/import-layers/yocto-poky/documentation/ref-manual/figures/configuration-compile-autoreconf.png
deleted file mode 100644
index a07464f..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/configuration-compile-autoreconf.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/cross-development-toolchains.png b/import-layers/yocto-poky/documentation/ref-manual/figures/cross-development-toolchains.png
deleted file mode 100644
index d36670a..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/cross-development-toolchains.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/git-workflow.png b/import-layers/yocto-poky/documentation/ref-manual/figures/git-workflow.png
deleted file mode 100644
index e401330..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/git-workflow.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/image-generation.png b/import-layers/yocto-poky/documentation/ref-manual/figures/image-generation.png
deleted file mode 100644
index 71a48dc..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/image-generation.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/images.png b/import-layers/yocto-poky/documentation/ref-manual/figures/images.png
deleted file mode 100644
index d99eac1..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/images.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/index-downloads.png b/import-layers/yocto-poky/documentation/ref-manual/figures/index-downloads.png
deleted file mode 100644
index 96303b8..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/index-downloads.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/layer-input.png b/import-layers/yocto-poky/documentation/ref-manual/figures/layer-input.png
deleted file mode 100644
index 0a4f2e7..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/layer-input.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/package-feeds.png b/import-layers/yocto-poky/documentation/ref-manual/figures/package-feeds.png
deleted file mode 100644
index 37c9c32..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/package-feeds.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/patching.png b/import-layers/yocto-poky/documentation/ref-manual/figures/patching.png
deleted file mode 100644
index 8ecd018..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/patching.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/sdk-generation.png b/import-layers/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
deleted file mode 100755
index adbe1f4..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/sdk.png b/import-layers/yocto-poky/documentation/ref-manual/figures/sdk.png
deleted file mode 100644
index 5c36b75..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/sdk.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/source-fetching.png b/import-layers/yocto-poky/documentation/ref-manual/figures/source-fetching.png
deleted file mode 100644
index 26aefb5..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/source-fetching.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/source-input.png b/import-layers/yocto-poky/documentation/ref-manual/figures/source-input.png
deleted file mode 100644
index f751505..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/source-input.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/source-repos.png b/import-layers/yocto-poky/documentation/ref-manual/figures/source-repos.png
deleted file mode 100644
index e9cff16..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/source-repos.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/user-configuration.png b/import-layers/yocto-poky/documentation/ref-manual/figures/user-configuration.png
deleted file mode 100755
index c298401..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/user-configuration.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/yocto-environment-ref.png b/import-layers/yocto-poky/documentation/ref-manual/figures/yocto-environment-ref.png
deleted file mode 100644
index 650c6c8..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/yocto-environment-ref.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/figures/yp-download.png b/import-layers/yocto-poky/documentation/ref-manual/figures/yp-download.png
deleted file mode 100644
index 5770be6..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/figures/yp-download.png
+++ /dev/null
Binary files differ
diff --git a/import-layers/yocto-poky/documentation/ref-manual/introduction.xml b/import-layers/yocto-poky/documentation/ref-manual/introduction.xml
deleted file mode 100644
index 29ef2d5..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/introduction.xml
+++ /dev/null
@@ -1,1084 +0,0 @@
-<!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='ref-manual-intro'>
-<title>Introduction</title>
-
-<section id='ref-welcome'>
- <title>Welcome</title>
-
- <para>
- Welcome to the Yocto Project Reference Manual.
- This manual provides reference information for the current release
- of the Yocto Project.
- This manual is best used after you have an understanding
- of the basics of the Yocto Project.
- The manual is neither meant to be read as a starting point to the
- Yocto Project nor read from start to finish.
- Use this manual to find concepts, variable definitions, class
- descriptions, and so forth as needed during the course of using
- the Yocto Project.
- </para>
-
- <para>
- For introductory information on the Yocto Project, see the
- <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and the
- "<link linkend='yp-intro'>Introducing the Yocto Project Development Environment</link>"
- section.
- </para>
-
- <para>
- If you want to use the Yocto Project to test run building an image
- without having to understand concepts, work through the
- <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
- You can find "how-to" information in the
- <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Tasks Manual</ulink>.
- <note><title>Tip</title>
- For more information about the Yocto Project Documentation set,
- see the
- "<link linkend='resources-links-and-related-documentation'>Links and Related Documentation</link>"
- section.
- </note>
- </para>
-</section>
-
-<section id='yp-intro'>
- <title>Introducing the Yocto Project Development Environment</title>
-
- <para>
- The Yocto Project is an open-source collaboration project whose
- focus is for developers of embedded Linux systems.
- Among other things, the Yocto Project uses an
- <link linkend='build-system-term'>OpenEmbedded build system</link>.
- The build system, which is based on the OpenEmbedded (OE) project and
- uses the
- <link linkend='bitbake-term'>BitBake</link> tool, constructs complete
- Linux images for architectures based on ARM, MIPS, PowerPC, x86 and
- x86-64.
- <note>
- Historically, the OpenEmbedded build system, which is the
- combination of BitBake and OE components, formed a reference
- build host that was known as
- "<link linkend='poky'>Poky</link>" (<emphasis>Pah</emphasis>-kee).
- The term "Poky", as used throughout the Yocto Project Documentation
- set, can have different meanings.
- </note>
- The Yocto Project provides various ancillary tools for the embedded
- developer and also features the Sato reference User Interface, which
- is optimized for stylus-driven, low-resolution screens.
- </para>
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="figures/YP-flow-diagram.png"
- format="PNG" align='center' width="8in"/>
- </imageobject>
- </mediaobject>
-
- <para>
- Here are some highlights for the Yocto Project:
- </para>
-
- <itemizedlist>
- <listitem><para>
- Provides a recent Linux kernel along with a set of system
- commands and libraries suitable for the embedded
- environment.
- </para></listitem>
- <listitem><para>
- Makes available system components such as X11, GTK+, Qt,
- Clutter, and SDL (among others) so you can create a rich user
- experience on devices that have display hardware.
- For devices that do not have a display or where you wish to
- use alternative UI frameworks, these components need not be
- installed.
- </para></listitem>
- <listitem><para>
- Creates a focused and stable core compatible with the
- OpenEmbedded project with which you can easily and reliably
- build and develop.
- </para></listitem>
- <listitem><para>
- Fully supports a wide range of hardware and device emulation
- through the Quick EMUlator (QEMU).
- </para></listitem>
- <listitem><para>
- Provides a layer mechanism that allows you to easily extend
- the system, make customizations, and keep them organized.
- </para></listitem>
- </itemizedlist>
-
- <para>
- You can use the Yocto Project to generate images for many kinds
- of devices.
- As mentioned earlier, the Yocto Project supports creation of
- reference images that you can boot within and emulate using QEMU.
- The standard example machines target QEMU full-system
- emulation for 32-bit and 64-bit variants of x86, ARM, MIPS, and
- PowerPC architectures.
- Beyond emulation, you can use the layer mechanism to extend
- support to just about any platform that Linux can run on and that
- a toolchain can target.
- </para>
-
- <para>
- Another Yocto Project feature is the Sato reference User
- Interface.
- This optional UI that is based on GTK+ is intended for devices with
- restricted screen sizes and is included as part of the
- OpenEmbedded Core layer so that developers can test parts of the
- software stack.
- </para>
-
- <para>
- While the Yocto Project does not provide a strict testing framework,
- it does provide or generate for you artifacts that let you perform
- target-level and emulated testing and debugging.
- Additionally, if you are an
- <trademark class='trade'>Eclipse</trademark> IDE user, you can
- install an Eclipse Yocto Plug-in to allow you to develop within that
- familiar environment.
- </para>
-
- <para>
- By default, using the Yocto Project to build an image creates a Poky
- distribution.
- However, you can create your own distribution by providing key
- <link link='metadata'>Metadata</link>.
- A good example is Angstrom, which has had a distribution
- based on the Yocto Project since its inception.
- Other examples include commercial distributions like
- <ulink url='https://www.yoctoproject.org/organization/wind-river-systems'>Wind River Linux</ulink>,
- <ulink url='https://www.yoctoproject.org/organization/mentor-graphics'>Mentor Embedded Linux</ulink>,
- <ulink url='https://www.yoctoproject.org/organization/enea-ab'>ENEA Linux</ulink>
- and <ulink url='https://www.yoctoproject.org/ecosystem/member-organizations'>others</ulink>.
- See the "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-your-own-distribution'>Creating Your Own Distribution</ulink>"
- section in the Yocto Project Development Tasks Manual for more
- information.
- </para>
-</section>
-
-<section id='intro-requirements'>
-<title>System Requirements</title>
- <para>
- For general Yocto Project system requirements, see the
- "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>" section
- in the Yocto Project Quick Start.
- The remainder of this section provides details on system requirements
- not covered in the Yocto Project Quick Start.
- </para>
-
- <section id='detailed-supported-distros'>
- <title>Supported Linux Distributions</title>
-
- <para>
- Currently, the Yocto Project is supported on the following
- distributions:
- <note>
- <para>
- Yocto Project releases are tested against the stable Linux
- distributions in the following list.
- The Yocto Project should work on other distributions but
- validation is not performed against them.
- </para>
-
- <para>
- In particular, the Yocto Project does not support
- and currently has no plans to support
- rolling-releases or development distributions due to their
- constantly changing nature.
- We welcome patches and bug reports, but keep in mind that
- our priority is on the supported platforms listed below.
- </para>
-
- <para>
- If you encounter problems, please go to
- <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
- and submit a bug.
- We are interested in hearing about your experience.
- </para>
- </note>
- <itemizedlist>
-<!--
- <listitem><para>Ubuntu 10.04</para></listitem>
- <listitem><para>Ubuntu 11.10</para></listitem>
- <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
- <listitem><para>Ubuntu 13.10</para></listitem>
- <listitem><para>Ubuntu 14.04 (LTS)</para></listitem> -->
- <listitem><para>Ubuntu 14.10</para></listitem>
- <listitem><para>Ubuntu 15.04</para></listitem>
- <listitem><para>Ubuntu 15.10</para></listitem>
- <listitem><para>Ubuntu 16.04 (LTS)</para></listitem>
-<!-- <listitem><para>Fedora 16 (Verne)</para></listitem>
- <listitem><para>Fedora 17 (Spherical)</para></listitem>
- <listitem><para>Fedora release 19 (Schrödinger's Cat)</para></listitem>
- <listitem><para>Fedora release 20 (Heisenbug)</para></listitem> -->
- <listitem><para>Fedora release 22</para></listitem>
- <listitem><para>Fedora release 23</para></listitem>
- <listitem><para>Fedora release 24</para></listitem>
-<!-- <listitem><para>CentOS release 5.6 (Final)</para></listitem>
- <listitem><para>CentOS release 5.7 (Final)</para></listitem>
- <listitem><para>CentOS release 5.8 (Final)</para></listitem>
- <listitem><para>CentOS release 6.3 (Final)</para></listitem>
- <listitem><para>CentOS release 6.x</para></listitem> -->
- <listitem><para>CentOS release 7.x</para></listitem>
-<!-- <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.x (Wheezy)</para></listitem> -->
- <listitem><para>Debian GNU/Linux 8.x (Jessie)</para></listitem>
- <listitem><para>Debian GNU/Linux 9.x (Stretch)</para></listitem>
-<!-- <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.5 (Wheezy)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem> -->
-<!-- <listitem><para>openSUSE 11.4</para></listitem>
- <listitem><para>openSUSE 12.1</para></listitem>
- <listitem><para>openSUSE 12.2</para></listitem>
- <listitem><para>openSUSE 12.3</para></listitem>
- <listitem><para>openSUSE 13.1</para></listitem> -->
- <listitem><para>openSUSE 13.2</para></listitem>
- <listitem><para>openSUSE 42.1</para></listitem>
- </itemizedlist>
- </para>
-
- <note>
- While the Yocto Project Team attempts to ensure all Yocto Project
- releases are one hundred percent compatible with each officially
- supported Linux distribution, instances might exist where you
- encounter a problem while using the Yocto Project on a specific
- distribution.
- </note>
- </section>
-
- <section id='required-packages-for-the-host-development-system'>
- <title>Required Packages for the Host Development System</title>
-
- <para>
- The list of packages you need on the host development system can
- be large when covering all build scenarios using the Yocto Project.
- This section provides required packages according to
- Linux distribution and function.
- </para>
-
- <section id='ubuntu-packages'>
- <title>Ubuntu and Debian</title>
-
- <para>
- The following list shows the required packages by function
- given a supported Ubuntu or Debian Linux distribution:
- <note>
- If your build system has the
- <filename>oss4-dev</filename> package installed, you
- might experience QEMU build failures due to the package
- installing its own custom
- <filename>/usr/include/linux/soundcard.h</filename> on
- the Debian system.
- If you run into this situation, either of the following
- solutions exist:
- <literallayout class='monospaced'>
- $ sudo apt-get build-dep qemu
- $ sudo apt-get remove oss4-dev
- </literallayout>
- </note>
- <itemizedlist>
- <listitem><para><emphasis>Essentials:</emphasis>
- Packages needed to build an image on a headless
- system:
- <literallayout class='monospaced'>
- $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
- </literallayout></para></listitem>
- <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
- Packages recommended if the host system has graphics
- support or if you are going to use the Eclipse
- IDE:
- <literallayout class='monospaced'>
- $ sudo apt-get install libsdl1.2-dev xterm
- </literallayout></para></listitem>
- <listitem><para><emphasis>Documentation:</emphasis>
- Packages needed if you are going to build out the
- Yocto Project documentation manuals:
- <literallayout class='monospaced'>
- $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
- </literallayout></para></listitem>
- <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
- Packages needed if you are going to run
- <filename>oe-selftest</filename>:
- <literallayout class='monospaced'>
- $ sudo apt-get install python-git
- </literallayout>
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='fedora-packages'>
- <title>Fedora Packages</title>
-
- <para>
- The following list shows the required packages by function
- given a supported Fedora Linux distribution:
- <itemizedlist>
- <listitem><para><emphasis>Essentials:</emphasis>
- Packages needed to build an image for a headless
- system:
- <literallayout class='monospaced'>
- $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
- </literallayout></para></listitem>
- <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
- Packages recommended if the host system has graphics
- support or if you are going to use the Eclipse
- IDE:
- <literallayout class='monospaced'>
- $ sudo dnf install SDL-devel xterm
- </literallayout></para></listitem>
- <listitem><para><emphasis>Documentation:</emphasis>
- Packages needed if you are going to build out the
- Yocto Project documentation manuals:
- <literallayout class='monospaced'>
- $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
- docbook-dtds docbook-utils fop libxslt dblatex xmlto
- </literallayout></para></listitem>
- <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
- Packages needed if you are going to run
- <filename>oe-selftest</filename>:
- <literallayout class='monospaced'>
- $ sudo dnf install python3-GitPython
- </literallayout>
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='opensuse-packages'>
- <title>openSUSE Packages</title>
-
- <para>
- The following list shows the required packages by function
- given a supported openSUSE Linux distribution:
- <itemizedlist>
- <listitem><para><emphasis>Essentials:</emphasis>
- Packages needed to build an image for a headless
- system:
- <literallayout class='monospaced'>
- $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
- </literallayout></para></listitem>
- <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
- Packages recommended if the host system has graphics
- support or if you are going to use the Eclipse
- IDE:
- <literallayout class='monospaced'>
- $ sudo zypper install libSDL-devel xterm
- </literallayout></para></listitem>
- <listitem><para><emphasis>Documentation:</emphasis>
- Packages needed if you are going to build out the
- Yocto Project documentation manuals:
- <literallayout class='monospaced'>
- $ sudo zypper install make dblatex xmlto
- </literallayout></para></listitem>
- <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
- Packages needed if you are going to run
- <filename>oe-selftest</filename>:
- <literallayout class='monospaced'>
- $ sudo zypper install python-GitPython
- </literallayout></para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='centos-packages'>
- <title>CentOS Packages</title>
-
- <para>
- The following list shows the required packages by function
- given a supported CentOS Linux distribution:
- <itemizedlist>
- <listitem><para><emphasis>Essentials:</emphasis>
- Packages needed to build an image for a headless
- system:
- <literallayout class='monospaced'>
- $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
- </literallayout>
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- Extra Packages for Enterprise Linux
- (i.e. <filename>epel-release</filename>)
- is a collection of packages from Fedora
- built on RHEL/CentOS for easy installation
- of packages not included in enterprise
- Linux by default.
- You need to install these packages
- separately.
- </para></listitem>
- <listitem><para>
- The <filename>makecache</filename> command
- consumes additional Metadata from
- <filename>epel-release</filename>.
- </para></listitem>
- </itemizedlist>
- </note>
- </para></listitem>
- <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
- Packages recommended if the host system has graphics
- support or if you are going to use the Eclipse
- IDE:
- <literallayout class='monospaced'>
- $ sudo yum install SDL-devel xterm
- </literallayout></para></listitem>
- <listitem><para><emphasis>Documentation:</emphasis>
- Packages needed if you are going to build out the
- Yocto Project documentation manuals:
- <literallayout class='monospaced'>
- $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
- docbook-dtds docbook-utils fop libxslt dblatex xmlto
- </literallayout></para></listitem>
- <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
- Packages needed if you are going to run
- <filename>oe-selftest</filename>:
- <literallayout class='monospaced'>
- $ sudo yum install GitPython
- </literallayout>
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
- </section>
-
- <section id='required-git-tar-and-python-versions'>
- <title>Required Git, tar, and Python Versions</title>
-
- <para>
- In order to use the build system, your host development system
- must meet the following version requirements for Git, tar, and
- Python:
- <itemizedlist>
- <listitem><para>Git 1.8.3.1 or greater</para></listitem>
- <listitem><para>tar 1.27 or greater</para></listitem>
- <listitem><para>Python 3.4.0 or greater</para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- If your host development system does not meet all these requirements,
- you can resolve this by installing a <filename>buildtools</filename>
- tarball that contains these tools.
- You can get the tarball one of two ways: download a pre-built
- tarball or use BitBake to build the tarball.
- </para>
-
- <section id='downloading-a-pre-built-buildtools-tarball'>
- <title>Downloading a Pre-Built <filename>buildtools</filename> Tarball</title>
-
- <para>
- Downloading and running a pre-built buildtools installer is
- the easiest of the two methods by which you can get these tools:
- <orderedlist>
- <listitem><para>
- Locate and download the <filename>*.sh</filename> at
- <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
- </para></listitem>
- <listitem><para>
- Execute the installation script.
- Here is an example:
- <literallayout class='monospaced'>
- $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
- </literallayout>
- During execution, a prompt appears that allows you to
- choose the installation directory.
- For example, you could choose the following:
- <literallayout class='monospaced'>
- /home/<replaceable>your-username</replaceable>/buildtools
- </literallayout>
- </para></listitem>
- <listitem><para>
- Source the tools environment setup script by using a
- command like the following:
- <literallayout class='monospaced'>
- $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-i586-poky-linux
- </literallayout>
- Of course, you need to supply your installation directory and be
- sure to use the right file (i.e. i585 or x86-64).
- </para>
- <para>
- After you have sourced the setup script,
- the tools are added to <filename>PATH</filename>
- and any other environment variables required to run the
- tools are initialized.
- The results are working versions versions of Git, tar,
- Python and <filename>chrpath</filename>.
- </para></listitem>
- </orderedlist>
- </para>
- </section>
-
- <section id='building-your-own-buildtools-tarball'>
- <title>Building Your Own <filename>buildtools</filename> Tarball</title>
-
- <para>
- Building and running your own buildtools installer applies
- only when you have a build host that can already run BitBake.
- In this case, you use that machine to build the
- <filename>.sh</filename> file and then
- take steps to transfer and run it on a
- machine that does not meet the minimal Git, tar, and Python
- requirements.
- </para>
-
- <para>
- Here are the steps to take to build and run your own
- buildtools installer:
- <orderedlist>
- <listitem><para>
- On the machine that is able to run BitBake,
- be sure you have set up your build environment with
- the setup script
- (<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
- </para></listitem>
- <listitem><para>
- Run the BitBake command to build the tarball:
- <literallayout class='monospaced'>
- $ bitbake buildtools-tarball
- </literallayout>
- <note>
- The
- <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>
- variable in your <filename>local.conf</filename> file
- determines whether you build tools for a 32-bit
- or 64-bit system.
- </note>
- Once the build completes, you can find the
- <filename>.sh</filename> file that installs
- the tools in the <filename>tmp/deploy/sdk</filename>
- subdirectory of the
- <link linkend='build-directory'>Build Directory</link>.
- The installer file has the string "buildtools"
- in the name.
- </para></listitem>
- <listitem><para>
- Transfer the <filename>.sh</filename> file from the
- build host to the machine that does not meet the
- Git, tar, or Python requirements.
- </para></listitem>
- <listitem><para>
- On the machine that does not meet the requirements,
- run the <filename>.sh</filename> file
- to install the tools.
- Here is an example:
- <literallayout class='monospaced'>
- $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
- </literallayout>
- During execution, a prompt appears that allows you to
- choose the installation directory.
- For example, you could choose the following:
- <literallayout class='monospaced'>
- /home/<replaceable>your_username</replaceable>/buildtools
- </literallayout>
- </para></listitem>
- <listitem><para>
- Source the tools environment setup script by using a
- command like the following:
- <literallayout class='monospaced'>
- $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-i586-poky-linux
- </literallayout>
- Of course, you need to supply your installation directory and be
- sure to use the right file (i.e. i585 or x86-64).
- </para>
- <para>
- After you have sourced the setup script,
- the tools are added to <filename>PATH</filename>
- and any other environment variables required to run the
- tools are initialized.
- The results are working versions versions of Git, tar,
- Python and <filename>chrpath</filename>.
- </para></listitem>
- </orderedlist>
- </para>
- </section>
- </section>
-</section>
-
-<section id='intro-getit'>
- <title>Obtaining the Yocto Project</title>
- <para>
- The Yocto Project development team makes the Yocto Project available through a number
- of methods:
- <itemizedlist>
- <listitem><para><emphasis>Source Repositories:</emphasis>
- Working from a copy of the upstream
- <filename>poky</filename> repository is the
- preferred method for obtaining and using a Yocto Project
- release.
- You can view the Yocto Project Source Repositories at
- <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
- In particular, you can find the
- <filename>poky</filename> repository at
- <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/'></ulink>.
- </para></listitem>
- <listitem><para><emphasis>Releases:</emphasis> Stable, tested
- releases are available as tarballs through
- <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
- <listitem><para><emphasis>Nightly Builds:</emphasis> These
- tarball releases are available at
- <ulink url='&YOCTO_AB_NIGHTLY_URL;'/>.
- These builds include Yocto Project releases, SDK installation
- scripts, and experimental builds.
- </para></listitem>
- <listitem><para><emphasis>Yocto Project Website:</emphasis> You can
- find tarball releases of the Yocto Project and supported BSPs
- at the
- <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
- Along with these downloads, you can find lots of other
- information at this site.
- </para></listitem>
- </itemizedlist>
- </para>
-</section>
-
-<section id='intro-getit-dev'>
- <title>Development Checkouts</title>
- <para>
- Development using the Yocto Project requires a local
- <link linkend='source-directory'>Source Directory</link>.
- You can set up the Source Directory by cloning a copy of the upstream
- <link linkend='poky'>poky</link> Git repository.
- For information on how to do this, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para>
-</section>
-
-<section id='yocto-project-terms'>
- <title>Yocto Project Terms</title>
-
- <para>
- Following is a list of terms and definitions users new to the Yocto
- Project development environment might find helpful.
- While some of these terms are universal, the list includes them
- just in case:
- <itemizedlist>
- <listitem><para>
- <emphasis>Append Files:</emphasis>
- Files that append build information to a recipe file.
- Append files are known as BitBake append files and
- <filename>.bbappend</filename> files.
- The OpenEmbedded build system expects every append file to have
- a corresponding recipe (<filename>.bb</filename>) file.
- Furthermore, the append file and corresponding recipe file
- must use the same root filename.
- The filenames can differ only in the file type suffix used
- (e.g.
- <filename>formfactor_0.0.bb</filename> and
- <filename>formfactor_0.0.bbappend</filename>).</para>
-
- <para>Information in append files extends or overrides the
- information in the similarly-named recipe file.
- For an example of an append file in use, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
- section in the Yocto Project Development Tasks Manual.
- <note>
- Append files can also use wildcard patterns in their
- version numbers so they can be applied to more than one
- version of the underlying recipe file.
- </note>
- </para></listitem>
- <listitem><para id='bitbake-term'>
- <emphasis>BitBake:</emphasis>
- The task executor and scheduler used by the OpenEmbedded build
- system to build images.
- For more information on BitBake, see the
- <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
- </para></listitem>
- <listitem><para id='board-support-package-bsp-term'>
- <emphasis>Board Support Package (BSP):</emphasis>
- A group of drivers, definitions, and other components that
- provide support for a specific hardware configuration.
- For more information on BSPs, see the
- <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
- </para></listitem>
- <listitem>
- <para id='build-directory'>
- <emphasis>Build Directory:</emphasis>
- This term refers to the area used by the OpenEmbedded build
- system for builds.
- The area is created when you <filename>source</filename> the
- setup environment script that is found in the Source Directory
- (i.e. <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
- The
- <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link>
- variable points to the Build Directory.</para>
-
- <para>You have a lot of flexibility when creating the Build
- Directory.
- Following are some examples that show how to create the
- directory.
- The examples assume your
- <link linkend='source-directory'>Source Directory</link> is
- named <filename>poky</filename>:
- <itemizedlist>
- <listitem><para>Create the Build Directory inside your
- Source Directory and let the name of the Build
- Directory default to <filename>build</filename>:
- <literallayout class='monospaced'>
- $ cd $HOME/poky
- $ source &OE_INIT_FILE;
- </literallayout>
- </para></listitem>
- <listitem><para>Create the Build Directory inside your
- home directory and specifically name it
- <filename>test-builds</filename>:
- <literallayout class='monospaced'>
- $ cd $HOME
- $ source poky/&OE_INIT_FILE; test-builds
- </literallayout>
- </para></listitem>
- <listitem><para>
- Provide a directory path and specifically name the
- Build Directory.
- Any intermediate folders in the pathname must exist.
- This next example creates a Build Directory named
- <filename>YP-&POKYVERSION;</filename>
- in your home directory within the existing
- directory <filename>mybuilds</filename>:
- <literallayout class='monospaced'>
- $cd $HOME
- $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
- </literallayout>
- </para></listitem>
- </itemizedlist>
- <note>
- By default, the Build Directory contains
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
- which is a temporary directory the build system uses for
- its work.
- <filename>TMPDIR</filename> cannot be under NFS.
- Thus, by default, the Build Directory cannot be under NFS.
- However, if you need the Build Directory to be under NFS,
- you can set this up by setting <filename>TMPDIR</filename>
- in your <filename>local.conf</filename> file
- to use a local drive.
- Doing so effectively separates <filename>TMPDIR</filename>
- from <filename>TOPDIR</filename>, which is the Build
- Directory.
- </note>
- </para></listitem>
- <listitem><para id='hardware-build-system-term'>
- <emphasis>Build System:</emphasis>
- The system used to build images in a Yocto Project
- Development environment.
- The build system is sometimes referred to as the
- development host.
- </para></listitem>
- <listitem><para>
- <emphasis>Classes:</emphasis>
- Files that provide for logic encapsulation and inheritance so
- that commonly used patterns can be defined once and then
- easily used in multiple recipes.
- For reference information on the Yocto Project classes, see the
- "<link linkend='ref-classes'>Classes</link>" chapter.
- Class files end with the <filename>.bbclass</filename>
- filename extension.
- </para></listitem>
- <listitem><para>
- <emphasis>Configuration File:</emphasis>
- Configuration information in various <filename>.conf</filename>
- files provides global definitions of variables.
- The <filename>conf/local.conf</filename> configuration file in
- the
- <link linkend='build-directory'>Build Directory</link>
- contains user-defined variables that affect every build.
- The <filename>meta-poky/conf/distro/poky.conf</filename>
- configuration file defines Yocto "distro" configuration
- variables used only when building with this policy.
- Machine configuration files, which
- are located throughout the
- <link linkend='source-directory'>Source Directory</link>, define
- variables for specific hardware and are only used when building
- for that target (e.g. the
- <filename>machine/beaglebone.conf</filename> configuration
- file defines variables for the Texas Instruments ARM Cortex-A8
- development board).
- Configuration files end with a <filename>.conf</filename>
- filename extension.
- </para></listitem>
- <listitem><para id='cross-development-toolchain'>
- <emphasis>Cross-Development Toolchain:</emphasis>
- In general, a cross-development toolchain is a collection of
- software development tools and utilities that run on one
- architecture and allow you to develop software for a
- different, or targeted, architecture.
- These toolchains contain cross-compilers, linkers, and
- debuggers that are specific to the target architecture.</para>
-
- <para>The Yocto Project supports two different cross-development
- toolchains:
- <itemizedlist>
- <listitem><para>
- A toolchain only used by and within
- BitBake when building an image for a target
- architecture.
- </para></listitem>
- <listitem><para>A relocatable toolchain used outside of
- BitBake by developers when developing applications
- that will run on a targeted device.
- </para></listitem>
- </itemizedlist></para>
-
- <para>Creation of these toolchains is simple and automated.
- For information on toolchain concepts as they apply to the
- Yocto Project, see the
- "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
- section.
- You can also find more information on using the
- relocatable toolchain in 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>Image:</emphasis>
- An image is an artifact of the BitBake build process given
- a collection of recipes and related Metadata.
- Images are the binary output that run on specific hardware or
- QEMU and are used for specific use-cases.
- For a list of the supported image types that the Yocto Project
- provides, see the
- "<link linkend='ref-images'>Images</link>"
- chapter.
- </para></listitem>
- <listitem><para>
- <emphasis>Layer:</emphasis>
- A collection of recipes representing the core,
- a BSP, or an application stack.
- 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 id='metadata'>
- <emphasis>Metadata:</emphasis>
- The files that BitBake parses when building an image.
- In general, Metadata includes recipes, classes, and
- configuration files.
- In the context of the kernel ("kernel Metadata"), the
- term refers to the kernel config fragments and features
- contained in the
- <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache'><filename>yocto-kernel-cache</filename></ulink>
- Git repository.
- </para></listitem>
- <listitem><para id='oe-core'>
- <emphasis>OE-Core:</emphasis>
- A core set of Metadata originating with OpenEmbedded (OE)
- that is shared between OE and the Yocto Project.
- This Metadata is found in the <filename>meta</filename>
- directory of the
- <link linkend='source-directory'>Source Directory</link>.
- </para></listitem>
- <listitem><para id='build-system-term'>
- <emphasis>OpenEmbedded Build System:</emphasis>
- The build system specific to the Yocto Project.
- The OpenEmbedded build system is based on another project known
- as "Poky", which uses
- <link linkend='bitbake-term'>BitBake</link> as the task
- executor.
- Throughout the Yocto Project documentation set, the
- OpenEmbedded build system is sometimes referred to simply
- as "the build system".
- If other build systems, such as a host or target build system
- are referenced, the documentation clearly states the
- difference.
- <note>
- For some historical information about Poky, see the
- <link linkend='poky'>Poky</link> term.
- </note>
- </para></listitem>
- <listitem><para>
- <emphasis>Package:</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_QS_URL;#packages'>The Build Host Packages</ulink>"
- section in the Yocto Project Quick Start 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. <link linkend='var-PR'><filename>PR</filename></link>,
- <link linkend='var-PV'><filename>PV</filename></link>, and
- <link linkend='var-PE'><filename>PE</filename></link>).
- </para></listitem>
- <listitem><para>
- <emphasis>Package Groups:</emphasis>
- Arbitrary groups of software Recipes.
- You use package groups to hold recipes that, when built,
- usually accomplish a single task.
- For example, a package group could contain the recipes for a
- company’s proprietary or value-add software.
- Or, the package group could contain the recipes that enable
- graphics.
- A package group is really just another recipe.
- Because package group files are recipes, they end with the
- <filename>.bb</filename> filename extension.
- </para></listitem>
- <listitem><para id='poky'>
- <emphasis>Poky:</emphasis>
- The term "poky", which is pronounced
- <emphasis>Pah</emphasis>-kee, can mean several things:
- <itemizedlist>
- <listitem><para>
- In its most general sense, poky is an open-source
- project that was initially developed by OpenedHand.
- OpenedHand developed poky off of the existing
- OpenEmbedded build system to create a commercially
- supportable build system for embedded Linux.
- After Intel Corporation acquired OpenedHand, the
- poky project became the basis for the Yocto Project's
- build system.
- </para></listitem>
- <listitem><para>
- Within the Yocto Project
- <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>,
- "poky" exists as a separate Git
- repository from which you can clone to yield a local
- Git repository that is a copy on your host system.
- Thus, "poky" can refer to the upstream or
- local copy of the files used for development within
- the Yocto Project.
- </para></listitem>
- <listitem><para>
- Finally, "poky" can refer to the default
- <link linkend='var-DISTRO'><filename>DISTRO</filename></link>
- (i.e. distribution) created when you use the Yocto
- Project in conjunction with the
- <filename>poky</filename> repository to build an image.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <emphasis>Recipe:</emphasis>
- A set of instructions for building packages.
- A recipe describes where you get source code, which patches
- to apply, how to configure the source, how to compile it and so on.
- Recipes also describe dependencies for libraries or for other
- recipes.
- Recipes represent the logical unit of execution, the software
- to build, the images to build, and use the
- <filename>.bb</filename> file extension.
- </para></listitem>
- <listitem><para id='reference-kit-term'>
- <emphasis>Reference Kit:</emphasis>
- A working example of a system, which includes a
- <link linkend='board-support-package-bsp-term'>BSP</link>
- as well as a
- <link linkend='hardware-build-system-term'>build system</link>
- and other components, that can work on specific hardware.
- </para></listitem>
- <listitem>
- <para id='source-directory'>
- <emphasis>Source Directory:</emphasis>
- This term refers to the directory structure created as a result
- of creating a local copy of the <filename>poky</filename> Git
- repository <filename>git://git.yoctoproject.org/poky</filename>
- or expanding a released <filename>poky</filename> tarball.
- <note>
- Creating a local copy of the <filename>poky</filename>
- Git repository is the recommended method for setting up
- your Source Directory.
- </note>
- Sometimes you might hear the term "poky directory" used to refer
- to this directory structure.
- <note>
- The OpenEmbedded build system does not support file or
- directory names that contain spaces.
- Be sure that the Source Directory you use does not contain
- these types of names.
- </note></para>
-
- <para>The Source Directory contains BitBake, Documentation,
- Metadata and other files that all support the Yocto Project.
- Consequently, you must have the Source Directory in place on
- your development system in order to do any development using
- the Yocto Project.</para>
-
- <para>When you create a local copy of the Git repository, you
- can name the repository anything you like.
- Throughout much of the documentation, "poky"
- is used as the name of the top-level folder of the local copy of
- the poky Git repository.
- So, for example, cloning the <filename>poky</filename> Git
- repository results in a local Git repository whose top-level
- folder is also named "poky".</para>
-
- <para>While it is not recommended that you use tarball expansion
- to set up the Source Directory, if you do, the top-level
- directory name of the Source Directory is derived from the
- Yocto Project release tarball.
- For example, downloading and unpacking
- <filename>&YOCTO_POKY_TARBALL;</filename> results in a
- Source Directory whose root folder is named
- <filename>&YOCTO_POKY;</filename>.</para>
-
- <para>It is important to understand the differences between the
- Source Directory created by unpacking a released tarball as
- compared to cloning
- <filename>git://git.yoctoproject.org/poky</filename>.
- When you unpack a tarball, you have an exact copy of the files
- based on the time of release - a fixed release point.
- Any changes you make to your local files in the Source Directory
- are on top of the release and will remain local only.
- On the other hand, when you clone the <filename>poky</filename>
- Git repository, you have an active development repository with
- access to the upstream repository's branches and tags.
- In this case, any local changes you make to the local
- Source Directory can be later applied to active development
- branches of the upstream <filename>poky</filename> Git
- repository.</para>
-
- <para>For more information on concepts related to Git
- repositories, branches, and tags, see the
- "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
- section.
- </para></listitem>
- <listitem><para><emphasis>Task:</emphasis>
- A unit of execution for BitBake (e.g.
- <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>,
- <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>,
- <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>,
- and so forth).
- </para></listitem>
- <listitem><para id='toaster-term'><emphasis>Toaster:</emphasis>
- A web interface to the Yocto Project's
- <link linkend='build-system-term'>OpenEmbedded Build System</link>.
- The interface enables you to configure and run your builds.
- Information about builds is collected and stored in a database.
- For information on Toaster, see the
- <ulink url='&YOCTO_DOCS_TOAST_URL;'>Yocto Project Toaster Manual</ulink>.
- </para></listitem>
- <listitem><para>
- <emphasis>Upstream:</emphasis>
- A reference to source code or repositories
- that are not local to the development system but located in a
- master area that is controlled by the maintainer of the source
- code.
- For example, in order for a developer to work on a particular
- piece of code, they need to first get a copy of it from an
- "upstream" source.
- </para></listitem>
- </itemizedlist>
- </para>
-</section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
diff --git a/import-layers/yocto-poky/documentation/ref-manual/migration.xml b/import-layers/yocto-poky/documentation/ref-manual/migration.xml
index 811577b..b060968 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/migration.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/migration.xml
@@ -293,7 +293,7 @@
For the remainder, you can now find them in the
<filename>meta-extras</filename> repository, which is in the
Yocto Project
- <link linkend='source-repositories'>Source Repositories</link>.
+ <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>.
</para>
</section>
</section>
@@ -442,7 +442,7 @@
at <filename>meta/recipes-core/init-ifupdown</filename>.
For information on how to use append files, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
- in the Yocto Project Development Tasks Manual.
+ section in the Yocto Project Development Tasks Manual.
</para>
</section>
@@ -866,10 +866,8 @@
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
<itemizedlist>
<listitem><para>
- The value of
- <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
- is now validated to ensure invalid feature items are not
- added.
+ The value of <filename>IMAGE_FEATURES</filename> is now
+ validated to ensure invalid feature items are not added.
Some users mistakenly add package names to this variable
instead of using
<link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
@@ -1022,8 +1020,8 @@
</para></listitem>
</itemizedlist>
For more information on Build History, see the
- "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</section>
@@ -1116,8 +1114,8 @@
supports pre-renamed package names.</para></listitem>
<listitem><para>
<filename>classes/rootfs_rpm</filename>: Implement
- <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
- for RPM.</para></listitem>
+ <filename>BAD_RECOMMENDATIONS</filename> for RPM.
+ </para></listitem>
<listitem><para>
<filename>systemd</filename>: Remove
<filename>systemd_unitdir</filename> if
@@ -1452,7 +1450,7 @@
<para>
Package Tests (ptest) are built but not installed by default.
For information on using Package Tests, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Setting up and running package test (ptest)</ulink>"
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages with ptest</ulink>"
section in the Yocto Project Development Tasks Manual.
For information on the <filename>ptest</filename> class, see the
"<link linkend='ref-classes-ptest'><filename>ptest.bbclass</filename></link>"
@@ -1748,8 +1746,8 @@
<para>
The minimum
- <link linkend='git'>Git</link> version required
- on the build host is now 1.7.8 because the
+ <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink> version
+ required on the build host is now 1.7.8 because the
<filename>--list</filename> option is now required by
BitBake's Git fetcher.
As always, if your host distribution does not provide a version of
@@ -1909,14 +1907,6 @@
for which <filename>module_conf_*</filename> is specified to
<filename>KERNEL_MODULE_PROBECONF</filename>.
</para>
-
- <para>
- For more information, see the
- <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
- and
- <link linkend='var-KERNEL_MODULE_PROBECONF'><filename>KERNEL_MODULE_PROBECONF</filename></link>
- variables.
- </para>
</section>
<section id='migration-1.7-qa-check-changes'>
@@ -2026,8 +2016,8 @@
You should manually remove old "build-id" files from your
existing build history repositories to avoid confusion.
For information on the build history feature, see the
- "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para></listitem>
</itemizedlist>
</para>
@@ -3037,7 +3027,7 @@
actively maintained.
See the
"<ulink url='&YOCTO_DOCS_TOAST_URL;#using-the-toaster-web-interface'>Using the Toaster Web Interface</ulink>"
- section in the Yocto Project Toaster User Manual for more
+ section in the Toaster User Manual for more
information on this interface.
</para></listitem>
<listitem><para><emphasis>"puccho" BitBake UI</emphasis>:
@@ -3057,7 +3047,8 @@
and the
<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>extensible SDK</ulink>.
For information on these SDKs and how to build and use them, see the
- <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+ <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+ manual.
<note>
The Yocto Project Eclipse IDE Plug-in is still supported and
is not affected by this change.
@@ -4038,7 +4029,7 @@
<para>For an example, see the
<filename>pixbufcache</filename> class in
<filename>meta/classes/</filename> in the Yocto Project
- <link linkend='source-repositories'>Source Repositories</link>.
+ <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>.
<note>
The <filename>SSTATEPOSTINSTFUNCS</filename> variable
itself is now deprecated in favor of the
@@ -4251,8 +4242,8 @@
<para>See the
"<ulink url='&YOCTO_DOCS_BB_URL;#svn-fetcher'>Subversion (SVN) Fetcher (svn://)</ulink>"
- section in the Yocto Project BitBake User Manual for
- additional information.
+ section in the BitBake User Manual for additional
+ information.
</para></listitem>
<listitem><para>
<emphasis><filename>BB_SETSCENE_VERIFY_FUNCTION</filename>
@@ -4625,8 +4616,7 @@
<listitem><para>
The <filename>USE_LDCONFIG</filename> variable has been
replaced with the "ldconfig"
- <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
- feature.
+ <filename>DISTRO_FEATURES</filename> feature.
Distributions that previously set:
<literallayout class='monospaced'>
USE_LDCONFIG = "0"
@@ -4685,9 +4675,9 @@
</para></listitem>
<listitem><para>
All native and nativesdk recipes now use a separate
- <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
- value instead of sharing the value used by recipes for the
- target, in order to avoid unnecessary rebuilds.</para>
+ <filename>DISTRO_FEATURES</filename> value instead of
+ sharing the value used by recipes for the target, in order
+ to avoid unnecessary rebuilds.</para>
<para>The <filename>DISTRO_FEATURES</filename> for
<filename>native</filename> recipes is
@@ -4738,9 +4728,9 @@
replacing its previous "memory resident mode" (i.e.
<filename>oe-init-build-env-memres</filename>).
Now you only need to set
- <filename>BB_SERVER_TIMEOUT</filename> to a timeout
- (in seconds) and BitBake's server stays resident for that
- amount of time between invocations.
+ <link linkend='var-BB_SERVER_TIMEOUT'><filename>BB_SERVER_TIMEOUT</filename></link>
+ to a timeout (in seconds) and BitBake's server stays resident for
+ that amount of time between invocations.
The <filename>oe-init-build-env-memres</filename> script has been
removed since a separate environment setup script is no longer
needed.
@@ -4805,7 +4795,7 @@
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
on the <filename>util-linux-su</filename> package
when "pam" is in
- <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+ <filename>DISTRO_FEATURES</filename>.
</para></listitem>
<listitem><para>
The <filename>switch_root</filename> program is now
@@ -4824,7 +4814,7 @@
packaged in a separate "util-linux-ionice" package.
The main <filename>util-linux</filename> package has
a recommended runtime dependency (i.e.
- <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
+ <filename>RRECOMMENDS</filename>)
on the <filename>util-linux-ionice</filename> package.
</para></listitem>
</itemizedlist>
@@ -4839,18 +4829,15 @@
The change also eliminates needing to pull in the entire
<filename>initscripts</filename> package.
The main <filename>initscripts</filename> package has a
- runtime dependency (i.e.
- <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+ runtime dependency (i.e. <filename>RDEPENDS</filename>)
on the <filename>sushell</filename> package when
- "selinux" is in
- <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+ "selinux" is in <filename>DISTRO_FEATURES</filename>.
</para></listitem>
<listitem><para>
<emphasis><filename>glib-2.0</filename>:</emphasis>
The <filename>glib-2.0</filename> package now has a
recommended runtime dependency (i.e.
- <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
- on the
+ <filename>RRECOMMENDS</filename>) on the
<filename>shared-mime-info</filename> package, since large
portions of GIO are not useful without the MIME database.
You can remove the dependency by using the
@@ -5045,7 +5032,8 @@
Kernel Device Tree support is now easier to enable in a kernel
recipe.
The Device Tree code has moved to a
- <filename>kernel-devicetree</filename> class.
+ <link linkend='ref-classes-kernel-devicetree'><filename>kernel-devicetree</filename></link>
+ class.
Functionality is automatically enabled for any recipe that inherits
the
<link linkend='ref-classes-kernel'><filename>kernel</filename></link>
@@ -5177,13 +5165,14 @@
multiconfig is enabled (one per configuration).
For more information, see the
"<ulink url='&YOCTO_DOCS_BB_URL;#events'>Events</ulink>"
- in the BitBake User Manual.
+ section in the BitBake User Manual.
</para></listitem>
<listitem><para>
By default, the <filename>security_flags.inc</filename> file
- sets a <filename>GCCPIE</filename> variable with an option
- to enable Position Independent Executables (PIE) within
- <filename>gcc</filename>.
+ sets a
+ <link linkend='var-GCCPIE'><filename>GCCPIE</filename></link>
+ variable with an option to enable Position Independent
+ Executables (PIE) within <filename>gcc</filename>.
Enabling PIE in the GNU C Compiler (GCC), makes Return
Oriented Programming (ROP) attacks much more difficult to
execute.
@@ -5238,6 +5227,457 @@
</para>
</section>
</section>
+
+<section id='moving-to-the-yocto-project-2.5-release'>
+ <title>Moving to the Yocto Project 2.5 Release</title>
+
+ <para>
+ This section provides migration information for moving to the
+ Yocto Project 2.5 Release from the prior release.
+ </para>
+
+ <section id='migration-2.5-packaging-changes'>
+ <title>Packaging Changes</title>
+
+ <para>
+ This section provides information about packaging changes that have
+ occurred:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis><filename>bind-libs</filename>:</emphasis>
+ The libraries packaged by the bind recipe are in a
+ separate <filename>bind-libs</filename> package.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>libfm-gtk</filename>:</emphasis>
+ The <filename>libfm</filename> GTK+ bindings are split into
+ a separate <filename>libfm-gtk</filename> package.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>flex-libfl</filename>:</emphasis>
+ The flex recipe splits out libfl into a separate
+ <filename>flex-libfl</filename> package to avoid too many
+ dependencies being pulled in where only the library is
+ needed.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>grub-efi</filename>:</emphasis>
+ The <filename>grub-efi</filename> configuration is split
+ into a separate <filename>grub-bootconf</filename>
+ recipe.
+ However, the dependency relationship from
+ <filename>grub-efi</filename> is through a
+ virtual/grub-bootconf provider making it possible to have
+ your own recipe provide the dependency.
+ Alternatively, you can use a BitBake append file to bring
+ the configuration back into the
+ <filename>grub-efi</filename> recipe.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>armv7a Legacy Package Feed Support:</emphasis>
+ Legacy support is removed for transitioning from
+ <filename>armv7a</filename> to
+ <filename>armv7a-vfp-neon</filename> in package feeds,
+ which was previously enabled by setting
+ <filename>PKGARCHCOMPAT_ARMV7A</filename>.
+ This transition occurred in 2011 and active package feeds
+ should by now be updated to the new naming.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.5-removed-recipes'>
+ <title>Removed Recipes</title>
+
+ <para>
+ The following recipes have been removed:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis><filename>gcc</filename>:</emphasis>
+ The version 6.4 recipes are replaced by 7.x.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>gst-player</filename>:</emphasis>
+ Renamed to <filename>gst-examples</filename> as per
+ upstream.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>hostap-utils</filename>:</emphasis>
+ This software package is obsolete.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>latencytop</filename>:</emphasis>
+ This recipe is no longer maintained upstream.
+ The last release was in 2009.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>libpfm4</filename>:</emphasis>
+ The only file that requires this recipe is
+ <filename>oprofile</filename>, which has been removed.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>linux-yocto</filename>:</emphasis>
+ The version 4.4, 4.9, and 4.10 recipes have been removed.
+ Versions 4.12, 4.14, and 4.15 remain.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>man</filename>:</emphasis>
+ This recipe has been replaced by modern
+ <filename>man-db</filename>
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>mkelfimage</filename>:</emphasis>
+ This tool has been removed in the upstream coreboot project,
+ and is no longer needed with the removal of the ELF image
+ type.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>nativesdk-postinst-intercept</filename>:</emphasis>
+ This recipe is not maintained.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>neon</filename>:</emphasis>
+ This software package is no longer maintained upstream and
+ is no longer needed by anything in OpenEmbedded-Core.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>oprofile</filename>:</emphasis>
+ The functionality of this recipe is replaced by
+ <filename>perf</filename> and keeping compatibility on
+ an ongoing basis with <filename>musl</filename> is
+ difficult.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>pax</filename>:</emphasis>
+ This software package is obsolete.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>stat</filename>:</emphasis>
+ This software package is not maintained upstream.
+ <filename>coreutils</filename> provides a modern stat binary.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>zisofs-tools-native</filename>:</emphasis>
+ This recipe is no longer needed because the compressed
+ ISO image feature has been removed.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.5-scripts-and-tools-changes'>
+ <title>Scripts and Tools Changes</title>
+
+ <para>
+ The following are changes to scripts and tools:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis><filename>yocto-bsp</filename>,
+ <filename>yocto-kernel</filename>, and
+ <filename>yocto-layer</filename></emphasis>:
+ The <filename>yocto-bsp</filename>,
+ <filename>yocto-kernel</filename>, and
+ <filename>yocto-layer</filename> scripts previously shipped
+ with poky but not in OpenEmbedded-Core have been removed.
+ These scripts are not maintained and are outdated.
+ In many cases, they are also limited in scope.
+ The <filename>bitbake-layers create-layer</filename> command
+ is a direct replacement for <filename>yocto-layer</filename>.
+ See the documentation to create a BSP or kernel recipe in
+ the
+ "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-kernel-recipe-example'>BSP Kernel Recipe Example</ulink>"
+ section.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>devtool finish</filename>:</emphasis>
+ <filename>devtool finish</filename> now exits with an error
+ if there are uncommitted changes or a rebase/am in progress
+ in the recipe's source repository.
+ If this error occurs, there might be uncommitted changes
+ that will not be included in updates to the patches applied
+ by the recipe.
+ A -f/--force option is provided for situations that the
+ uncommitted changes are inconsequential and you want to
+ proceed regardless.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>scripts/oe-setup-rpmrepo</filename> script:</emphasis>
+ The functionality of
+ <filename>scripts/oe-setup-rpmrepo</filename> is replaced by
+ <filename>bitbake package-index</filename>.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>scripts/test-dependencies.sh</filename> script:</emphasis>
+ The script is largely made obsolete by the
+ recipe-specific sysroots functionality introduced in the
+ previous release.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.5-bitbake-changes'>
+ <title>BitBake Changes</title>
+
+ <para>
+ The following are BitBake changes:
+ <itemizedlist>
+ <listitem><para>
+ The <filename>--runall</filename> option has changed.
+ There are two different behaviors people might want:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis>Behavior A:</emphasis>
+ For a given target (or set of targets) look through
+ the task graph and run task X only if it is present
+ and will be built.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Behavior B:</emphasis>
+ For a given target (or set of targets) look through
+ the task graph and run task X if any recipe in the
+ taskgraph has such a target, even if it is not in
+ the original task graph.
+ </para></listitem>
+ </itemizedlist>
+ The <filename>--runall</filename> option now performs
+ "Behavior B".
+ Previously <filename>--runall</filename> behaved like
+ "Behavior A".
+ A <filename>--runonly</filename> option has been added to
+ retain the ability to perform "Behavior A".
+ </para></listitem>
+ <listitem><para>
+ Several explicit "run this task for all recipes in the
+ dependency tree" tasks have been removed (e.g.
+ <filename>fetchall</filename>,
+ <filename>checkuriall</filename>, and the
+ <filename>*all</filename> tasks provided by the
+ <filename>distrodata</filename> and
+ <filename>archiver</filename> classes).
+ There is a BitBake option to complete this for any arbitrary
+ task. For example:
+ <literallayout class='monospaced'>
+ bitbake <target> -c fetchall
+ </literallayout>
+ should now be replaced with:
+ <literallayout class='monospaced'>
+ bitbake <target> --runall=fetch
+ </literallayout>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.5-python-and-python3-changes'>
+ <title>Python and Python 3 Changes</title>
+
+ <para>
+ The following are auto-packaging changes to Python and Python 3:
+ </para>
+ <para>
+ The script-managed <filename>python-*-manifest.inc</filename> files
+ that were previously used to generate Python and Python 3
+ packages have been replaced with a JSON-based file that is
+ easier to read and maintain.
+ A new task is available for maintainers of the Python recipes to
+ update the JSON file when upgrading to new Python versions.
+ You can now edit the file directly instead of having to edit a
+ script and run it to update the file.
+ </para>
+ <para>
+ One particular change to note is that the Python recipes no longer
+ have build-time provides for their packages.
+ This assumes <filename>python-foo</filename> is one of the packages
+ provided by the Python recipe.
+ You can no longer run <filename>bitbake python-foo</filename> or
+ have a <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink> on
+ <filename>python-foo</filename>, but doing either of the following
+ causes the package to work as expected:
+ <literallayout class='monospaced'>
+ IMAGE_INSTALL_append = " python-foo"
+ </literallayout>
+ or
+ <literallayout class='monospaced'>
+ RDEPENDS_${PN} = "python-foo"
+ </literallayout>
+ The earlier build-time provides behavior was a quirk of the way the
+ Python manifest file was created.
+ For more information on this change please see
+ <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce'>this commit</ulink>.
+ </para>
+ </section>
+
+ <section id='migration-2.5-miscellaneous-changes'>
+ <title>Miscellaneous Changes</title>
+
+ <para>
+ The following are additional changes:
+ <itemizedlist>
+ <listitem><para>
+ The <filename>kernel</filename> class supports building
+ packages for multiple kernels.
+ If your kernel recipe or <filename>.bbappend</filename> file
+ mentions packaging at all, you should replace references to
+ the kernel in package names with
+ <filename>${KERNEL_PACKAGE_NAME}</filename>.
+ For example, if you disable automatic installation of the
+ kernel image using
+ <filename>RDEPENDS_kernel-base = ""</filename> you can avoid
+ warnings using
+ <filename>RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""</filename>
+ instead.
+ </para></listitem>
+ <listitem><para>
+ The <filename>buildhistory</filename> class commits changes
+ to the repository by default so you no longer need to set
+ <filename>BUILDHISTORY_COMMIT = "1"</filename>.
+ If you want to disable commits you need to set
+ <filename>BUILDHISTORY_COMMIT = "0"</filename> in your
+ configuration.
+ </para></listitem>
+ <listitem><para>
+ The <filename>beaglebone</filename> reference machine has
+ been renamed to <filename>beaglebone-yocto</filename>.
+ The <filename>beaglebone-yocto</filename> BSP is a reference
+ implementation using only mainline components available in
+ OpenEmbedded-Core and <filename>meta-yocto-bsp</filename>,
+ whereas Texas Instruments maintains a full-featured BSP in
+ the <filename>meta-ti</filename> layer.
+ This rename avoids the previous name clash that existed
+ between the two BSPs.
+ </para></listitem>
+ <listitem><para>
+ The <filename>update-alternatives</filename> class no longer
+ works with SysV <filename>init</filename> scripts because
+ this usage has been problematic.
+ Also, the <filename>sysklogd</filename> recipe no longer
+ uses <filename>update-alternatives</filename> because it is
+ incompatible with other implementations.
+ </para></listitem>
+ <listitem><para>
+ By default, the <filename>cmake</filename> class uses
+ <filename>ninja</filename> instead of
+ <filename>make</filename> for building.
+ This improves build performance.
+ If a recipe is broken with <filename>ninja</filename>, then
+ the recipe can set
+ <filename>OECMAKE_GENERATOR = "Unix Makefiles"</filename>
+ to change back to <filename>make</filename>.
+ </para></listitem>
+ <listitem><para>
+ The previously deprecated <filename>base_*</filename>
+ functions have been removed in favor of their replacements
+ in <filename>meta/lib/oe</filename> and
+ <filename>bitbake/lib/bb</filename>.
+ These are typically used from recipes and classes.
+ Any references to the old functions must be updated.
+ The following table shows the removed functions and their
+ replacements:
+
+ <literallayout class='monospaced'>
+ <emphasis>Removed</emphasis> <emphasis>Replacement</emphasis>
+ ============================ ============================
+ base_path_join() oe.path.join()
+ base_path_relative() oe.path.relative()
+ base_path_out() oe.path.format_display()
+ base_read_file() oe.utils.read_file()
+ base_ifelse() oe.utils.ifelse()
+ base_conditional() oe.utils.conditional()
+ base_less_or_equal() oe.utils.less_or_equal()
+ base_version_less_or_equal() oe.utils.version_less_or_equal()
+ base_contains() bb.utils.contains()
+ base_both_contain() oe.utils.both_contain()
+ base_prune_suffix() oe.utils.prune_suffix()
+ oe_filter() oe.utils.str_filter()
+ oe_filter_out() oe.utils.str_filter_out() (or use the _remove operator).
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ Using <filename>exit 1</filename> to explicitly defer a
+ postinstall script until first boot is now deprecated since
+ it is not an obvious mechanism and can mask actual errors.
+ If you want to explicitly defer a postinstall to first boot
+ on the target rather than at <filename>rootfs</filename>
+ creation time, use
+ <filename>pkg_postinst_ontarget()</filename>
+ or call
+ <filename>postinst-intercepts defer_to_first_boot</filename>
+ from <filename>pkg_postinst()</filename>.
+ Any failure of a <filename>pkg_postinst()</filename>
+ script (including <filename>exit 1</filename>)
+ will trigger a warning during
+ <filename>do_rootfs</filename>.
+ </para></listitem>
+ <listitem><para>
+ The <filename>elf</filename> image type has been removed.
+ This image type was removed because the
+ <filename>mkelfimage</filename> tool
+ that was required to create it is no longer provided by
+ coreboot upstream and required updating every time
+ <filename>binutils</filename> updated.
+ </para></listitem>
+ <listitem><para>
+ Support for .iso image compression (previously enabled
+ through <filename>COMPRESSISO = "1"</filename>) has been
+ removed.
+ The userspace tools (<filename>zisofs-tools</filename>) are
+ unmaintained and <filename>squashfs</filename> provides
+ better performance and compression.
+ In order to build a live image with squashfs+lz4 compression
+ enabled you should now set
+ <filename>LIVE_ROOTFS_TYPE = "squashfs-lz4"</filename>
+ and ensure that <filename>live</filename>
+ is in <filename>IMAGE_FSTYPES</filename>.
+ </para></listitem>
+ <listitem><para>
+ Recipes with an unconditional dependency on
+ <filename>libpam</filename> are only buildable with
+ <filename>pam</filename> in
+ <filename>DISTRO_FEATURES</filename>.
+ If the dependency is truly optional then it is recommended
+ that the dependency be conditional upon
+ <filename>pam</filename> being in
+ <filename>DISTRO_FEATURES</filename>.
+ </para></listitem>
+ <listitem><para>
+ For EFI-based machines, the bootloader
+ (<filename>grub-efi</filename> by default) is installed into
+ the image at /boot.
+ Wic can be used to split the bootloader into separate boot
+ and rootfs partitions if necessary.
+ </para></listitem>
+ <listitem><para>
+ Patches whose context does not match exactly (i.e. where
+ patch reports "fuzz" when applying) will generate a
+ warning.
+ For an example of this see
+ <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=cc97bc08125b63821ce3f616771830f77c456f57'>this commit</ulink>.
+ </para></listitem>
+ <listitem><para>
+ Layers are expected to set
+ <filename>LAYERSERIES_COMPAT_layername</filename>
+ to match the version(s) of OpenEmbedded-Core they are
+ compatible with.
+ This is specified as codenames using spaces to separate
+ multiple values (e.g. "rocko sumo").
+ If a layer does not set
+ <filename>LAYERSERIES_COMPAT_layername</filename>, a warning
+ will is shown.
+ If a layer sets a value that does not include the current
+ version ("sumo" for the 2.5 release), then an error will be
+ produced.
+ </para></listitem>
+ <listitem><para>
+ The <filename>TZ</filename> environment variable is set to
+ "UTC" within the build environment in order to fix
+ reproducibility problems in some recipes.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-bitbake.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-bitbake.xml
deleted file mode 100644
index 17f4c54..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-bitbake.xml
+++ /dev/null
@@ -1,477 +0,0 @@
-<!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='ref-bitbake'>
-
- <title>BitBake</title>
-
- <para>
- BitBake is a program written in Python that interprets the
- <link linkend='metadata'>Metadata</link> used by
- the OpenEmbedded build system.
- At some point, developers wonder what actually happens when you enter:
- <literallayout class='monospaced'>
- $ bitbake core-image-sato
- </literallayout>
- </para>
-
- <para>
- This chapter provides an overview of what happens behind the scenes from BitBake's perspective.
- </para>
-
- <note>
- BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
- As such, it has no real knowledge of what the tasks being executed actually do.
- BitBake just considers a list of tasks with dependencies and handles
- <link linkend='metadata'>Metadata</link>
- consisting of variables in a certain format that get passed to the tasks.
- </note>
-
- <section id='ref-bitbake-parsing'>
- <title>Parsing</title>
-
- <para>
- BitBake parses configuration files, classes, and <filename>.bb</filename> files.
- </para>
-
- <para>
- The first thing BitBake does is look for the
- <filename>bitbake.conf</filename> file.
- This file resides in the
- <link linkend='source-directory'>Source Directory</link>
- within the <filename>meta/conf/</filename> directory.
- BitBake finds it by examining its
- <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
- variable and looking for the <filename>meta/conf/</filename>
- directory.
- </para>
-
- <para>
- The <filename>bitbake.conf</filename> file lists other configuration
- files to include from a <filename>conf/</filename>
- directory below the directories listed in <filename>BBPATH</filename>.
- In general, the most important configuration file from a user's perspective
- is <filename>local.conf</filename>, which contains a user's customized
- settings for the OpenEmbedded build environment.
- Other notable configuration files are the distribution
- configuration file (set by the
- <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable)
- and the machine configuration file
- (set by the
- <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable).
- The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment
- variables are both usually set in
- the <filename>local.conf</filename> file.
- Valid distribution
- configuration files are available in the <filename>meta/conf/distro/</filename> directory
- and valid machine configuration
- files in the <filename>meta/conf/machine/</filename> directory.
- Within the <filename>meta/conf/machine/include/</filename>
- directory are various <filename>tune-*.inc</filename> configuration files that provide common
- "tuning" settings specific to and shared between particular architectures and machines.
- </para>
-
- <para>
- After the parsing of the configuration files, some standard classes are included.
- The <filename>base.bbclass</filename> file is always included.
- Other classes that are specified in the configuration using the
- <filename><link linkend='var-INHERIT'>INHERIT</link></filename>
- variable are also included.
- Class files are searched for in a <filename>classes</filename> subdirectory
- under the paths in <filename>BBPATH</filename> in the same way as
- configuration files.
- </para>
-
- <para>
- After classes are included, the variable
- <filename><link linkend='var-BBFILES'>BBFILES</link></filename>
- is set, usually in
- <filename>local.conf</filename>, and defines the list of places to search for
- <filename>.bb</filename> files.
- By default, the <filename>BBFILES</filename> variable specifies the
- <filename>meta/recipes-*/</filename> directory within Poky.
- Adding extra content to <filename>BBFILES</filename> is best achieved through the use of
- BitBake layers as described in the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
- section of the Yocto Project Development Tasks Manual.
- </para>
-
- <para>
- BitBake parses each <filename>.bb</filename> file in <filename>BBFILES</filename> and
- stores the values of various variables.
- In summary, for each <filename>.bb</filename>
- file the configuration plus the base class of variables are set, followed
- by the data in the <filename>.bb</filename> file
- itself, followed by any inherit commands that
- <filename>.bb</filename> file might contain.
- </para>
-
- <para>
- Because parsing <filename>.bb</filename> files is a time
- consuming process, a cache is kept to speed up subsequent parsing.
- This cache is invalid if the timestamp of the <filename>.bb</filename>
- file itself changes, or if the timestamps of any of the include,
- configuration files or class files on which the
- <filename>.bb</filename> file depends change.
- </para>
-
- <note>
- <para>
- You need to be aware of how BitBake parses curly braces.
- If a recipe uses a closing curly brace within the function and
- the character has no leading spaces, BitBake produces a parsing
- error.
- If you use a pair of curly brace in a shell function, the
- closing curly brace must not be located at the start of the line
- without leading spaces.
- </para>
-
- <para>
- Here is an example that causes BitBake to produce a parsing
- error:
- <literallayout class='monospaced'>
- fakeroot create_shar() {
- cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
- usage()
- {
- echo "test"
- ###### The following "}" at the start of the line causes a parsing error ######
- }
- EOF
- }
- </literallayout>
- Writing the recipe this way avoids the error:
- <literallayout class='monospaced'>
- fakeroot create_shar() {
- cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
- usage()
- {
- echo "test"
- ######The following "}" with a leading space at the start of the line avoids the error ######
- }
- EOF
- }
- </literallayout>
- </para>
- </note>
- </section>
-
- <section id='ref-bitbake-providers'>
- <title>Preferences and Providers</title>
-
- <para>
- Once all the <filename>.bb</filename> files have been
- parsed, BitBake starts to build the target (<filename>core-image-sato</filename>
- in the previous section's example) and looks for providers of that target.
- Once a provider is selected, BitBake resolves all the dependencies for
- the target.
- In the case of <filename>core-image-sato</filename>, it would lead to
- <filename>packagegroup-core-x11-sato</filename>,
- which in turn leads to recipes like <filename>matchbox-terminal</filename>,
- <filename>pcmanfm</filename> and <filename>gthumb</filename>.
- These recipes in turn depend on <filename>glibc</filename> and the toolchain.
- </para>
-
- <para>
- Sometimes a target might have multiple providers.
- A common example is "virtual/kernel", which is provided by each kernel package.
- Each machine often selects the best kernel provider by using a line similar to the
- following in the machine configuration file:
- </para>
-
- <literallayout class='monospaced'>
- PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
- </literallayout>
-
- <para>
- The default <filename><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></filename>
- is the provider with the same name as the target.
- </para>
-
- <para>
- Understanding how providers are chosen is made complicated by the fact
- that multiple versions might exist.
- BitBake defaults to the highest version of a provider.
- Version comparisons are made using the same method as Debian.
- You can use the
- <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
- variable to specify a particular version (usually in the distro configuration).
- You can influence the order by using the
- <filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></filename>
- variable.
- By default, files have a preference of "0".
- Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the
- package unlikely to be used unless it is explicitly referenced.
- Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the package is used.
- <filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting.
- <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental package
- versions until they have undergone sufficient testing to be considered stable.
- </para>
-
- <para>
- In summary, BitBake has created a list of providers, which is prioritized, for each target.
- </para>
- </section>
-
- <section id='ref-bitbake-dependencies'>
- <title>Dependencies</title>
-
- <para>
- Each target BitBake builds consists of multiple tasks such as
- <filename>fetch</filename>, <filename>unpack</filename>,
- <filename>patch</filename>, <filename>configure</filename>,
- and <filename>compile</filename>.
- For best performance on multi-core systems, BitBake considers each task as an independent
- entity with its own set of dependencies.
- </para>
-
- <para>
- Dependencies are defined through several variables.
- You can find information about variables BitBake uses in the
- BitBake documentation, which is found in the
- <filename>bitbake/doc/manual</filename> directory within the
- <link linkend='source-directory'>Source Directory</link>.
- At a basic level, it is sufficient to know that BitBake uses the
- <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and
- <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
- variables when calculating dependencies.
- </para>
- </section>
-
- <section id='ref-bitbake-tasklist'>
- <title>The Task List</title>
-
- <para>
- Based on the generated list of providers and the dependency information,
- BitBake can now calculate exactly what tasks it needs to run and in what
- order it needs to run them.
- The build now starts with BitBake forking off threads up to the limit set in the
- <filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></filename> variable.
- BitBake continues to fork threads as long as there are tasks ready to run,
- those tasks have all their dependencies met, and the thread threshold has not been
- exceeded.
- </para>
-
- <para>
- It is worth noting that you can greatly speed up the build time by properly setting
- the <filename>BB_NUMBER_THREADS</filename> variable.
- See the
- "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
- section in the Yocto Project Quick Start for more information.
- </para>
-
- <para>
- As each task completes, a timestamp is written to the directory specified by the
- <filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
- On subsequent runs, BitBake looks within the <filename>build/tmp/stamps</filename>
- directory and does not rerun
- tasks that are already completed unless a timestamp is found to be invalid.
- Currently, invalid timestamps are only considered on a per
- <filename>.bb</filename> file basis.
- So, for example, if the configure stamp has a timestamp greater than the
- compile timestamp for a given target, then the compile task would rerun.
- Running the compile task again, however, has no effect on other providers
- that depend on that target.
- This behavior could change or become configurable in future versions of BitBake.
- </para>
-
- <note>
- Some tasks are marked as "nostamp" tasks.
- No timestamp file is created when these tasks are run.
- Consequently, "nostamp" tasks are always rerun.
- </note>
- </section>
-
- <section id='ref-bitbake-runtask'>
- <title>Running a Task</title>
-
- <para>
- Tasks can either be a shell task or a Python task.
- For shell tasks, BitBake writes a shell script to
- <filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script.
- The generated shell script contains all the exported variables, and the shell functions
- with all variables expanded.
- Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
- Looking at the expanded shell functions in the run file and the output in the log files
- is a useful debugging technique.
- </para>
-
- <para>
- For Python tasks, BitBake executes the task internally and logs information to the
- controlling terminal.
- Future versions of BitBake will write the functions to files similar to the way
- shell tasks are handled.
- Logging will be handled in a way similar to shell tasks as well.
- </para>
-
- <para>
- Once all the tasks have been completed BitBake exits.
- </para>
-
- <para>
- When running a task, BitBake tightly controls the execution environment
- of the build tasks to make sure unwanted contamination from the build machine
- cannot influence the build.
- Consequently, if you do want something to get passed into the build
- task's environment, you must take a few steps:
- <orderedlist>
- <listitem><para>Tell BitBake to load what you want from the environment
- into the data store.
- You can do so through the <filename>BB_ENV_EXTRAWHITE</filename>
- variable.
- For example, assume you want to prevent the build system from
- accessing your <filename>$HOME/.ccache</filename> directory.
- The following command tells BitBake to load
- <filename>CCACHE_DIR</filename> from the environment into the data
- store:
- <literallayout class='monospaced'>
- export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
- </literallayout></para></listitem>
- <listitem><para>Tell BitBake to export what you have loaded into the
- environment store to the task environment of every running task.
- Loading something from the environment into the data store
- (previous step) only makes it available in the datastore.
- To export it to the task environment of every running task,
- use a command similar to the following in your
- <filename>local.conf</filename> or distro configuration file:
- <literallayout class='monospaced'>
- export CCACHE_DIR
- </literallayout></para></listitem>
- </orderedlist>
- </para>
-
- <note>
- A side effect of the previous steps is that BitBake records the variable
- as a dependency of the build process in things like the shared state
- checksums.
- If doing so results in unnecessary rebuilds of tasks, you can whitelist the
- variable so that the shared state code ignores the dependency when it creates
- checksums.
- For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
- example in the "<link linkend='checksums'>Checksums (Signatures)</link>" section.
- </note>
- </section>
-
- <section id='ref-bitbake-commandline'>
- <title>BitBake Command Line</title>
-
- <para>
- Following is the BitBake help output:
- </para>
-
- <screen>
-$ bitbake --help
-Usage: bitbake [options] [recipename/target ...]
-
- Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
- It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
- will provide the layer, BBFILES and other configuration information.
-
-Options:
- --version show program's version number and exit
- -h, --help show this help message and exit
- -b BUILDFILE, --buildfile=BUILDFILE
- Execute tasks from a specific .bb recipe directly.
- WARNING: Does not handle any dependencies from other
- recipes.
- -k, --continue Continue as much as possible after an error. While the
- target that failed and anything depending on it cannot
- be built, as much as possible will be built before
- stopping.
- -a, --tryaltconfigs Continue with builds by trying to use alternative
- providers where possible.
- -f, --force Force the specified targets/task to run (invalidating
- any existing stamp file).
- -c CMD, --cmd=CMD Specify the task to execute. The exact options
- available depend on the metadata. Some examples might
- be 'compile' or 'populate_sysroot' or 'listtasks' may
- give a list of the tasks available.
- -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
- Invalidate the stamp for the specified task such as
- 'compile' and then run the default task for the
- specified target(s).
- -r PREFILE, --read=PREFILE
- Read the specified file before bitbake.conf.
- -R POSTFILE, --postread=POSTFILE
- Read the specified file after bitbake.conf.
- -v, --verbose Output more log message data to the terminal.
- -D, --debug Increase the debug level. You can specify this more
- than once.
- -n, --dry-run Don't execute, just go through the motions.
- -S, --dump-signatures
- Don't execute, just dump out the signature
- construction information.
- -p, --parse-only Quit after parsing the BB recipes.
- -s, --show-versions Show current and preferred versions of all recipes.
- -e, --environment Show the global or per-package environment complete
- with information about where variables were
- set/changed.
- -g, --graphviz Save dependency tree information for the specified
- targets in the dot syntax.
- -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
- Assume these dependencies don't exist and are already
- provided (equivalent to ASSUME_PROVIDED). Useful to
- make dependency graphs more appealing
- -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
- Show debug logging for the specified logging domains
- -P, --profile Profile the command and save reports.
- -u UI, --ui=UI The user interface to use (e.g. knotty and taskexp).
- -t SERVERTYPE, --servertype=SERVERTYPE
- Choose which server to use, process or xmlrpc.
- --revisions-changed Set the exit code depending on whether upstream
- floating revisions have changed or not.
- --server-only Run bitbake without a UI, only starting a server
- (cooker) process.
- -B BIND, --bind=BIND The name/address for the bitbake server to bind to.
- --no-setscene Do not run any setscene tasks. sstate will be ignored
- and everything needed, built.
- --remote-server=REMOTE_SERVER
- Connect to the specified server.
- -m, --kill-server Terminate the remote server.
- --observe-only Connect to a server as an observing-only client.
- </screen>
- </section>
-
- <section id='ref-bitbake-fetchers'>
- <title>Fetchers</title>
-
- <para>
- BitBake also contains a set of "fetcher" modules that allow
- retrieval of source code from various types of sources.
- For example, BitBake can get source code from a disk with the metadata, from websites,
- from remote shell accounts, or from Source Code Management (SCM) systems
- like <filename>cvs/subversion/git</filename>.
- </para>
-
- <para>
- Fetchers are usually triggered by entries in
- <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>.
- You can find information about the options and formats of entries for specific
- fetchers in the BitBake manual located in the
- <filename>bitbake/doc/manual</filename> directory of the
- <link linkend='source-directory'>Source Directory</link>.
- </para>
-
- <para>
- One useful feature for certain Source Code Manager (SCM) fetchers
- is the ability to "auto-update" when the upstream SCM changes
- version.
- Since this ability requires certain functionality from the SCM,
- not all systems support it.
- Currently Subversion, Bazaar and to a limited extent, Git support
- the ability to "auto-update".
- This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
- variable.
- See the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>"
- section in the Yocto Project Development Tasks Manual for more
- information.
- </para>
-
- </section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4 spell spelllang=en_gb
--->
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-classes.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-classes.xml
index 5961d3e..77f21ed 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-classes.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-classes.xml
@@ -35,8 +35,7 @@
<para>
This chapter discusses only the most useful and important classes.
Other classes do exist within the <filename>meta/classes</filename>
- directory in the
- <link linkend='source-directory'>Source Directory</link>.
+ directory in the Source Directory.
You can reference the <filename>.bbclass</filename> files directly
for more information.
</para>
@@ -128,9 +127,8 @@
<para>
By default, the <filename>autotools*</filename> classes
use out-of-tree builds (i.e.
- <filename>autotools.bbclass</filename>).
- (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename>
- <link linkend='var-S'><filename>S</filename></link>).
+ <filename>autotools.bbclass</filename> building with
+ <filename>B != S</filename>).
</para>
<para>
@@ -357,8 +355,8 @@
history of build output metadata, which can be used to detect possible
regressions as well as used for analysis of the build output.
For more information on using Build History, see the
- "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</section>
@@ -407,8 +405,7 @@
<title><filename>ccache.bbclass</filename></title>
<para>
- The <filename>ccache</filename> class enables the
- <ulink url='http://ccache.samba.org/'>C/C++ Compiler Cache</ulink>
+ The <filename>ccache</filename> class enables the C/C++ Compiler Cache
for the build.
This class is used to give a minor performance boost during the build.
However, using the class can lead to unexpected side-effects.
@@ -568,8 +565,9 @@
provides support for the recipes that build the Canadian
Cross-compilation tools for SDKs.
See the
- "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
- section for more discussion on these cross-compilation tools.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual for more
+ discussion on these cross-compilation tools.
</para>
</section>
@@ -581,8 +579,9 @@
provides support for the recipes that build the cross-compilation
tools used for building SDKs.
See the
- "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
- section for more discussion on these cross-compilation tools.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual for more
+ discussion on these cross-compilation tools.
</para>
</section>
@@ -1249,8 +1248,8 @@
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage'>Customizing Images</ulink>"
section in the Yocto Project Development Tasks Manual.
For information on how images are created, see the
- "<link linkend='images-dev-environment'>Images</link>" section elsewhere
- in this manual.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#images-dev-environment'>Images</ulink>"
+ section in the Yocto Project Overview and Concpets Manual.
</para>
</section>
@@ -1291,7 +1290,7 @@
This class also handles conversion and compression of images.
<note>
To build a VMware VMDK image, you need to add "wic.vmdk" to
- <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>.
+ <filename>IMAGE_FSTYPES</filename>.
This would also be similar for Virtual Box Virtual Disk Image
("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
</note>
@@ -1552,7 +1551,8 @@
<link linkend='var-FILES'><filename>FILES</filename></link>
variable values that contain "//", which is invalid.
</para></listitem>
- <listitem><para><emphasis><filename>host-user-contaminated:</filename></emphasis>
+ <listitem><para id='insane-host-user-contaminated'>
+ <emphasis><filename>host-user-contaminated:</filename></emphasis>
Checks that no package produced by the recipe contains any
files outside of <filename>/home</filename> with a user or
group ID that matches the user running BitBake.
@@ -1883,6 +1883,17 @@
</para>
</section>
+<section id='ref-classes-kernel-devicetree'>
+ <title><filename>kernel-devicetree.bbclass</filename></title>
+
+ <para>
+ The <filename>kernel-devicetree</filename> class, which is inherited by
+ the
+ <link linkend='ref-classes-kernel'><filename>kernel</filename></link>
+ class, supports device tree generation.
+ </para>
+</section>
+
<section id='ref-classes-kernel-fitimage'>
<title><filename>kernel-fitimage.bbclass</filename></title>
@@ -2122,7 +2133,7 @@
<para>
For general information on out-of-tree Linux kernel modules, see the
- "<ulink url='&YOCTO_DOCS_KERNEL_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
+ "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
section in the Yocto Project Linux Kernel Development Manual.
</para>
</section>
@@ -2709,8 +2720,8 @@
<para>
For more information on the cross-development toolchain
generation, see the
- "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
For information on advantages gained when building a
cross-development toolchain using the
<link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
@@ -3007,8 +3018,8 @@
<para>
For information on how root filesystem images are created, see the
- "<link linkend='image-generation-dev-environment'>Image Generation</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#image-generation-dev-environment'>Image Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -3169,8 +3180,8 @@
<para>
For more information on sstate, see the
- "<link linkend='shared-state-cache'>Shared State Cache</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>Shared State Cache</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-development-environment.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-development-environment.xml
deleted file mode 100644
index 52197d1..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-development-environment.xml
+++ /dev/null
@@ -1,2761 +0,0 @@
-<!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='ref-development-environment'>
-<title>The Yocto Project Development Environment</title>
-
-<para>
- This chapter takes a look at the Yocto Project development
- environment and also provides a detailed look at what goes on during
- development in that environment.
- The chapter provides Yocto Project Development environment concepts that
- help you understand how work is accomplished in an open source environment,
- which is very different as compared to work accomplished in a closed,
- proprietary environment.
-</para>
-
-<para>
- Specifically, this chapter addresses open source philosophy, workflows,
- Git, source repositories, licensing, recipe syntax, and development
- syntax.
-</para>
-
-<section id='open-source-philosophy'>
- <title>Open Source Philosophy</title>
-
- <para>
- Open source philosophy is characterized by software development
- directed by peer production and collaboration through an active
- community of developers.
- Contrast this to the more standard centralized development models
- used by commercial software companies where a finite set of developers
- produces a product for sale using a defined set of procedures that
- ultimately result in an end product whose architecture and source
- material are closed to the public.
- </para>
-
- <para>
- Open source projects conceptually have differing concurrent agendas,
- approaches, and production.
- These facets of the development process can come from anyone in the
- public (community) that has a stake in the software project.
- The open source environment contains new copyright, licensing, domain,
- and consumer issues that differ from the more traditional development
- environment.
- In an open source environment, the end product, source material,
- and documentation are all available to the public at no cost.
- </para>
-
- <para>
- A benchmark example of an open source project is the Linux kernel,
- which was initially conceived and created by Finnish computer science
- student Linus Torvalds in 1991.
- Conversely, a good example of a non-open source project is the
- <trademark class='registered'>Windows</trademark> family of operating
- systems developed by
- <trademark class='registered'>Microsoft</trademark> Corporation.
- </para>
-
- <para>
- Wikipedia has a good historical description of the Open Source
- Philosophy
- <ulink url='http://en.wikipedia.org/wiki/Open_source'>here</ulink>.
- You can also find helpful information on how to participate in the
- Linux Community
- <ulink url='http://ldn.linuxfoundation.org/book/how-participate-linux-community'>here</ulink>.
- </para>
-</section>
-
-<section id='workflows'>
- <title>Workflows</title>
-
- <para>
- This section provides workflow concepts using the Yocto Project and
- Git.
- In particular, the information covers basic practices that describe
- roles and actions in a collaborative development environment.
- <note>
- If you are familiar with this type of development environment, you
- might not want to read this section.
- </note>
- </para>
-
- <para>
- The Yocto Project files are maintained using Git in "master"
- branches whose Git histories track every change and whose structures
- provides branches for all diverging functionality.
- Although there is no need to use Git, many open source projects do so.
- <para>
-
- </para>
- For the Yocto Project, a key individual called the "maintainer" is
- responsible for the "master" branch of a given Git repository.
- The "master" branch is the “upstream” repository from which final or
- most recent builds of the project occur.
- The maintainer is responsible for accepting changes from other
- developers and for organizing the underlying branch structure to
- reflect release strategies and so forth.
- <note>For information on finding out who is responsible for (maintains)
- a particular area of code, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
- section of the Yocto Project Development Tasks Manual.
- </note>
- </para>
-
- <para>
- The Yocto Project <filename>poky</filename> Git repository also has an
- upstream contribution Git repository named
- <filename>poky-contrib</filename>.
- You can see all the branches in this repository using the web interface
- of the
- <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> organized
- within the "Poky Support" area.
- These branches temporarily hold changes to the project that have been
- submitted or committed by the Yocto Project development team and by
- community members who contribute to the project.
- The maintainer determines if the changes are qualified to be moved
- from the "contrib" branches into the "master" branch of the Git
- repository.
- </para>
-
- <para>
- Developers (including contributing community members) create and
- maintain cloned repositories of the upstream "master" branch.
- The cloned repositories are local to their development platforms and
- are used to develop changes.
- When a developer is satisfied with a particular feature or change,
- they "push" the changes to the appropriate "contrib" repository.
- </para>
-
- <para>
- Developers are responsible for keeping their local repository
- up-to-date with "master".
- They are also responsible for straightening out any conflicts that
- might arise within files that are being worked on simultaneously by
- more than one person.
- All this work is done locally on the developer’s machine before
- anything is pushed to a "contrib" area and examined at the maintainer’s
- level.
- </para>
-
- <para>
- A somewhat formal method exists by which developers commit changes
- and push them into the "contrib" area and subsequently request that
- the maintainer include them into "master".
- This process is called “submitting a patch” or "submitting a change."
- For information on submitting patches and changes, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para>
-
- <para>
- To summarize the development workflow: a single point of entry
- exists for changes into the project’s "master" branch of the
- Git repository, which is controlled by the project’s maintainer.
- And, a set of developers exist who independently develop, test, and
- submit changes to "contrib" areas for the maintainer to examine.
- The maintainer then chooses which changes are going to become a
- permanent part of the project.
- </para>
-
- <para>
- <imagedata fileref="figures/git-workflow.png" width="6in" depth="3in" align="left" scalefit="1" />
- </para>
-
- <para>
- While each development environment is unique, there are some best
- practices or methods that help development run smoothly.
- The following list describes some of these practices.
- For more information about Git workflows, see the workflow topics in
- the
- <ulink url='http://book.git-scm.com'>Git Community Book</ulink>.
- <itemizedlist>
- <listitem><para>
- <emphasis>Make Small Changes:</emphasis>
- It is best to keep the changes you commit small as compared to
- bundling many disparate changes into a single commit.
- This practice not only keeps things manageable but also allows
- the maintainer to more easily include or refuse changes.</para>
-
- <para>It is also good practice to leave the repository in a
- state that allows you to still successfully build your project.
- In other words, do not commit half of a feature,
- then add the other half as a separate, later commit.
- Each commit should take you from one buildable project state
- to another buildable state.
- </para></listitem>
- <listitem><para>
- <emphasis>Use Branches Liberally:</emphasis>
- It is very easy to create, use, and delete local branches in
- your working Git repository.
- You can name these branches anything you like.
- It is helpful to give them names associated with the particular
- feature or change on which you are working.
- Once you are done with a feature or change and have merged it
- into your local master branch, simply discard the temporary
- branch.
- </para></listitem>
- <listitem><para>
- <emphasis>Merge Changes:</emphasis>
- The <filename>git merge</filename> command allows you to take
- the changes from one branch and fold them into another branch.
- This process is especially helpful when more than a single
- developer might be working on different parts of the same
- feature.
- Merging changes also automatically identifies any collisions
- or "conflicts" that might happen as a result of the same lines
- of code being altered by two different developers.
- </para></listitem>
- <listitem><para>
- <emphasis>Manage Branches:</emphasis>
- Because branches are easy to use, you should use a system
- where branches indicate varying levels of code readiness.
- For example, you can have a "work" branch to develop in, a
- "test" branch where the code or change is tested, a "stage"
- branch where changes are ready to be committed, and so forth.
- As your project develops, you can merge code across the
- branches to reflect ever-increasing stable states of the
- development.
- </para></listitem>
- <listitem><para>
- <emphasis>Use Push and Pull:</emphasis>
- The push-pull workflow is based on the concept of developers
- "pushing" local commits to a remote repository, which is
- usually a contribution repository.
- This workflow is also based on developers "pulling" known
- states of the project down into their local development
- repositories.
- The workflow easily allows you to pull changes submitted by
- other developers from the upstream repository into your
- work area ensuring that you have the most recent software
- on which to develop.
- The Yocto Project has two scripts named
- <filename>create-pull-request</filename> and
- <filename>send-pull-request</filename> that ship with the
- release to facilitate this workflow.
- You can find these scripts in the <filename>scripts</filename>
- folder of the
- <link linkend='source-directory'>Source Directory</link>.
- For information on how to use these scripts, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para></listitem>
- <listitem><para>
- <emphasis>Patch Workflow:</emphasis>
- This workflow allows you to notify the maintainer through an
- email that you have a change (or patch) you would like
- considered for the "master" branch of the Git repository.
- To send this type of change, you format the patch and then
- send the email using the Git commands
- <filename>git format-patch</filename> and
- <filename>git send-email</filename>.
- For information on how to use these scripts, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para></listitem>
- </itemizedlist>
- </para>
-</section>
-
-<section id='git'>
- <title>Git</title>
-
- <para>
- The Yocto Project makes extensive use of Git, which is a
- free, open source distributed version control system.
- Git supports distributed development, non-linear development,
- and can handle large projects.
- It is best that you have some fundamental understanding
- of how Git tracks projects and how to work with Git if
- you are going to use the Yocto Project for development.
- This section provides a quick overview of how Git works and
- provides you with a summary of some essential Git commands.
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- For more information on Git, see
- <ulink url='http://git-scm.com/documentation'></ulink>.
- </para></listitem>
- <listitem><para>
- If you need to download Git, it is recommended that you add
- Git to your system through your distribution's "software
- store" (e.g. for Ubuntu, use the Ubuntu Software feature).
- For the Git download page, see
- <ulink url='http://git-scm.com/download'></ulink>.
- </para></listitem>
- <listitem><para>
- For examples beyond the limited few in this section on how
- to use Git with the Yocto Project, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para></listitem>
- </itemizedlist>
- </note>
- </para>
-
- <section id='repositories-tags-and-branches'>
- <title>Repositories, Tags, and Branches</title>
-
- <para>
- As mentioned briefly in the previous section and also in the
- "<link linkend='workflows'>Workflows</link>" section,
- the Yocto Project maintains source repositories at
- <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
- If you look at this web-interface of the repositories, each item
- is a separate Git repository.
- </para>
-
- <para>
- Git repositories use branching techniques that track content
- change (not files) within a project (e.g. a new feature or updated
- documentation).
- Creating a tree-like structure based on project divergence allows
- for excellent historical information over the life of a project.
- This methodology also allows for an environment from which you can
- do lots of local experimentation on projects as you develop
- changes or new features.
- </para>
-
- <para>
- A Git repository represents all development efforts for a given
- project.
- For example, the Git repository <filename>poky</filename> contains
- all changes and developments for Poky over the course of its
- entire life.
- That means that all changes that make up all releases are captured.
- The repository maintains a complete history of changes.
- </para>
-
- <para>
- You can create a local copy of any repository by "cloning" it
- with the <filename>git clone</filename> command.
- When you clone a Git repository, you end up with an identical
- copy of the repository on your development system.
- Once you have a local copy of a repository, you can take steps to
- develop locally.
- For examples on how to clone Git repositories, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para>
-
- <para>
- It is important to understand that Git tracks content change and
- not files.
- Git uses "branches" to organize different development efforts.
- For example, the <filename>poky</filename> repository has
- several branches that include the current "&DISTRO_NAME_NO_CAP;"
- branch, the "master" branch, and many branches for past
- Yocto Project releases.
- You can see all the branches by going to
- <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and
- clicking on the
- <filename><ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/refs/heads'>[...]</ulink></filename>
- link beneath the "Branch" heading.
- </para>
-
- <para>
- Each of these branches represents a specific area of development.
- The "master" branch represents the current or most recent
- development.
- All other branches represent offshoots of the "master" branch.
- </para>
-
- <para>
- When you create a local copy of a Git repository, the copy has
- the same set of branches as the original.
- This means you can use Git to create a local working area
- (also called a branch) that tracks a specific development branch
- from the upstream source Git repository.
- in other words, you can define your local Git environment to
- work on any development branch in the repository.
- To help illustrate, consider the following example Git commands:
- <literallayout class='monospaced'>
- $ cd ~
- $ git clone git://git.yoctoproject.org/poky
- $ cd poky
- $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
- </literallayout>
- In the previous example after moving to the home directory, the
- <filename>git clone</filename> command creates a
- local copy of the upstream <filename>poky</filename> Git repository.
- By default, Git checks out the "master" branch for your work.
- After changing the working directory to the new local repository
- (i.e. <filename>poky</filename>), the
- <filename>git checkout</filename> command creates
- and checks out a local branch named "&DISTRO_NAME_NO_CAP;", which
- tracks the upstream "origin/&DISTRO_NAME_NO_CAP;" branch.
- Changes you make while in this branch would ultimately affect
- the upstream "&DISTRO_NAME_NO_CAP;" branch of the
- <filename>poky</filename> repository.
- </para>
-
- <para>
- It is important to understand that when you create and checkout a
- local working branch based on a branch name,
- your local environment matches the "tip" of that particular
- development branch at the time you created your local branch,
- which could be different from the files in the "master" branch
- of the upstream repository.
- In other words, creating and checking out a local branch based on
- the "&DISTRO_NAME_NO_CAP;" branch name is not the same as
- cloning and checking out the "master" branch if the repository.
- Keep reading to see how you create a local snapshot of a Yocto
- Project Release.
- </para>
-
- <para>
- Git uses "tags" to mark specific changes in a repository.
- Typically, a tag is used to mark a special point such as the final
- change before a project is released.
- You can see the tags used with the <filename>poky</filename> Git
- repository by going to
- <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and
- clicking on the
- <filename><ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/refs/tags'>[...]</ulink></filename>
- link beneath the "Tag" heading.
- </para>
-
- <para>
- Some key tags for the <filename>poky</filename> are
- <filename>jethro-14.0.3</filename>,
- <filename>morty-16.0.1</filename>,
- <filename>pyro-17.0.0</filename>, and
- <filename>&DISTRO_NAME_NO_CAP;-&POKYVERSION;</filename>.
- These tags represent Yocto Project releases.
- </para>
-
- <para>
- When you create a local copy of the Git repository, you also
- have access to all the tags in the upstream repository.
- Similar to branches, you can create and checkout a local working
- Git branch based on a tag name.
- When you do this, you get a snapshot of the Git repository that
- reflects the state of the files when the change was made associated
- with that tag.
- The most common use is to checkout a working branch that matches
- a specific Yocto Project release.
- Here is an example:
- <literallayout class='monospaced'>
- $ cd ~
- $ git clone git://git.yoctoproject.org/poky
- $ cd poky
- $ git fetch --all --tags --prune
- $ git checkout tags/pyro-17.0.0 -b my-pyro-17.0.0
- </literallayout>
- In this example, the name of the top-level directory of your
- local Yocto Project repository is <filename>poky</filename>.
- After moving to the <filename>poky</filename> directory, the
- <filename>git fetch</filename> command makes all the upstream
- tags available locally in your repository.
- Finally, the <filename>git checkout</filename> command
- creates and checks out a branch named "my-pyro-17.0.0" that is
- based on the specific change upstream in the repository
- associated with the "pyro-17.0.0" tag.
- The files in your repository now exactly match that particular
- Yocto Project release as it is tagged in the upstream Git
- repository.
- It is important to understand that when you create and
- checkout a local working branch based on a tag, your environment
- matches a specific point in time and not the entire development
- branch (i.e. the "tip" of the branch).
- </para>
- </section>
-
- <section id='basic-commands'>
- <title>Basic Commands</title>
-
- <para>
- Git has an extensive set of commands that lets you manage changes
- and perform collaboration over the life of a project.
- Conveniently though, you can manage with a small set of basic
- operations and workflows once you understand the basic
- philosophy behind Git.
- You do not have to be an expert in Git to be functional.
- A good place to look for instruction on a minimal set of Git
- commands is
- <ulink url='http://git-scm.com/documentation'>here</ulink>.
- </para>
-
- <para>
- If you do not know much about Git, you should educate
- yourself by visiting the links previously mentioned.
- </para>
-
- <para>
- The following list of Git commands briefly describes some basic
- Git operations as a way to get started.
- As with any set of commands, this list (in most cases) simply shows
- the base command and omits the many arguments they support.
- See the Git documentation for complete descriptions and strategies
- on how to use these commands:
- <itemizedlist>
- <listitem><para>
- <emphasis><filename>git init</filename>:</emphasis>
- Initializes an empty Git repository.
- You cannot use Git commands unless you have a
- <filename>.git</filename> repository.
- </para></listitem>
- <listitem><para id='git-commands-clone'>
- <emphasis><filename>git clone</filename>:</emphasis>
- Creates a local clone of a Git repository that is on
- equal footing with a fellow developer’s Git repository
- or an upstream repository.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git add</filename>:</emphasis>
- Locally stages updated file contents to the index that
- Git uses to track changes.
- You must stage all files that have changed before you
- can commit them.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git commit</filename>:</emphasis>
- Creates a local "commit" that documents the changes you
- made.
- Only changes that have been staged can be committed.
- Commits are used for historical purposes, for determining
- if a maintainer of a project will allow the change,
- and for ultimately pushing the change from your local
- Git repository into the project’s upstream repository.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git status</filename>:</emphasis>
- Reports any modified files that possibly need to be
- staged and gives you a status of where you stand regarding
- local commits as compared to the upstream repository.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git checkout</filename> <replaceable>branch-name</replaceable>:</emphasis>
- Changes your working branch.
- This command is analogous to "cd".
- </para></listitem>
- <listitem><para><emphasis><filename>git checkout –b</filename> <replaceable>working-branch</replaceable>:</emphasis>
- Creates and checks out a working branch on your local
- machine that you can use to isolate your work.
- It is a good idea to use local branches when adding
- specific features or changes.
- Using isolated branches facilitates easy removal of
- changes if they do not work out.
- </para></listitem>
- <listitem><para><emphasis><filename>git branch</filename>:</emphasis>
- Displays the existing local branches associated with your
- local repository.
- The branch that you have currently checked out is noted
- with an asterisk character.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git branch -D</filename> <replaceable>branch-name</replaceable>:</emphasis>
- Deletes an existing local branch.
- You need to be in a local branch other than the one you
- are deleting in order to delete
- <replaceable>branch-name</replaceable>.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git pull</filename>:</emphasis>
- Retrieves information from an upstream Git repository
- and places it in your local Git repository.
- You use this command to make sure you are synchronized with
- the repository from which you are basing changes
- (.e.g. the "master" branch).
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git push</filename>:</emphasis>
- Sends all your committed local changes to the upstream Git
- repository that your local repository is tracking
- (e.g. a contribution repository).
- The maintainer of the project draws from these repositories
- to merge changes (commits) into the appropriate branch
- of project's upstream repository.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git merge</filename>:</emphasis>
- Combines or adds changes from one
- local branch of your repository with another branch.
- When you create a local Git repository, the default branch
- is named "master".
- A typical workflow is to create a temporary branch that is
- based off "master" that you would use for isolated work.
- You would make your changes in that isolated branch,
- stage and commit them locally, switch to the "master"
- branch, and then use the <filename>git merge</filename>
- command to apply the changes from your isolated branch
- into the currently checked out branch (e.g. "master").
- After the merge is complete and if you are done with
- working in that isolated branch, you can safely delete
- the isolated branch.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git cherry-pick</filename>:</emphasis>
- Choose and apply specific commits from one branch
- into another branch.
- There are times when you might not be able to merge
- all the changes in one branch with
- another but need to pick out certain ones.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>gitk</filename>:</emphasis>
- Provides a GUI view of the branches and changes in your
- local Git repository.
- This command is a good way to graphically see where things
- have diverged in your local repository.
- <note>
- You need to install the <filename>gitk</filename>
- package on your development system to use this
- command.
- </note>
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git log</filename>:</emphasis>
- Reports a history of your commits to the repository.
- This report lists all commits regardless of whether you
- have pushed them upstream or not.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>git diff</filename>:</emphasis>
- Displays line-by-line differences between a local
- working file and the same file as understood by Git.
- This command is useful to see what you have changed
- in any given file.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-</section>
-
-<section id='yocto-project-repositories'>
- <title>Yocto Project Source Repositories</title>
-
- <para>
- The Yocto Project team maintains complete source repositories for all
- Yocto Project files at
- <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
- This web-based source code browser is organized into categories by
- function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and
- so forth.
- From the interface, you can click on any particular item in the "Name"
- column and see the URL at the bottom of the page that you need to clone
- a Git repository for that particular item.
- Having a local Git repository of the
- <link linkend='source-directory'>Source Directory</link>, which is
- usually named "poky", allows
- you to make changes, contribute to the history, and ultimately enhance
- the Yocto Project's tools, Board Support Packages, and so forth.
- </para>
-
- <para>
- For any supported release of Yocto Project, you can also go to the
- <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and
- select the "Downloads" tab and get a released tarball of the
- <filename>poky</filename> repository or any supported BSP tarballs.
- Unpacking these tarballs gives you a snapshot of the released
- files.
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- The recommended method for setting up the Yocto Project
- <link linkend='source-directory'>Source Directory</link>
- and the files for supported BSPs
- (e.g., <filename>meta-intel</filename>) is to use
- <link linkend='git'>Git</link> to create a local copy of
- the upstream repositories.
- </para></listitem>
- <listitem><para>
- Be sure to always work in matching branches for both
- the selected BSP repository and the
- <link linkend='source-directory'>Source Directory</link>
- (i.e. <filename>poky</filename>) repository.
- For example, if you have checked out the "master" branch
- of <filename>poky</filename> and you are going to use
- <filename>meta-intel</filename>, be sure to checkout the
- "master" branch of <filename>meta-intel</filename>.
- </para></listitem>
- </itemizedlist>
- </note>
- </para>
-
- <para>
- In summary, here is where you can get the project files needed for
- development:
- <itemizedlist>
- <listitem><para id='source-repositories'>
- <emphasis>
- <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink>
- </emphasis>
- This area contains IDE Plugins, Matchbox, Poky, Poky Support,
- Tools, Yocto Linux Kernel, and Yocto Metadata Layers.
- You can create local copies of Git repositories for each of
- these areas.</para>
-
- <para>
- <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
- For steps on how to view and access these upstream Git
- repositories, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#accessing-source-repositories'>Accessing Source Repositories</ulink>"
- Section in the Yocto Project Development Tasks Manual.
- </para></listitem>
- <listitem><para><anchor id='index-downloads' />
- <emphasis>
- <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink>
- </emphasis>
- This is an index of releases such as
- the <trademark class='trade'>Eclipse</trademark>
- Yocto Plug-in, miscellaneous support, Poky, Pseudo, installers
- for cross-development toolchains, and all released versions of
- Yocto Project in the form of images or tarballs.
- Downloading and extracting these files does not produce a local
- copy of the Git repository but rather a snapshot of a
- particular release or image.</para>
-
- <para>
- <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" />
- For steps on how to view and access these files, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#accessing-index-of-releases'>Accessing Index of Releases</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para></listitem>
- <listitem><para id='downloads-page'>
- <emphasis>"Downloads" page for the
- <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:
- </emphasis></para>
-
- <para role="writernotes">This section will change due to
- reworking of the YP Website.</para>
-
- <para>The Yocto Project website includes a "Downloads" tab
- that allows you to download any Yocto Project
- release and Board Support Package (BSP) in tarball form.
- The tarballs are similar to those found in the
- <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> area.</para>
-
- <para>
- <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
- For steps on how to use the "Downloads" page, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-downloads-page'>Using the Downloads Page</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para></listitem>
- </itemizedlist>
- </para>
-</section>
-
-<section id='licensing'>
- <title>Licensing</title>
-
- <para>
- Because open source projects are open to the public, they have
- different licensing structures in place.
- License evolution for both Open Source and Free Software has an
- interesting history.
- If you are interested in this history, you can find basic information
- here:
- <itemizedlist>
- <listitem><para>
- <ulink url='http://en.wikipedia.org/wiki/Open-source_license'>Open source license history</ulink>
- </para></listitem>
- <listitem><para>
- <ulink url='http://en.wikipedia.org/wiki/Free_software_license'>Free software license history</ulink>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- In general, the Yocto Project is broadly licensed under the
- Massachusetts Institute of Technology (MIT) License.
- MIT licensing permits the reuse of software within proprietary
- software as long as the license is distributed with that software.
- MIT is also compatible with the GNU General Public License (GPL).
- Patches to the Yocto Project follow the upstream licensing scheme.
- You can find information on the MIT license
- <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>.
- You can find information on the GNU GPL
- <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>here</ulink>.
- </para>
-
- <para>
- When you build an image using the Yocto Project, the build process
- uses a known list of licenses to ensure compliance.
- You can find this list in the
- <link linkend='source-directory'>Source Directory</link> at
- <filename>meta/files/common-licenses</filename>.
- Once the build completes, the list of all licenses found and used
- during that build are kept in the
- <link linkend='build-directory'>Build Directory</link>
- at <filename>tmp/deploy/licenses</filename>.
- </para>
-
- <para>
- If a module requires a license that is not in the base list, the
- build process generates a warning during the build.
- These tools make it easier for a developer to be certain of the
- licenses with which their shipped products must comply.
- However, even with these tools it is still up to the developer to
- resolve potential licensing issues.
- </para>
-
- <para>
- The base list of licenses used by the build process is a combination
- of the Software Package Data Exchange (SPDX) list and the Open
- Source Initiative (OSI) projects.
- <ulink url='http://spdx.org'>SPDX Group</ulink> is a working group of
- the Linux Foundation that maintains a specification for a standard
- format for communicating the components, licenses, and copyrights
- associated with a software package.
- <ulink url='http://opensource.org'>OSI</ulink> is a corporation
- dedicated to the Open Source Definition and the effort for reviewing
- and approving licenses that conform to the Open Source Definition
- (OSD).
- </para>
-
- <para>
- You can find a list of the combined SPDX and OSI licenses that the
- Yocto Project uses in the
- <filename>meta/files/common-licenses</filename> directory in your
- <link linkend='source-directory'>Source Directory</link>.
- </para>
-
- <para>
- For information that can help you maintain compliance with various
- open source licensing during the lifecycle of a product created using
- the Yocto Project, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para>
-</section>
-
-<section id='recipe-syntax'>
- <title>Recipe Syntax</title>
-
- <para>
- Understanding recipe file syntax is important for
- writing recipes.
- The following list overviews the basic items that make up a
- BitBake recipe file.
- For more complete BitBake syntax descriptions, see the
- "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-metadata'>Syntax and Operators</ulink>"
- chapter of the BitBake User Manual.
- <itemizedlist>
- <listitem><para><emphasis>Variable Assignments and Manipulations:</emphasis>
- Variable assignments allow a value to be assigned to a
- variable.
- The assignment can be static text or might include
- the contents of other variables.
- In addition to the assignment, appending and prepending
- operations are also supported.</para>
- <para>The following example shows some of the ways
- you can use variables in recipes:
- <literallayout class='monospaced'>
- S = "${WORKDIR}/postfix-${PV}"
- CFLAGS += "-DNO_ASM"
- SRC_URI_append = " file://fixup.patch"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Functions:</emphasis>
- Functions provide a series of actions to be performed.
- You usually use functions to override the default
- implementation of a task function or to complement
- a default function (i.e. append or prepend to an
- existing function).
- Standard functions use <filename>sh</filename> shell
- syntax, although access to OpenEmbedded variables and
- internal methods are also available.</para>
- <para>The following is an example function from the
- <filename>sed</filename> recipe:
- <literallayout class='monospaced'>
- do_install () {
- autotools_do_install
- install -d ${D}${base_bindir}
- mv ${D}${bindir}/sed ${D}${base_bindir}/sed
- rmdir ${D}${bindir}/
- }
- </literallayout>
- It is also possible to implement new functions that
- are called between existing tasks as long as the
- new functions are not replacing or complementing the
- default functions.
- You can implement functions in Python
- instead of shell.
- Both of these options are not seen in the majority of
- recipes.</para></listitem>
- <listitem><para><emphasis>Keywords:</emphasis>
- BitBake recipes use only a few keywords.
- You use keywords to include common
- functions (<filename>inherit</filename>), load parts
- of a recipe from other files
- (<filename>include</filename> and
- <filename>require</filename>) and export variables
- to the environment (<filename>export</filename>).</para>
- <para>The following example shows the use of some of
- these keywords:
- <literallayout class='monospaced'>
- export POSTCONF = "${STAGING_BINDIR}/postconf"
- inherit autoconf
- require otherfile.inc
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Comments:</emphasis>
- Any lines that begin with the hash character
- (<filename>#</filename>) are treated as comment lines
- and are ignored:
- <literallayout class='monospaced'>
- # This is a comment
- </literallayout>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- This next list summarizes the most important and most commonly
- used parts of the recipe syntax.
- For more information on these parts of the syntax, you can
- reference the
- <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-metadata'>Syntax and Operators</ulink>
- chapter in the BitBake User Manual.
- <itemizedlist>
- <listitem><para><emphasis>Line Continuation: <filename>\</filename></emphasis> -
- Use the backward slash (<filename>\</filename>)
- character to split a statement over multiple lines.
- Place the slash character at the end of the line that
- is to be continued on the next line:
- <literallayout class='monospaced'>
- VAR = "A really long \
- line"
- </literallayout>
- <note>
- You cannot have any characters including spaces
- or tabs after the slash character.
- </note>
- </para></listitem>
- <listitem><para>
- <emphasis>Using Variables: <filename>${...}</filename></emphasis> -
- Use the <filename>${<replaceable>VARNAME</replaceable>}</filename> syntax to
- access the contents of a variable:
- <literallayout class='monospaced'>
- SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
- </literallayout>
- <note>
- It is important to understand that the value of a
- variable expressed in this form does not get
- substituted automatically.
- The expansion of these expressions happens
- on-demand later (e.g. usually when a function that
- makes reference to the variable executes).
- This behavior ensures that the values are most
- appropriate for the context in which they are
- finally used.
- On the rare occasion that you do need the variable
- expression to be expanded immediately, you can use
- the <filename>:=</filename> operator instead of
- <filename>=</filename> when you make the
- assignment, but this is not generally needed.
- </note>
- </para></listitem>
- <listitem><para><emphasis>Quote All Assignments: <filename>"<replaceable>value</replaceable>"</filename></emphasis> -
- Use double quotes around the value in all variable
- assignments.
- <literallayout class='monospaced'>
- VAR1 = "${OTHERVAR}"
- VAR2 = "The version is ${PV}"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Conditional Assignment: <filename>?=</filename></emphasis> -
- Conditional assignment is used to assign a value to
- a variable, but only when the variable is currently
- unset.
- Use the question mark followed by the equal sign
- (<filename>?=</filename>) to make a "soft" assignment
- used for conditional assignment.
- Typically, "soft" assignments are used in the
- <filename>local.conf</filename> file for variables
- that are allowed to come through from the external
- environment.
- </para>
- <para>Here is an example where
- <filename>VAR1</filename> is set to "New value" if
- it is currently empty.
- However, if <filename>VAR1</filename> has already been
- set, it remains unchanged:
- <literallayout class='monospaced'>
- VAR1 ?= "New value"
- </literallayout>
- In this next example, <filename>VAR1</filename>
- is left with the value "Original value":
- <literallayout class='monospaced'>
- VAR1 = "Original value"
- VAR1 ?= "New value"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Appending: <filename>+=</filename></emphasis> -
- Use the plus character followed by the equals sign
- (<filename>+=</filename>) to append values to existing
- variables.
- <note>
- This operator adds a space between the existing
- content of the variable and the new content.
- </note></para>
- <para>Here is an example:
- <literallayout class='monospaced'>
- SRC_URI += "file://fix-makefile.patch"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Prepending: <filename>=+</filename></emphasis> -
- Use the equals sign followed by the plus character
- (<filename>=+</filename>) to prepend values to existing
- variables.
- <note>
- This operator adds a space between the new content
- and the existing content of the variable.
- </note></para>
- <para>Here is an example:
- <literallayout class='monospaced'>
- VAR =+ "Starts"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Appending: <filename>_append</filename></emphasis> -
- Use the <filename>_append</filename> operator to
- append values to existing variables.
- This operator does not add any additional space.
- Also, the operator is applied after all the
- <filename>+=</filename>, and
- <filename>=+</filename> operators have been applied and
- after all <filename>=</filename> assignments have
- occurred.
- </para>
- <para>The following example shows the space being
- explicitly added to the start to ensure the appended
- value is not merged with the existing value:
- <literallayout class='monospaced'>
- SRC_URI_append = " file://fix-makefile.patch"
- </literallayout>
- You can also use the <filename>_append</filename>
- operator with overrides, which results in the actions
- only being performed for the specified target or
- machine:
- <literallayout class='monospaced'>
- SRC_URI_append_sh4 = " file://fix-makefile.patch"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Prepending: <filename>_prepend</filename></emphasis> -
- Use the <filename>_prepend</filename> operator to
- prepend values to existing variables.
- This operator does not add any additional space.
- Also, the operator is applied after all the
- <filename>+=</filename>, and
- <filename>=+</filename> operators have been applied and
- after all <filename>=</filename> assignments have
- occurred.
- </para>
- <para>The following example shows the space being
- explicitly added to the end to ensure the prepended
- value is not merged with the existing value:
- <literallayout class='monospaced'>
- CFLAGS_prepend = "-I${S}/myincludes "
- </literallayout>
- You can also use the <filename>_prepend</filename>
- operator with overrides, which results in the actions
- only being performed for the specified target or
- machine:
- <literallayout class='monospaced'>
- CFLAGS_prepend_sh4 = "-I${S}/myincludes "
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Overrides:</emphasis> -
- You can use overrides to set a value conditionally,
- typically based on how the recipe is being built.
- For example, to set the
- <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link>
- variable's value to "standard/base" for any target
- <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
- except for qemuarm where it should be set to
- "standard/arm-versatile-926ejs", you would do the
- following:
- <literallayout class='monospaced'>
- KBRANCH = "standard/base"
- KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
- </literallayout>
- Overrides are also used to separate alternate values
- of a variable in other situations.
- For example, when setting variables such as
- <link linkend='var-FILES'><filename>FILES</filename></link>
- and
- <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
- that are specific to individual packages produced by
- a recipe, you should always use an override that
- specifies the name of the package.
- </para></listitem>
- <listitem><para><emphasis>Indentation:</emphasis>
- Use spaces for indentation rather than than tabs.
- For shell functions, both currently work.
- However, it is a policy decision of the Yocto Project
- to use tabs in shell functions.
- Realize that some layers have a policy to use spaces
- for all indentation.
- </para></listitem>
- <listitem><para><emphasis>Using Python for Complex Operations: <filename>${@<replaceable>python_code</replaceable>}</filename></emphasis> -
- For more advanced processing, it is possible to use
- Python code during variable assignments (e.g.
- search and replacement on a variable).</para>
- <para>You indicate Python code using the
- <filename>${@<replaceable>python_code</replaceable>}</filename>
- syntax for the variable assignment:
- <literallayout class='monospaced'>
- SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Shell Function Syntax:</emphasis>
- Write shell functions as if you were writing a shell
- script when you describe a list of actions to take.
- You should ensure that your script works with a generic
- <filename>sh</filename> and that it does not require
- any <filename>bash</filename> or other shell-specific
- functionality.
- The same considerations apply to various system
- utilities (e.g. <filename>sed</filename>,
- <filename>grep</filename>, <filename>awk</filename>,
- and so forth) that you might wish to use.
- If in doubt, you should check with multiple
- implementations - including those from BusyBox.
- </para></listitem>
- </itemizedlist>
- </para>
-</section>
-
-<section id="development-concepts">
- <title>Development Concepts</title>
-
- <para>
- This section takes a more detailed look inside the development
- process.
- The following diagram represents development at a high level.
- The remainder of this chapter expands on the fundamental input, output,
- process, and
- <link linkend='metadata'>Metadata</link>) blocks
- that make up development in the Yocto Project environment.
- </para>
-
- <para id='general-yocto-environment-figure'>
- <imagedata fileref="figures/yocto-environment-ref.png" align="center" width="8in" depth="4.25in" />
- </para>
-
- <para>
- In general, development 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
- <link linkend='bitbake-term'>BitBake</link>.
- 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.
- </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" />
- </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
- <link linkend='source-directory'>Source Directory</link>.
- 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-poky</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
- (i.e.
- <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
- </para>
-
- <para>
- Sourcing the build environment script creates a
- <link linkend='build-directory'>Build Directory</link>
- 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 build environment setup 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_FILE;</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-poky</filename> layer:
- <itemizedlist>
- <listitem><para><emphasis>Parallelism Options:</emphasis>
- Controlled by the
- <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>,
- <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>,
- and
- <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS'><filename>BB_NUMBER_PARSE_THREADS</filename></ulink>
- 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 Tasks 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 the <filename>site.conf</filename> file, you need to
- create that yourself.
- The <filename>auto.conf</filename> file is typically created by
- an autobuilder:
- <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 packaging format to use
- through the
- <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
- variable.</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>
- 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 <replaceable>target</replaceable></filename>
- command, BitBake sorts out the configurations to ultimately
- define your build environment.
- It is important to understand that the OpenEmbedded build system
- reads the configuration files in a specific order:
- <filename>site.conf</filename>, <filename>auto.conf</filename>,
- and <filename>local.conf</filename>.
- And, the build system applies the normal assignment statement
- rules.
- Because the files are parsed in a specific order, variable
- assignments for the same variable could be affected.
- For example, if the <filename>auto.conf</filename> file and
- the <filename>local.conf</filename> set
- <replaceable>variable1</replaceable> to different values, because
- the build system parses <filename>local.conf</filename> after
- <filename>auto.conf</filename>,
- <replaceable>variable1</replaceable> is assigned the value from
- the <filename>local.conf</filename> file.
- </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 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 Tasks 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/<replaceable>distro</replaceable>.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>) hold
- common functionality that can be shared among
- recipes in the distribution.
- When your recipes inherit a class, they take on the
- settings and functions for that class.
- You can read more about class files in the
- "<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/<replaceable>distro</replaceable>.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 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/<replaceable>machine</replaceable>.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>recipes-*</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
- come 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.
- You can also instruct the OpenEmbedded build system to create
- tarballs from Git repositories, which is not the default behavior,
- and store them in the <filename>DL_DIR</filename> by using the
- <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
- variable.
- </para>
-
- <para>
- 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</filename></link>
- class to include that 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</filename> class, 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
- <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
- 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>
-
- <note>
- For information on how to have the OpenEmbedded build system
- generate tarballs for Git repositories and place them in the
- <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
- directory, see the
- <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
- variable.
- </note>
-
- <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="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
- <link linkend='build-directory'>Build Directory</link>.
- 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.
- The OpenEmbedded build system provides classes to generate
- different package types, and you specify which classes to enable
- through 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</filename></link>
- class.
- </para>
-
- <para>
- The package feed area resides in the Build Directory.
- The directory the build system uses to temporarily store packages
- is determined by a combination of variables and the particular
- package manager in use.
- See the "Package Feeds" box in the illustration and note the
- information to the right of that area.
- In particular, the following defines where package files are
- kept:
- <itemizedlist>
- <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
- Defined as <filename>tmp/deploy</filename> in the Build
- Directory.
- </para></listitem>
- <listitem><para><filename>DEPLOY_DIR_*</filename>:
- Depending on the package manager used, the package type
- sub-folder.
- Given RPM, IPK, or DEB packaging and tarball creation, the
- <link linkend='var-DEPLOY_DIR_RPM'><filename>DEPLOY_DIR_RPM</filename></link>,
- <link linkend='var-DEPLOY_DIR_IPK'><filename>DEPLOY_DIR_IPK</filename></link>,
- <link linkend='var-DEPLOY_DIR_DEB'><filename>DEPLOY_DIR_DEB</filename></link>,
- or
- <link linkend='var-DEPLOY_DIR_TAR'><filename>DEPLOY_DIR_TAR</filename></link>,
- variables are used, respectively.
- </para></listitem>
- <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>:
- Defines architecture-specific sub-folders.
- For example, packages could exist for the i586 or qemux86
- architectures.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- BitBake uses the <filename>do_package_write_*</filename> tasks to
- generate packages and place them into the package holding area (e.g.
- <filename>do_package_write_ipk</filename> for IPK packages).
- See the
- "<link linkend='ref-tasks-package_write_deb'><filename>do_package_write_deb</filename></link>",
- "<link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>",
- "<link linkend='ref-tasks-package_write_rpm'><filename>do_package_write_rpm</filename></link>",
- and
- "<link linkend='ref-tasks-package_write_tar'><filename>do_package_write_tar</filename></link>"
- sections for additional information.
- As an example, consider a scenario where an IPK packaging manager
- is being used and package architecture support for both i586
- and qemux86 exist.
- Packages for the i586 architecture are placed in
- <filename>build/tmp/deploy/ipk/i586</filename>, while packages for
- the qemux86 architecture are placed in
- <filename>build/tmp/deploy/ipk/qemux86</filename>.
- </para>
- </section>
-
- <section id='bitbake-dev-environment'>
- <title>BitBake</title>
-
- <para>
- The OpenEmbedded build system uses
- <link linkend='bitbake-term'>BitBake</link>
- 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>
-
- <para>
- Separate documentation exists for the BitBake tool.
- See the
- <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>
- for reference material on BitBake.
- </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="5in" />
- </para>
-
- <para>
- The
- <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
- and
- <link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
- tasks fetch the source files and unpack them into the work
- directory.
- <note>
- For every local file (e.g. <filename>file://</filename>)
- that is part of a recipe's
- <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
- statement, the OpenEmbedded build system takes a checksum
- of the file for the recipe and inserts the checksum into
- the signature for the <filename>do_fetch</filename>.
- If any local file has been modified, the
- <filename>do_fetch</filename> task and all tasks that
- depend on it are re-executed.
- </note>
- By default, everything is accomplished in the
- <link linkend='build-directory'>Build Directory</link>,
- 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 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 that directory for any given recipe is defined from
- several different variables.
- You can see the variables that define these directories
- by looking at the figure:
- <itemizedlist>
- <listitem><para><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> -
- The base directory where the OpenEmbedded build system
- performs all its work during the build.
- </para></listitem>
- <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link> -
- The architecture of the built package or packages.
- </para></listitem>
- <listitem><para><link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link> -
- The operating system of the target device.
- </para></listitem>
- <listitem><para><link linkend='var-PN'><filename>PN</filename></link> -
- The name of the built package.
- </para></listitem>
- <listitem><para><link linkend='var-PV'><filename>PV</filename></link> -
- The version of the recipe used to build the package.
- </para></listitem>
- <listitem><para><link linkend='var-PR'><filename>PR</filename></link> -
- The revision of the recipe used to build the package.
- </para></listitem>
- <listitem><para><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link> -
- The location within <filename>TMPDIR</filename> where
- a specific package is built.
- </para></listitem>
- <listitem><para><link linkend='var-S'><filename>S</filename></link> -
- Contains the unpacked source files for a given recipe.
- </para></listitem>
- </itemizedlist>
- </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
- <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
- 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><link linkend='ref-tasks-prepare_recipe_sysroot'><filename>do_prepare_recipe_sysroot</filename></link>:</emphasis>
- This task sets up the two sysroots in
- <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}</filename>
- (i.e. <filename>recipe-sysroot</filename> and
- <filename>recipe-sysroot-native</filename>) so that
- the sysroots contain the contents of the
- <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
- tasks of the recipes on which the recipe
- containing the tasks depends.
- A sysroot exists for both the target and for the native
- binaries, which run on the host system.
- </para></listitem>
- <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
- <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
- task are specific
- to source code configuration for the source code
- being built by the recipe.</para>
-
- <para>If you are using the
- <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
- class,
- you can add additional configuration options by using
- the <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
- or
- <link linkend='var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></link>
- variables.
- For information on how this variable works within
- that class, see the
- <filename>meta/classes/autotools.bbclass</filename> file.
- </para></listitem>
- <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
- Once a configuration task has been satisfied, BitBake
- compiles the source using the
- <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
- 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 is, by
- default, 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
- <link linkend='ref-tasks-install'><filename>do_install</filename></link>
- 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
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- and
- <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
- 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> -
- The destination directory for packages before they are
- split.
- </para></listitem>
- <listitem><para><link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link> -
- A shared, global-state directory that holds data
- generated during the packaging process.
- </para></listitem>
- <listitem><para><link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link> -
- A temporary work area used by the
- <filename>do_package</filename> task.
- </para></listitem>
- <listitem><para><link linkend='var-PKGDEST'><filename>PKGDEST</filename></link> -
- The parent directory for packages after they have
- been split.
- </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 the
- <link linkend='ref-classes-package'><filename>package</filename></link>
- class.
- </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 id='image-generation-dev-environment'>
- <title>Image Generation</title>
-
- <para>
- Once packages are split and stored in the Package Feeds area,
- the OpenEmbedded build system uses BitBake to generate the
- root filesystem image:
- <imagedata fileref="figures/image-generation.png" align="center" width="6in" depth="7in" />
- </para>
-
- <para>
- The image generation process consists of several stages and
- depends on several tasks and variables.
- The
- <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
- task creates the root filesystem (file and directory structure)
- for an image.
- This task uses several key variables to help create the list
- of packages to actually install:
- <itemizedlist>
- <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
- Lists out the base set of packages to install from
- the Package Feeds area.</para></listitem>
- <listitem><para><link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>:
- Specifies packages that should not be installed.
- </para></listitem>
- <listitem><para><link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
- Specifies features to include in the image.
- Most of these features map to additional packages for
- installation.</para></listitem>
- <listitem><para><link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>:
- Specifies the package backend to use and consequently
- helps determine where to locate packages within the
- Package Feeds area.</para></listitem>
- <listitem><para><link linkend='var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></link>:
- Determines the language(s) for which additional
- language support packages are installed.
- </para></listitem>
- <listitem><para><link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>:
- The final list of packages passed to the package manager
- for installation into the image.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- With
- <link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
- pointing to the location of the filesystem under construction and
- the <filename>PACKAGE_INSTALL</filename> variable providing the
- final list of packages to install, the root file system is
- created.
- </para>
-
- <para>
- Package installation is under control of the package manager
- (e.g. dnf/rpm, opkg, or apt/dpkg) regardless of whether or
- not package management is enabled for the target.
- At the end of the process, if package management is not
- enabled for the target, the package manager's data files
- are deleted from the root filesystem.
- As part of the final stage of package installation, postinstall
- scripts that are part of the packages are run.
- Any scripts that fail to run
- on the build host are run on the target when the target system
- is first booted.
- If you are using a
- <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
- all the post installation scripts must succeed during the
- package installation phase since the root filesystem is
- read-only.
- </para>
-
- <para>
- The final stages of the <filename>do_rootfs</filename> task
- handle post processing.
- Post processing includes creation of a manifest file and
- optimizations.
- </para>
-
- <para>
- The manifest file (<filename>.manifest</filename>) resides
- in the same directory as the root filesystem image.
- This file lists out, line-by-line, the installed packages.
- The manifest file is useful for the
- <link linkend='ref-classes-testimage*'><filename>testimage</filename></link>
- class, for example, to determine whether or not to run
- specific tests.
- See the
- <link linkend='var-IMAGE_MANIFEST'><filename>IMAGE_MANIFEST</filename></link>
- variable for additional information.
- </para>
-
- <para>
- Optimizing processes run across the image include
- <filename>mklibs</filename>, <filename>prelink</filename>,
- and any other post-processing commands as defined by the
- <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>
- variable.
- The <filename>mklibs</filename> process optimizes the size
- of the libraries, while the
- <filename>prelink</filename> process optimizes the dynamic
- linking of shared libraries to reduce start up time of
- executables.
- </para>
-
- <para>
- After the root filesystem is built, processing begins on
- the image through the
- <link linkend='ref-tasks-image'><filename>do_image</filename></link>
- task.
- The build system runs any pre-processing commands as defined
- by the
- <link linkend='var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></link>
- variable.
- This variable specifies a list of functions to call before
- the OpenEmbedded build system creates the final image output
- files.
- </para>
-
- <para>
- The OpenEmbedded build system dynamically creates
- <filename>do_image_*</filename> tasks as needed, based
- on the image types specified in the
- <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
- variable.
- The process turns everything into an image file or a set of
- image files and compresses the root filesystem image to reduce
- the overall size of the image.
- The formats used for the root filesystem depend on the
- <filename>IMAGE_FSTYPES</filename> variable.
- </para>
-
- <para>
- As an example, a dynamically created task when creating a
- particular image <replaceable>type</replaceable> would take the
- following form:
- <literallayout class='monospaced'>
- do_image_<replaceable>type</replaceable>[depends]
- </literallayout>
- So, if the <replaceable>type</replaceable> as specified by the
- <filename>IMAGE_FSTYPES</filename> were
- <filename>ext4</filename>, the dynamically generated task
- would be as follows:
- <literallayout class='monospaced'>
- do_image_ext4[depends]
- </literallayout>
- </para>
-
- <para>
- The final task involved in image creation is the
- <link linkend='ref-tasks-image-complete'><filename>do_image_complete</filename></link>
- task.
- This task completes the image by applying any image
- post processing as defined through the
- <link linkend='var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></link>
- variable.
- The variable specifies a list of functions to call once the
- OpenEmbedded build system has created the final image output
- files.
- </para>
-
- <note>
- The entire image generation process is run under Pseudo.
- Running under Pseudo ensures that the files in the root
- filesystem have correct ownership.
- </note>
- </section>
-
- <section id='sdk-generation-dev-environment'>
- <title>SDK Generation</title>
-
- <para>
- The OpenEmbedded build system uses BitBake to generate the
- Software Development Kit (SDK) installer script for both the
- standard and extensible SDKs:
- <imagedata fileref="figures/sdk-generation.png" align="center" />
- </para>
-
- <note>
- For more information on the cross-development toolchain
- generation, see the
- "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
- section.
- For information on advantages gained when building a
- cross-development toolchain using the
- <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
- task, see the
- "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
- section in the Yocto Project Application Development and the
- Extensible Software Development Kit (SDK) manual.
- </note>
-
- <para>
- Like image generation, the SDK script process consists of
- several stages and depends on many variables.
- The <filename>do_populate_sdk</filename> and
- <filename>do_populate_sdk_ext</filename> tasks use these
- key variables to help create the list of packages to actually
- install.
- For information on the variables listed in the figure, see the
- "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
- section.
- </para>
-
- <para>
- The <filename>do_populate_sdk</filename> task helps create
- the standard SDK and handles two parts: a target part and a
- host part.
- The target part is the part built for the target hardware and
- includes libraries and headers.
- The host part is the part of the SDK that runs on the
- <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
- </para>
-
- <para>
- The <filename>do_populate_sdk_ext</filename> task helps create
- the extensible SDK and handles host and target parts
- differently than its counter part does for the standard SDK.
- For the extensible SDK, the task encapsulates the build system,
- which includes everything needed (host and target) for the SDK.
- </para>
-
- <para>
- Regardless of the type of SDK being constructed, the
- tasks perform some cleanup after which a cross-development
- environment setup script and any needed configuration files
- are created.
- The final output is the Cross-development
- toolchain installation script (<filename>.sh</filename> file),
- which includes the environment setup script.
- </para>
- </section>
-
- <section id='stamp-files-and-the-rerunning-of-tasks'>
- <title>Stamp Files and the Rerunning of Tasks</title>
-
- <para>
- For each task that completes successfully, BitBake writes a
- stamp file into the
- <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>
- directory.
- The beginning of the stamp file's filename is determined by the
- <link linkend='var-STAMP'><filename>STAMP</filename></link>
- variable, and the end of the name consists of the task's name
- and current
- <ulink url='&YOCTO_DOCS_BB_URL;#checksums'>input checksum</ulink>.
- <note>
- This naming scheme assumes that
- <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_SIGNATURE_HANDLER'><filename>BB_SIGNATURE_HANDLER</filename></ulink>
- is "OEBasicHash", which is almost always the case in
- current OpenEmbedded.
- </note>
- To determine if a task needs to be rerun, BitBake checks if a
- stamp file with a matching input checksum exists for the task.
- If such a stamp file exists, the task's output is assumed to
- exist and still be valid.
- If the file does not exist, the task is rerun.
- <note>
- <para>The stamp mechanism is more general than the shared
- state (sstate) cache mechanism described in the
- "<link linkend='setscene-tasks-and-shared-state'>Setscene Tasks and Shared State</link>"
- section.
- BitBake avoids rerunning any task that has a valid
- stamp file, not just tasks that can be accelerated through
- the sstate cache.</para>
- <para>However, you should realize that stamp files only
- serve as a marker that some work has been done and that
- these files do not record task output.
- The actual task output would usually be somewhere in
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
- (e.g. in some recipe's
- <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.)
- What the sstate cache mechanism adds is a way to cache task
- output that can then be shared between build machines.
- </para>
- </note>
- Since <filename>STAMPS_DIR</filename> is usually a subdirectory
- of <filename>TMPDIR</filename>, removing
- <filename>TMPDIR</filename> will also remove
- <filename>STAMPS_DIR</filename>, which means tasks will
- properly be rerun to repopulate <filename>TMPDIR</filename>.
- </para>
-
- <para>
- If you want some task to always be considered "out of date",
- you can mark it with the
- <ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'><filename>nostamp</filename></ulink>
- varflag.
- If some other task depends on such a task, then that task will
- also always be considered out of date, which might not be what
- you want.
- </para>
-
- <para>
- For details on how to view information about a task's
- signature, see the
- "<link linkend='usingpoky-viewing-task-variable-dependencies'>Viewing Task Variable Dependencies</link>"
- section.
- </para>
- </section>
-
- <section id='setscene-tasks-and-shared-state'>
- <title>Setscene Tasks and Shared State</title>
-
- <para>
- The description of tasks so far assumes that BitBake needs to
- build everything and there are no prebuilt objects available.
- BitBake does support skipping tasks if prebuilt objects are
- available.
- These objects are usually made available in the form of a
- shared state (sstate) cache.
- <note>
- For information on variables affecting sstate, see the
- <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
- and
- <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
- variables.
- </note>
- </para>
-
- <para>
- The idea of a setscene task (i.e
- <filename>do_</filename><replaceable>taskname</replaceable><filename>_setscene</filename>)
- is a version of the task where
- instead of building something, BitBake can skip to the end
- result and simply place a set of files into specific locations
- as needed.
- In some cases, it makes sense to have a setscene task variant
- (e.g. generating package files in the
- <filename>do_package_write_*</filename> task).
- In other cases, it does not make sense, (e.g. a
- <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
- task or
- <link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
- task) since the work involved would be equal to or greater than
- the underlying task.
- </para>
-
- <para>
- In the OpenEmbedded build system, the common tasks that have
- setscene variants are <link linkend='ref-tasks-package'><filename>do_package</filename></link>,
- <filename>do_package_write_*</filename>,
- <link linkend='ref-tasks-deploy'><filename>do_deploy</filename></link>,
- <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>,
- and
- <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>.
- Notice that these are most of the tasks whose output is an
- end result.
- </para>
-
- <para>
- The OpenEmbedded build system has knowledge of the relationship
- between these tasks and other tasks that precede them.
- For example, if BitBake runs
- <filename>do_populate_sysroot_setscene</filename> for
- something, there is little point in running any of the
- <filename>do_fetch</filename>, <filename>do_unpack</filename>,
- <filename>do_patch</filename>,
- <filename>do_configure</filename>,
- <filename>do_compile</filename>, and
- <filename>do_install</filename> tasks.
- However, if <filename>do_package</filename> needs to be run,
- BitBake would need to run those other tasks.
- </para>
-
- <para>
- It becomes more complicated if everything can come from an
- sstate cache because some objects are simply not required at
- all.
- For example, you do not need a compiler or native tools, such
- as quilt, if there is nothing to compile or patch.
- If the <filename>do_package_write_*</filename> packages are
- available from sstate, BitBake does not need the
- <filename>do_package</filename> task data.
- </para>
-
- <para>
- To handle all these complexities, BitBake runs in two phases.
- The first is the "setscene" stage.
- During this stage, BitBake first checks the sstate cache for
- any targets it is planning to build.
- BitBake does a fast check to see if the object exists rather
- than a complete download.
- If nothing exists, the second phase, which is the setscene
- stage, completes and the main build proceeds.
- </para>
-
- <para>
- If objects are found in the sstate cache, the OpenEmbedded
- build system works backwards from the end targets specified
- by the user.
- For example, if an image is being built, the OpenEmbedded build
- system first looks for the packages needed for that image and
- the tools needed to construct an image.
- If those are available, the compiler is not needed.
- Thus, the compiler is not even downloaded.
- If something was found to be unavailable, or the download or
- setscene task fails, the OpenEmbedded build system then tries
- to install dependencies, such as the compiler, from the cache.
- </para>
-
- <para>
- The availability of objects in the sstate cache is handled by
- the function specified by the
- <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></ulink>
- variable and returns a list of the objects that are available.
- The function specified by the
- <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></ulink>
- variable is the function that determines whether a given
- dependency needs to be followed, and whether for any given
- relationship the function needs to be passed.
- The function returns a True or False value.
- </para>
- </section>
- </section>
-
- <section id='images-dev-environment'>
- <title>Images</title>
-
- <para>
- The images produced by the OpenEmbedded build system
- are compressed forms of the
- root filesystem that are ready to boot on a target device.
- You can see from the
- <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,
- see the
- "<link linkend='ref-images'>Images</link>" chapter.
- </para>
-
- <para>
- Images are written out to the
- <link linkend='build-directory'>Build Directory</link>
- inside the <filename>tmp/deploy/images/<replaceable>machine</replaceable>/</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,
- while the
- <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
- variable points to the appropriate directory containing images for
- the current configuration.
- <itemizedlist>
- <listitem><para><filename><replaceable>kernel-image</replaceable></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/<replaceable>machine</replaceable></filename>
- directory can contain multiple image files for the
- machine.</para></listitem>
- <listitem><para><filename><replaceable>root-filesystem-image</replaceable></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/<replaceable>machine</replaceable></filename>
- directory can contain multiple root filesystems for the
- machine.</para></listitem>
- <listitem><para><filename><replaceable>kernel-modules</replaceable></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/<replaceable>machine</replaceable></filename>
- directory can contain multiple kernel module tarballs
- for the machine.</para></listitem>
- <listitem><para><filename><replaceable>bootloaders</replaceable></filename>:
- Bootloaders supporting the image, if applicable to the
- target machine.
- The <filename>deploy/images/<replaceable>machine</replaceable></filename>
- directory can contain multiple bootloaders for the
- machine.</para></listitem>
- <listitem><para><filename><replaceable>symlinks</replaceable></filename>:
- The <filename>deploy/images/<replaceable>machine</replaceable></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.
- The SDK generation process differs depending on whether you build
- a standard SDK
- (e.g. <filename>bitbake -c populate_sdk</filename> <replaceable>imagename</replaceable>)
- or an extensible SDK
- (e.g. <filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>).
- This section is going to take a closer look at this output:
- <imagedata fileref="figures/sdk.png" align="center" width="9in" depth="7.25in" />
- </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 environment setup script is added so that you can initialize
- the environment before using the tools.
- </para>
-
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><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
- or building and installing your own SDK installer.
- </para></listitem>
- <listitem><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.
- </para></listitem>
- <listitem><para>
- For information on setting up a cross-development
- environment, see the
- <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
- </para></listitem>
- </itemizedlist>
- </note>
- <para>
- Once built, the SDK installers are written out to the
- <filename>deploy/sdk</filename> folder inside the
- <link linkend='build-directory'>Build Directory</link>
- as shown in the figure at the beginning of this section.
- Depending on the type of SDK, several variables exist that help
- configure these files.
- The following list shows the variables associated with a standard
- SDK:
- <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 <replaceable>imagename</replaceable></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>
- <listitem><para><link linkend='var-SDKPATH'><filename>SDKPATH</filename></link>:
- Defines the default SDK installation path offered by the
- installation script.
- </para></listitem>
- </itemizedlist>
- This next list, shows the variables associated with an extensible
- SDK:
- <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-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></link>:
- Controls whether or not shared state artifacts are copied
- into the extensible SDK.
- By default, all required shared state artifacts are copied
- into the SDK.
- </para></listitem>
- <listitem><para><link linkend='var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></link>:
- Specifies whether or not packagedata will be included in
- the extensible SDK for all recipes in the "world" target.
- </para></listitem>
- <listitem><para><link linkend='var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></link>:
- Specifies whether or not the toolchain will be included
- when building the extensible SDK.
- </para></listitem>
- <listitem><para><link linkend='var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></link>:
- A list of variables allowed through from the build system
- configuration into the extensible SDK configuration.
- </para></listitem>
- <listitem><para><link linkend='var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></link>:
- A list of variables not allowed through from the build
- system configuration into the extensible SDK configuration.
- </para></listitem>
- <listitem><para><link linkend='var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></link>:
- A list of classes to remove from the
- <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
- value globally within the extensible SDK configuration.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-</section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-devtool-reference.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-devtool-reference.xml
index e29bf89..b974d0f 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-devtool-reference.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-devtool-reference.xml
@@ -20,7 +20,7 @@
For more information on how to apply the command when using the
extensible SDK, see the
"<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>"
- section in the Yocto Project Application Development and the
+ chapter in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
</para>
@@ -35,59 +35,51 @@
the commands:
<literallayout class='monospaced'>
$ devtool --help
- usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI]
- [--fetch-dev] [--version VERSION] [--no-git]
- [--srcrev SRCREV | --autorev] [--srcbranch SRCBRANCH]
- [--binary] [--also-native] [--src-subdir SUBDIR]
- [--mirrors] [--provides PROVIDES]
- [recipename] [srctree] [fetchuri]
+ NOTE: Starting bitbake server...
+ usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
+ [--color COLOR] [-h]
+ <subcommand> ...
- Adds a new recipe to the workspace to build a specified source tree. Can
- optionally fetch a remote URI and unpack it to create the source tree.
-
- arguments:
- recipename Name for new recipe to add (just name - no version,
- path or extension). If not specified, will attempt
- to auto-detect it.
- srctree Path to external source tree. If not specified, a
- subdirectory of
- /home/<replaceable>user</replaceable>/poky/build/workspace/sources will be
- used.
- fetchuri Fetch the specified URI and extract it to create
- the source tree
+ OpenEmbedded development tool
options:
- -h, --help show this help message and exit
- --same-dir, -s Build in same directory as source
- --no-same-dir Force build in a separate build directory
- --fetch URI, -f URI Fetch the specified URI and extract it to create
- the source tree (deprecated - pass as positional
- argument instead)
- --fetch-dev For npm, also fetch devDependencies
- --version VERSION, -V VERSION
- Version to use within recipe (PV)
- --no-git, -g If fetching source, do not set up source tree as a
- git repository
- --srcrev SRCREV, -S SRCREV
- Source revision to fetch if fetching from an SCM
- such as git (default latest)
- --autorev, -a When fetching from a git repository, set SRCREV in
- the recipe to a floating revision instead of fixed
- --srcbranch SRCBRANCH, -B SRCBRANCH
- Branch in source repository if fetching from an SCM
- such as git (default master)
- --binary, -b Treat the source tree as something that should be
- installed verbatim (no compilation, same directory
- structure). Useful with binary packages e.g. RPMs.
- --also-native Also add native variant (i.e. support building
- recipe for the build host as well as the target
- machine)
- --src-subdir SUBDIR Specify subdirectory within source tree to use
- --mirrors Enable PREMIRRORS and MIRRORS for source tree
- fetching (disable by default).
- --provides PROVIDES, -p PROVIDES
- Specify an alias for the item provided by the
- recipe. E.g. virtual/libgl
+ --basepath BASEPATH Base directory of SDK / build directory
+ --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it
+ from the metadata
+ -d, --debug Enable debug output
+ -q, --quiet Print only errors
+ --color COLOR Colorize output (where COLOR is auto, always, never)
+ -h, --help show this help message and exit
+
+ subcommands:
+ Beginning work on a recipe:
+ add Add a new recipe
+ modify Modify the source for an existing recipe
+ upgrade Upgrade an existing recipe
+ Getting information:
+ status Show workspace status
+ search Search available recipes
+ latest-version Report the latest version of an existing recipe
+ Working on a recipe in the workspace:
+ build Build a recipe
+ rename Rename a recipe file in the workspace
+ edit-recipe Edit a recipe file
+ find-recipe Find a recipe file
+ configure-help Get help on configure script options
+ update-recipe Apply changes from external source tree to recipe
+ reset Remove a recipe from your workspace
+ finish Finish working on a recipe in your workspace
+ Testing changes on target:
+ deploy-target Deploy recipe output files to live target machine
+ undeploy-target Undeploy recipe output files in live target machine
+ build-image Build image including workspace recipe packages
+ Advanced:
+ create-workspace Set up workspace in an alternative location
+ export Export workspace into a tar archive
+ import Import exported tar archive into workspace
+ extract Extract the source for an existing recipe
+ sync Synchronize the source tree for an existing recipe
+ Use devtool <subcommand> --help to get help on a specific command
</literallayout>
</para>
@@ -97,9 +89,12 @@
name and using <filename>--help</filename>:
<literallayout class='monospaced'>
$ devtool add --help
+ NOTE: Starting bitbake server...
usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI]
- [--version VERSION] [--no-git] [--autorev] [--binary]
- [--also-native] [--src-subdir SUBDIR]
+ [--fetch-dev] [--version VERSION] [--no-git]
+ [--srcrev SRCREV | --autorev] [--srcbranch SRCBRANCH]
+ [--binary] [--also-native] [--src-subdir SUBDIR]
+ [--mirrors] [--provides PROVIDES]
[recipename] [srctree] [fetchuri]
Adds a new recipe to the workspace to build a specified source tree. Can
@@ -123,18 +118,30 @@
--fetch URI, -f URI Fetch the specified URI and extract it to create the
source tree (deprecated - pass as positional argument
instead)
+ --fetch-dev For npm, also fetch devDependencies
--version VERSION, -V VERSION
Version to use within recipe (PV)
--no-git, -g If fetching source, do not set up source tree as a git
repository
+ --srcrev SRCREV, -S SRCREV
+ Source revision to fetch if fetching from an SCM such
+ as git (default latest)
--autorev, -a When fetching from a git repository, set SRCREV in the
recipe to a floating revision instead of fixed
+ --srcbranch SRCBRANCH, -B SRCBRANCH
+ Branch in source repository if fetching from an SCM
+ such as git (default master)
--binary, -b Treat the source tree as something that should be
installed verbatim (no compilation, same directory
structure). Useful with binary packages e.g. RPMs.
--also-native Also add native variant (i.e. support building recipe
for the build host as well as the target machine)
--src-subdir SUBDIR Specify subdirectory within source tree to use
+ --mirrors Enable PREMIRRORS and MIRRORS for source tree fetching
+ (disable by default).
+ --provides PROVIDES, -p PROVIDES
+ Specify an alias for the item provided by the recipe.
+ E.g. virtual/libgl
</literallayout>
</para>
</section>
@@ -161,7 +168,7 @@
<para>
<literallayout class='monospaced'>
- attic - A directory created if devtool believes it preserve
+ attic - A directory created if devtool believes it must preserve
anything when you run "devtool reset". For example, if you
run "devtool add", make changes to the recipe, and then
run "devtool reset", devtool takes notice that the file has
@@ -426,12 +433,27 @@
<title>Upgrading a Recipe</title>
<para>
- Use the <filename>devtool upgrade</filename> command
- to upgrade an existing recipe to a new upstream version.
- The command puts the upgraded recipe file into the
- workspace along with any associated files, and extracts
- the source tree to a specified location should patches
- need rebased or added to as a result of the upgrade.
+ As software matures, upstream recipes are upgraded to newer
+ versions.
+ As a developer, you need to keep your local recipes up-to-date
+ with the upstream version releases.
+ Several methods exist by which you can upgrade recipes.
+ You can read about them in the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#gs-upgrading-recipes'>Upgrading Recipes</ulink>"
+ section of the Yocto Project Development Tasks Manual.
+ This section overviews the <filename>devtool upgrade</filename>
+ command.
+ </para>
+
+ <para>
+ The <filename>devtool upgrade</filename> command
+ upgrades an existing recipe to a more recent version of the
+ recipe upstream.
+ The command puts the upgraded recipe file along with any associated
+ files into a "workspace" and, if necessary, extracts the source
+ tree to a specified location.
+ During the upgrade, patches associated with the recipe are
+ rebased or added as needed.
</para>
<para>
@@ -443,9 +465,21 @@
the version number to which you want to upgrade (i.e. the
<link linkend='var-PV'><filename>PV</filename></link>),
the source revision to which you want to upgrade (i.e. the
- <link linkend='var-SRCREV'><filename>SRCREV</filename></link>,
+ <link linkend='var-SRCREV'><filename>SRCREV</filename></link>),
whether or not to apply patches, and so forth.
</para>
+
+ <para>
+ You can read more on the <filename>devtool upgrade</filename>
+ workflow in the
+ "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software'>Use <filename>devtool upgrade</filename> to Create a Version of the Recipe that Supports a Newer Version of the Software</ulink>"
+ section in the Yocto Project Application Development and the
+ Extensible Software Development Kit (eSDK) manual.
+ You can also see an example of how to use
+ <filename>devtool upgrade</filename> in the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#gs-using-devtool-upgrade'>Using <filename>devtool upgrade</filename></ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para>
</section>
<section id='devtool-resetting-a-recipe'>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-features.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-features.xml
index 02857dc..cb74df6 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-features.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-features.xml
@@ -161,9 +161,9 @@
protocols support.
<note>
The default value for the
- <link linkend='var-DISTRO_FEATURES'><filename>DISTRO FEATURES</filename></link>
- variable includes "bluetooth", which causes bluez5
- to be backfilled in for bluetooth support.
+ <filename>DISTRO FEATURES</filename> variable includes
+ "bluetooth", which causes bluez5 to be backfilled in
+ for bluetooth support.
If you do not want bluez5 backfilled and would rather
use bluez4, you need to use the
<link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-images.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-images.xml
index c752f94..1f96186 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-images.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-images.xml
@@ -40,15 +40,19 @@
<para>
Following is a list of supported recipes:
<itemizedlist>
- <listitem><para><filename>build-appliance-image</filename>:
- An example virtual machine that contains all the pieces required to
- run builds using the build system as well as the build system itself.
+ <listitem><para>
+ <filename>build-appliance-image</filename>:
+ An example virtual machine that contains all the pieces
+ required to run builds using the build system as well as the
+ build system itself.
You can boot and run the image using either the
<ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
- or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
+ or
+ <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
For more information on this image, see the
- <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
- the Yocto Project website.</para></listitem>
+ <ulink url='&YOCTO_HOME_URL;/software-item/build-appliance/'>Build Appliance</ulink>
+ page on the Yocto Project website.
+ </para></listitem>
<listitem><para><filename>core-image-base</filename>:
A console-only image that fully supports the target device hardware.</para></listitem>
<listitem><para><filename>core-image-clutter</filename>:
@@ -151,7 +155,8 @@
This image provides the Wayland protocol libraries and the
reference Weston compositor.
For more information, see the
- "<link linkend='wayland'>Wayland</link>" section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-using-wayland-and-weston'>Using Wayland and Weston</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para></listitem>
<listitem><para><filename>core-image-x11</filename>:
A very basic X11 image with a terminal.
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-kickstart.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-kickstart.xml
index 1dd36b2..a58f9d7 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-kickstart.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-kickstart.xml
@@ -27,15 +27,10 @@
Kickstart commands are based on the Fedora kickstart versions but
with modifications to reflect Wic capabilities.
You can see the original documentation for those commands at the
- following links:
- <itemizedlist>
- <listitem><para>
- <ulink url='http://fedoraproject.org/wiki/Anaconda/Kickstart#part_or_partition'>http://fedoraproject.org/wiki/Anaconda/Kickstart#part_or_partition</ulink>
- </para></listitem>
- <listitem><para>
- <ulink url='http://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader'>http://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader</ulink>
- </para></listitem>
- </itemizedlist>
+ following link:
+ <literallayout class='monospaced'>
+ <ulink url='http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html'>http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html</ulink>
+ </literallayout>
</para>
</section>
@@ -43,7 +38,7 @@
<title>Command: part or partition</title>
<para>
- Either of these commands create a partition on the system and use
+ Either of these commands creates a partition on the system and uses
the following syntax:
<literallayout class='monospaced'>
part [<replaceable>mntpoint</replaceable>]
@@ -55,7 +50,7 @@
<para>
The <filename><replaceable>mntpoint</replaceable></filename> is
- where the partition will be mounted and must be of one of the
+ where the partition is mounted and must be in one of the
following forms:
<itemizedlist>
<listitem><para>
@@ -64,7 +59,7 @@
</para></listitem>
<listitem><para>
<filename>swap</filename>:
- The created partition is used as swap space.
+ The created partition is used as swap space
</para></listitem>
</itemizedlist>
</para>
@@ -74,13 +69,22 @@
partition to automatically be mounted.
Wic achieves this by adding entries to the filesystem table (fstab)
during image generation.
- In order for wic to generate a valid fstab, you must also provide
+ In order for Wic to generate a valid fstab, you must also provide
one of the <filename>--ondrive</filename>,
<filename>--ondisk</filename>, or
<filename>--use-uuid</filename> partition options as part of the
command.
- Here is an example using "/" as the mountpoint.
- The command uses "--ondisk" to force the partition onto the
+ <note>
+ The mount program must understand the PARTUUID syntax you use
+ with <filename>--use-uuid</filename> and non-root
+ <replaceable>mountpoint</replaceable>, including swap.
+ The busybox versions of these application are currently
+ excluded.
+ </note>
+ Here is an example that uses "/" as the
+ <replaceable>mountpoint</replaceable>.
+ The command uses <filename>--ondisk</filename> to force the
+ partition onto the
<filename>sdb</filename> disk:
<literallayout class='monospaced'>
part / --source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024
@@ -101,17 +105,26 @@
<filename>--source</filename>.
</para></listitem>
<listitem><para>
+ <emphasis><filename>--fixed-size</filename>:</emphasis>
+ The exact partition size in MBytes.
+ You cannot specify with <filename>--size</filename>.
+ An error occurs when assembling the disk image if the
+ partition data is larger than
+ <filename>--fixed-size</filename>.
+ </para></listitem>
+ <listitem><para>
<emphasis><filename>--source</filename>:</emphasis>
This option is a Wic-specific option that names the source
of the data that populates the partition.
The most common value for this option is "rootfs", but you
can use any value that maps to a valid source plug-in.
For information on the source plug-ins, see the
- "<link linkend='wic-plug-ins-interface'>Wic Plug-Ins Interface</link>"
- section.</para>
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#wic-using-the-wic-plug-ins-interface'>Using the Wic Plug-Ins Interface</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para>
<para>If you use <filename>--source rootfs</filename>, Wic
- creates a partition as large as needed and to fill it with
+ creates a partition as large as needed and fills it with
the contents of the root filesystem pointed to by the
<filename>-r</filename> command-line option or the
equivalent rootfs derived from the <filename>-e</filename>
@@ -130,8 +143,8 @@
<filename>-r</filename> command-line option or the
equivalent rootfs derived from the <filename>-e</filename>
command-line option.
- Exactly what those contents and filesystem type end up
- being are dependent on the given plug-in implementation.
+ Exactly what those contents are and filesystem type used are
+ dependent on the given plug-in implementation.
</para>
<para>If you do not use the <filename>--source</filename>
@@ -173,7 +186,7 @@
<emphasis><filename>--fsoptions</filename>:</emphasis>
Specifies a free-form string of options to be used when
mounting the filesystem.
- This string will be copied into the
+ This string is copied into the
<filename>/etc/fstab</filename> file of the installed
system and should be enclosed in quotes.
If not specified, the default string is "defaults".
@@ -191,9 +204,9 @@
</para></listitem>
<listitem><para>
<emphasis><filename>--align (in KBytes)</filename>:</emphasis>
- This option is a Wic-specific option that says to start a
- partition on an <replaceable>x</replaceable> KBytes
- boundary.
+ This option is a Wic-specific option that says to start
+ partitions on boundaries given
+ <replaceable>x</replaceable> KBytes.
</para></listitem>
<listitem><para>
<emphasis><filename>--no-table</filename>:</emphasis>
@@ -203,10 +216,17 @@
However, the partition is not added to the partition table.
</para></listitem>
<listitem><para>
+ <emphasis><filename>--exclude-path</filename>:</emphasis>
+ This option is a Wic-specific option that excludes the given
+ relative path from the resulting image.
+ This option is only effective with the rootfs source
+ plug-in.
+ </para></listitem>
+ <listitem><para>
<emphasis><filename>--extra-space</filename>:</emphasis>
This option is a Wic-specific option that adds extra space
after the space filled by the content of the partition.
- The final size can go beyond the size specified by the
+ The final size can exceed the size specified by the
<filename>--size</filename> option.
The default value is 10 Mbytes.
</para></listitem>
@@ -218,6 +238,11 @@
The default value is "1.3".
</para></listitem>
<listitem><para>
+ <emphasis><filename>--part-name</filename>:</emphasis>
+ This option is a Wic-specific option that specifies a name
+ for GPT partitions.
+ </para></listitem>
+ <listitem><para>
<emphasis><filename>--part-type</filename>:</emphasis>
This option is a Wic-specific option that specifies the
partition type globally unique identifier (GUID) for GPT
@@ -237,6 +262,31 @@
This option is a Wic-specific option that specifies the
partition UUID.
</para></listitem>
+ <listitem><para>
+ <emphasis><filename>--fsuuid</filename>:</emphasis>
+ This option is a Wic-specific option that specifies the
+ filesystem UUID.
+ You can generate or modify
+ <link linkend='var-WKS_FILE'><filename>WKS_FILE</filename></link>
+ with this option if a preconfigured filesystem UUID is
+ added to the kernel command line in the bootloader
+ configuration before you run Wic.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>--system-id</filename>:</emphasis>
+ This option is a Wic-specific option that specifies the
+ partition system ID, which is a one byte long, hexadecimal
+ parameter with or without the 0x prefix.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>--mkfs-extraopts</filename>:</emphasis>
+ This option specifies additional options to pass to the
+ <filename>mkfs</filename> utility.
+ Some default options for certain filesystems do not take
+ effect.
+ See Wic's help on kickstart
+ (i.e. <filename>wic help kickstart</filename>).
+ </para></listitem>
</itemizedlist>
</para>
</section>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-manual.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-manual.xml
index d4b7bee..169a31e 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-manual.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-manual.xml
@@ -118,14 +118,9 @@
<revremark>Released with the Yocto Project 2.4 Release.</revremark>
</revision>
<revision>
- <revnumber>2.4.1</revnumber>
- <date>January 2018</date>
- <revremark>Released with the Yocto Project 2.4.1 Release.</revremark>
- </revision>
- <revision>
- <revnumber>2.4.2</revnumber>
- <date>March 2018</date>
- <revremark>Released with the Yocto Project 2.4.2 Release.</revremark>
+ <revnumber>2.5</revnumber>
+ <date>May 2018</date>
+ <revremark>Released with the Yocto Project 2.5 Release.</revremark>
</revision>
</revhistory>
@@ -147,37 +142,45 @@
is for the &YOCTO_DOC_VERSION; release of the
Yocto Project.
To be sure you have the latest version of the manual
- for this release, use the manual from the
- <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
- </para></listitem>
- <listitem><para>
- For manuals associated with other releases of the Yocto
- Project, go to the
+ for this release, go to the
<ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
- and use the drop-down "Active Releases" button
- and choose the manual associated with the desired
- Yocto Project.
+ and select the manual from that site.
+ Manuals from the site are more up-to-date than manuals
+ derived from the Yocto Project released TAR files.
</para></listitem>
<listitem><para>
- To report any inaccuracies or problems with this
- manual, send an email to the Yocto Project
- discussion group at
- <filename>yocto@yoctoproject.com</filename> or log into
- the freenode <filename>#yocto</filename> channel.
- </para></listitem>
+ If you located this manual through a web search, the
+ version of the manual might not be the one you want
+ (e.g. the search might have returned a manual much
+ older than the Yocto Project version with which you
+ are working).
+ You can see all Yocto Project major releases by
+ visiting the
+ <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
+ page.
+ If you need a version of this manual for a different
+ Yocto Project release, visit the
+ <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+ and select the manual set by using the
+ "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
+ pull-down menus.
+ </para></listitem>
+ <listitem><para>
+ To report any inaccuracies or problems with this
+ manual, send an email to the Yocto Project
+ discussion group at
+ <filename>yocto@yoctoproject.com</filename> or log into
+ the freenode <filename>#yocto</filename> channel.
+ </para></listitem>
</itemizedlist>
</note>
</legalnotice>
</bookinfo>
- <xi:include href="introduction.xml"/>
+ <xi:include href="ref-system-requirements.xml"/>
- <xi:include href="usingpoky.xml"/>
-
- <xi:include href="ref-development-environment.xml"/>
-
- <xi:include href="technical-details.xml"/>
+ <xi:include href="ref-terms.xml"/>
<xi:include href="ref-release-process.xml"/>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-release-process.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-release-process.xml
index e2902eb..c665cd9 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-release-process.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-release-process.xml
@@ -61,7 +61,7 @@
<para>
Each major release receives a codename that identifies the release in
the
- <link linkend='yocto-project-repositories'>Yocto Project Source Repositories</link>.
+ <ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>.
The concept is that branches of
<link linkend='metadata'>Metadata</link>
with the same codename are likely to be compatible and thus
@@ -217,7 +217,7 @@
in the <filename>poky</filename> repository.
<note>
You can find all these branches in the Yocto Project
- <link linkend='source-repositories'>Source Repositories</link>.
+ <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>.
</note>
Testing within these public branches ensures in a publicly visible way
that all of the main supposed architectures and recipes in OE-Core
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-structure.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-structure.xml
index 4bddc59..8e0c9f5 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-structure.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-structure.xml
@@ -18,7 +18,7 @@
<para>
For information on how to establish a local Source Directory on your
development system, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
@@ -114,7 +114,7 @@
<title><filename>meta/</filename></title>
<para>
- This directory contains the OpenEmbedded Core metadata.
+ This directory contains the OpenEmbedded-Core metadata.
The directory holds recipes, common classes, and machine
configuration for emulated targets (<filename>qemux86</filename>,
<filename>qemuarm</filename>, and so forth.)
@@ -137,8 +137,7 @@
This directory contains the Yocto Project reference
hardware Board Support Packages (BSPs).
For more information on BSPs, see the
- <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support
- Package (BSP) Developer's Guide</ulink>.
+ <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
</para>
</section>
@@ -234,8 +233,7 @@
</para>
<para>
- By default, running this script without a
- <link linkend='build-directory'>Build Directory</link>
+ By default, running this script without a Build Directory
argument creates the <filename>build</filename> directory
in your current working directory.
If you provide a Build Directory argument when you
@@ -306,8 +304,8 @@
The directory tracks build information into image, packages, and
SDK subdirectories.
For information on the build history feature, see the
- "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</section>
@@ -350,7 +348,7 @@
which defaults to <filename>meta-poky/conf</filename>
when you are building from the Yocto Project development
environment and defaults to <filename>meta/conf</filename> when
- you are building from the OpenEmbedded Core environment.
+ you are building from the OpenEmbedded-Core environment.
Because the script variable points to the source of the
<filename>local.conf.sample</filename> file, this implies that
you can configure your build environment from any layer by setting
@@ -402,7 +400,7 @@
which defaults to <filename>meta-poky/conf</filename>
when you are building from the Yocto Project development
environment and defaults to <filename>meta/conf</filename> when
- you are building from the OpenEmbedded Core environment.
+ you are building from the OpenEmbedded-Core environment.
Because the script variable points to the source of the
<filename>bblayers.conf.sample</filename> file, this implies that
you can base your build from any layer by setting the variable in
@@ -520,9 +518,10 @@
variable points to this directory.
For more detail on the contents of the <filename>deploy</filename>
directory, see the
- "<link linkend='images-dev-environment'>Images</link>" and
- "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
- sections.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#images-dev-environment'>Images</ulink>"
+ and
+ "<ulink url='&YOCTO_DOCS_OM_URL;#sdk-dev-environment'>Application Development SDK</ulink>"
+ sections in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -695,8 +694,8 @@
<para>
For information on how BitBake uses stamp files to determine if
a task should be rerun, see the
- "<link linkend='stamp-files-and-the-rerunning-of-tasks'>Stamp Files and the Rerunning of Tasks</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks'>Stamp Files and the Rerunning of Tasks</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -735,8 +734,7 @@
built within the Yocto Project.
For this package, a work directory of
<filename>tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....></filename>,
- referred to as the
- <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.
+ referred to as the <filename>WORKDIR</filename>, is created.
Within this directory, the source is unpacked to
<filename>linux-qemux86-standard-build</filename> and then patched by Quilt.
(See the
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-system-requirements.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-system-requirements.xml
new file mode 100644
index 0000000..aea1fdf
--- /dev/null
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-system-requirements.xml
@@ -0,0 +1,490 @@
+<!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='ref-manual-system-requirements'>
+<title>System Requirements</title>
+
+ <para>
+ Welcome to the Yocto Project Reference Manual!
+ This manual provides reference information for the current release
+ of the Yocto Project.
+ The manual is best used after you have an understanding
+ of the basics of the Yocto Project.
+ The manual is neither meant to be read as a starting point to the
+ Yocto Project nor read from start to finish.
+ Use this manual to find variable definitions, class
+ descriptions, and so forth as needed during the course of using
+ the Yocto Project.
+ </para>
+
+ <para>
+ For introductory information on the Yocto Project, see the
+ <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#overview-development-environment'>Yocto Project Development Environment</ulink>"
+ chapter in the Yocto Project Overview and Concepts Manual.
+ </para>
+
+ <para>
+ If you want to use the Yocto Project to quickly build an image
+ without having to understand concepts, work through the
+ <ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink>
+ document.
+ You can find "how-to" information in the
+ <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Tasks Manual</ulink>.
+ You can find Yocto Project overview and conceptual information in the
+ <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>.
+ <note><title>Tip</title>
+ For more information about the Yocto Project Documentation set,
+ see the
+ "<link linkend='resources-links-and-related-documentation'>Links and Related Documentation</link>"
+ section.
+ </note>
+ </para>
+
+ <section id='detailed-supported-distros'>
+ <title>Supported Linux Distributions</title>
+
+ <para>
+ Currently, the Yocto Project is supported on the following
+ distributions:
+ <note><title>Notes</title>
+ <itemizedlist>
+ <listitem><para>
+ Yocto Project releases are tested against the stable
+ Linux distributions in the following list.
+ The Yocto Project should work on other distributions but
+ validation is not performed against them.
+ </para></listitem>
+ <listitem><para>
+ In particular, the Yocto Project does not support
+ and currently has no plans to support
+ rolling-releases or development distributions due to
+ their constantly changing nature.
+ We welcome patches and bug reports, but keep in mind
+ that our priority is on the supported platforms listed
+ below.
+ </para></listitem>
+ <listitem><para>
+ If you encounter problems, please go to
+ <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
+ and submit a bug.
+ We are interested in hearing about your experience.
+ For information on how to submit a bug, see the
+ Yocto Project
+ <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>Bugzilla wiki page</ulink>
+ and the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project'>Submitting a Defect Against the Yocto Project</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para></listitem>
+ </itemizedlist>
+ </note>
+ <itemizedlist>
+<!--
+ <listitem><para>Ubuntu 10.04</para></listitem>
+ <listitem><para>Ubuntu 11.10</para></listitem>
+ <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
+ <listitem><para>Ubuntu 13.10</para></listitem>
+ <listitem><para>Ubuntu 14.04 (LTS)</para></listitem> -->
+ <listitem><para>Ubuntu 14.10</para></listitem>
+ <listitem><para>Ubuntu 15.04</para></listitem>
+ <listitem><para>Ubuntu 15.10</para></listitem>
+ <listitem><para>Ubuntu 16.04 (LTS)</para></listitem>
+<!-- <listitem><para>Fedora 16 (Verne)</para></listitem>
+ <listitem><para>Fedora 17 (Spherical)</para></listitem>
+ <listitem><para>Fedora release 19 (Schrödinger's Cat)</para></listitem>
+ <listitem><para>Fedora release 20 (Heisenbug)</para></listitem> -->
+ <listitem><para>Fedora release 22</para></listitem>
+ <listitem><para>Fedora release 23</para></listitem>
+<!-- <listitem><para>Fedora release 24</para></listitem>
+ <listitem><para>CentOS release 5.6 (Final)</para></listitem>
+ <listitem><para>CentOS release 5.7 (Final)</para></listitem>
+ <listitem><para>CentOS release 5.8 (Final)</para></listitem>
+ <listitem><para>CentOS release 6.3 (Final)</para></listitem>
+ <listitem><para>CentOS release 6.x</para></listitem> -->
+ <listitem><para>CentOS release 7.x</para></listitem>
+<!-- <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.x (Wheezy)</para></listitem> -->
+ <listitem><para>Debian GNU/Linux 8.x (Jessie)</para></listitem>
+ <listitem><para>Debian GNU/Linux 9.x (Stretch)</para></listitem>
+<!-- <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.5 (Wheezy)</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem> -->
+<!-- <listitem><para>openSUSE 11.4</para></listitem>
+ <listitem><para>openSUSE 12.1</para></listitem>
+ <listitem><para>openSUSE 12.2</para></listitem>
+ <listitem><para>openSUSE 12.3</para></listitem>
+ <listitem><para>openSUSE 13.1</para></listitem> -->
+ <listitem><para>openSUSE 13.2</para></listitem>
+ <listitem><para>openSUSE 42.1</para></listitem>
+ </itemizedlist>
+ </para>
+
+ <note>
+ While the Yocto Project Team attempts to ensure all Yocto Project
+ releases are one hundred percent compatible with each officially
+ supported Linux distribution, instances might exist where you
+ encounter a problem while using the Yocto Project on a specific
+ distribution.
+ </note>
+ </section>
+
+ <section id='required-packages-for-the-host-development-system'>
+ <title>Required Packages for the Host Development System</title>
+
+ <para>
+ The list of packages you need on the host development system can
+ be large when covering all build scenarios using the Yocto Project.
+ This section provides required packages according to
+ Linux distribution and function.
+ </para>
+
+ <section id='ubuntu-packages'>
+ <title>Ubuntu and Debian</title>
+
+ <para>
+ The following list shows the required packages by function
+ given a supported Ubuntu or Debian Linux distribution:
+ <note>
+ If your build system has the
+ <filename>oss4-dev</filename> package installed, you
+ might experience QEMU build failures due to the package
+ installing its own custom
+ <filename>/usr/include/linux/soundcard.h</filename> on
+ the Debian system.
+ If you run into this situation, either of the following
+ solutions exist:
+ <literallayout class='monospaced'>
+ $ sudo apt-get build-dep qemu
+ $ sudo apt-get remove oss4-dev
+ </literallayout>
+ </note>
+ <itemizedlist>
+ <listitem><para><emphasis>Essentials:</emphasis>
+ Packages needed to build an image on a headless
+ system:
+ <literallayout class='monospaced'>
+ $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+ Packages recommended if the host system has graphics
+ support or if you are going to use the Eclipse
+ IDE:
+ <literallayout class='monospaced'>
+ $ sudo apt-get install libsdl1.2-dev xterm
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Documentation:</emphasis>
+ Packages needed if you are going to build out the
+ Yocto Project documentation manuals:
+ <literallayout class='monospaced'>
+ $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+ Packages needed if you are going to run
+ <filename>oe-selftest</filename>:
+ <literallayout class='monospaced'>
+ $ sudo apt-get install python-git
+ </literallayout>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='fedora-packages'>
+ <title>Fedora Packages</title>
+
+ <para>
+ The following list shows the required packages by function
+ given a supported Fedora Linux distribution:
+ <itemizedlist>
+ <listitem><para><emphasis>Essentials:</emphasis>
+ Packages needed to build an image for a headless
+ system:
+ <literallayout class='monospaced'>
+ $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+ Packages recommended if the host system has graphics
+ support or if you are going to use the Eclipse
+ IDE:
+ <literallayout class='monospaced'>
+ $ sudo dnf install SDL-devel xterm
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Documentation:</emphasis>
+ Packages needed if you are going to build out the
+ Yocto Project documentation manuals:
+ <literallayout class='monospaced'>
+ $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
+ docbook-dtds docbook-utils fop libxslt dblatex xmlto
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+ Packages needed if you are going to run
+ <filename>oe-selftest</filename>:
+ <literallayout class='monospaced'>
+ $ sudo dnf install python3-GitPython
+ </literallayout>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='opensuse-packages'>
+ <title>openSUSE Packages</title>
+
+ <para>
+ The following list shows the required packages by function
+ given a supported openSUSE Linux distribution:
+ <itemizedlist>
+ <listitem><para><emphasis>Essentials:</emphasis>
+ Packages needed to build an image for a headless
+ system:
+ <literallayout class='monospaced'>
+ $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+ Packages recommended if the host system has graphics
+ support or if you are going to use the Eclipse
+ IDE:
+ <literallayout class='monospaced'>
+ $ sudo zypper install libSDL-devel xterm
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Documentation:</emphasis>
+ Packages needed if you are going to build out the
+ Yocto Project documentation manuals:
+ <literallayout class='monospaced'>
+ $ sudo zypper install make dblatex xmlto
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+ Packages needed if you are going to run
+ <filename>oe-selftest</filename>:
+ <literallayout class='monospaced'>
+ $ sudo zypper install python-GitPython
+ </literallayout></para></listitem>
+ </itemizedlist>
+ <note>
+ Sanity testing, through the
+ <link linkend='ref-classes-testimage*'>testimage</link>
+ classes, does not work on systems using the
+ <ulink url='https://en.opensuse.org/Portal:Wicked'>Wicked</ulink>
+ network manager.
+ </note>
+ </para>
+ </section>
+
+ <section id='centos-packages'>
+ <title>CentOS Packages</title>
+
+ <para>
+ The following list shows the required packages by function
+ given a supported CentOS Linux distribution:
+ <itemizedlist>
+ <listitem><para><emphasis>Essentials:</emphasis>
+ Packages needed to build an image for a headless
+ system:
+ <literallayout class='monospaced'>
+ $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+ </literallayout>
+ <note><title>Notes</title>
+ <itemizedlist>
+ <listitem><para>
+ Extra Packages for Enterprise Linux
+ (i.e. <filename>epel-release</filename>)
+ is a collection of packages from Fedora
+ built on RHEL/CentOS for easy installation
+ of packages not included in enterprise
+ Linux by default.
+ You need to install these packages
+ separately.
+ </para></listitem>
+ <listitem><para>
+ The <filename>makecache</filename> command
+ consumes additional Metadata from
+ <filename>epel-release</filename>.
+ </para></listitem>
+ </itemizedlist>
+ </note>
+ </para></listitem>
+ <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
+ Packages recommended if the host system has graphics
+ support or if you are going to use the Eclipse
+ IDE:
+ <literallayout class='monospaced'>
+ $ sudo yum install SDL-devel xterm
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>Documentation:</emphasis>
+ Packages needed if you are going to build out the
+ Yocto Project documentation manuals:
+ <literallayout class='monospaced'>
+ $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+ docbook-dtds docbook-utils fop libxslt dblatex xmlto
+ </literallayout></para></listitem>
+ <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+ Packages needed if you are going to run
+ <filename>oe-selftest</filename>:
+ <literallayout class='monospaced'>
+ $ sudo yum install GitPython
+ </literallayout>
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+ </section>
+
+ <section id='required-git-tar-and-python-versions'>
+ <title>Required Git, tar, and Python Versions</title>
+
+ <para>
+ In order to use the build system, your host development system
+ must meet the following version requirements for Git, tar, and
+ Python:
+ <itemizedlist>
+ <listitem><para>Git 1.8.3.1 or greater</para></listitem>
+ <listitem><para>tar 1.27 or greater</para></listitem>
+ <listitem><para>Python 3.4.0 or greater</para></listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ If your host development system does not meet all these requirements,
+ you can resolve this by installing a <filename>buildtools</filename>
+ tarball that contains these tools.
+ You can get the tarball one of two ways: download a pre-built
+ tarball or use BitBake to build the tarball.
+ </para>
+
+ <section id='downloading-a-pre-built-buildtools-tarball'>
+ <title>Downloading a Pre-Built <filename>buildtools</filename> Tarball</title>
+
+ <para>
+ Downloading and running a pre-built buildtools installer is
+ the easiest of the two methods by which you can get these tools:
+ <orderedlist>
+ <listitem><para>
+ Locate and download the <filename>*.sh</filename> at
+ <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
+ </para></listitem>
+ <listitem><para>
+ Execute the installation script.
+ Here is an example:
+ <literallayout class='monospaced'>
+ $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+ </literallayout>
+ During execution, a prompt appears that allows you to
+ choose the installation directory.
+ For example, you could choose the following:
+ <literallayout class='monospaced'>
+ /home/<replaceable>your-username</replaceable>/buildtools
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ Source the tools environment setup script by using a
+ command like the following:
+ <literallayout class='monospaced'>
+ $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-i586-poky-linux
+ </literallayout>
+ Of course, you need to supply your installation directory and be
+ sure to use the right file (i.e. i585 or x86-64).
+ </para>
+ <para>
+ After you have sourced the setup script,
+ the tools are added to <filename>PATH</filename>
+ and any other environment variables required to run the
+ tools are initialized.
+ The results are working versions versions of Git, tar,
+ Python and <filename>chrpath</filename>.
+ </para></listitem>
+ </orderedlist>
+ </para>
+ </section>
+
+ <section id='building-your-own-buildtools-tarball'>
+ <title>Building Your Own <filename>buildtools</filename> Tarball</title>
+
+ <para>
+ Building and running your own buildtools installer applies
+ only when you have a build host that can already run BitBake.
+ In this case, you use that machine to build the
+ <filename>.sh</filename> file and then
+ take steps to transfer and run it on a
+ machine that does not meet the minimal Git, tar, and Python
+ requirements.
+ </para>
+
+ <para>
+ Here are the steps to take to build and run your own
+ buildtools installer:
+ <orderedlist>
+ <listitem><para>
+ On the machine that is able to run BitBake,
+ be sure you have set up your build environment with
+ the setup script
+ (<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
+ </para></listitem>
+ <listitem><para>
+ Run the BitBake command to build the tarball:
+ <literallayout class='monospaced'>
+ $ bitbake buildtools-tarball
+ </literallayout>
+ <note>
+ The
+ <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>
+ variable in your <filename>local.conf</filename> file
+ determines whether you build tools for a 32-bit
+ or 64-bit system.
+ </note>
+ Once the build completes, you can find the
+ <filename>.sh</filename> file that installs
+ the tools in the <filename>tmp/deploy/sdk</filename>
+ subdirectory of the
+ <link linkend='build-directory'>Build Directory</link>.
+ The installer file has the string "buildtools"
+ in the name.
+ </para></listitem>
+ <listitem><para>
+ Transfer the <filename>.sh</filename> file from the
+ build host to the machine that does not meet the
+ Git, tar, or Python requirements.
+ </para></listitem>
+ <listitem><para>
+ On the machine that does not meet the requirements,
+ run the <filename>.sh</filename> file
+ to install the tools.
+ Here is an example:
+ <literallayout class='monospaced'>
+ $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+ </literallayout>
+ During execution, a prompt appears that allows you to
+ choose the installation directory.
+ For example, you could choose the following:
+ <literallayout class='monospaced'>
+ /home/<replaceable>your_username</replaceable>/buildtools
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ Source the tools environment setup script by using a
+ command like the following:
+ <literallayout class='monospaced'>
+ $ source /home/<replaceable>your_username</replaceable>/buildtools/environment-setup-i586-poky-linux
+ </literallayout>
+ Of course, you need to supply your installation directory and be
+ sure to use the right file (i.e. i585 or x86-64).
+ </para>
+ <para>
+ After you have sourced the setup script,
+ the tools are added to <filename>PATH</filename>
+ and any other environment variables required to run the
+ tools are initialized.
+ The results are working versions versions of Git, tar,
+ Python and <filename>chrpath</filename>.
+ </para></listitem>
+ </orderedlist>
+ </para>
+ </section>
+ </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-tasks.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-tasks.xml
index c726cb9..e6cf686 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-tasks.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-tasks.xml
@@ -111,8 +111,7 @@
<link linkend='ref-classes-deploy'><filename>deploy</filename></link>
class and should write the output to
<filename>${</filename><link linkend='var-DEPLOYDIR'><filename>DEPLOYDIR</filename></link><filename>}</filename>,
- which is not to be confused with
- <filename>${</filename><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link><filename>}</filename>.
+ which is not to be confused with <filename>${DEPLOY_DIR}</filename>.
The <filename>deploy</filename> class sets up
<filename>do_deploy</filename> as a shared state (sstate) task that
can be accelerated through sstate use.
@@ -220,8 +219,8 @@
<para>
For more information on image creation, see the
- "<link linkend='image-generation-dev-environment'>Image Generation</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#image-generation-dev-environment'>Image Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -232,7 +231,7 @@
Completes the image generation process.
The <filename>do_image_complete</filename> task runs after the
OpenEmbedded build system has run the
- <link linkend='ref-tasks-rootfs'><filename>do_image</filename></link>
+ <link linkend='ref-tasks-image'><filename>do_image</filename></link>
task during which image pre-processing occurs and through
dynamically generated <filename>do_image_*</filename> tasks the
image is constructed.
@@ -246,8 +245,8 @@
<para>
For more information on image creation, see the
- "<link linkend='image-generation-dev-environment'>Image Generation</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#image-generation-dev-environment'>Image Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -268,7 +267,7 @@
and
<link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>),
run under
- <link linkend='fakeroot-and-pseudo'>fakeroot</link>.
+ <ulink url='&YOCTO_DOCS_OM_URL;#fakeroot-and-pseudo'>fakeroot</ulink>.
<note>
<title>Caution</title>
@@ -280,7 +279,7 @@
UID and/or GID of the original file, which is usually not
what you want.
The
- <link linkend='ref-classes-insane'><filename>host-user-contaminated</filename></link>
+ <link linkend='insane-host-user-contaminated'><filename>host-user-contaminated</filename></link>
QA check checks for files that probably have the wrong
ownership.
</para>
@@ -342,8 +341,8 @@
For additional information, see the
<link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link>
variable and the
- "<link linkend='automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -367,8 +366,8 @@
<filename>${</filename><link linkend='var-DEPLOY_DIR_DEB'><filename>DEPLOY_DIR_DEB</filename></link><filename>}</filename>
directory in the package feeds area.
For more information, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -381,8 +380,8 @@
<filename>${</filename><link linkend='var-DEPLOY_DIR_IPK'><filename>DEPLOY_DIR_IPK</filename></link><filename>}</filename>
directory in the package feeds area.
For more information, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -395,8 +394,8 @@
<filename>${</filename><link linkend='var-DEPLOY_DIR_RPM'><filename>DEPLOY_DIR_RPM</filename></link><filename>}</filename>
directory in the package feeds area.
For more information, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -408,8 +407,8 @@
<filename>${</filename><link linkend='var-DEPLOY_DIR_TAR'><filename>DEPLOY_DIR_TAR</filename></link><filename>}</filename>
directory in the package feeds area.
For more information, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</section>
@@ -430,9 +429,87 @@
<para>
Locates patch files and applies them to the source code.
- See the
- "<link linkend='patching-dev-environment'>Patching</link>"
- section for more information.
+ </para>
+
+ <para>
+ After fetching and unpacking source files, the build system
+ uses the recipe's
+ <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+ statements to locate and apply patch files to the source code.
+ <note>
+ The build system uses the
+ <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+ variable to determine the default set of directories when
+ searching for patches.
+ </note>
+ Patch files, by default, are <filename>*.patch</filename> and
+ <filename>*.diff</filename> files created and kept in a
+ subdirectory of the directory holding the recipe file.
+ For example, consider the
+ <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/bluez5'><filename>bluez5</filename></ulink>
+ recipe from the OE-Core layer (i.e.
+ <filename>poky/meta</filename>):
+ <literallayout class='monospaced'>
+ poky/meta/recipes-connectivity/bluez5
+ </literallayout>
+ This recipe has two patch files located here:
+ <literallayout class='monospaced'>
+ poky/meta/recipes-connectivity/bluez5/bluez5
+ </literallayout>
+ </para>
+
+ <para>
+ In the <filename>bluez5</filename> recipe, the
+ <filename>SRC_URI</filename> statements point to the source and
+ patch files needed to build the package.
+ <note>
+ In the case for the <filename>bluez5_5.48.bb</filename>
+ recipe, the <filename>SRC_URI</filename> statements are from an
+ include file <filename>bluez5.inc</filename>.
+ </note>
+ </para>
+
+ <para>
+ As mentioned earlier, the build system treats files whose file
+ types are <filename>.patch</filename> and
+ <filename>.diff</filename> as patch files.
+ However, you can use the "apply=yes" parameter with the
+ <filename>SRC_URI</filename> statement to indicate any file as a
+ patch file:
+ <literallayout class='monospaced'>
+ SRC_URI = " \
+ git://<replaceable>path_to_repo</replaceable>/<replaceable>some_package</replaceable> \
+ file://<replaceable>file</replaceable>;apply=yes \
+ "
+ </literallayout>
+ </para>
+
+ <para>
+ Conversely, if you have a directory full of patch files and you
+ want to exclude some so that the <filename>do_patch</filename>
+ task does not apply them during the patch phase, you can use
+ the "apply=no" parameter with the <filename>SRC_URI</filename>
+ statement:
+ <literallayout class='monospaced'>
+ SRC_URI = " \
+ git://<replaceable>path_to_repo</replaceable>/<replaceable>some_package</replaceable> \
+ file://<replaceable>path_to_lots_of_patch_files</replaceable> \
+ file://<replaceable>path_to_lots_of_patch_files</replaceable>/<replaceable>patch_file5</replaceable>;apply=no \
+ "
+ </literallayout>
+ In the previous example, assuming all the files in the directory
+ holding the patch files end with either <filename>.patch</filename>
+ or <filename>.diff</filename>, every file would be applied as a
+ patch by default except for the
+ <replaceable>patch_file5</replaceable> patch.
+ </para>
+
+ <para>
+ You can find out more about the patching process in the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#patching-dev-environment'>Patching</ulink>"
+ section in the Yocto Project Overview and Concepts Manual and the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code'>Patching Code</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</section>
@@ -451,8 +528,9 @@
<para>
Creates the file and directory structure for an installable SDK.
See the
- "<link linkend='sdk-generation-dev-environment'>SDK Generation</link>"
- section for more information.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#sdk-generation-dev-environment'>SDK Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual for more
+ information.
</para>
</section>
@@ -538,8 +616,9 @@
<link linkend='var-S'><filename>S</filename></link> variable also
plays a role in where unpacked source files ultimately reside.
For more information on how source files are unpacked, see the
- "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
- section and the <filename>WORKDIR</filename> and
+ "<ulink url='&YOCTO_DOCS_OM_URL;#source-fetching-dev-environment'>Source Fetching</ulink>"
+ section in the Yocto Project Overview and Concepts Manual and also
+ see the <filename>WORKDIR</filename> and
<filename>S</filename> variable descriptions.
</para>
</section>
@@ -593,24 +672,13 @@
</para>
</section>
- <section id='ref-tasks-checkuriall'>
- <title><filename>do_checkuriall</filename></title>
-
- <para>
- Validates the
- <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
- value for all recipes required to build a target.
- </para>
- </section>
-
<section id='ref-tasks-clean'>
<title><filename>do_clean</filename></title>
<para>
Removes all output files for a target from the
<link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
- task forward (i.e.
- <link linkend='ref-tasks-patch'><filename>do_unpack</filename></link>,
+ task forward (i.e. <filename>do_unpack</filename>,
<link linkend='ref-tasks-configure'><filename>do_configure</filename></link>,
<link linkend='ref-tasks-compile'><filename>do_compile</filename></link>,
<link linkend='ref-tasks-install'><filename>do_install</filename></link>,
@@ -627,8 +695,8 @@
<para>
Running this task does not remove the
- <link linkend='shared-state-cache'>sstate</link>) cache
- files.
+ <ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>sstate</ulink>
+ cache files.
Consequently, if no changes have been made and the recipe is
rebuilt after cleaning, output files are simply restored from the
sstate cache.
@@ -644,8 +712,9 @@
<para>
Removes all output files, shared state
- (<link linkend='shared-state-cache'>sstate</link>) cache, and
- downloaded source files for a target (i.e. the contents of
+ (<ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>sstate</ulink>)
+ cache, and downloaded source files for a target (i.e. the contents
+ of
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>).
Essentially, the <filename>do_cleanall</filename> task is
identical to the
@@ -674,13 +743,14 @@
<para>
Removes all output files and shared state
- (<link linkend='shared-state-cache'>sstate</link>)
+ (<ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>sstate</ulink>)
cache for a target.
Essentially, the <filename>do_cleansstate</filename> task is
identical to the
<link linkend='ref-tasks-clean'><filename>do_clean</filename></link>
task with the added removal of shared state
- (<link linkend='shared-state-cache'>sstate</link>) cache.
+ (<ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>sstate</ulink>)
+ cache.
</para>
<para>
@@ -736,14 +806,6 @@
</para>
</section>
- <section id='ref-tasks-fetchall'>
- <title><filename>do_fetchall</filename></title>
-
- <para>
- Fetches all remote sources required to build a target.
- </para>
- </section>
-
<section id='ref-tasks-listtasks'>
<title><filename>do_listtasks</filename></title>
@@ -757,7 +819,7 @@
<para>
Creates or updates the index in the
- <link linkend='package-feeds-dev-environment'>Package Feeds</link>
+ <ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>
area.
<note>
This task is not triggered with the
@@ -809,8 +871,9 @@
Creates the root filesystem (file and directory structure) for an
image.
See the
- "<link linkend='image-generation-dev-environment'>Image Generation</link>"
- section for more information on how the root filesystem is created.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#image-generation-dev-environment'>Image Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual for more
+ information on how the root filesystem is created.
</para>
</section>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-terms.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-terms.xml
new file mode 100644
index 0000000..cc09d3f
--- /dev/null
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-terms.xml
@@ -0,0 +1,507 @@
+<!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='ref-terms'>
+<title>Yocto Project Terms</title>
+
+ <para>
+ Following is a list of terms and definitions users new to the Yocto
+ Project development environment might find helpful.
+ While some of these terms are universal, the list includes them
+ just in case:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis>Append Files:</emphasis>
+ Files that append build information to a recipe file.
+ Append files are known as BitBake append files and
+ <filename>.bbappend</filename> files.
+ The OpenEmbedded build system expects every append file to have
+ a corresponding recipe (<filename>.bb</filename>) file.
+ Furthermore, the append file and corresponding recipe file
+ must use the same root filename.
+ The filenames can differ only in the file type suffix used
+ (e.g.
+ <filename>formfactor_0.0.bb</filename> and
+ <filename>formfactor_0.0.bbappend</filename>).</para>
+
+ <para>Information in append files extends or overrides the
+ information in the similarly-named recipe file.
+ For an example of an append file in use, see the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ <note>
+ Append files can also use wildcard patterns in their
+ version numbers so they can be applied to more than one
+ version of the underlying recipe file.
+ </note>
+ </para></listitem>
+ <listitem><para id='bitbake-term'>
+ <emphasis>BitBake:</emphasis>
+ The task executor and scheduler used by the OpenEmbedded build
+ system to build images.
+ For more information on BitBake, see the
+ <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+ </para></listitem>
+ <listitem><para id='board-support-package-bsp-term'>
+ <emphasis>Board Support Package (BSP):</emphasis>
+ A group of drivers, definitions, and other components that
+ provide support for a specific hardware configuration.
+ For more information on BSPs, see the
+ <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+ </para></listitem>
+ <listitem>
+ <para id='build-directory'>
+ <emphasis>Build Directory:</emphasis>
+ This term refers to the area used by the OpenEmbedded build
+ system for builds.
+ The area is created when you <filename>source</filename> the
+ setup environment script that is found in the Source Directory
+ (i.e. <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
+ The
+ <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link>
+ variable points to the Build Directory.</para>
+
+ <para>You have a lot of flexibility when creating the Build
+ Directory.
+ Following are some examples that show how to create the
+ directory.
+ The examples assume your
+ <link linkend='source-directory'>Source Directory</link> is
+ named <filename>poky</filename>:
+ <itemizedlist>
+ <listitem><para>Create the Build Directory inside your
+ Source Directory and let the name of the Build
+ Directory default to <filename>build</filename>:
+ <literallayout class='monospaced'>
+ $ cd $HOME/poky
+ $ source &OE_INIT_FILE;
+ </literallayout>
+ </para></listitem>
+ <listitem><para>Create the Build Directory inside your
+ home directory and specifically name it
+ <filename>test-builds</filename>:
+ <literallayout class='monospaced'>
+ $ cd $HOME
+ $ source poky/&OE_INIT_FILE; test-builds
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ Provide a directory path and specifically name the
+ Build Directory.
+ Any intermediate folders in the pathname must exist.
+ This next example creates a Build Directory named
+ <filename>YP-&POKYVERSION;</filename>
+ in your home directory within the existing
+ directory <filename>mybuilds</filename>:
+ <literallayout class='monospaced'>
+ $cd $HOME
+ $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
+ </literallayout>
+ </para></listitem>
+ </itemizedlist>
+ <note>
+ By default, the Build Directory contains
+ <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
+ which is a temporary directory the build system uses for
+ its work.
+ <filename>TMPDIR</filename> cannot be under NFS.
+ Thus, by default, the Build Directory cannot be under NFS.
+ However, if you need the Build Directory to be under NFS,
+ you can set this up by setting <filename>TMPDIR</filename>
+ in your <filename>local.conf</filename> file
+ to use a local drive.
+ Doing so effectively separates <filename>TMPDIR</filename>
+ from <filename>TOPDIR</filename>, which is the Build
+ Directory.
+ </note>
+ </para></listitem>
+ <listitem><para id='hardware-build-system-term'>
+ <emphasis>Build Host:</emphasis>
+ The system used to build images in a Yocto Project
+ Development environment.
+ The build system is sometimes referred to as the
+ development host.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Classes:</emphasis>
+ Files that provide for logic encapsulation and inheritance so
+ that commonly used patterns can be defined once and then
+ easily used in multiple recipes.
+ For reference information on the Yocto Project classes, see the
+ "<link linkend='ref-classes'>Classes</link>" chapter.
+ Class files end with the <filename>.bbclass</filename>
+ filename extension.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Configuration File:</emphasis>
+ Files that hold global definitions of variables,
+ user-defined variables, and hardware configuration
+ information.
+ These files tell the OpenEmbedded build system what to
+ build and what to put into the image to support a
+ particular platform.</para>
+
+ <para>Configuration files end with a <filename>.conf</filename>
+ filename extension.
+ The <filename>conf/local.conf</filename> configuration file in
+ the
+ <link linkend='build-directory'>Build Directory</link>
+ contains user-defined variables that affect every build.
+ The <filename>meta-poky/conf/distro/poky.conf</filename>
+ configuration file defines Yocto "distro" configuration
+ variables used only when building with this policy.
+ Machine configuration files, which
+ are located throughout the
+ <link linkend='source-directory'>Source Directory</link>, define
+ variables for specific hardware and are only used when building
+ for that target (e.g. the
+ <filename>machine/beaglebone.conf</filename> configuration
+ file defines variables for the Texas Instruments ARM Cortex-A8
+ development board).
+ </para></listitem>
+ <listitem><para id='term-container-layer'>
+ <emphasis>Container Layer:</emphasis>
+ Layers that hold other layers.
+ An example of a container layer is the
+ <filename>meta-intel</filename> layer.
+ This layer contains BSP layers for the Intel-core2-32
+ <trademark class='registered'>Intel</trademark> Common Core
+ (Intel-core2-32) and the Intel-corei7-64
+ <trademark class='registered'>Intel</trademark> Common Core
+ (Intel-corei7-64).
+ the <filename>meta-intel</filename> layer also contains
+ the <filename>common/</filename> directory, which contains
+ common content across those layers.
+ </para></listitem>
+ <listitem><para id='cross-development-toolchain'>
+ <emphasis>Cross-Development Toolchain:</emphasis>
+ In general, a cross-development toolchain is a collection of
+ software development tools and utilities that run on one
+ architecture and allow you to develop software for a
+ different, or targeted, architecture.
+ These toolchains contain cross-compilers, linkers, and
+ debuggers that are specific to the target architecture.</para>
+
+ <para>The Yocto Project supports two different cross-development
+ toolchains:
+ <itemizedlist>
+ <listitem><para>
+ A toolchain only used by and within
+ BitBake when building an image for a target
+ architecture.
+ </para></listitem>
+ <listitem><para>A relocatable toolchain used outside of
+ BitBake by developers when developing applications
+ that will run on a targeted device.
+ </para></listitem>
+ </itemizedlist></para>
+
+ <para>Creation of these toolchains is simple and automated.
+ For information on toolchain concepts as they apply to the
+ Yocto Project, see the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
+ You can also find more information on using the
+ relocatable toolchain in 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>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.</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>Image:</emphasis>
+ An image is an artifact of the BitBake build process given
+ a collection of recipes and related Metadata.
+ Images are the binary output that run on specific hardware or
+ QEMU and are used for specific use-cases.
+ For a list of the supported image types that the Yocto Project
+ provides, see the
+ "<link linkend='ref-images'>Images</link>"
+ chapter.
+ </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 introductory information on layers, see the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model'>The Yocto Project Layer Model</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
+ 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 id='metadata'>
+ <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
+ <link linkend='build-system-term'>OpenEmbedded build system</link>
+ 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>
+
+ <para>In the context of the kernel ("kernel Metadata"), the
+ term refers to the kernel config fragments and features
+ contained in the
+ <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache'><filename>yocto-kernel-cache</filename></ulink>
+ Git repository.
+ </para></listitem>
+ <listitem><para id='oe-core'>
+ <emphasis>OpenEmbedded-Core (OE-Core):</emphasis>
+ OE-Core is metadata comprised of foundational 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 an 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 id='build-system-term'>
+ <emphasis>OpenEmbedded Build System:</emphasis>
+ The build system specific to the Yocto Project.
+ The OpenEmbedded build system is based on another project known
+ as "Poky", which uses
+ <link linkend='bitbake-term'>BitBake</link> as the task
+ executor.
+ Throughout the Yocto Project documentation set, the
+ OpenEmbedded build system is sometimes referred to simply
+ as "the build system".
+ If other build systems, such as a host or target build system
+ are referenced, the documentation clearly states the
+ difference.
+ <note>
+ For some historical information about Poky, see the
+ <link linkend='poky'>Poky</link> term.
+ </note>
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Package:</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
+ "<link linkend='required-packages-for-the-host-development-system'>Required Packages for the Host Development System</link>"
+ section 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. <link linkend='var-PR'><filename>PR</filename></link>,
+ <link linkend='var-PV'><filename>PV</filename></link>, and
+ <link linkend='var-PE'><filename>PE</filename></link>).
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Package Groups:</emphasis>
+ Arbitrary groups of software Recipes.
+ You use package groups to hold recipes that, when built,
+ usually accomplish a single task.
+ For example, a package group could contain the recipes for a
+ company’s proprietary or value-add software.
+ Or, the package group could contain the recipes that enable
+ graphics.
+ A package group is really just another recipe.
+ Because package group files are recipes, they end with the
+ <filename>.bb</filename> filename extension.
+ </para></listitem>
+ <listitem><para id='poky'>
+ <emphasis>Poky:</emphasis>
+ Poky, which is pronounced <emphasis>Pock</emphasis>-ee,
+ 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 began an open-source
+ project initially developed by OpenedHand.
+ OpenedHand developed Poky from the existing
+ OpenEmbedded build system to create a commercially
+ supportable build system for embedded Linux.
+ After Intel Corporation acquired OpenedHand, the
+ poky project became the basis for the Yocto Project's
+ build system.
+ </note>
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Recipe:</emphasis>
+ A set of instructions for building packages.
+ A recipe describes where you get source code, which patches
+ to apply, how to configure the source, how to compile it and so on.
+ Recipes also describe dependencies for libraries or for other
+ recipes.
+ Recipes represent the logical unit of execution, the software
+ to build, the images to build, and use the
+ <filename>.bb</filename> file extension.
+ </para></listitem>
+ <listitem><para id='reference-kit-term'>
+ <emphasis>Reference Kit:</emphasis>
+ A working example of a system, which includes a
+ <link linkend='board-support-package-bsp-term'>BSP</link>
+ as well as a
+ <link linkend='hardware-build-system-term'>build host</link>
+ and other components, that can work on specific hardware.
+ </para></listitem>
+ <listitem>
+ <para id='source-directory'>
+ <emphasis>Source Directory:</emphasis>
+ This term refers to the directory structure created as a result
+ of creating a local copy of the <filename>poky</filename> Git
+ repository <filename>git://git.yoctoproject.org/poky</filename>
+ or expanding a released <filename>poky</filename> tarball.
+ <note>
+ Creating a local copy of the <filename>poky</filename>
+ Git repository is the recommended method for setting up
+ your Source Directory.
+ </note>
+ Sometimes you might hear the term "poky directory" used to refer
+ to this directory structure.
+ <note>
+ The OpenEmbedded build system does not support file or
+ directory names that contain spaces.
+ Be sure that the Source Directory you use does not contain
+ these types of names.
+ </note></para>
+
+ <para>The Source Directory contains BitBake, Documentation,
+ Metadata and other files that all support the Yocto Project.
+ Consequently, you must have the Source Directory in place on
+ your development system in order to do any development using
+ the Yocto Project.</para>
+
+ <para>When you create a local copy of the Git repository, you
+ can name the repository anything you like.
+ Throughout much of the documentation, "poky"
+ is used as the name of the top-level folder of the local copy of
+ the poky Git repository.
+ So, for example, cloning the <filename>poky</filename> Git
+ repository results in a local Git repository whose top-level
+ folder is also named "poky".</para>
+
+ <para>While it is not recommended that you use tarball expansion
+ to set up the Source Directory, if you do, the top-level
+ directory name of the Source Directory is derived from the
+ Yocto Project release tarball.
+ For example, downloading and unpacking
+ <filename>&YOCTO_POKY_TARBALL;</filename> results in a
+ Source Directory whose root folder is named
+ <filename>&YOCTO_POKY;</filename>.</para>
+
+ <para>It is important to understand the differences between the
+ Source Directory created by unpacking a released tarball as
+ compared to cloning
+ <filename>git://git.yoctoproject.org/poky</filename>.
+ When you unpack a tarball, you have an exact copy of the files
+ based on the time of release - a fixed release point.
+ Any changes you make to your local files in the Source Directory
+ are on top of the release and will remain local only.
+ On the other hand, when you clone the <filename>poky</filename>
+ Git repository, you have an active development repository with
+ access to the upstream repository's branches and tags.
+ In this case, any local changes you make to the local
+ Source Directory can be later applied to active development
+ branches of the upstream <filename>poky</filename> Git
+ repository.</para>
+
+ <para>For more information on concepts related to Git
+ repositories, branches, and tags, see the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#repositories-tags-and-branches'>Repositories, Tags, and Branches</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
+ </para></listitem>
+ <listitem><para><emphasis>Task:</emphasis>
+ A unit of execution for BitBake (e.g.
+ <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>,
+ <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>,
+ <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>,
+ and so forth).
+ </para></listitem>
+ <listitem><para id='toaster-term'><emphasis>Toaster:</emphasis>
+ A web interface to the Yocto Project's
+ <link linkend='build-system-term'>OpenEmbedded Build System</link>.
+ The interface enables you to configure and run your builds.
+ Information about builds is collected and stored in a database.
+ For information on Toaster, see the
+ <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Upstream:</emphasis>
+ A reference to source code or repositories
+ that are not local to the development system but located in a
+ master area that is controlled by the maintainer of the source
+ code.
+ For example, in order for a developer to work on a particular
+ piece of code, they need to first get a copy of it from an
+ "upstream" source.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/import-layers/yocto-poky/documentation/ref-manual/ref-variables.xml b/import-layers/yocto-poky/documentation/ref-manual/ref-variables.xml
index 2b01723..1c55a92 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/ref-variables.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/ref-variables.xml
@@ -22,7 +22,7 @@
<link linkend='var-D'>D</link>
<link linkend='var-EFI_PROVIDER'>E</link>
<link linkend='var-FEATURE_PACKAGES'>F</link>
- <link linkend='var-GDB'>G</link>
+ <link linkend='var-GCCPIE'>G</link>
<link linkend='var-HOMEPAGE'>H</link>
<link linkend='var-ICECC_DISABLED'>I</link>
<!-- <link linkend='var-glossary-j'>J</link> -->
@@ -72,12 +72,13 @@
<glossentry id='var-ALLOW_EMPTY'><glossterm>ALLOW_EMPTY</glossterm>
<info>
- ALLOW_EMPTY[doc] = "Specifies if an output package should still be produced if it is empty."
+ ALLOW_EMPTY[doc] = "Specifies whether to produce an output package even if it is empty."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies if an output package should still be produced if it is empty.
+ Specifies whether to produce an output package even if it is
+ empty.
By default, BitBake does not produce empty packages.
This default behavior can cause issues when there is an
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> or
@@ -253,13 +254,14 @@
<glossentry id='var-APPEND'><glossterm>APPEND</glossterm>
<info>
- APPEND[doc] = "An override list of append strings for each LABEL."
+ APPEND[doc] = "An override list of append strings for target specified using LABELS."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- An override list of append strings for each
- <link linkend='var-LABELS'><filename>LABEL</filename></link>.
+ An override list of append strings for each target
+ specified with
+ <link linkend='var-LABELS'><filename>LABELS</filename></link>.
</para>
<para>
@@ -354,7 +356,7 @@
</para>
<para>
- In OpenEmbedded Core, <filename>ASSUME_PROVIDED</filename>
+ In OpenEmbedded-Core, <filename>ASSUME_PROVIDED</filename>
mostly specifies native tools that should not be built.
An example is <filename>git-native</filename>, which when
specified, allows for the Git binary from the host to be
@@ -775,10 +777,9 @@
WARN: Issue a warning but continue the
build when a threshold is broken.
Subsequent warnings are issued as
- defined by the
- <link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
- which must be defined in the
- conf/local.conf file.
+ defined by the BB_DISKMON_WARNINTERVAL
+ variable, which must be defined in
+ the conf/local.conf file.
<replaceable>dir</replaceable> is:
Any directory you choose. You can specify one or
@@ -971,15 +972,41 @@
<para>
For more information on speeding up builds, see the
- "<link linkend='speeding-up-the-build'>Speeding Up the Build</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#speeding-up-a-build'>Speeding Up a Build</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-BB_SERVER_TIMEOUT'><glossterm>BB_SERVER_TIMEOUT</glossterm>
+ <info>
+ BB_SERVER_TIMEOUT [doc] = "Specifies the time (in seconds) after which to unload the BitBake server due to inactivity."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Specifies the time (in seconds) after which to unload the
+ BitBake server due to inactivity.
+ Set <filename>BB_SERVER_TIMEOUT</filename> to determine how
+ long the BitBake server stays resident between invocations.
+ </para>
+
+ <para>
+ For example, the following statement in your
+ <filename>local.conf</filename> file instructs the server
+ to be unloaded after 20 seconds of inactivity:
+ <literallayout class='monospaced'>
+ BB_SERVER_TIMEOUT = "20"
+ </literallayout>
+ If you want the server to never be unloaded, set
+ <filename>BB_SERVER_TIMEOUT</filename> to "-1".
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
<info>
- BBCLASSEXTEND[doc] = "Allows you to extend a recipe so that it builds variants of the software. Common variants for recipes are 'native', 'cross', 'nativesdk' and multilibs."
+ BBCLASSEXTEND[doc] = "Allows you to extend a recipe so that it builds variants of the software. Common variants for recipes are 'native', 'cross', 'nativesdk', and multilibs."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -1116,6 +1143,53 @@
</glossdef>
</glossentry>
+ <glossentry id='var-BBFILES_DYNAMIC'><glossterm>BBFILES_DYNAMIC</glossterm>
+ <info>
+ BBFILES_DYNAMIC[doc] = "Activates content when identified layers are present."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Activates content when identified layers are present.
+ You identify the layers by the collections that the layers
+ define.
+ </para>
+
+ <para>
+ Use the <filename>BBFILES_DYNAMIC</filename> variable to
+ avoid <filename>.bbappend</filename> files whose
+ corresponding <filename>.bb</filename> file is in a layer
+ that attempts to modify other layers through
+ <filename>.bbappend</filename> but does not want to
+ introduce a hard dependency on those other layers.
+ </para>
+
+ <para>
+ Use the following form for
+ <filename>BBFILES_DYNAMIC</filename>:
+ <literallayout class='monospaced'>
+ <replaceable>collection_name</replaceable>:<replaceable>filename_pattern</replaceable>
+ </literallayout>
+ The following example identifies two collection names and
+ two filename patterns:
+ <literallayout class='monospaced'>
+ BBFILES_DYNAMIC += " \
+ clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
+ core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
+ "
+ </literallayout>
+ This next example shows an error message that occurs
+ because invalid entries are found, which cause parsing to
+ abort:
+ <literallayout class='monospaced'>
+ ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
+ /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
+ /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
<info>
BBINCLUDELOGS[doc] = "Variable that controls how BitBake displays logs on build failure."
@@ -1200,8 +1274,8 @@
The expressions are compared against the full paths to
the files.
For complete syntax information, see Python's
- documentation at
- <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
+ documentation for the appropriate release at
+ <ulink url='http://docs.python.org/release/'></ulink>.
</para>
<para>
@@ -1520,12 +1594,12 @@
<glossentry id='var-BUILD_CPPFLAGS'><glossterm>BUILD_CPPFLAGS</glossterm>
<info>
- BUILD_CPPFLAGS[doc] = "Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers) when building for the build host."
+ BUILD_CPPFLAGS[doc] = "Specifies the flags to pass to the C preprocessor (i.e. to both the C and the C++ compilers) when building for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies the flags to pass to the C pre-processor
+ Specifies the flags to pass to the C preprocessor
(i.e. to both the C and the C++ compilers) when building
for the build host.
When building in the <filename>-native</filename> context,
@@ -1797,7 +1871,7 @@
<para>
Git requires that the value you provide for the
<filename>BUILDHISTORY_COMMIT_AUTHOR</filename> variable
- takes the form of "name <email@host>".
+ takes the form of "name <replaceable>email@host</replaceable>".
Providing an email address or host that is not valid does
not produce an error.
</para>
@@ -1849,12 +1923,12 @@
class, this variable specifies the build history features
to be enabled.
For more information on how build history works, see the
- "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
<para>
- You can specify three features in the form of a
+ You can specify these features in the form of a
space-separated list:
<itemizedlist>
<listitem><para><emphasis>image:</emphasis>
@@ -1869,12 +1943,20 @@
Analysis of the contents of the software
development kit (SDK).
</para></listitem>
+ <listitem><para><emphasis>task:</emphasis>
+ Save output file signatures for
+ <ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>shared state</ulink>
+ (sstate) tasks.
+ This saves one file per task and lists the SHA-256
+ checksums for each file staged (i.e. the output of
+ the task).
+ </para></listitem>
</itemizedlist>
</para>
<para>
By default, the <filename>buildhistory</filename> class
- enables all three features:
+ enables the following features:
<literallayout class='monospaced'>
BUILDHISTORY_FEATURES ?= "image package sdk"
</literallayout>
@@ -2212,13 +2294,6 @@
level, in case the hardware supports Bluetooth but you
do not ever intend to use it.
</para>
-
- <para>
- For more information, see the
- <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
- and <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
- variables.
- </para>
</glossdef>
</glossentry>
@@ -2732,13 +2807,13 @@
<glossentry id='var-COREBASE'><glossterm>COREBASE</glossterm>
<info>
- COREBASE[doc] = "Specifies the parent directory of the OpenEmbedded Core Metadata layer (i.e. meta)."
+ COREBASE[doc] = "Specifies the parent directory of the OpenEmbedded-Core Metadata layer (i.e. meta)."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies the parent directory of the OpenEmbedded
- Core Metadata layer (i.e. <filename>meta</filename>).
+ Specifies the parent directory of the OpenEmbedded-Core
+ Metadata layer (i.e. <filename>meta</filename>).
</para>
<para>
@@ -2938,12 +3013,12 @@
task.
This location defaults to:
<literallayout class='monospaced'>
- ${<link linkend='var-WORKDIR'>WORKDIR</link>}/image
+ ${WORKDIR}/image
</literallayout>
<note><title>Caution</title>
Tasks that read from or write to this directory should
run under
- <link linkend='fakeroot-and-pseudo'>fakeroot</link>.
+ <ulink url='&YOCTO_DOCS_OM_URL;#fakeroot-and-pseudo'>fakeroot</ulink>.
</note>
</para>
</glossdef>
@@ -3190,9 +3265,10 @@
add any runtime dependencies between the
packages produced by the two recipes.
However, as explained in the
- "<link linkend='automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</link>"
- section, runtime dependencies will often be
- added automatically, meaning
+ "<ulink url='&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</ulink>"
+ section in the Yocto Project Overview and
+ Concepts Manual, runtime dependencies will
+ often be added automatically, meaning
<filename>DEPENDS</filename> alone is
sufficient for most recipes.
</para></listitem>
@@ -3234,13 +3310,13 @@
<glossentry id='var-DEPLOY_DIR'><glossterm>DEPLOY_DIR</glossterm>
<info>
- DEPLOY_DIR[doc] = "Points to the general area that the OpenEmbedded build system uses to place images, packages, SDKs and other output files that are ready to be used outside of the build system."
+ DEPLOY_DIR[doc] = "Points to the general area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Points to the general area that the OpenEmbedded build
- system uses to place images, packages, SDKs and other output
+ system uses to place images, packages, SDKs, and other output
files that are ready to be used outside of the build system.
By default, this directory resides within the
<link linkend='build-directory'>Build Directory</link>
@@ -3254,18 +3330,19 @@
section.
For more detail on the contents of the
<filename>deploy</filename> directory, see the
- "<link linkend='images-dev-environment'>Images</link>",
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>",
+ "<ulink url='&YOCTO_DOCS_OM_URL;#images-dev-environment'>Images</ulink>",
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>",
and
- "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
- sections.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#sdk-dev-environment'>Application Development SDK</ulink>"
+ sections all in the Yocto Project Overview and Concepts
+ Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-DEPLOY_DIR_DEB'><glossterm>DEPLOY_DIR_DEB</glossterm>
<info>
- DEPLOY_DIR_DEB[doc] = "Points to a Debian-specific area that the OpenEmbedded build system uses to place images, packages, SDKs and other output files that are ready to be used outside of the build system."
+ DEPLOY_DIR_DEB[doc] = "Points to a Debian-specific area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -3297,8 +3374,8 @@
<link linkend='ref-tasks-package_write_deb'><filename>do_package_write_deb</filename></link>
task writes Debian packages into the appropriate folder.
For more information on how packaging works, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</glossdef>
</glossentry>
@@ -3327,16 +3404,18 @@
section.
For more detail on the contents of the
<filename>deploy</filename> directory, see the
- "<link linkend='images-dev-environment'>Images</link>" and
- "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
- sections.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#images-dev-environment'>Images</ulink>"
+ and
+ "<ulink url='&YOCTO_DOCS_OM_URL;#sdk-dev-environment'>Application Development SDK</ulink>"
+ sections both in the Yocto Project Overview and Concepts
+ Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-DEPLOY_DIR_IPK'><glossterm>DEPLOY_DIR_IPK</glossterm>
<info>
- DEPLOY_DIR_IPK[doc] = "Points to a IPK-specific area that the OpenEmbedded build system uses to place images, packages, SDKs and other output files that are ready to be used outside of the build system."
+ DEPLOY_DIR_IPK[doc] = "Points to a IPK-specific area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -3367,15 +3446,15 @@
<link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>
task writes IPK packages into the appropriate folder.
For more information on how packaging works, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-DEPLOY_DIR_RPM'><glossterm>DEPLOY_DIR_RPM</glossterm>
<info>
- DEPLOY_DIR_RPM[doc] = "Points to a RPM-specific area that the OpenEmbedded build system uses to place images, packages, SDKs and other output files that are ready to be used outside of the build system."
+ DEPLOY_DIR_RPM[doc] = "Points to a RPM-specific area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -3406,15 +3485,15 @@
<link linkend='ref-tasks-package_write_rpm'><filename>do_package_write_rpm</filename></link>
task writes RPM packages into the appropriate folder.
For more information on how packaging works, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-DEPLOY_DIR_TAR'><glossterm>DEPLOY_DIR_TAR</glossterm>
<info>
- DEPLOY_DIR_TAR[doc] = "Points to a tarball area that the OpenEmbedded build system uses to place images, packages, SDKs and other output files that are ready to be used outside of the build system."
+ DEPLOY_DIR_TAR[doc] = "Points to a tarball area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -3445,8 +3524,8 @@
<link linkend='ref-tasks-package_write_tar'><filename>do_package_write_tar</filename></link>
task writes TAR packages into the appropriate folder.
For more information on how packaging works, see the
- "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment'>Package Feeds</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</glossdef>
</glossentry>
@@ -3698,7 +3777,7 @@
It is not intended to be user-configurable.
It is best to just reference the variable to see which distro features are
being backfilled for all distro configurations.
- See the <link linkend='ref-features-backfill'>Feature backfilling</link> section for
+ See the <link linkend='ref-features-backfill'>Feature Backfilling</link> section for
more information.
</para>
</glossdef>
@@ -4386,7 +4465,7 @@
<glossentry id='var-EXTRA_IMAGECMD'><glossterm>EXTRA_IMAGECMD</glossterm>
<info>
- EXTRA_IMAGECMD[doc] = "Specifies additional options for the image creation command that has been specified in IMAGE_CMD. When setting this variable, you should use an override for the associated type."
+ EXTRA_IMAGECMD[doc] = "Specifies additional options for the image creation command that has been specified in IMAGE_CMD. When setting this variable, you should use an override for the associated image type."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -4394,8 +4473,8 @@
Specifies additional options for the image
creation command that has been specified in
<link linkend='var-IMAGE_CMD'><filename>IMAGE_CMD</filename></link>.
- When setting this variable, you should
- use an override for the associated type.
+ When setting this variable, use an override for the
+ associated image type.
Here is an example:
<literallayout class='monospaced'>
EXTRA_IMAGECMD_ext3 ?= "-i 4096"
@@ -4787,7 +4866,7 @@
The previous statement appears in the
<filename>linux-yocto-dev.bbappend</filename> file, which
is found in the Yocto Project
- <link linkend='source-repositories'>Source Repositories</link>
+ <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
in
<filename>meta-intel/common/recipes-kernel/linux</filename>.
Here, the machine override is a special
@@ -4821,7 +4900,7 @@
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
You can find more information on how overrides are handled
in the
- <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake Manual</ulink>.
+ <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
</para>
<para>
@@ -4853,7 +4932,9 @@
During the build process, BitBake searches each directory in
<filename>FILESPATH</filename> in the specified order when
looking for files and patches specified by each
- <filename>file://</filename> URI in a recipe.
+ <filename>file://</filename> URI in a recipe's
+ <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+ statements.
</para>
<para>
@@ -4881,9 +4962,19 @@
If you want the build system to find patches or files
that reside with your append files, you need to extend
the <filename>FILESPATH</filename> variable by using
- the
- <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
- variable.
+ the <filename>FILESEXTRAPATHS</filename> variable.
+ </para>
+
+ <para>
+ You can find out more about the patching process in the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#patching-dev-environment'>Patching</ulink>"
+ section in the Yocto Project Overview and Concepts Manual
+ and the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code'>Patching Code</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ See the
+ <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
+ task as well.
</para>
</glossdef>
</glossentry>
@@ -5004,6 +5095,30 @@
<glossdiv id='var-glossary-g'><title>G</title>
+ <glossentry id='var-GCCPIE'><glossterm>GCCPIE</glossterm>
+ <info>
+ GCCPIE[doc] = "Enables Position Independent Executables (PIE) within the GNU C Compiler (GCC)."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Enables Position Independent Executables (PIE) within the
+ GNU C Compiler (GCC).
+ Enabling PIE in the GCC makes Return Oriented Programming
+ (ROP) attacks much more difficult to
+ execute.
+ </para>
+
+ <para>
+ By default the <filename>security_flags.inc</filename>
+ file enables PIE by setting the variable as follows:
+ <literallayout class='monospaced'>
+ GCCPIE ?= "--enable-default-pie"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-GDB'><glossterm>GDB</glossterm>
<info>
GDB[doc] = "The minimal command and arguments to run the GNU Debugger."
@@ -5031,13 +5146,13 @@
<glossentry id='var-GLIBC_GENERATE_LOCALES'><glossterm>GLIBC_GENERATE_LOCALES</glossterm>
<info>
- GLIBC_GENERATE_LOCALES[doc]= "Specifies the list of GLIBC locales to generate should you not wish generate all LIBC locals, which can be time consuming."
+ GLIBC_GENERATE_LOCALES[doc]= "Specifies the list of GLIBC locales to generate should you not wish to generate all LIBC locals, which can be time consuming."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the list of GLIBC locales to generate should you
- not wish generate all LIBC locals, which can be time
+ not wish to generate all LIBC locals, which can be time
consuming.
<note>
If you specifically remove the locale
@@ -5307,7 +5422,7 @@
<glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
<info>
- HOST_SYS[doc] = "Specifies the system, including the architecture and the operating system, for with the build is occurring in the context of the current recipe."
+ HOST_SYS[doc] = "Specifies the system, including the architecture and the operating system, for which the build is occurring in the context of the current recipe."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -5383,7 +5498,7 @@
contamination.
Unlike
<link linkend='var-HOSTTOOLS'><filename>HOSTTOOLS</filename></link>,
- the OpenEmbedded build system does not produce and error
+ the OpenEmbedded build system does not produce an error
if a tool specified in the value of
<filename>HOSTTOOLS_NONFATAL</filename> is not found on the
build host.
@@ -5402,7 +5517,7 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the name of the vendor.
<filename>HOST_VENDOR</filename> is normally the same as
- <link linkend='var-TARGET_PREFIX'><filename>TARGET_VENDOR</filename></link>.
+ <link linkend='var-TARGET_VENDOR'><filename>TARGET_VENDOR</filename></link>.
</para>
</glossdef>
</glossentry>
@@ -5620,18 +5735,17 @@
<glossentry id='var-IMAGE_BOOT_FILES'><glossterm>IMAGE_BOOT_FILES</glossterm>
<info>
- IMAGE_BOOT_FILES[doc] = "Whitespace separated list of files from ${DEPLOY_DIR_IMAGE} to place in boot partition. Entries will be installed under a same name as the source file. To change the destination file name, pass a desired name after a semicolon (eg. u-boot.img;uboot)."
+ IMAGE_BOOT_FILES[doc] = "A space-separated list of files from ${DEPLOY_DIR_IMAGE} to place in boot partition."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
A space-separated list of files installed into the
- boot partition when preparing an image using the
- <filename>wic</filename> tool with the
- <filename>bootimg-partition</filename> source
+ boot partition when preparing an image using the Wic tool
+ with the <filename>bootimg-partition</filename> source
plugin.
- By default, the files are installed under
- the same name as the source files.
+ By default, the files are installed under the same name as
+ the source files.
To change the installed name, separate it from the
original name with a semi-colon (;).
Source files need to be located in
@@ -5647,9 +5761,8 @@
<para>
Alternatively, source files can be picked up using
a glob pattern.
- In this case, the destination file
- will have the same name as the base name of the source file
- path.
+ In this case, the destination file must have the same name
+ as the base name of the source file path.
To install files into a directory within the
target location, pass its name after a semi-colon
(;).
@@ -5665,6 +5778,15 @@
<filename>boot</filename> directory within the
target partition.
</para>
+
+ <para>
+ You can find information on how to use the Wic tool in the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
+ section of the Yocto Project Development Tasks Manual.
+ Reference material for Wic is located in the
+ "<ulink url='&YOCTO_DOCS_REF_URL;#ref-kickstart'>OpenEmbedded Kickstart (.wks) Reference</ulink>"
+ chapter.
+ </para>
</glossdef>
</glossentry>
@@ -5840,70 +5962,86 @@
<glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm>
<info>
- IMAGE_INSTALL[doc] = "Specifies the packages to install into an image. Image recipes set IMAGE_INSTALL to specify the packages to install into an image through image.bbclass."
+ IMAGE_INSTALL[doc] = "Used by recipes to specify the packages to install into an image through image.bbclass."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies the packages to install into an image.
- The <filename>IMAGE_INSTALL</filename> variable is a
- mechanism for an image recipe and you should use it
- with care to avoid ordering issues.
- <note>
- When working with an
- <link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
- image, do not use the <filename>IMAGE_INSTALL</filename>
- variable to specify packages for installation.
- Instead, use the
- <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
- variable, which allows the initial RAM filesystem
- (initramfs) recipe to use a fixed set of packages and
- not be affected by <filename>IMAGE_INSTALL</filename>.
- For information on creating an initramfs, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </note>
+ Used by recipes to specify the packages to install into an
+ image through the
+ <link linkend='ref-classes-image'><filename>image</filename></link>
+ class.
+ Use the <filename>IMAGE_INSTALL</filename> variable with
+ care to avoid ordering issues.
</para>
<para>
Image recipes set <filename>IMAGE_INSTALL</filename>
to specify the packages to install into an image through
<filename>image.bbclass</filename>.
- Additionally, "helper" classes exist, such as
- <filename>core-image.bbclass</filename>, that can take
+ Additionally, "helper" classes such as the
+ <link linkend='ref-classes-core-image'><filename>core-image</filename></link>
+ class exist that can take lists used with
<filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
- lists and turn these into auto-generated entries in
+ and turn them into auto-generated entries in
<filename>IMAGE_INSTALL</filename> in addition to its
default contents.
</para>
<para>
- Using <filename>IMAGE_INSTALL</filename> with the
- <filename>+=</filename> operator from the
- <filename>/conf/local.conf</filename> file or from within
- an image recipe is not recommended as it can cause ordering
- issues.
- Since <filename>core-image.bbclass</filename> sets
- <filename>IMAGE_INSTALL</filename> to a default value using
- the <filename>?=</filename> operator, using a
- <filename>+=</filename> operation against
- <filename>IMAGE_INSTALL</filename> will result in
- unexpected behavior when used in
- <filename>conf/local.conf</filename>.
- Furthermore, the same operation from within an image
- recipe may or may not succeed depending on the specific
- situation.
- In both these cases, the behavior is contrary to how most
- users expect the <filename>+=</filename> operator to work.
- </para>
-
- <para>
When you use this variable, it is best to use it as follows:
<literallayout class='monospaced'>
IMAGE_INSTALL_append = " <replaceable>package-name</replaceable>"
</literallayout>
Be sure to include the space between the quotation character
and the start of the package name or names.
+ <note><title>Caution</title>
+ <itemizedlist>
+ <listitem><para>
+ When working with a
+ <link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
+ image, do not use the
+ <filename>IMAGE_INSTALL</filename> variable to
+ specify packages for installation.
+ Instead, use the
+ <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
+ variable, which allows the initial RAM
+ filesystem (initramfs) recipe to use a fixed
+ set of packages and not be affected by
+ <filename>IMAGE_INSTALL</filename>.
+ For information on creating an initramfs, see
+ the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
+ section in the Yocto Project Development Tasks
+ Manual.
+ </para></listitem>
+ <listitem><para>
+ Using <filename>IMAGE_INSTALL</filename> with
+ the
+ <ulink url='&YOCTO_DOCS_BB_URL;#appending-and-prepending'><filename>+=</filename></ulink>
+ BitBake operator within the
+ <filename>/conf/local.conf</filename> file or
+ from within an image recipe is not recommended.
+ Use of this operator in these ways can cause
+ ordering issues.
+ Since <filename>core-image.bbclass</filename>
+ sets <filename>IMAGE_INSTALL</filename> to a
+ default value using the
+ <ulink url='&YOCTO_DOCS_BB_URL;#setting-a-default-value'><filename>?=</filename></ulink>
+ operator, using a <filename>+=</filename>
+ operation against
+ <filename>IMAGE_INSTALL</filename> results in
+ unexpected behavior when used within
+ <filename>conf/local.conf</filename>.
+ Furthermore, the same operation from within
+ an image recipe may or may not succeed
+ depending on the specific situation.
+ In both these cases, the behavior is contrary
+ to how most users expect the
+ <filename>+=</filename> operator to work.
+ </para></listitem>
+ </itemizedlist>
+ </note>
</para>
</glossdef>
</glossentry>
@@ -5981,8 +6119,8 @@
variables.
You can find information on how the image
is created in the
- "<link linkend='image-generation-dev-environment'>Image Generation</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#image-generation-dev-environment'>Image Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</glossdef>
</glossentry>
@@ -6056,12 +6194,12 @@
<glossentry id='var-IMAGE_PKGTYPE'><glossterm>IMAGE_PKGTYPE</glossterm>
<info>
- IMAGE_PKGTYPE[doc] = "Defines the package type (DEB, RPM, IPK, or TAR) used by the OpenEmbedded build system."
+ IMAGE_PKGTYPE[doc] = "Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the OpenEmbedded build system."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Defines the package type (DEB, RPM, IPK, or TAR) used
+ Defines the package type (i.e. DEB, RPM, IPK, or TAR) used
by the OpenEmbedded build system.
The variable is defined appropriately by the
<link linkend='ref-classes-package_deb'><filename>package_deb</filename></link>,
@@ -6108,13 +6246,13 @@
<glossentry id='var-IMAGE_POSTPROCESS_COMMAND'><glossterm>IMAGE_POSTPROCESS_COMMAND</glossterm>
<info>
- IMAGE_POSTPROCESS_COMMAND[doc] = "Specifies a list of functions to call once the OpenEmbedded build system has created the final image output files."
+ IMAGE_POSTPROCESS_COMMAND[doc] = "Specifies a list of functions to call once the OpenEmbedded build system creates the final image output files."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies a list of functions to call once the
- OpenEmbedded build system has created the final image
+ OpenEmbedded build system creates the final image
output files.
You can specify functions separated by semicolons:
<literallayout class='monospaced'>
@@ -6136,13 +6274,13 @@
<glossentry id='var-IMAGE_PREPROCESS_COMMAND'><glossterm>IMAGE_PREPROCESS_COMMAND</glossterm>
<info>
- IMAGE_PREPROCESS_COMMAND[doc] = "Specifies a list of functions to call before the OpenEmbedded build system has created the final image output files."
+ IMAGE_PREPROCESS_COMMAND[doc] = "Specifies a list of functions to call before the OpenEmbedded build system creates the final image output files."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies a list of functions to call before the
- OpenEmbedded build system has created the final image
+ OpenEmbedded build system creates the final image
output files.
You can specify functions separated by semicolons:
<literallayout class='monospaced'>
@@ -6488,7 +6626,7 @@
For more information on <filename>INHERIT</filename>, see
the
"<ulink url="&YOCTO_DOCS_BB_URL;#inherit-configuration-directive"><filename>INHERIT</filename> Configuration Directive</ulink>"
- section in the Yocto Project Bitbake User Manual.
+ section in the Bitbake User Manual.
</para>
</glossdef>
</glossentry>
@@ -6662,8 +6800,7 @@
<para>
You can also find more information by referencing the
<filename>meta-poky/conf/local.conf.sample.extended</filename>
- configuration file in the
- <link linkend='source-directory'>Source Directory</link>,
+ configuration file in the Source Directory,
the
<link linkend='ref-classes-image'><filename>image</filename></link>
class, and the
@@ -6729,8 +6866,7 @@
<para>
Setting the variable to "1" in a configuration file causes the
OpenEmbedded build system to generate a kernel image with the
- initramfs specified in
- <link linkend='var-INITRAMFS_IMAGE'><filename>INITRAMFS_IMAGE</filename></link>
+ initramfs specified in <filename>INITRAMFS_IMAGE</filename>
bundled within:
<literallayout class='monospaced'>
INITRAMFS_IMAGE_BUNDLE = "1"
@@ -7008,7 +7144,7 @@
<glossentry id='var-KBRANCH'><glossterm>KBRANCH</glossterm>
<info>
- KBRANCH[doc] = "A regular expression used by the build process to explicitly identify the kernel branch that is validated, patched and configured during a build."
+ KBRANCH[doc] = "A regular expression used by the build process to explicitly identify the kernel branch that is validated, patched, and configured during a build."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -7112,7 +7248,8 @@
For more information on how to use the
<filename>KBUILD_DEFCONFIG</filename> variable, see the
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#using-an-in-tree-defconfig-file'>Using an "In-Tree" <filename>defconfig</filename> File</ulink>"
- section.
+ section in the Yocto Project Linux Kernel Development
+ Manual.
</para>
</glossdef>
</glossentry>
@@ -7155,7 +7292,7 @@
<glossentry id='var-KERNEL_DEVICETREE'><glossterm>KERNEL_DEVICETREE</glossterm>
<info>
- KERNEL_DEVICETREE[doc] = "Specifies the name of the generated Linux kernel device tree (i.e. the <filename>.dtb</filename>) file."
+ KERNEL_DEVICETREE[doc] = "Specifies the name of the generated Linux kernel device tree (i.e. the .dtb) file."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -7415,7 +7552,8 @@
class.
For information on how this variable is used, see the
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
- section.
+ section in the Yocto Project Linux Kernel Development
+ Manual.
</para>
<para>
@@ -7446,7 +7584,8 @@
class.
For information on how this variable is used, see the
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
- section.
+ section in the Yocto Project Linux Kernel Development
+ Manual.
</para>
<para>
@@ -7696,6 +7835,53 @@
</glossdef>
</glossentry>
+ <glossentry id='var-LAYERSERIES_COMPAT'><glossterm>LAYERSERIES_COMPAT</glossterm>
+ <info>
+ LAYERSERIES_COMPAT[doc] = "Lists the OpenEmbedded-Core versions for which a layer is compatible."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Lists the versions of the
+ <link linkend='oe-core'>OpenEmbedded-Core</link> for which
+ a layer is compatible.
+ Using the <filename>LAYERSERIES_COMPAT</filename> variable
+ allows the layer maintainer to indicate which combinations
+ of the layer and OE-Core can be expected to work.
+ The variable gives the system a way to detect when a layer
+ has not been tested with new releases of OE-Core (e.g.
+ the layer is not maintained).
+ </para>
+
+ <para>
+ To specify the OE-Core versions for which a layer is
+ compatible, use this variable in your layer's
+ <filename>conf/layer.conf</filename> configuration file.
+ For the list, use the Yocto Project
+ <ulink url='https://wiki.yoctoproject.org/wiki/Releases'>Release Name</ulink>
+ (e.g. &DISTRO_NAME_NO_CAP;).
+ To specify multiple OE-Core versions for the layer,
+ use a space-separated list:
+ <literallayout class='monospaced'>
+ LAYERSERIES_COMPAT_<replaceable>layer_root_name</replaceable> = "&DISTRO_NAME_NO_CAP; &DISTRO_NAME_NO_CAP_MINUS_ONE;"
+ </literallayout>
+ <note>
+ Setting <filename>LAYERSERIES_COMPAT</filename> is
+ required by the Yocto Project Compatible version 2
+ standard.
+ The OpenEmbedded build system produces a warning if
+ the variable is not set for any given layer.
+ </note>
+ </para>
+
+ <para>
+ See the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-your-own-layer'>Creating Your Own Layer</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
<info>
LAYERVERSION[doc] = "Optionally specifies the version of a layer as a single number. This variable is used in the conf/layer.conf file and must be suffixed with the name of the specific layer."
@@ -7766,13 +7952,13 @@
<glossentry id='var-LEAD_SONAME'><glossterm>LEAD_SONAME</glossterm>
<info>
- LEAD_SONAME[doc] = "Specifies the lead (or primary) compiled library file (.so) that the debian class applies its naming policy to given a recipe that packages multiple libraries."
+ LEAD_SONAME[doc] = "Specifies the lead (or primary) compiled library file (i.e. .so) that the debian class applies its naming policy to given a recipe that packages multiple libraries."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the lead (or primary) compiled library file
- (<filename>.so</filename>) that the
+ (i.e. <filename>.so</filename>) that the
<link linkend='ref-classes-debian'><filename>debian</filename></link>
class applies its naming policy to given a recipe that
packages multiple libraries.
@@ -7808,8 +7994,8 @@
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
is set to "CLOSED").</para>
<para>For more information, see the
- "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
- Tracking License Changes</link>" section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-LIC_FILES_CHKSUM'>Tracking License Changes</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
@@ -7944,8 +8130,8 @@
require additional licenses in order to be used in a
commercial product.
For more information, see the
- "<link linkend='enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
@@ -7964,8 +8150,8 @@
This practice is otherwise known as "whitelisting"
license flags.
For more information, see the
- <link linkend='enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
@@ -8186,7 +8372,7 @@
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
<info>
- MACHINE_ESSENTIAL_EXTRA_RDEPENDS[doc] = "A list of required machine-specific packages to install as part of the image being built. Because this is a 'machine essential' variable, the list of packages are essential for the machine to boot."
+ MACHINE_ESSENTIAL_EXTRA_RDEPENDS[doc] = "A list of required machine-specific packages to install as part of the image being built. Because this is a 'machine-essential' variable, the list of packages are essential for the machine to boot."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -8194,7 +8380,7 @@
A list of required machine-specific packages to install as part of
the image being built.
The build process depends on these packages being present.
- Furthermore, because this is a "machine essential" variable, the list of
+ Furthermore, because this is a "machine-essential" variable, the list of
packages are essential for the machine to boot.
The impact of this variable affects images based on
<filename>packagegroup-core-boot</filename>,
@@ -8223,7 +8409,7 @@
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
<info>
- MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS[doc] = "A list of recommended machine-specific packages to install as part of the image being built. Because this is a 'machine essential' variable, the list of packages are essential for the machine to boot."
+ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS[doc] = "A list of recommended machine-specific packages to install as part of the image being built. Because this is a 'machine-essential' variable, the list of packages are essential for the machine to boot."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -8231,7 +8417,7 @@
A list of recommended machine-specific packages to install as part of
the image being built.
The build process does not depend on these packages being present.
- However, because this is a "machine essential" variable, the list of
+ However, because this is a "machine-essential" variable, the list of
packages are essential for the machine to boot.
The impact of this variable affects images based on
<filename>packagegroup-core-boot</filename>,
@@ -8421,7 +8607,7 @@
It is not intended to be user-configurable.
It is best to just reference the variable to see which machine features are
being backfilled for all machine configurations.
- See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
+ See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
more information.
</para>
</glossdef>
@@ -8439,7 +8625,7 @@
that should not be backfilled (i.e. added to
<filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>)
during the build.
- See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
+ See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
more information.
</para>
</glossdef>
@@ -8529,14 +8715,14 @@
<glossentry id='var-MLPREFIX'><glossterm>MLPREFIX</glossterm>
<info>
- MLPREFIX[doc] = "Specifies a prefix has been added to PN to create a special version of a recipe or package, such as a Multilib version."
+ MLPREFIX[doc] = "Specifies a prefix has been added to PN to create a special version of a recipe or package (i.e. a Multilib version)."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies a prefix has been added to
<link linkend='var-PN'><filename>PN</filename></link> to create a special version
- of a recipe or package, such as a Multilib version.
+ of a recipe or package (i.e. a Multilib version).
The variable is used in places where the prefix needs to be
added to or removed from a the name (e.g. the
<link linkend='var-BPN'><filename>BPN</filename></link> variable).
@@ -8827,7 +9013,7 @@
<glossentry id='var-NO_RECOMMENDATIONS'><glossterm>NO_RECOMMENDATIONS</glossterm>
<info>
- NO_RECOMMENDATIONS[doc] = "When set to '1', no recommended packages will be installed. Realize that some recommended packages might be required for certain system functionality, such as kernel-modules. It is up to the user to add packages to IMAGE_INSTALL as needed."
+ NO_RECOMMENDATIONS[doc] = "When set to '1', no recommended packages will be installed. Some recommended packages might be required for certain system functionality, such as kernel-modules. It is up to the user to add packages to IMAGE_INSTALL as needed."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -9003,8 +9189,8 @@
for details on how this class applies these additional
sed command arguments.
For general information on the
- <filename>binconfig.bbclass</filename> class, see the
- "<link linkend='ref-classes-binconfig'>Binary Configuration Scripts - <filename>binconfig.bbclass</filename></link>"
+ <filename>binconfig</filename> class, see the
+ "<link linkend='ref-classes-binconfig'><filename>binconfig.bbclass</filename></link>"
section.
</para>
</glossdef>
@@ -9183,8 +9369,9 @@
<filename>OVERRIDES</filename> in the output of the
<filename>bitbake -e</filename> command.
See the
- "<link linkend='usingpoky-debugging-viewing-variable-values'>Viewing Variable Values</link>"
- section for more information.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-debugging-viewing-variable-values'>Viewing Variable Values</ulink>"
+ section in the Yocto Project Development Tasks
+ Manual for more information.
</note>
</para>
</glossdef>
@@ -9223,11 +9410,17 @@
By default, the value of this variable is set to
<link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
when building for the target,
- <filename>BUILD_ARCH</filename> when building for the
- build host and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building
+ <link linkend='var-BUILD_ARCH'><filename>BUILD_ARCH</filename></link>
+ when building for the
+ build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building
for the SDK.
+ <note>
+ See
+ <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>
+ for more information.
+ </note>
However, if your recipe's output packages are built
- specific to the target machine rather than general for
+ specific to the target machine rather than generally for
the architecture of the machine, you should set
<filename>PACKAGE_ARCH</filename> to the value of
<link linkend='var-MACHINE_ARCH'><filename>MACHINE_ARCH</filename></link>
@@ -9298,9 +9491,10 @@
</literallayout>
<note><title>Warning</title>
While it is a legal option, the
- <filename>package_tar</filename> class is broken
- and is not supported.
- It is recommended that you do not use it.
+ <filename>package_tar</filename> class has limited
+ functionality due to no support for package
+ dependencies by that backend.
+ Therefore, it is recommended that you do not use it.
</note>
The build system uses only the first argument in the list
as the package manager when creating your image or SDK.
@@ -9477,20 +9671,29 @@
<glossentry id='var-PACKAGE_FEED_ARCHS'><glossterm>PACKAGE_FEED_ARCHS</glossterm>
<info>
- PACKAGE_FEED_ARCHS[doc] = "Specifies user-defined package architectures when constructing package feed URIs."
+ PACKAGE_FEED_ARCHS[doc] = "Optionally specifies user-defined package architectures when constructing package feed URIs."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies the package architectures used as part of the
- package feed URIs during the build.
- The <filename>PACKAGE_FEED_ARCHS</filename> variable is
- appended to the final package feed URI, which is constructed
- using the
+ Optionally specifies the package architectures used as
+ part of the package feed URIs during the build.
+ When used, the <filename>PACKAGE_FEED_ARCHS</filename>
+ variable is appended to the final package feed URI, which
+ is constructed using the
<link linkend='var-PACKAGE_FEED_URIS'><filename>PACKAGE_FEED_URIS</filename></link>
and
<link linkend='var-PACKAGE_FEED_BASE_PATHS'><filename>PACKAGE_FEED_BASE_PATHS</filename></link>
variables.
+ <note><title>Tip</title>
+ You can use the <filename>PACKAGE_FEEDS_ARCHS</filename>
+ variable to whitelist specific package architectures.
+ If you do not need to whitelist specific architectures,
+ which is a common case, you can omit this variable.
+ Omitting the variable results in all available
+ architectures for the current machine being included
+ into remote package feeds.
+ </note>
</para>
<para>
@@ -9798,7 +10001,7 @@
In this case, <filename>--with-croco</filename> is
added to the configure script argument list and
<filename>libcroco</filename> is added to
- <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
+ <filename>DEPENDS</filename>.
On the other hand, if the feature is disabled say through
a <filename>.bbappend</filename> file in another layer, then
the second argument <filename>--without-croco</filename> is
@@ -9870,8 +10073,8 @@
and
<link linkend='ref-classes-cmake'><filename>cmake</filename></link>
use <filename>PACKAGECONFIG_CONFARGS</filename> to pass
- <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
- options to <filename>configure</filename> and
+ <filename>PACKAGECONFIG</filename> options to
+ <filename>configure</filename> and
<filename>cmake</filename>, respectively.
If you are using
<filename>PACKAGECONFIG</filename> but not a class that
@@ -9879,12 +10082,6 @@
you need to use
<filename>PACKAGECONFIG_CONFARGS</filename> appropriately.
</para>
-
- <para>
- For additional information, see the
- <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
- variable.
- </para>
</glossdef>
</glossentry>
@@ -9911,12 +10108,12 @@
<glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
<info>
- PACKAGES[doc] = "The list of packages to be created from the recipe."
+ PACKAGES[doc] = "The list of packages the recipe creates."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- The list of packages to be created from the recipe.
+ The list of packages the recipe creates.
The default value is the following:
<literallayout class='monospaced'>
${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
@@ -10066,8 +10263,8 @@
<para>
For more information on speeding up builds, see the
- "<link linkend='speeding-up-the-build'>Speeding Up the Build</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#speeding-up-a-build'>Speeding Up a Build</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
@@ -10308,10 +10505,14 @@
${STAGING_DIR_HOST}/pkgdata
</literallayout>
For examples of how this data is used, see the
- "<link linkend='automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</link>"
- section and the
- "<link linkend='viewing-package-information-with-oe-pkgdata-util'>Viewing Package Information with <filename>oe-pkgdata-util</filename></link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</ulink>"
+ section in the Yocto Project Overview and Concepts Manual
+ and the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#viewing-package-information-with-oe-pkgdata-util'>Viewing Package Information with <filename>oe-pkgdata-util</filename></ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ For more information on the shared, global-state directory,
+ see
+ <link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>.
</para>
</glossdef>
</glossentry>
@@ -10414,7 +10615,7 @@
<glossentry id='var-PN'><glossterm>PN</glossterm>
<info>
- PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package. It refers to a package name in the context of a file created or produced by the OpenEmbedded build system."
+ PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package.
</info>
<glossdef>
<para role="glossdeffirst">
@@ -10555,11 +10756,11 @@
<filename>PR</filename> to know when to rebuild a
recipe.
The build system uses the task
- <ulink url='&YOCTO_DOCS_BB_URL;#checksums'>input checksums</ulink>
+ <ulink url='&YOCTO_DOCS_OM_URL;#overview-checksums'>input checksums</ulink>
along with the
<link linkend='structure-build-tmp-stamps'>stamp</link>
and
- <link linkend='shared-state-cache'>shared state cache</link>
+ <ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>shared state cache</ulink>
mechanisms.
</note>
The <filename>PR</filename> variable primarily becomes
@@ -10598,26 +10799,40 @@
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- If multiple recipes provide an item, this variable
- determines which recipe should be given preference.
- You should always suffix the variable with the name of the
- provided item, and you should set it to the
- <link linkend='var-PN'><filename>PN</filename></link>
- of the recipe to which you want to give precedence.
- Some examples:
+ If multiple recipes provide the same item, this variable
+ determines which recipe is preferred and thus provides
+ the item (i.e. the preferred provider).
+ You should always suffix this variable with the name of the
+ provided item.
+ And, you should define the variable using the preferred
+ recipe's name
+ (<link linkend='var-PN'><filename>PN</filename></link>).
+ Here is a common example:
<literallayout class='monospaced'>
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+ </literallayout>
+ In the previous example, multiple recipes are providing
+ "virtual/kernel".
+ The <filename>PREFERRED_PROVIDER</filename> variable is
+ set with the name (<filename>PN</filename>) of the recipe
+ you prefer to provide "virtual/kernel".
+ </para>
+
+ <para>
+ Following are more examples:
+ <literallayout class='monospaced'>
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
</literallayout>
- For more information see:
- <link linkend='metadata-virtual-providers'>Metadata (Virtual Providers)</link>
+ For more information, see the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers'>Using Virtual Providers</ulink>"
+ section in the Yocto Project Development Tasks Manual.
<note>
- If you set <filename>PREFERRED_PROVIDER</filename>
- for a <filename>virtual/*</filename> item, then any
+ If you use a <filename>virtual/*</filename> item
+ with <filename>PREFERRED_PROVIDER</filename>, then any
recipe that
<link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
- that item that is not selected by
+ that item but is not selected (defined) by
<filename>PREFERRED_PROVIDER</filename> is prevented
from building, which is usually desirable since this
mechanism is designed to select between mutually
@@ -10696,8 +10911,8 @@
The <filename>_forcevariable</filename> override is
not handled specially.
This override only works because the default value of
- <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
- includes "forcevariable".
+ <filename>OVERRIDES</filename> includes
+ "forcevariable".
</note>
</para>
</glossdef>
@@ -10754,7 +10969,7 @@
<glossentry id='var-PRIORITY'><glossterm>PRIORITY</glossterm>
<info>
- PRIORITY[doc] = "Indicates the importance of a package. The default value is 'optional'. Other standard values are 'required', 'standard' and 'extra'."
+ PRIORITY[doc] = "Indicates the importance of a package. The default value is 'optional'. Other standard values are 'required', 'standard', and 'extra'."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -10814,8 +11029,8 @@
<para>
For more information, see the
- "<link linkend='automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
</glossdef>
</glossentry>
@@ -10860,8 +11075,7 @@
Recipes that provide the functionality in question list the
virtual target in <filename>PROVIDES</filename>.
Recipes that depend on the functionality in question can
- include the virtual target in
- <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
+ include the virtual target in <filename>DEPENDS</filename>
to leave the choice of provider open.
</para>
@@ -11001,8 +11215,7 @@
</para>
<para>
- Recipes that inherit the
- <link linkend='ref-classes-distutils'><filename>distutils</filename></link>
+ Recipes that inherit the <filename>distutils</filename>
class during cross-builds also use this variable to
locate the headers and libraries of the appropriate Python
that the extension is targeting.
@@ -11131,8 +11344,8 @@
Therefore, most recipes do not need to set
<filename>RDEPENDS</filename>.
For more information, see the
- "<link linkend='automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies'>Automatically Added Runtime Dependencies</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
<para>
@@ -11571,9 +11784,9 @@
In the example, the package name
(<filename>${<link linkend='var-PN'>PN</link>}-dev</filename>)
must appear as it would in the
- <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
- namespace before any renaming of the output package by
- classes such as <filename>debian.bbclass</filename>.
+ <filename>PACKAGES</filename> namespace before any renaming
+ of the output package by classes such as
+ <filename>debian.bbclass</filename>.
</para>
<para>
@@ -11807,11 +12020,11 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
The directory set up and used by the
<link linkend='ref-classes-populate-sdk'><filename>populate_sdk_base</filename></link>
- to which the SDK is deployed.
+ class to which the SDK is deployed.
The <filename>populate_sdk_base</filename> class defines
<filename>SDK_DEPLOY</filename> as follows:
<literallayout class='monospaced'>
- SDK_DEPLOY = "${<link linkend='var-TMPDIR'>TMPDIR</link>}/deploy/sdk"
+ SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
</literallayout>
</para>
</glossdef>
@@ -11830,7 +12043,7 @@
<link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
class defines the variable as follows:
<literallayout class='monospaced'>
- SDK_DIR = "${<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>}/sdk"
+ SDK_DIR = "${WORKDIR}/sdk"
</literallayout>
<note>
The <filename>SDK_DIR</filename> directory is a
@@ -11876,7 +12089,7 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
The manifest file for the host part of the SDK.
This file lists all the installed packages that make up
- the host part of SDK.
+ the host part of the SDK.
The file contains package information on a line-per-package
basis as follows:
<literallayout class='monospaced'>
@@ -12060,13 +12273,16 @@
<link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
class defines the variable as follows:
<literallayout class='monospaced'>
- SDK_OUTPUT = "${<link linkend='var-SDK_DIR'>SDK_DIR</link>}/image"
+ SDK_DIR = "${WORKDIR}/sdk"
+ SDK_OUTPUT = "${SDK_DIR}/image"
+ SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
</literallayout>
<note>
The <filename>SDK_OUTPUT</filename> directory is a
temporary directory as it is part of
- <filename>WORKDIR</filename> by way of
- <filename>SDK_DIR</filename>.
+ <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+ by way of
+ <link linkend='var-SDK_DIR'><filename>SDK_DIR</filename></link>.
The final output directory is
<link linkend='var-SDK_DEPLOY'><filename>SDK_DEPLOY</filename></link>.
</note>
@@ -12096,13 +12312,13 @@
<glossentry id='var-SDK_POSTPROCESS_COMMAND'><glossterm>SDK_POSTPROCESS_COMMAND</glossterm>
<info>
- SDK_POSTPROCESS_COMMAND[doc] = "Specifies a list of functions to call once the OpenEmbedded build system has created the SDK."
+ SDK_POSTPROCESS_COMMAND[doc] = "Specifies a list of functions to call once the OpenEmbedded build system creates the SDK."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies a list of functions to call once the
- OpenEmbedded build system has created the SDK.
+ OpenEmbedded build system creates the SDK.
You can specify functions separated by semicolons:
<literallayout class='monospaced'>
SDK_POSTPROCESS_COMMAND += "<replaceable>function</replaceable>; ... "
@@ -12443,12 +12659,13 @@
<glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm>
<info>
- SERIAL_CONSOLE[doc] = "The speed and device for the serial port used to attach the serial console. This variable is given to the kernel as the 'console' parameter. After booting occurs, getty is started on that port so remote login is possible."
+ SERIAL_CONSOLE[doc] = "Defines the serial consoles (TTYs) to enable using getty."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Defines a serial console (TTY) to enable using getty.
+ Defines a serial console (TTY) to enable using
+ <ulink url='https://en.wikipedia.org/wiki/Getty_(Unix)'>getty</ulink>.
Provide a value that specifies the baud rate followed by
the TTY device name separated by a space.
You cannot specify more than one TTY device:
@@ -12473,7 +12690,8 @@
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Defines the serial consoles (TTYs) to enable using getty.
+ Defines a serial console (TTY) to enable using
+ <ulink url='https://en.wikipedia.org/wiki/Getty_(Unix)'>getty</ulink>.
Provide a value that specifies the baud rate followed by
the TTY device name separated by a semicolon.
Use spaces to separate multiple devices:
@@ -12527,8 +12745,25 @@
</para>
<para>
- In this example, <filename>intone</filename> depends on
- <filename>mplayer2</filename>.
+ In the previous example, <filename>intone</filename>
+ depends on <filename>mplayer2</filename>.
+ </para>
+
+ <para>
+ You can use the special token <filename>"*"</filename> on
+ the left-hand side of the dependency to match all
+ recipes except the one on the right-hand side.
+ Here is an example:
+ <literallayout class='monospaced'>
+ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"
+ </literallayout>
+ </para>
+
+ <para>
+ In the previous example, all recipes except
+ <filename>quilt-native</filename> ignore task
+ signatures from the <filename>quilt-native</filename>
+ recipe when determining their task signatures.
</para>
<para>
@@ -12789,6 +13024,48 @@
</glossdef>
</glossentry>
+ <glossentry id='var-SPL_BINARY'><glossterm>SPL_BINARY</glossterm>
+ <info>
+ SPL_BINARY[doc] = "The file type of the Secondary Program Loader (SPL)."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The file type for the Secondary Program Loader (SPL).
+ Some devices use an SPL from which to boot (e.g. the
+ BeagleBone development board).
+ For such cases, you can declare the file type of the
+ SPL binary in the <filename>u-boot.inc</filename> include
+ file, which is used in the U-Boot recipe.
+ </para>
+
+ <para>
+ The SPL file type is set to "null" by default in the
+ <filename>u-boot.inc</filename> file as follows:
+ <literallayout class='monospaced'>
+ # Some versions of u-boot build an SPL (Second Program Loader) image that
+ # should be packaged along with the u-boot binary as well as placed in the
+ # deploy directory. For those versions they can set the following variables
+ # to allow packaging the SPL.
+ SPL_BINARY ?= ""
+ SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
+ SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}"
+ SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}"
+ </literallayout>
+ The <filename>SPL_BINARY</filename> variable helps form
+ various <filename>SPL_*</filename> variables used by
+ the OpenEmbedded build system.
+ </para>
+
+ <para>
+ See the BeagleBone machine configuration example in the
+ "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-bitbake-layers-script'>Creating a new BSP Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
+ section in the Yocto Project Board Support Package
+ Developer's Guide for additional information.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
<info>
SRC_URI[doc] = "The list of source files - local or remote. This variable tells the OpenEmbedded build system what bits to pull in for the build and how to pull them in."
@@ -12823,7 +13100,9 @@
Fetches files, which are usually files shipped with
the
<link linkend='metadata'>Metadata</link>,
- from the local machine.
+ from the local machine (e.g.
+ <ulink url='&YOCTO_DOCS_OM_URL;#patching-dev-environment'>patch</ulink>
+ files).
The path is relative to the
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
variable.
@@ -12952,14 +13231,14 @@
</para></listitem>
<listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
(or extracts its contents) into the specified
- subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+ subdirectory of <filename>WORKDIR</filename>
when the local (<filename>file://</filename>)
fetcher is used.
</para></listitem>
<listitem><para><emphasis><filename>localdir</filename> -</emphasis> Places the file
(or extracts its contents) into the specified
- subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
- when the CVS fetcher is used.
+ subdirectory of <filename>WORKDIR</filename> when
+ the CVS fetcher is used.
</para></listitem>
<listitem><para><emphasis><filename>subpath</filename> -</emphasis>
Limits the checkout to a specific subpath of the
@@ -13046,13 +13325,13 @@
<glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
<info>
- SRCREV[doc] = "The revision of the source code used to build the package. This variable applies to Subversion, Git, Mercurial and Bazaar only."
+ SRCREV[doc] = "The revision of the source code used to build the package. This variable applies to Subversion, Git, Mercurial, and Bazaar only."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
The revision of the source code used to build the package.
- This variable applies to Subversion, Git, Mercurial and
+ This variable applies to Subversion, Git, Mercurial, and
Bazaar only.
Note that if you want to build a fixed revision and you
want to avoid performing a query on the remote repository
@@ -13088,7 +13367,7 @@
<glossentry id='var-SSTATE_MIRROR_ALLOW_NETWORK'><glossterm>SSTATE_MIRROR_ALLOW_NETWORK</glossterm>
<info>
- SSTATE_MIRROR_ALLOW_NETWORK[doc] = "If set to "1", allows fetches from mirrors that are specified in SSTATE_MIRRORS to work even when fetching from the network has been disabled by setting BB_NO_NETWORK to "1"."
+ SSTATE_MIRROR_ALLOW_NETWORK[doc] = "If set to "1", allows fetches from mirrors that are specified in SSTATE_MIRRORS to work even when fetching from the network is disabled by setting BB_NO_NETWORK to "1"."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -13096,7 +13375,7 @@
If set to "1", allows fetches from
mirrors that are specified in
<link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
- to work even when fetching from the network has been
+ to work even when fetching from the network is
disabled by setting <filename>BB_NO_NETWORK</filename>
to "1".
Using the
@@ -13301,27 +13580,27 @@
<glossentry id='var-STAGING_DIR'><glossterm>STAGING_DIR</glossterm>
<info>
- STAGING_DIR[doc] = "Specifies the path to the top-level sysroots directory (i.e. ${TMPDIR}/sysroots)."
+ STAGING_DIR[doc] = "Helps construct the recipe-sysroots directory, which is used during packaging."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies the path to the top-level sysroots directory
- (i.e.
- <filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/sysroots</filename>).
+ Helps construct the <filename>recipe-sysroots</filename>
+ directory, which is used during packaging.
</para>
<para>
- <filename>STAGING_DIR</filename> contains the directories
- that are staged into the sysroot by the
+ For information on how staging for recipe-specific
+ sysroots occurs, see the
<link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
- task.
- See the
- <link linkend='var-SYSROOT_DIRS'><filename>SYSROOT_DIRS</filename></link>
- variable and the
+ task, the
"<ulink url='&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes'>Sharing Files Between Recipes</ulink>"
- section in the Yocto Project Development Tasks Manual
- for more information.
+ section in the Yocto Project Development Tasks Manual, the
+ "<ulink url='&YOCTO_DOCS_OM_URL;#configuration-compilation-and-staging-dev-environment'>Configuration, Compilation, and Staging</ulink>"
+ section in the Yocto Project Overview and Concepts Manual,
+ and the
+ <link linkend='var-SYSROOT_DIRS'><filename>SYSROOT_DIRS</filename></link>
+ variable.
<note>
Recipes should never write files directly under
the <filename>STAGING_DIR</filename> directory because
@@ -13346,11 +13625,12 @@
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the path to the sysroot directory for the system
- that the component is built to run on (the system that hosts
- the component).
- For most recipes, this sysroot is the one that the recipe's
+ on which the component is built to run (the system that
+ hosts the component).
+ For most recipes, this sysroot is the one in which that
+ recipe's
<link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
- task copies files into.
+ task copies files.
Exceptions include <filename>-native</filename> recipes,
where the <filename>do_populate_sysroot</filename> task
instead uses
@@ -13359,17 +13639,19 @@
<filename>STAGING_DIR_HOST</filename> can have the
following values:
<itemizedlist>
- <listitem><para>For recipes building for the target
- machine, the value is
+ <listitem><para>
+ For recipes building for the target machine, the
+ value is
"${<link linkend='var-STAGING_DIR'>STAGING_DIR</link>}/${<link linkend='var-MACHINE'>MACHINE</link>}".
</para></listitem>
- <listitem><para>For native recipes building
- for the build host, the value is empty given the
- assumption that when building for the build host,
- the build host's own directories should be used.
- <note><para>
- <filename>-native</filename> recipes are not
- installed into host paths like such as
+ <listitem><para>
+ For native recipes building for the build host, the
+ value is empty given the assumption that when
+ building for the build host, the build host's own
+ directories should be used.
+ <note>
+ <para><filename>-native</filename> recipes are
+ not installed into host paths like such as
<filename>/usr</filename>.
Rather, these recipes are installed into
<filename>STAGING_DIR_NATIVE</filename>.
@@ -13385,7 +13667,7 @@
example, GCC's <filename>-isystem</filename>
option.</para>
- <para>This emphasizes that the
+ <para>Thus, the emphasis is that the
<filename>STAGING_DIR*</filename> variables
should be viewed as input variables by tasks
such as
@@ -13399,7 +13681,7 @@
<filename>-native</filename> recipes, as
they make use of host headers and libraries.
</para>
- </note>
+ </note>
</para></listitem>
</itemizedlist>
</para>
@@ -13590,8 +13872,8 @@
<para>
For information on how BitBake uses stamp files to determine
if a task should be rerun, see the
- "<link linkend='stamp-files-and-the-rerunning-of-tasks'>Stamp Files and the Rerunning of Tasks</link>"
- section.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks'>Stamp Files and the Rerunning of Tasks</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
</para>
<para>
@@ -13637,13 +13919,13 @@
<glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
<info>
- SUMMARY[doc] = "The short (80 characters or less) summary of the binary package for packaging systems such as opkg, rpm or dpkg. By default, SUMMARY is used to define the DESCRIPTION variable if DESCRIPTION is not set in the recipe."
+ SUMMARY[doc] = "The short (80 characters or less) summary of the binary package for packaging systems such as opkg, rpm, or dpkg. By default, SUMMARY is used to define the DESCRIPTION variable if DESCRIPTION is not set in the recipe."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
The short (72 characters or less) summary of the binary package for packaging
- systems such as <filename>opkg</filename>, <filename>rpm</filename> or
+ systems such as <filename>opkg</filename>, <filename>rpm</filename>, or
<filename>dpkg</filename>.
By default, <filename>SUMMARY</filename> is used to define
the <link linkend='var-DESCRIPTION'><filename>DESCRIPTION</filename></link>
@@ -13655,7 +13937,7 @@
<glossentry id='var-SVNDIR'><glossterm>SVNDIR</glossterm>
<info>
- SVNDIR[doc] = "The directory where Subversion checkouts will be stored."
+ SVNDIR[doc] = "The directory where Subversion checkouts are stored."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -13724,7 +14006,7 @@
in your recipe.
The variable's default value is set in the
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
- as follows:
+ class as follows:
<literallayout class='monospaced'>
SYSLINUX_SERIAL ?= "0 115200"
</literallayout>
@@ -13738,13 +14020,13 @@
<glossentry id='var-SYSLINUX_SPLASH'><glossterm>SYSLINUX_SPLASH</glossterm>
<info>
- SYSLINUX_SPLASH[doc] = "An .LSS file used as the background for the VGA boot menu when you are using the boot menu."
+ SYSLINUX_SPLASH[doc] = "An .LSS file used as the background for the VGA boot menu when you use the boot menu."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
An <filename>.LSS</filename> file used as the background
- for the VGA boot menu when you are using the boot menu.
+ for the VGA boot menu when you use the boot menu.
You need to set this variable in your recipe.
</para>
@@ -13767,7 +14049,7 @@
Specifies the alternate console=tty... kernel boot argument.
The variable's default value is set in the
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
- as follows:
+ class as follows:
<literallayout class='monospaced'>
SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
</literallayout>
@@ -13781,7 +14063,7 @@
<glossentry id='var-SYSROOT_DESTDIR'><glossterm>SYSROOT_DESTDIR</glossterm>
<info>
- SYSROOT_DESTDIR[doc] = "Points to the temporary work directory (default ${WORKDIR}/sysroot-destdir) where the files that will be populated into the sysroot are assembled during the do_populate_sysroot task."
+ SYSROOT_DESTDIR[doc] = "Points to the temporary work directory (default ${WORKDIR}/sysroot-destdir) where the files populated into the sysroot are assembled during the do_populate_sysroot task."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -13789,8 +14071,7 @@
Points to the temporary directory under the work directory
(default
"<filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/sysroot-destdir</filename>")
- where the files
- that will be populated into the sysroot are assembled
+ where the files populated into the sysroot are assembled
during the
<link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
task.
@@ -13905,17 +14186,17 @@
<glossentry id='var-SYSTEMD_AUTO_ENABLE'><glossterm>SYSTEMD_AUTO_ENABLE</glossterm>
<info>
- SYSTEMD_AUTO_ENABLE[doc] = "For recipes that inherit the systemd class, this variable specifies whether the service you have specified in SYSTEMD_SERVICE should be started automatically or not."
+ SYSTEMD_AUTO_ENABLE[doc] = "For recipes that inherit the systemd class, this variable specifies whether the specified service in SYSTEMD_SERVICE should start automatically or not."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
When inheriting the
<link linkend='ref-classes-systemd'><filename>systemd</filename></link>
- class, this variable specifies whether the service you have
- specified in
+ class, this variable specifies whether the specified service
+ in
<link linkend='var-SYSTEMD_SERVICE'><filename>SYSTEMD_SERVICE</filename></link>
- should be started automatically or not.
+ should start automatically or not.
By default, the service is enabled to automatically start
at boot time.
The default setting is in the
@@ -13963,7 +14244,7 @@
<glossentry id='var-SYSTEMD_BOOT_ENTRIES'><glossterm>SYSTEMD_BOOT_ENTRIES</glossterm>
<info>
- SYSTEMD_BOOT_ENTRIES[doc] = "When EFI_PROVIDER is set to "systemd-boot", the SYSTEMD_BOOT_ENTRIES variable specifies a list of entry files (*.conf) to be installed containing one boot entry per file."
+ SYSTEMD_BOOT_ENTRIES[doc] = "When EFI_PROVIDER is set to "systemd-boot", the SYSTEMD_BOOT_ENTRIES variable specifies a list of entry files (*.conf) to install that contain one boot entry per file."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -13973,8 +14254,8 @@
is set to "systemd-boot", the
<filename>SYSTEMD_BOOT_ENTRIES</filename> variable specifies
a list of entry files
- (<filename>*.conf</filename>) to be installed
- containing one boot entry per file.
+ (<filename>*.conf</filename>) to install that contain
+ one boot entry per file.
By default, the
<link linkend='ref-classes-systemd-boot'><filename>systemd-boot</filename></link>
class sets the <filename>SYSTEMD_BOOT_ENTRIES</filename> as
@@ -14076,7 +14357,7 @@
<glossentry id='var-SYSVINIT_ENABLED_GETTYS'><glossterm>SYSVINIT_ENABLED_GETTYS</glossterm>
<info>
- SYSVINIT_ENABLED_GETTYS[doc] = "Specifies which virtual terminals should be running a getty, the default is '1'."
+ SYSVINIT_ENABLED_GETTYS[doc] = "Specifies which virtual terminals should run a getty, the default is '1'."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -14084,7 +14365,7 @@
When using
<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>,
specifies a space-separated list of the virtual terminals
- that should be running a
+ that should run a
<ulink url='http://en.wikipedia.org/wiki/Getty_%28Unix%29'>getty</ulink>
(allowing login), assuming
<link linkend='var-USE_VT'><filename>USE_VT</filename></link>
@@ -14250,10 +14531,8 @@
<para>
Additionally, the SDK's environment setup script sets
- the
- <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
- variable in the environment to the
- <filename>TARGET_CFLAGS</filename> value so that
+ the <filename>CFLAGS</filename> variable in the environment
+ to the <filename>TARGET_CFLAGS</filename> value so that
executables built using the SDK also have the flags
applied.
</para>
@@ -14277,12 +14556,10 @@
<para>
Additionally, the SDK's environment setup script sets
- the
- <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
- variable in the environment to the
- <filename>TARGET_CPPFLAGS</filename> value so that
- executables built using the SDK also have the flags
- applied.
+ the <filename>CPPFLAGS</filename> variable in the
+ environment to the <filename>TARGET_CPPFLAGS</filename>
+ value so that executables built using the SDK also have
+ the flags applied.
</para>
</glossdef>
</glossentry>
@@ -14303,12 +14580,10 @@
<para>
Additionally, the SDK's environment setup script sets
- the
- <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
- variable in the environment to the
- <filename>TARGET_CXXFLAGS</filename> value so that
- executables built using the SDK also have the flags
- applied.
+ the <filename>CXXFLAGS</filename> variable in the
+ environment to the <filename>TARGET_CXXFLAGS</filename>
+ value so that executables built using the SDK also have
+ the flags applied.
</para>
</glossdef>
</glossentry>
@@ -14382,10 +14657,10 @@
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the target's operating system.
- The variable can be set to "linux" for <filename>glibc</filename>-based systems and
- to "linux-musl" for <filename>musl</filename>.
- For ARM/EABI targets, there are also "linux-gnueabi" and
- "linux-musleabi" values possible.
+ The variable can be set to "linux" for glibc-based systems
+ (GNU C Library) and to "linux-musl" for musl libc.
+ For ARM/EABI targets, "linux-gnueabi" and "linux-musleabi"
+ possible values exist.
</para>
</glossdef>
</glossentry>
@@ -14553,10 +14828,14 @@
default toolchain.
Using older or newer versions of these components
might cause build problems.
- See the
- <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
+ See the Release Notes for the Yocto Project release
for the specific components with which the toolchain
must be compatible.
+ To access the Release Notes, go to the
+ <ulink url='&YOCTO_HOME_URL;/software-overview/downloads/'>Downloads</ulink>
+ page on the Yocto Project website and click on the
+ "RELEASE INFORMATION" link for the appropriate
+ release.
</note>
</para>
@@ -14671,7 +14950,7 @@
<glossentry id='var-TEST_LOG_DIR'><glossterm>TEST_LOG_DIR</glossterm>
<info>
- TEST_LOG_DIR[doc] = "Holds the SSH log and the boot log for QEMU machines. The <filename>TEST_LOG_DIR</filename> variable defaults to "${WORKDIR}/testimage"."
+ TEST_LOG_DIR[doc] = "Holds the SSH log and the boot log for QEMU machines. The TEST_LOG_DIR variable defaults to "${WORKDIR}/testimage"."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -15083,8 +15362,8 @@
<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.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
For information on setting up a cross-development
environment, see the
<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
@@ -15142,8 +15421,8 @@
<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.
+ "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+ section in the Yocto Project Overview and Concepts Manual.
For information on setting up a cross-development
environment, see the
<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
@@ -15181,7 +15460,7 @@
a value where underscores are not allowed, for example
within package filenames.
In this case, dash characters replace any underscore
- characters used in TARGET_ARCH.
+ characters used in <filename>TARGET_ARCH</filename>.
</para>
<para>
@@ -15749,7 +16028,7 @@
<glossentry id='var-UPDATERCPN'><glossterm>UPDATERCPN</glossterm>
<info>
- UPDATERCPN[doc] = "Specifies the package that contains the initscript that is to be enabled."
+ UPDATERCPN[doc] = "Specifies the package that contains the initscript that is enabled."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -15757,7 +16036,7 @@
For recipes inheriting the
<link linkend='ref-classes-update-rc.d'><filename>update-rc.d</filename></link>
class, <filename>UPDATERCPN</filename> specifies
- the package that contains the initscript that is to be
+ the package that contains the initscript that is
enabled.
</para>
@@ -16045,7 +16324,7 @@
<glossentry id='var-USERADD_PARAM'><glossterm>USERADD_PARAM</glossterm>
<info>
- USERADD_PARAM[doc] = "When a recipe inherits the useradd class, this variable specifies for a package what parameters should be passed to the useradd command if you wish to add a user to the system when the package is installed."
+ USERADD_PARAM[doc] = "When a recipe inherits the useradd class, this variable specifies for a package what parameters should pass to the useradd command if you add a user to the system when the package is installed."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -16053,9 +16332,9 @@
When inheriting the
<link linkend='ref-classes-useradd'><filename>useradd</filename></link>
class, this variable
- specifies for a package what parameters should be passed
+ specifies for a package what parameters should pass
to the <filename>useradd</filename> command
- if you wish to add a user to the system when the package
+ if you add a user to the system when the package
is installed.
</para>
@@ -16266,7 +16545,7 @@
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
section in the Yocto Project Development Tasks Manual.
For details on the kickstart file format, see the
- "<link linkend='openembedded-kickstart-wks-reference'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
+ "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
Chapter.
</para>
</glossdef>
@@ -16295,7 +16574,7 @@
</literallayout>
The actual directory depends on several things:
<itemizedlist>
- <listitem><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>:
+ <listitem><filename>TMPDIR</filename>:
The top-level build output directory</listitem>
<listitem><link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>:
The target system identifier</listitem>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/resources.xml b/import-layers/yocto-poky/documentation/ref-manual/resources.xml
index d59bea2..be04696 100644
--- a/import-layers/yocto-poky/documentation/ref-manual/resources.xml
+++ b/import-layers/yocto-poky/documentation/ref-manual/resources.xml
@@ -37,8 +37,8 @@
<para>
The Yocto Project uses its own implementation of
- <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track
- defects (bugs).
+ <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink> to
+ track defects (bugs).
Implementations of Bugzilla work well for group development because
they track bugs and code changes, can be used to communicate changes
and problems with developers, can be used to submit and review patches,
@@ -68,6 +68,8 @@
<ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>Bugzilla wiki page</ulink>
</para></listitem>
</itemizedlist>
+ For information on Bugzilla in general, see
+ <ulink url='http://www.bugzilla.org/about/'></ulink>.
</para>
</section>
@@ -160,10 +162,18 @@
</para></listitem>
<listitem><para>
<emphasis>
- <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>:
+ <ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink>:
</emphasis>
- This short document lets you get started
- with the Yocto Project and quickly begin building an image.
+ This short document lets you experience building an image using
+ the Yocto Project without having to understand any concepts or
+ details.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>
+ <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>:
+ </emphasis>
+ This manual provides overview and conceptual information
+ about the Yocto Project.
</para></listitem>
<listitem><para>
<emphasis>
@@ -201,6 +211,23 @@
</para></listitem>
<listitem><para>
<emphasis>
+ <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>:
+ </emphasis>
+ This manual provides reference material such as variable,
+ task, and class descriptions.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>
+ <ulink url='&YOCTO_DOCS_MM_URL;'>Yocto Project Mega-Manual</ulink>:
+ </emphasis>
+ This manual is simply a single HTML file comprised of the
+ bulk of the Yocto Project manuals.
+ The Mega-Manual primarily exists as a vehicle by which you can
+ easily search for phrases and terms used in the Yocto Project
+ documentation set.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>
<ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>:
</emphasis>
This manual presents a set of common and generally useful
@@ -209,7 +236,18 @@
</para></listitem>
<listitem><para>
<emphasis>
- <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-appendix-latest-yp-eclipse-plug-in'>Eclipse IDE Yocto Plug-in</ulink>:
+ <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>:
+ </emphasis>
+ This manual introduces and describes how to set up and use
+ Toaster.
+ Toaster is an Application Programming Interface (API) and
+ web-based interface to the
+ <link linkend='build-system-term'>OpenEmbedded Build System</link>,
+ which uses BitBake, that reports build information.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>
+ <ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Eclipse IDE Yocto Plug-in</ulink>:
</emphasis>
Instructions that demonstrate how an application developer
uses the Eclipse Yocto Project Plug-in feature within
@@ -222,22 +260,13 @@
A list of commonly asked questions and their answers.
</para></listitem>
<listitem><para>
- <emphasis>
- <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>:
- </emphasis>
+ <emphasis>Release Notes:</emphasis>
Features, updates and known issues for the current
release of the Yocto Project.
- </para></listitem>
- <listitem><para>
- <emphasis>
- <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>:
- </emphasis>
- This manual introduces and describes how to set up and use
- Toaster.
- Toaster is an Application Programming Interface (API) and
- web-based interface to the
- <link linkend='build-system-term'>OpenEmbedded Build System</link>,
- which uses BitBake, that reports build information.
+ To access the Release Notes, go to the
+ <ulink url='&YOCTO_HOME_URL;/software-overview/downloads/'>Downloads</ulink>
+ page on the Yocto Project website and click on the
+ "RELEASE INFORMATION" link for the appropriate release.
</para></listitem>
<listitem><para>
<emphasis>
diff --git a/import-layers/yocto-poky/documentation/ref-manual/technical-details.xml b/import-layers/yocto-poky/documentation/ref-manual/technical-details.xml
deleted file mode 100644
index e9e76e4..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/technical-details.xml
+++ /dev/null
@@ -1,2042 +0,0 @@
-<!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='technical-details'>
-<title>Technical Details</title>
-
- <para>
- This chapter provides technical details for various parts of the
- Yocto Project.
- Currently, topics include Yocto Project components,
- cross-toolchain generation, shared state (sstate) cache,
- x32, Wayland support, and Licenses.
- </para>
-
-<section id='usingpoky-components'>
- <title>Yocto Project Components</title>
-
- <para>
- The
- <link linkend='bitbake-term'>BitBake</link>
- task executor together with various types of configuration files form
- the OpenEmbedded Core.
- This section overviews these components by describing their use and
- how they interact.
- </para>
-
- <para>
- BitBake handles the parsing and execution of the data files.
- The data itself is of various types:
- <itemizedlist>
- <listitem><para><emphasis>Recipes:</emphasis> Provides details
- about particular pieces of software.
- </para></listitem>
- <listitem><para><emphasis>Class Data:</emphasis> Abstracts
- common build information (e.g. how to build a Linux kernel).
- </para></listitem>
- <listitem><para><emphasis>Configuration Data:</emphasis> Defines
- machine-specific settings, policy decisions, and so forth.
- Configuration data acts as the glue to bind everything
- together.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- BitBake knows how to combine multiple data sources together and refers
- to each data source as a layer.
- For information on layers, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
- Creating Layers</ulink>" section of the Yocto Project Development
- Tasks Manual.
- </para>
-
- <para>
- Following are some brief details on these core components.
- For additional information on how these components interact during
- a build, see the
- "<link linkend='development-concepts'>Development Concepts</link>"
- section.
- </para>
-
- <section id='usingpoky-components-bitbake'>
- <title>BitBake</title>
-
- <para>
- BitBake is the tool at the heart of the OpenEmbedded build system
- and is responsible for parsing the
- <link linkend='metadata'>Metadata</link>,
- generating a list of tasks from it, and then executing those tasks.
- </para>
-
- <para>
- This section briefly introduces BitBake.
- If you want more information on BitBake, see the
- <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
- </para>
-
- <para>
- To see a list of the options BitBake supports, use either of
- the following commands:
- <literallayout class='monospaced'>
- $ bitbake -h
- $ bitbake --help
- </literallayout>
- </para>
-
- <para>
- The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
- <filename>packagename</filename> is the name of the package you want to build
- (referred to as the "target" in this manual).
- The target often equates to the first part of a recipe's filename
- (e.g. "foo" for a recipe named
- <filename>foo_1.3.0-r0.bb</filename>).
- So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
- might type the following:
- <literallayout class='monospaced'>
- $ bitbake matchbox-desktop
- </literallayout>
- Several different versions of <filename>matchbox-desktop</filename> might exist.
- BitBake chooses the one selected by the distribution configuration.
- You can get more details about how BitBake chooses between different
- target versions and providers in the
- "<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>"
- section of the BitBake User Manual.
- </para>
-
- <para>
- BitBake also tries to execute any dependent tasks first.
- So for example, before building <filename>matchbox-desktop</filename>, BitBake
- would build a cross compiler and <filename>glibc</filename> if they had not already
- been built.
- </para>
-
- <para>
- A useful BitBake option to consider is the <filename>-k</filename> or
- <filename>--continue</filename> option.
- This option instructs BitBake to try and continue processing the job
- as long as possible even after encountering an error.
- When an error occurs, the target that
- failed and those that depend on it cannot be remade.
- However, when you use this option other dependencies can still be
- processed.
- </para>
- </section>
-
- <section id='usingpoky-components-metadata'>
- <title>Metadata (Recipes)</title>
-
- <para>
- Files that have the <filename>.bb</filename> suffix are "recipes"
- files.
- In general, a recipe contains information about a single piece of
- software.
- This information includes the location from which to download the
- unaltered source, any source patches to be applied to that source
- (if needed), which special configuration options to apply,
- how to compile the source files, and how to package the compiled
- output.
- </para>
-
- <para>
- The term "package" is sometimes used to refer to recipes. However,
- since the word "package" is used for the packaged output from the OpenEmbedded
- build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
- this document avoids using the term "package" when referring to recipes.
- </para>
- </section>
-
- <section id='metadata-virtual-providers'>
- <title>Metadata (Virtual Providers)</title>
-
- <para>
- Prior to the build, if you know that several different recipes
- provide the same functionality, you can use a virtual provider
- (i.e. <filename>virtual/*</filename>) as a placeholder for the
- actual provider.
- The actual provider would be determined at build
- time.
- In this case, you should add <filename>virtual/*</filename>
- to <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>,
- rather than listing the specified provider.
- You would select the actual provider by setting the
- <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>
- variable (i.e. <filename>PREFERRED_PROVIDER_virtual/*</filename>)
- in the build's configuration file (e.g.
- <filename>poky/build/conf/local.conf</filename>).
- <note>
- Any recipe that PROVIDES a <filename>virtual/*</filename> item
- that is ultimately not selected through
- <filename>PREFERRED_PROVIDER</filename> does not get built.
- Preventing these recipes from building is usually the desired
- behavior since this mechanism's purpose is to select between
- mutually exclusive alternative providers.
- </note>
- </para>
-
- <para>
- The following lists specific examples of virtual providers:
- <itemizedlist>
- <listitem><para>
- <filename>virtual/mesa</filename>:
- Provides <filename>gbm.pc</filename>.
- </para></listitem>
- <listitem><para>
- <filename>virtual/egl</filename>:
- Provides <filename>egl.pc</filename> and possibly
- <filename>wayland-egl.pc</filename>.
- </para></listitem>
- <listitem><para>
- <filename>virtual/libgl</filename>:
- Provides <filename>gl.pc</filename> (i.e. libGL).
- </para></listitem>
- <listitem><para>
- <filename>virtual/libgles1</filename>:
- Provides <filename>glesv1_cm.pc</filename>
- (i.e. libGLESv1_CM).
- </para></listitem>
- <listitem><para>
- <filename>virtual/libgles2</filename>:
- Provides <filename>glesv2.pc</filename> (i.e. libGLESv2).
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='usingpoky-components-classes'>
- <title>Classes</title>
-
- <para>
- Class files (<filename>.bbclass</filename>) contain information that
- is useful to share between
- <link linkend='metadata'>Metadata</link> files.
- An example is the
- <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
- class, which contains common settings for any application that
- Autotools uses.
- The "<link linkend='ref-classes'>Classes</link>" chapter provides
- details about classes and how to use them.
- </para>
- </section>
-
- <section id='usingpoky-components-configuration'>
- <title>Configuration</title>
-
- <para>
- The configuration files (<filename>.conf</filename>) define various configuration variables
- that govern the OpenEmbedded build process.
- These files fall into several areas that define machine configuration options,
- distribution configuration options, compiler tuning options, general common configuration
- options, and user configuration options in <filename>local.conf</filename>, which is found
- in the
- <link linkend='build-directory'>Build Directory</link>.
- </para>
- </section>
-</section>
-
-<section id="cross-development-toolchain-generation">
- <title>Cross-Development Toolchain Generation</title>
-
- <para>
- The Yocto Project does most of the work for you when it comes to
- creating
- <link linkend='cross-development-toolchain'>cross-development toolchains</link>.
- This section provides some technical background on how
- cross-development toolchains are created and used.
- For more information on toolchains, you can also see the
- <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
- manual.
- </para>
-
- <para>
- In the Yocto Project development environment, cross-development
- toolchains are used to build the image and applications that run on the
- target hardware.
- With just a few commands, the OpenEmbedded build system creates
- these necessary toolchains for you.
- </para>
-
- <para>
- The following figure shows a high-level build environment regarding
- toolchain construction and use.
- </para>
-
- <para>
- <imagedata fileref="figures/cross-development-toolchains.png" width="8in" depth="6in" align="center" />
- </para>
-
- <para>
- Most of the work occurs on the Build Host.
- This is the machine used to build images and generally work within the
- the Yocto Project environment.
- When you run BitBake to create an image, the OpenEmbedded build system
- uses the host <filename>gcc</filename> compiler to bootstrap a
- cross-compiler named <filename>gcc-cross</filename>.
- The <filename>gcc-cross</filename> compiler is what BitBake uses to
- compile source files when creating the target image.
- You can think of <filename>gcc-cross</filename> simply as an
- automatically generated cross-compiler that is used internally within
- BitBake only.
- <note>
- The extensible SDK does not use
- <filename>gcc-cross-canadian</filename> since this SDK
- ships a copy of the OpenEmbedded build system and the sysroot
- within it contains <filename>gcc-cross</filename>.
- </note>
- </para>
-
- <para>
- The chain of events that occurs when <filename>gcc-cross</filename> is
- bootstrapped is as follows:
- <literallayout class='monospaced'>
- gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> glibc-initial -> glibc -> gcc-cross -> gcc-runtime
- </literallayout>
- <itemizedlist>
- <listitem><para><filename>gcc</filename>:
- The build host's GNU Compiler Collection (GCC).
- </para></listitem>
- <listitem><para><filename>binutils-cross</filename>:
- The bare minimum binary utilities needed in order to run
- the <filename>gcc-cross-initial</filename> phase of the
- bootstrap operation.
- </para></listitem>
- <listitem><para><filename>gcc-cross-initial</filename>:
- An early stage of the bootstrap process for creating
- the cross-compiler.
- This stage builds enough of the <filename>gcc-cross</filename>,
- the C library, and other pieces needed to finish building the
- final cross-compiler in later stages.
- This tool is a "native" package (i.e. it is designed to run on
- the build host).
- </para></listitem>
- <listitem><para><filename>linux-libc-headers</filename>:
- Headers needed for the cross-compiler.
- </para></listitem>
- <listitem><para><filename>glibc-initial</filename>:
- An initial version of the Embedded GLIBC needed to bootstrap
- <filename>glibc</filename>.
- </para></listitem>
- <listitem><para><filename>gcc-cross</filename>:
- The final stage of the bootstrap process for the
- cross-compiler.
- This stage results in the actual cross-compiler that
- BitBake uses when it builds an image for a targeted
- device.
- <note>
- If you are replacing this cross compiler toolchain
- with a custom version, you must replace
- <filename>gcc-cross</filename>.
- </note>
- This tool is also a "native" package (i.e. it is
- designed to run on the build host).
- </para></listitem>
- <listitem><para><filename>gcc-runtime</filename>:
- Runtime libraries resulting from the toolchain bootstrapping
- process.
- This tool produces a binary that consists of the
- runtime libraries need for the targeted device.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- You can use the OpenEmbedded build system to build an installer for
- the relocatable SDK used to develop applications.
- When you run the installer, it installs the toolchain, which contains
- the development tools (e.g., the
- <filename>gcc-cross-canadian</filename>),
- <filename>binutils-cross-canadian</filename>, and other
- <filename>nativesdk-*</filename> tools,
- which are tools native to the SDK (i.e. native to
- <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>),
- you need to cross-compile and test your software.
- The figure shows the commands you use to easily build out this
- toolchain.
- This cross-development toolchain is built to execute on the
- <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
- which might or might not be the same
- machine as the Build Host.
- <note>
- If your target architecture is supported by the Yocto Project,
- you can take advantage of pre-built images that ship with the
- Yocto Project and already contain cross-development toolchain
- installers.
- </note>
- </para>
-
- <para>
- Here is the bootstrap process for the relocatable toolchain:
- <literallayout class='monospaced'>
- gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers ->
- glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian
- </literallayout>
- <itemizedlist>
- <listitem><para><filename>gcc</filename>:
- The build host's GNU Compiler Collection (GCC).
- </para></listitem>
- <listitem><para><filename>binutils-crosssdk</filename>:
- The bare minimum binary utilities needed in order to run
- the <filename>gcc-crosssdk-initial</filename> phase of the
- bootstrap operation.
- </para></listitem>
- <listitem><para><filename>gcc-crosssdk-initial</filename>:
- An early stage of the bootstrap process for creating
- the cross-compiler.
- This stage builds enough of the
- <filename>gcc-crosssdk</filename> and supporting pieces so that
- the final stage of the bootstrap process can produce the
- finished cross-compiler.
- This tool is a "native" binary that runs on the build host.
- </para></listitem>
- <listitem><para><filename>linux-libc-headers</filename>:
- Headers needed for the cross-compiler.
- </para></listitem>
- <listitem><para><filename>glibc-initial</filename>:
- An initial version of the Embedded GLIBC needed to bootstrap
- <filename>nativesdk-glibc</filename>.
- </para></listitem>
- <listitem><para><filename>nativesdk-glibc</filename>:
- The Embedded GLIBC needed to bootstrap the
- <filename>gcc-crosssdk</filename>.
- </para></listitem>
- <listitem><para><filename>gcc-crosssdk</filename>:
- The final stage of the bootstrap process for the
- relocatable cross-compiler.
- The <filename>gcc-crosssdk</filename> is a transitory compiler
- and never leaves the build host.
- Its purpose is to help in the bootstrap process to create the
- eventual relocatable <filename>gcc-cross-canadian</filename>
- compiler, which is relocatable.
- This tool is also a "native" package (i.e. it is
- designed to run on the build host).
- </para></listitem>
- <listitem><para><filename>gcc-cross-canadian</filename>:
- The final relocatable cross-compiler.
- When run on the
- <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
- this tool
- produces executable code that runs on the target device.
- Only one cross-canadian compiler is produced per architecture
- since they can be targeted at different processor optimizations
- using configurations passed to the compiler through the
- compile commands.
- This circumvents the need for multiple compilers and thus
- reduces the size of the toolchains.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <note>
- For information on advantages gained when building a
- cross-development toolchain installer, see the
- "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
- section in the Yocto Project Application Development and the
- Extensible Software Development Kit (eSDK) manual.
- </note>
-</section>
-
-<section id="shared-state-cache">
- <title>Shared State Cache</title>
-
- <para>
- By design, the OpenEmbedded build system builds everything from scratch unless
- BitBake can determine that parts do not need to be rebuilt.
- Fundamentally, building from scratch is attractive as it means all parts are
- built fresh and there is no possibility of stale data causing problems.
- When developers hit problems, they typically default back to building from scratch
- so they know the state of things from the start.
- </para>
-
- <para>
- Building an image from scratch is both an advantage and a disadvantage to the process.
- As mentioned in the previous paragraph, building from scratch ensures that
- everything is current and starts from a known state.
- However, building from scratch also takes much longer as it generally means
- rebuilding things that do not necessarily need to be rebuilt.
- </para>
-
- <para>
- The Yocto Project implements shared state code that supports incremental builds.
- The implementation of the shared state code answers the following questions that
- were fundamental roadblocks within the OpenEmbedded incremental build support system:
- <itemizedlist>
- <listitem><para>What pieces of the system have changed and what pieces have
- not changed?</para></listitem>
- <listitem><para>How are changed pieces of software removed and replaced?</para></listitem>
- <listitem><para>How are pre-built components that do not need to be rebuilt from scratch
- used when they are available?</para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- For the first question, the build system detects changes in the "inputs" to a given task by
- creating a checksum (or signature) of the task's inputs.
- If the checksum changes, the system assumes the inputs have changed and the task needs to be
- rerun.
- For the second question, the shared state (sstate) code tracks which tasks add which output
- to the build process.
- This means the output from a given task can be removed, upgraded or otherwise manipulated.
- The third question is partly addressed by the solution for the second question
- assuming the build system can fetch the sstate objects from remote locations and
- install them if they are deemed to be valid.
- </para>
-
- <note>
- The OpenEmbedded build system does not maintain
- <link linkend='var-PR'><filename>PR</filename></link> information
- as part of the shared state packages.
- Consequently, considerations exist that affect maintaining shared
- state feeds.
- For information on how the OpenEmbedded build system
- works with packages and can
- track incrementing <filename>PR</filename> information, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </note>
-
- <para>
- The rest of this section goes into detail about the overall incremental build
- architecture, the checksums (signatures), shared state, and some tips and tricks.
- </para>
-
- <section id='overall-architecture'>
- <title>Overall Architecture</title>
-
- <para>
- When determining what parts of the system need to be built, BitBake
- works on a per-task basis rather than a per-recipe basis.
- You might wonder why using a per-task basis is preferred over a per-recipe basis.
- To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
- In this case, the
- <link linkend='ref-tasks-install'><filename>do_install</filename></link>
- and
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- task outputs are still valid.
- However, with a per-recipe approach, the build would not include the
- <filename>.deb</filename> files.
- Consequently, you would have to invalidate the whole build and rerun it.
- Rerunning everything is not the best solution.
- Also, in this case, the core must be "taught" much about specific tasks.
- This methodology does not scale well and does not allow users to easily add new tasks
- in layers or as external recipes without touching the packaged-staging core.
- </para>
- </section>
-
- <section id='checksums'>
- <title>Checksums (Signatures)</title>
-
- <para>
- The shared state code uses a checksum, which is a unique signature of a task's
- inputs, to determine if a task needs to be run again.
- Because it is a change in a task's inputs that triggers a rerun, the process
- needs to detect all the inputs to a given task.
- For shell tasks, this turns out to be fairly easy because
- the build process generates a "run" shell script for each task and
- it is possible to create a checksum that gives you a good idea of when
- the task's data changes.
- </para>
-
- <para>
- To complicate the problem, there are things that should not be
- included in the checksum.
- First, there is the actual specific build path of a given task -
- the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
- It does not matter if the work directory changes because it should
- not affect the output for target packages.
- Also, the build process has the objective of making native
- or cross packages relocatable.
- <note>
- Both native and cross packages run on the build host.
- However, cross packages generate output for the target
- architecture.
- </note>
- The checksum therefore needs to exclude
- <filename>WORKDIR</filename>.
- The simplistic approach for excluding the work directory is to set
- <filename>WORKDIR</filename> to some fixed value and create the
- checksum for the "run" script.
- </para>
-
- <para>
- Another problem results from the "run" scripts containing functions that
- might or might not get called.
- The incremental build solution contains code that figures out dependencies
- between shell functions.
- This code is used to prune the "run" scripts down to the minimum set,
- thereby alleviating this problem and making the "run" scripts much more
- readable as a bonus.
- </para>
-
- <para>
- So far we have solutions for shell scripts.
- What about Python tasks?
- The same approach applies even though these tasks are more difficult.
- The process needs to figure out what variables a Python function accesses
- and what functions it calls.
- Again, the incremental build solution contains code that first figures out
- the variable and function dependencies, and then creates a checksum for the data
- used as the input to the task.
- </para>
-
- <para>
- Like the <filename>WORKDIR</filename> case, situations exist where dependencies
- should be ignored.
- For these cases, you can instruct the build process to ignore a dependency
- by using a line like the following:
- <literallayout class='monospaced'>
- PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
- </literallayout>
- This example ensures that the
- <link linkend='var-PACKAGE_ARCHS'><filename>PACKAGE_ARCHS</filename></link>
- variable does not
- depend on the value of
- <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
- even if it does reference it.
- </para>
-
- <para>
- Equally, there are cases where we need to add dependencies BitBake is not able to find.
- You can accomplish this by using a line like the following:
- <literallayout class='monospaced'>
- PACKAGE_ARCHS[vardeps] = "MACHINE"
- </literallayout>
- This example explicitly adds the <filename>MACHINE</filename> variable as a
- dependency for <filename>PACKAGE_ARCHS</filename>.
- </para>
-
- <para>
- Consider a case with in-line Python, for example, where BitBake is not
- able to figure out dependencies.
- When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
- produces output when it discovers something for which it cannot figure out
- dependencies.
- The Yocto Project team has currently not managed to cover those dependencies
- in detail and is aware of the need to fix this situation.
- </para>
-
- <para>
- Thus far, this section has limited discussion to the direct inputs into a task.
- Information based on direct inputs is referred to as the "basehash" in the
- code.
- However, there is still the question of a task's indirect inputs - the
- things that were already built and present in the
- <link linkend='build-directory'>Build Directory</link>.
- The checksum (or signature) for a particular task needs to add the hashes
- of all the tasks on which the particular task depends.
- Choosing which dependencies to add is a policy decision.
- However, the effect is to generate a master checksum that combines the basehash
- and the hashes of the task's dependencies.
- </para>
-
- <para>
- At the code level, there are a variety of ways both the basehash and the
- dependent task hashes can be influenced.
- Within the BitBake configuration file, we can give BitBake some extra information
- to help it construct the basehash.
- The following statement effectively results in a list of global variable
- dependency excludes - variables never included in any checksum:
- <literallayout class='monospaced'>
- BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
- SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
- USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
- PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
- CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
- </literallayout>
- The previous example excludes
- <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
- since that variable is actually constructed as a path within
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>, which is on
- the whitelist.
- </para>
-
- <para>
- The rules for deciding which hashes of dependent tasks to include through
- dependency chains are more complex and are generally accomplished with a
- Python function.
- The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
- of this and also illustrates how you can insert your own policy into the system
- if so desired.
- This file defines the two basic signature generators
- <link linkend='oe-core'>OE-Core</link> uses: "OEBasic" and
- "OEBasicHash".
- By default, there is a dummy "noop" signature handler enabled in BitBake.
- This means that behavior is unchanged from previous versions.
- OE-Core uses the "OEBasicHash" signature handler by default
- through this setting in the <filename>bitbake.conf</filename> file:
- <literallayout class='monospaced'>
- BB_SIGNATURE_HANDLER ?= "OEBasicHash"
- </literallayout>
- The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
- "OEBasic" version but adds the task hash to the stamp files.
- This results in any
- <link linkend='metadata'>Metadata</link>
- change that changes the task hash, automatically
- causing the task to be run again.
- This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
- values, and changes to Metadata automatically ripple across the build.
- </para>
-
- <para>
- It is also worth noting that the end result of these signature generators is to
- make some dependency and hash information available to the build.
- This information includes:
- <itemizedlist>
- <listitem><para><filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>:
- The base hashes for each task in the recipe.
- </para></listitem>
- <listitem><para><filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
- The base hashes for each dependent task.
- </para></listitem>
- <listitem><para><filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
- The task dependencies for each task.
- </para></listitem>
- <listitem><para><filename>BB_TASKHASH</filename>:
- The hash of the currently running task.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='shared-state'>
- <title>Shared State</title>
-
- <para>
- Checksums and dependencies, as discussed in the previous section, solve half the
- problem of supporting a shared state.
- The other part of the problem is being able to use checksum information during the build
- and being able to reuse or rebuild specific components.
- </para>
-
- <para>
- The
- <link linkend='ref-classes-sstate'><filename>sstate</filename></link>
- class is a relatively generic implementation of how to "capture"
- a snapshot of a given task.
- The idea is that the build process does not care about the source of a task's output.
- Output could be freshly built or it could be downloaded and unpacked from
- somewhere - the build process does not need to worry about its origin.
- </para>
-
- <para>
- There are two types of output, one is just about creating a directory
- in <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
- A good example is the output of either
- <link linkend='ref-tasks-install'><filename>do_install</filename></link>
- or
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>.
- The other type of output occurs when a set of data is merged into a shared directory
- tree such as the sysroot.
- </para>
-
- <para>
- The Yocto Project team has tried to keep the details of the
- implementation hidden in <filename>sstate</filename> class.
- From a user's perspective, adding shared state wrapping to a task
- is as simple as this
- <link linkend='ref-tasks-deploy'><filename>do_deploy</filename></link>
- example taken from the
- <link linkend='ref-classes-deploy'><filename>deploy</filename></link>
- class:
- <literallayout class='monospaced'>
- DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
- SSTATETASKS += "do_deploy"
- do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
- do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
-
- python do_deploy_setscene () {
- sstate_setscene(d)
- }
- addtask do_deploy_setscene
- do_deploy[dirs] = "${DEPLOYDIR} ${B}"
- </literallayout>
- The following list explains the previous example:
- <itemizedlist>
- <listitem><para>
- Adding "do_deploy" to <filename>SSTATETASKS</filename>
- adds some required sstate-related processing, which is
- implemented in the
- <link linkend='ref-classes-sstate'><filename>sstate</filename></link>
- class, to before and after the
- <link linkend='ref-tasks-deploy'><filename>do_deploy</filename></link>
- task.
- </para></listitem>
- <listitem><para>
- The
- <filename>do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"</filename>
- declares that <filename>do_deploy</filename> places its
- output in <filename>${DEPLOYDIR}</filename> when run
- normally (i.e. when not using the sstate cache).
- This output becomes the input to the shared state cache.
- </para></listitem>
- <listitem><para>
- The
- <filename>do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"</filename>
- line causes the contents of the shared state cache to be
- copied to <filename>${DEPLOY_DIR_IMAGE}</filename>.
- <note>
- If <filename>do_deploy</filename> is not already in
- the shared state cache or if its input checksum
- (signature) has changed from when the output was
- cached, the task will be run to populate the shared
- state cache, after which the contents of the shared
- state cache is copied to
- <filename>${DEPLOY_DIR_IMAGE}</filename>.
- If <filename>do_deploy</filename> is in the shared
- state cache and its signature indicates that the
- cached output is still valid (i.e. if no
- relevant task inputs have changed), then the contents
- of the shared state cache will be copied directly to
- <filename>${DEPLOY_DIR_IMAGE}</filename> by the
- <filename>do_deploy_setscene</filename> task instead,
- skipping the <filename>do_deploy</filename> task.
- </note>
- </para></listitem>
- <listitem><para>
- The following task definition is glue logic needed to make
- the previous settings effective:
- <literallayout class='monospaced'>
- python do_deploy_setscene () {
- sstate_setscene(d)
- }
- addtask do_deploy_setscene
- </literallayout>
- <filename>sstate_setscene()</filename> takes the flags
- above as input and accelerates the
- <filename>do_deploy</filename> task through the
- shared state cache if possible.
- If the task was accelerated,
- <filename>sstate_setscene()</filename> returns True.
- Otherwise, it returns False, and the normal
- <filename>do_deploy</filename> task runs.
- For more information, see the
- "<ulink url='&YOCTO_DOCS_BB_URL;#setscene'>setscene</ulink>"
- section in the BitBake User Manual.
- </para></listitem>
- <listitem><para>
- The <filename>do_deploy[dirs] = "${DEPLOYDIR} ${B}"</filename>
- line creates <filename>${DEPLOYDIR}</filename> and
- <filename>${B}</filename> before the
- <filename>do_deploy</filename> task runs, and also sets
- the current working directory of
- <filename>do_deploy</filename> to
- <filename>${B}</filename>.
- For more information, see the
- "<ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'>Variable Flags</ulink>"
- section in the BitBake User Manual.
- <note>
- In cases where
- <filename>sstate-inputdirs</filename> and
- <filename>sstate-outputdirs</filename> would be the
- same, you can use
- <filename>sstate-plaindirs</filename>.
- For example, to preserve the
- <filename>${PKGD}</filename> and
- <filename>${PKGDEST}</filename> output from the
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- task, use the following:
- <literallayout class='monospaced'>
- do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
- </literallayout>
- </note>
- </para></listitem>
- <listitem><para>
- <filename>sstate-inputdirs</filename> and
- <filename>sstate-outputdirs</filename> can also be used
- with multiple directories.
- For example, the following declares
- <filename>PKGDESTWORK</filename> and
- <filename>SHLIBWORK</filename> as shared state
- input directories, which populates the shared state
- cache, and <filename>PKGDATA_DIR</filename> and
- <filename>SHLIBSDIR</filename> as the corresponding
- shared state output directories:
- <literallayout class='monospaced'>
- do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
- do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
- </literallayout>
- </para></listitem>
- <listitem><para>
- These methods also include the ability to take a lockfile
- when manipulating shared state directory structures,
- for cases where file additions or removals are sensitive:
- <literallayout class='monospaced'>
- do_package[sstate-lockfile] = "${PACKAGELOCK}"
- </literallayout>
- </para></listitem>
- </itemizedlist>
- </para>
-
-<!--
- <para>
- In this example, we add some extra flags to the task, a name field ("deploy"), an
- input directory where the task sends data, and the output
- directory where the data from the task should eventually be copied.
- We also add a <filename>_setscene</filename> variant of the task and add the task
- name to the <filename>SSTATETASKS</filename> list.
- </para>
-
- <para>
- If you have a directory whose contents you need to preserve, you can do this with
- a line like the following:
- <literallayout class='monospaced'>
- do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
- </literallayout>
- This method, as well as the following example, also works for multiple directories.
- <literallayout class='monospaced'>
- do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
- do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
- do_package[sstate-lockfile] = "${PACKAGELOCK}"
- </literallayout>
- These methods also include the ability to take a lockfile when manipulating
- shared state directory structures since some cases are sensitive to file
- additions or removals.
- </para>
--->
-
- <para>
- Behind the scenes, the shared state code works by looking in
- <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> and
- <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
- for shared state files.
- Here is an example:
- <literallayout class='monospaced'>
- SSTATE_MIRRORS ?= "\
- file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
- file://.* file:///some/local/dir/sstate/PATH"
- </literallayout>
- <note>
- The shared state directory (<filename>SSTATE_DIR</filename>) is
- organized into two-character subdirectories, where the subdirectory
- names are based on the first two characters of the hash.
- If the shared state directory structure for a mirror has the
- same structure as <filename>SSTATE_DIR</filename>, you must
- specify "PATH" as part of the URI to enable the build system
- to map to the appropriate subdirectory.
- </note>
- </para>
-
- <para>
- The shared state package validity can be detected just by looking at the
- filename since the filename contains the task checksum (or signature) as
- described earlier in this section.
- If a valid shared state package is found, the build process downloads it
- and uses it to accelerate the task.
- </para>
-
- <para>
- The build processes use the <filename>*_setscene</filename> tasks
- for the task acceleration phase.
- BitBake goes through this phase before the main execution code and tries
- to accelerate any tasks for which it can find shared state packages.
- If a shared state package for a task is available, the shared state
- package is used.
- This means the task and any tasks on which it is dependent are not
- executed.
- </para>
-
- <para>
- As a real world example, the aim is when building an IPK-based image,
- only the
- <link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>
- tasks would have their
- shared state packages fetched and extracted.
- Since the sysroot is not used, it would never get extracted.
- This is another reason why a task-based approach is preferred over a
- recipe-based approach, which would have to install the output from every task.
- </para>
- </section>
-
- <section id='tips-and-tricks'>
- <title>Tips and Tricks</title>
-
- <para>
- The code in the build system that supports incremental builds is not
- simple code.
- This section presents some tips and tricks that help you work around
- issues related to shared state code.
- </para>
-
- <section id='debugging'>
- <title>Debugging</title>
-
- <para>
- Seeing what metadata went into creating the input signature
- of a shared state (sstate) task can be a useful debugging aid.
- This information is available in signature information
- (<filename>siginfo</filename>) files in
- <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>.
- For information on how to view and interpret information in
- <filename>siginfo</filename> files, see the
- "<link linkend='usingpoky-viewing-task-variable-dependencies'>Viewing Task Variable Dependencies</link>"
- section.
- </para>
- </section>
-
- <section id='invalidating-shared-state'>
- <title>Invalidating Shared State</title>
-
- <para>
- The OpenEmbedded build system uses checksums and shared state
- cache to avoid unnecessarily rebuilding tasks.
- Collectively, this scheme is known as "shared state code."
- </para>
-
- <para>
- As with all schemes, this one has some drawbacks.
- It is possible that you could make implicit changes to your
- code that the checksum calculations do not take into
- account.
- These implicit changes affect a task's output but do not trigger
- the shared state code into rebuilding a recipe.
- Consider an example during which a tool changes its output.
- Assume that the output of <filename>rpmdeps</filename> changes.
- The result of the change should be that all the
- <filename>package</filename> and
- <filename>package_write_rpm</filename> shared state cache
- items become invalid.
- However, because the change to the output is
- external to the code and therefore implicit,
- the associated shared state cache items do not become
- invalidated.
- In this case, the build process uses the cached items rather
- than running the task again.
- Obviously, these types of implicit changes can cause problems.
- </para>
-
- <para>
- To avoid these problems during the build, you need to
- understand the effects of any changes you make.
- Realize that changes you make directly to a function
- are automatically factored into the checksum calculation.
- Thus, these explicit changes invalidate the associated area of
- shared state cache.
- However, you need to be aware of any implicit changes that
- are not obvious changes to the code and could affect the output
- of a given task.
- </para>
-
- <para>
- When you identify an implicit change, you can easily take steps
- to invalidate the cache and force the tasks to run.
- The steps you can take are as simple as changing a function's
- comments in the source code.
- For example, to invalidate package shared state files, change
- the comment statements of
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- or the comments of one of the functions it calls.
- Even though the change is purely cosmetic, it causes the
- checksum to be recalculated and forces the OpenEmbedded build
- system to run the task again.
- </para>
-
- <note>
- For an example of a commit that makes a cosmetic change to
- invalidate shared state, see this
- <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
- </note>
- </section>
- </section>
-</section>
-
-<section id='automatically-added-runtime-dependencies'>
- <title>Automatically Added Runtime Dependencies</title>
-
- <para>
- The OpenEmbedded build system automatically adds common types of
- runtime dependencies between packages, which means that you do not
- need to explicitly declare the packages using
- <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
- Three automatic mechanisms exist (<filename>shlibdeps</filename>,
- <filename>pcdeps</filename>, and <filename>depchains</filename>) that
- handle shared libraries, package configuration (pkg-config) modules,
- and <filename>-dev</filename> and <filename>-dbg</filename> packages,
- respectively.
- For other types of runtime dependencies, you must manually declare
- the dependencies.
- <itemizedlist>
- <listitem><para>
- <filename>shlibdeps</filename>:
- During the
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- task of each recipe, all shared libraries installed by the
- recipe are located.
- For each shared library, the package that contains the shared
- library is registered as providing the shared library.
- More specifically, the package is registered as providing the
- <ulink url='https://en.wikipedia.org/wiki/Soname'>soname</ulink>
- of the library.
- The resulting shared-library-to-package mapping
- is saved globally in
- <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
- by the
- <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
- task.</para>
-
- <para>Simultaneously, all executables and shared libraries
- installed by the recipe are inspected to see what shared
- libraries they link against.
- For each shared library dependency that is found,
- <filename>PKGDATA_DIR</filename> is queried to
- see if some package (likely from a different recipe) contains
- the shared library.
- If such a package is found, a runtime dependency is added from
- the package that depends on the shared library to the package
- that contains the library.</para>
-
- <para>The automatically added runtime dependency also includes
- a version restriction.
- This version restriction specifies that at least the current
- version of the package that provides the shared library must be
- used, as if
- "<replaceable>package</replaceable> (>= <replaceable>version</replaceable>)"
- had been added to
- <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
- This forces an upgrade of the package containing the shared
- library when installing the package that depends on the
- library, if needed.</para>
-
- <para>If you want to avoid a package being registered as
- providing a particular shared library (e.g. because the library
- is for internal use only), then add the library to
- <link linkend='var-PRIVATE_LIBS'><filename>PRIVATE_LIBS</filename></link>
- inside the package's recipe.
- </para></listitem>
- <listitem><para>
- <filename>pcdeps</filename>:
- During the
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- task of each recipe, all pkg-config modules
- (<filename>*.pc</filename> files) installed by the recipe are
- located.
- For each module, the package that contains the module is
- registered as providing the module.
- The resulting module-to-package mapping is saved globally in
- <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
- by the
- <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
- task.</para>
-
- <para>Simultaneously, all pkg-config modules installed by the
- recipe are inspected to see what other pkg-config modules they
- depend on.
- A module is seen as depending on another module if it contains
- a "Requires:" line that specifies the other module.
- For each module dependency,
- <filename>PKGDATA_DIR</filename> is queried to see if some
- package contains the module.
- If such a package is found, a runtime dependency is added from
- the package that depends on the module to the package that
- contains the module.
- <note>
- The <filename>pcdeps</filename> mechanism most often infers
- dependencies between <filename>-dev</filename> packages.
- </note>
- </para></listitem>
- <listitem><para>
- <filename>depchains</filename>:
- If a package <filename>foo</filename> depends on a package
- <filename>bar</filename>, then <filename>foo-dev</filename>
- and <filename>foo-dbg</filename> are also made to depend on
- <filename>bar-dev</filename> and <filename>bar-dbg</filename>,
- respectively.
- Taking the <filename>-dev</filename> packages as an example,
- the <filename>bar-dev</filename> package might provide
- headers and shared library symlinks needed by
- <filename>foo-dev</filename>, which shows the need
- for a dependency between the packages.</para>
-
- <para>The dependencies added by <filename>depchains</filename>
- are in the form of
- <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>.
- <note>
- By default, <filename>foo-dev</filename> also has an
- <filename>RDEPENDS</filename>-style dependency on
- <filename>foo</filename>, because the default value of
- <filename>RDEPENDS_${PN}-dev</filename> (set in
- <filename>bitbake.conf</filename>) includes
- "${PN}".
- </note></para>
-
- <para>To ensure that the dependency chain is never broken,
- <filename>-dev</filename> and <filename>-dbg</filename>
- packages are always generated by default, even if the packages
- turn out to be empty.
- See the
- <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>
- variable for more information.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- The <filename>do_package</filename> task depends on the
- <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
- task of each recipe in
- <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
- through use of a
- <filename>[</filename><ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'><filename>deptask</filename></ulink><filename>]</filename>
- declaration, which guarantees that the required
- shared-library/module-to-package mapping information will be available
- when needed as long as <filename>DEPENDS</filename> has been
- correctly set.
- </para>
-</section>
-
-<section id='fakeroot-and-pseudo'>
- <title>Fakeroot and Pseudo</title>
-
- <para>
- Some tasks are easier to implement when allowed to perform certain
- operations that are normally reserved for the root user.
- For example, the
- <link linkend='ref-tasks-install'><filename>do_install</filename></link>
- task benefits from being able to set the UID and GID of installed files
- to arbitrary values.
- </para>
-
- <para>
- One approach to allowing tasks to perform root-only operations
- would be to require BitBake to run as root.
- However, this method is cumbersome and has security issues.
- The approach that is actually used is to run tasks that benefit from
- root privileges in a "fake" root environment.
- Within this environment, the task and its child processes believe that
- they are running as the root user, and see an internally consistent
- view of the filesystem.
- As long as generating the final output (e.g. a package or an image)
- does not require root privileges, the fact that some earlier steps ran
- in a fake root environment does not cause problems.
- </para>
-
- <para>
- The capability to run tasks in a fake root environment is known as
- "fakeroot", which is derived from the BitBake keyword/variable
- flag that requests a fake root environment for a task.
- In current versions of the OpenEmbedded build system,
- the program that implements fakeroot is known as Pseudo.
- </para>
-
- <para>
- Pseudo overrides system calls through the
- <filename>LD_PRELOAD</filename> mechanism to give the
- illusion of running as root.
- To keep track of "fake" file ownership and permissions resulting from
- operations that require root permissions, an sqlite3
- database is used.
- This database is stored in
- <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/pseudo/files.db</filename>
- for individual recipes.
- Storing the database in a file as opposed to in memory
- gives persistence between tasks, and even between builds.
- <note><title>Caution</title>
- If you add your own task that manipulates the same files or
- directories as a fakeroot task, then that task should also run
- under fakeroot.
- Otherwise, the task will not be able to run root-only operations,
- and will not see the fake file ownership and permissions set by the
- other task.
- You should also add a dependency on
- <filename>virtual/fakeroot-native:do_populate_sysroot</filename>,
- giving the following:
- <literallayout class='monospaced'>
- fakeroot do_mytask () {
- ...
- }
- do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"
- </literallayout>
- </note>
- For more information, see the
- <ulink url='&YOCTO_DOCS_BB_URL;#var-FAKEROOT'><filename>FAKEROOT*</filename></ulink>
- variables in the BitBake User Manual.
- You can also reference this
- <ulink url='http://www.ibm.com/developerworks/opensource/library/os-aapseudo1/index.html'>Pseudo</ulink>
- article.
- </para>
-</section>
-
-<section id='wic-plug-ins-interface'>
- <title>Wic Plug-Ins Interface</title>
-
- <para>
- You can extend and specialize Wic functionality by using
- Wic plug-ins.
- This section explains the Wic plug-in interface.
- For information on using Wic in general, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
- section in the Yocto Project Development Tasks Manual.
- <note>
- Wic plug-ins consist of "source" and "imager" plug-ins.
- Imager plug-ins are beyond the scope of this section.
- </note>
- </para>
-
- <para>
- Source plug-ins provide a mechanism to customize partition
- content during the Wic image generation process.
- You can use source plug-ins to map values that you specify
- using <filename>--source</filename> commands in kickstart
- files (i.e. <filename>*.wks</filename>) to a plug-in
- implementation used to populate a given partition.
- <note>
- If you use plug-ins that have build-time dependencies
- (e.g. native tools, bootloaders, and so forth)
- when building a Wic image, you need to specify those
- dependencies using the
- <link linkend='var-WKS_FILE_DEPENDS'><filename>WKS_FILE_DEPENDS</filename></link>
- variable.
- </note>
- </para>
-
- <para>
- Source plug-ins are subclasses defined in plug-in files.
- As shipped, the Yocto Project provides several plug-in
- files.
- You can see the source plug-in files that ship with the
- Yocto Project
- <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source'>here</ulink>.
- Each of these plug-in files contain source plug-ins that
- are designed to populate a specific Wic image partition.
- </para>
-
- <para>
- Source plug-ins are subclasses of the
- <filename>SourcePlugin</filename> class, which is
- defined in the
- <filename>poky/scripts/lib/wic/pluginbase.py</filename>
- file.
- For example, the <filename>BootimgEFIPlugin</filename>
- source plug-in found in the
- <filename>bootimg-efi.py</filename> file is a subclass of
- the <filename>SourcePlugin</filename> class, which is found
- in the <filename>pluginbase.py</filename> file.
- </para>
-
- <para>
- You can also implement source plug-ins in a layer outside
- of the Source Repositories (external layer).
- To do so, be sure that your plug-in files are located in
- a directory whose path is
- <filename>scripts/lib/wic/plugins/source/</filename>
- within your external layer.
- When the plug-in files are located there, the source
- plug-ins they contain are made available to Wic.
- </para>
-
- <para>
- When the Wic implementation needs to invoke a
- partition-specific implementation, it looks for the plug-in
- with the same name as the <filename>--source</filename>
- parameter used in the kickstart file given to that
- partition.
- For example, if the partition is set up using the following
- command in a kickstart file:
- <literallayout class='monospaced'>
- part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024
- </literallayout>
- The methods defined as class members of the matching
- source plug-in (i.e. <filename>bootimg-pcbios</filename>)
- in the <filename>bootimg-pcbios.py</filename> plug-in file
- are used.
- </para>
-
- <para>
- To be more concrete, here is the corresponding plug-in
- definition from the <filename>bootimg-pcbios.py</filename>
- file for the previous command along with an example
- method called by the Wic implementation when it needs to
- prepare a partition using an implementation-specific
- function:
- <literallayout class='monospaced'>
- bootimg-pcbios.py
- .
- .
- .
- class BootimgPcbiosPlugin(SourcePlugin):
- """
- Create MBR boot partition and install syslinux on it.
- """
-
- name = 'bootimg-pcbios'
- .
- .
- .
- @classmethod
- def do_prepare_partition(cls, part, source_params, creator, cr_workdir,
- oe_builddir, bootimg_dir, kernel_dir,
- rootfs_dir, native_sysroot):
- """
- Called to do the actual content population for a partition i.e. it
- 'prepares' the partition to be incorporated into the image.
- In this case, prepare content for legacy bios boot partition.
- """
- .
- .
- .
- </literallayout>
- If a subclass (plug-in) itself does not implement a
- particular function, Wic locates and uses the default
- version in the superclass.
- It is for this reason that all source plug-ins are derived
- from the <filename>SourcePlugin</filename> class.
- </para>
-
- <para>
- The <filename>SourcePlugin</filename> class defined in
- the <filename>pluginbase.py</filename> file defines
- a set of methods that source plug-ins can implement or
- override.
- Any plug-ins (subclass of
- <filename>SourcePlugin</filename>) that do not implement
- a particular method inherit the implementation of the
- method from the <filename>SourcePlugin</filename> class.
- For more information, see the
- <filename>SourcePlugin</filename> class in the
- <filename>pluginbase.py</filename> file for details:
- </para>
-
- <para>
- The following list describes the methods implemented in the
- <filename>SourcePlugin</filename> class:
- <itemizedlist>
- <listitem><para>
- <emphasis><filename>do_prepare_partition()</filename>:</emphasis>
- Called to populate a partition with actual content.
- In other words, the method prepares the final
- partition image that is incorporated into the
- disk image.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>do_configure_partition()</filename>:</emphasis>
- Called before
- <filename>do_prepare_partition()</filename> to
- create custom configuration files for a partition
- (e.g. syslinux or grub configuration files).
- </para></listitem>
- <listitem><para>
- <emphasis><filename>do_install_disk()</filename>:</emphasis>
- Called after all partitions have been prepared and
- assembled into a disk image.
- This method provides a hook to allow finalization
- of a disk image (e.g. writing an MBR).
- </para></listitem>
- <listitem><para>
- <emphasis><filename>do_stage_partition()</filename>:</emphasis>
- Special content-staging hook called before
- <filename>do_prepare_partition()</filename>.
- This method is normally empty.</para>
-
- <para>Typically, a partition just uses the passed-in
- parameters (e.g. the unmodified value of
- <filename>bootimg_dir</filename>).
- However, in some cases, things might need to be
- more tailored.
- As an example, certain files might additionally
- need to be taken from
- <filename>bootimg_dir + /boot</filename>.
- This hook allows those files to be staged in a
- customized fashion.
- <note>
- <filename>get_bitbake_var()</filename>
- allows you to access non-standard variables
- that you might want to use for this
- behavior.
- </note>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- You can extend the source plug-in mechanism.
- To add more hooks, create more source plug-in methods
- within <filename>SourcePlugin</filename> and the
- corresponding derived subclasses.
- The code that calls the plug-in methods uses the
- <filename>plugin.get_source_plugin_methods()</filename>
- function to find the method or methods needed by the call.
- Retrieval of those methods is accomplished by filling up
- a dict with keys that contain the method names of interest.
- On success, these will be filled in with the actual
- methods.
- See the Wic implementation for examples and details.
- </para>
-</section>
-
-<section id='x32'>
- <title>x32</title>
-
- <para>
- x32 is a processor-specific Application Binary Interface (psABI) for x86_64.
- An ABI defines the calling conventions between functions in a processing environment.
- The interface determines what registers are used and what the sizes are for various C data types.
- </para>
-
- <para>
- Some processing environments prefer using 32-bit applications even when running
- on Intel 64-bit platforms.
- Consider the i386 psABI, which is a very old 32-bit ABI for Intel 64-bit platforms.
- The i386 psABI does not provide efficient use and access of the Intel 64-bit processor resources,
- leaving the system underutilized.
- Now consider the x86_64 psABI.
- This ABI is newer and uses 64-bits for data sizes and program pointers.
- The extra bits increase the footprint size of the programs, libraries,
- and also increases the memory and file system size requirements.
- Executing under the x32 psABI enables user programs to utilize CPU and system resources
- more efficiently while keeping the memory footprint of the applications low.
- Extra bits are used for registers but not for addressing mechanisms.
- </para>
-
- <section id='support'>
- <title>Support</title>
-
- <para>
- This Yocto Project release supports the final specifications of x32
- psABI.
- Support for x32 psABI exists as follows:
- <itemizedlist>
- <listitem><para>You can create packages and images in x32 psABI format on x86_64 architecture targets.
- </para></listitem>
- <listitem><para>You can successfully build many recipes with the x32 toolchain.</para></listitem>
- <listitem><para>You can create and boot <filename>core-image-minimal</filename> and
- <filename>core-image-sato</filename> images.</para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='completing-x32'>
- <title>Completing x32</title>
-
- <para>
- Future Plans for the x32 psABI in the Yocto Project include the following:
- <itemizedlist>
- <listitem><para>Enhance and fix the few remaining recipes so they
- work with and support x32 toolchains.</para></listitem>
- <listitem><para>Enhance RPM Package Manager (RPM) support for x32 binaries.</para></listitem>
- <listitem><para>Support larger images.</para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='using-x32-right-now'>
- <title>Using x32 Right Now</title>
-
- <para>
- Follow these steps to use the x32 spABI:
- <itemizedlist>
- <listitem><para>Enable the x32 psABI tuning file for <filename>x86_64</filename>
- machines by editing the <filename>conf/local.conf</filename> like this:
- <literallayout class='monospaced'>
- MACHINE = "qemux86-64"
- DEFAULTTUNE = "x86-64-x32"
- baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
- or 'INVALID'), True) or 'lib'}"
- #MACHINE = "genericx86"
- #DEFAULTTUNE = "core2-64-x32"
- </literallayout></para></listitem>
- <listitem><para>As usual, use BitBake to build an image that supports the x32 psABI.
- Here is an example:
- <literallayout class='monospaced'>
- $ bitbake core-image-sato
- </literallayout></para></listitem>
- <listitem><para>As usual, run your image using QEMU:
- <literallayout class='monospaced'>
- $ runqemu qemux86-64 core-image-sato
- </literallayout></para></listitem>
- </itemizedlist>
- </para>
- </section>
-</section>
-
-<section id="wayland">
- <title>Wayland</title>
-
- <para>
- <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)'>Wayland</ulink>
- is a computer display server protocol that
- provides a method for compositing window managers to communicate
- directly with applications and video hardware and expects them to
- communicate with input hardware using other libraries.
- Using Wayland with supporting targets can result in better control
- over graphics frame rendering than an application might otherwise
- achieve.
- </para>
-
- <para>
- The Yocto Project provides the Wayland protocol libraries and the
- reference
- <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Weston</ulink>
- compositor as part of its release.
- This section describes what you need to do to implement Wayland and
- use the compositor when building an image for a supporting target.
- </para>
-
- <section id="wayland-support">
- <title>Support</title>
-
- <para>
- The Wayland protocol libraries and the reference Weston compositor
- ship as integrated packages in the <filename>meta</filename> layer
- of the
- <link linkend='source-directory'>Source Directory</link>.
- Specifically, you can find the recipes that build both Wayland
- and Weston at <filename>meta/recipes-graphics/wayland</filename>.
- </para>
-
- <para>
- You can build both the Wayland and Weston packages for use only
- with targets that accept the
- <ulink url='http://dri.freedesktop.org/wiki/'>Mesa 3D and Direct Rendering Infrastructure</ulink>,
- which is also known as Mesa DRI.
- This implies that you cannot build and use the packages if your
- target uses, for example, the
- <trademark class='registered'>Intel</trademark> Embedded Media and
- Graphics Driver (<trademark class='registered'>Intel</trademark>
- EMGD) that overrides Mesa DRI.
- </para>
-
- <note>
- Due to lack of EGL support, Weston 1.0.3 will not run directly on
- the emulated QEMU hardware.
- However, this version of Weston will run under X emulation without
- issues.
- </note>
- </section>
-
- <section id="enabling-wayland-in-an-image">
- <title>Enabling Wayland in an Image</title>
-
- <para>
- To enable Wayland, you need to enable it to be built and enable
- it to be included in the image.
- </para>
-
- <section id="enable-building">
- <title>Building</title>
-
- <para>
- To cause Mesa to build the <filename>wayland-egl</filename>
- platform and Weston to build Wayland with Kernel Mode
- Setting
- (<ulink url='https://wiki.archlinux.org/index.php/Kernel_Mode_Setting'>KMS</ulink>)
- support, include the "wayland" flag in the
- <link linkend="var-DISTRO_FEATURES"><filename>DISTRO_FEATURES</filename></link>
- statement in your <filename>local.conf</filename> file:
- <literallayout class='monospaced'>
- DISTRO_FEATURES_append = " wayland"
- </literallayout>
- </para>
-
- <note>
- If X11 has been enabled elsewhere, Weston will build Wayland
- with X11 support
- </note>
- </section>
-
- <section id="enable-installation-in-an-image">
- <title>Installing</title>
-
- <para>
- To install the Wayland feature into an image, you must
- include the following
- <link linkend='var-CORE_IMAGE_EXTRA_INSTALL'><filename>CORE_IMAGE_EXTRA_INSTALL</filename></link>
- statement in your <filename>local.conf</filename> file:
- <literallayout class='monospaced'>
- CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
- </literallayout>
- </para>
- </section>
- </section>
-
- <section id="running-weston">
- <title>Running Weston</title>
-
- <para>
- To run Weston inside X11, enabling it as described earlier and
- building a Sato image is sufficient.
- If you are running your image under Sato, a Weston Launcher appears
- in the "Utility" category.
- </para>
-
- <para>
- Alternatively, you can run Weston through the command-line
- interpretor (CLI), which is better suited for development work.
- To run Weston under the CLI, you need to do the following after
- your image is built:
- <orderedlist>
- <listitem><para>Run these commands to export
- <filename>XDG_RUNTIME_DIR</filename>:
- <literallayout class='monospaced'>
- mkdir -p /tmp/$USER-weston
- chmod 0700 /tmp/$USER-weston
- export XDG_RUNTIME_DIR=/tmp/$USER-weston
- </literallayout></para></listitem>
- <listitem><para>Launch Weston in the shell:
- <literallayout class='monospaced'>
- weston
- </literallayout></para></listitem>
- </orderedlist>
- </para>
- </section>
-</section>
-
-<section id="licenses">
- <title>Licenses</title>
-
- <para>
- This section describes the mechanism by which the OpenEmbedded build system
- tracks changes to licensing text.
- The section also describes how to enable commercially licensed recipes,
- which by default are disabled.
- </para>
-
- <para>
- For information that can help you maintain compliance with various open
- source licensing during the lifecycle of the product, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para>
-
- <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
- <title>Tracking License Changes</title>
-
- <para>
- The license of an upstream project might change in the future.
- In order to prevent these changes going unnoticed, the
- <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
- variable tracks changes to the license text. The checksums are validated at the end of the
- configure step, and if the checksums do not match, the build will fail.
- </para>
-
- <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
- <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
-
- <para>
- The <filename>LIC_FILES_CHKSUM</filename>
- variable contains checksums of the license text in the source
- code for the recipe.
- Following is an example of how to specify
- <filename>LIC_FILES_CHKSUM</filename>:
- <literallayout class='monospaced'>
- LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
- file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
- file://licfile2.txt;endline=50;md5=zzzz \
- ..."
- </literallayout>
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- When using "beginline" and "endline", realize that
- line numbering begins with one and not zero.
- Also, the included lines are inclusive (i.e. lines
- five through and including 29 in the previous
- example for <filename>licfile1.txt</filename>).
- </para></listitem>
- <listitem><para>
- When a license check fails, the selected license
- text is included as part of the QA message.
- Using this output, you can determine the exact
- start and finish for the needed license text.
- </para></listitem>
- </itemizedlist>
- </note>
- </para>
-
- <para>
- The build system uses the
- <filename><link linkend='var-S'>S</link></filename> variable as
- the default directory when searching files listed in
- <filename>LIC_FILES_CHKSUM</filename>.
- The previous example employs the default directory.
- </para>
-
- <para>
- Consider this next example:
- <literallayout class='monospaced'>
- LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
- md5=bb14ed3c4cda583abc85401304b5cd4e"
- LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
- </literallayout>
- </para>
-
- <para>
- The first line locates a file in
- <filename>${S}/src/ls.c</filename> and isolates lines five
- through 16 as license text.
- The second line refers to a file in
- <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
- </para>
- <para>
- Note that <filename>LIC_FILES_CHKSUM</filename> variable is
- mandatory for all recipes, unless the
- <filename>LICENSE</filename> variable is set to "CLOSED".
- </para>
- </section>
-
- <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
- <title>Explanation of Syntax</title>
- <para>
- As mentioned in the previous section, the
- <filename>LIC_FILES_CHKSUM</filename> variable lists all the
- important files that contain the license text for the source code.
- It is possible to specify a checksum for an entire file, or a specific section of a
- file (specified by beginning and ending line numbers with the "beginline" and "endline"
- parameters, respectively).
- The latter is useful for source files with a license notice header,
- README documents, and so forth.
- If you do not use the "beginline" parameter, then it is assumed that the text begins on the
- first line of the file.
- Similarly, if you do not use the "endline" parameter, it is assumed that the license text
- ends with the last line of the file.
- </para>
-
- <para>
- The "md5" parameter stores the md5 checksum of the license text.
- If the license text changes in any way as compared to this parameter
- then a mismatch occurs.
- This mismatch triggers a build failure and notifies the developer.
- Notification allows the developer to review and address the license text changes.
- Also note that if a mismatch occurs during the build, the correct md5
- checksum is placed in the build log and can be easily copied to the recipe.
- </para>
-
- <para>
- There is no limit to how many files you can specify using the
- <filename>LIC_FILES_CHKSUM</filename> variable.
- Generally, however, every project requires a few specifications for license tracking.
- Many projects have a "COPYING" file that stores the license information for all the source
- code files.
- This practice allows you to just track the "COPYING" file as long as it is kept up to date.
- </para>
-
- <tip>
- If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
- error and displays the correct "md5" parameter value during the build.
- The correct parameter is also captured in the build log.
- </tip>
-
- <tip>
- If the whole file contains only license text, you do not need to use the "beginline" and
- "endline" parameters.
- </tip>
- </section>
- </section>
-
- <section id="enabling-commercially-licensed-recipes">
- <title>Enabling Commercially Licensed Recipes</title>
-
- <para>
- By default, the OpenEmbedded build system disables
- components that have commercial or other special licensing
- requirements.
- Such requirements are defined on a
- recipe-by-recipe basis through the
- <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
- variable definition in the affected recipe.
- For instance, the
- <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
- recipe contains the following statement:
- <literallayout class='monospaced'>
- LICENSE_FLAGS = "commercial"
- </literallayout>
- Here is a slightly more complicated example that contains both an
- explicit recipe name and version (after variable expansion):
- <literallayout class='monospaced'>
- LICENSE_FLAGS = "license_${PN}_${PV}"
- </literallayout>
- In order for a component restricted by a <filename>LICENSE_FLAGS</filename>
- definition to be enabled and included in an image, it
- needs to have a matching entry in the global
- <link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link>
- variable, which is a variable
- typically defined in your <filename>local.conf</filename> file.
- For example, to enable
- the <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
- package, you could add either the string
- "commercial_gst-plugins-ugly" or the more general string
- "commercial" to <filename>LICENSE_FLAGS_WHITELIST</filename>.
- See the
- "<link linkend='license-flag-matching'>License Flag Matching</link>" section
- for a full explanation of how <filename>LICENSE_FLAGS</filename> matching works.
- Here is the example:
- <literallayout class='monospaced'>
- LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
- </literallayout>
- Likewise, to additionally enable the package built from the recipe containing
- <filename>LICENSE_FLAGS = "license_${PN}_${PV}"</filename>, and assuming
- that the actual recipe name was <filename>emgd_1.10.bb</filename>,
- the following string would enable that package as well as
- the original <filename>gst-plugins-ugly</filename> package:
- <literallayout class='monospaced'>
- LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
- </literallayout>
- As a convenience, you do not need to specify the complete license string
- in the whitelist for every package.
- You can use an abbreviated form, which consists
- of just the first portion or portions of the license string before
- the initial underscore character or characters.
- A partial string will match
- any license that contains the given string as the first
- portion of its license.
- For example, the following
- whitelist string will also match both of the packages
- previously mentioned as well as any other packages that have
- licenses starting with "commercial" or "license".
- <literallayout class='monospaced'>
- LICENSE_FLAGS_WHITELIST = "commercial license"
- </literallayout>
- </para>
-
- <section id="license-flag-matching">
- <title>License Flag Matching</title>
-
- <para>
- License flag matching allows you to control what recipes the
- OpenEmbedded build system includes in the build.
- Fundamentally, the build system attempts to match
- <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
- strings found in recipes against
- <link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link>
- strings found in the whitelist.
- A match causes the build system to include a recipe in the
- build, while failure to find a match causes the build system to
- exclude a recipe.
- </para>
-
- <para>
- In general, license flag matching is simple.
- However, understanding some concepts will help you
- correctly and effectively use matching.
- </para>
-
- <para>
- Before a flag
- defined by a particular recipe is tested against the
- contents of the whitelist, the expanded string
- <filename>_${PN}</filename> is appended to the flag.
- This expansion makes each <filename>LICENSE_FLAGS</filename>
- value recipe-specific.
- After expansion, the string is then matched against the
- whitelist.
- Thus, specifying
- <filename>LICENSE_FLAGS = "commercial"</filename>
- in recipe "foo", for example, results in the string
- <filename>"commercial_foo"</filename>.
- And, to create a match, that string must appear in the
- whitelist.
- </para>
-
- <para>
- Judicious use of the <filename>LICENSE_FLAGS</filename>
- strings and the contents of the
- <filename>LICENSE_FLAGS_WHITELIST</filename> variable
- allows you a lot of flexibility for including or excluding
- recipes based on licensing.
- For example, you can broaden the matching capabilities by
- using license flags string subsets in the whitelist.
- <note>When using a string subset, be sure to use the part of
- the expanded string that precedes the appended underscore
- character (e.g. <filename>usethispart_1.3</filename>,
- <filename>usethispart_1.4</filename>, and so forth).
- </note>
- For example, simply specifying the string "commercial" in
- the whitelist matches any expanded
- <filename>LICENSE_FLAGS</filename> definition that starts with
- the string "commercial" such as "commercial_foo" and
- "commercial_bar", which are the strings the build system
- automatically generates for hypothetical recipes named
- "foo" and "bar" assuming those recipes simply specify the
- following:
- <literallayout class='monospaced'>
- LICENSE_FLAGS = "commercial"
- </literallayout>
- Thus, you can choose to exhaustively
- enumerate each license flag in the whitelist and
- allow only specific recipes into the image, or
- you can use a string subset that causes a broader range of
- matches to allow a range of recipes into the image.
- </para>
-
- <para>
- This scheme works even if the
- <filename>LICENSE_FLAGS</filename> string already
- has <filename>_${PN}</filename> appended.
- For example, the build system turns the license flag
- "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
- match both the general "commercial" and the specific
- "commercial_1.2_foo" strings found in the whitelist, as
- expected.
- </para>
-
- <para>
- Here are some other scenarios:
- <itemizedlist>
- <listitem><para>You can specify a versioned string in the
- recipe such as "commercial_foo_1.2" in a "foo" recipe.
- The build system expands this string to
- "commercial_foo_1.2_foo".
- Combine this license flag with a whitelist that has
- the string "commercial" and you match the flag along
- with any other flag that starts with the string
- "commercial".</para></listitem>
- <listitem><para>Under the same circumstances, you can
- use "commercial_foo" in the whitelist and the
- build system not only matches "commercial_foo_1.2" but
- also matches any license flag with the string
- "commercial_foo", regardless of the version.
- </para></listitem>
- <listitem><para>You can be very specific and use both the
- package and version parts in the whitelist (e.g.
- "commercial_foo_1.2") to specifically match a
- versioned recipe.</para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id="other-variables-related-to-commercial-licenses">
- <title>Other Variables Related to Commercial Licenses</title>
-
- <para>
- Other helpful variables related to commercial
- license handling exist and are defined in the
- <filename>poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
- <literallayout class='monospaced'>
- COMMERCIAL_AUDIO_PLUGINS ?= ""
- COMMERCIAL_VIDEO_PLUGINS ?= ""
- </literallayout>
- If you want to enable these components, you can do so by making sure you have
- statements similar to the following
- in your <filename>local.conf</filename> configuration file:
- <literallayout class='monospaced'>
- COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
- gst-plugins-ugly-mpegaudioparse"
- COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
- gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
- LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
- </literallayout>
- Of course, you could also create a matching whitelist
- for those components using the more general "commercial"
- in the whitelist, but that would also enable all the
- other packages with
- <link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
- containing "commercial", which you may or may not want:
- <literallayout class='monospaced'>
- LICENSE_FLAGS_WHITELIST = "commercial"
- </literallayout>
- </para>
-
- <para>
- Specifying audio and video plug-ins as part of the
- <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and
- <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements
- (along with the enabling
- <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
- plug-ins or components into built images, thus adding
- support for media formats or components.
- </para>
- </section>
- </section>
-</section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
diff --git a/import-layers/yocto-poky/documentation/ref-manual/usingpoky.xml b/import-layers/yocto-poky/documentation/ref-manual/usingpoky.xml
deleted file mode 100644
index 13d9ad6..0000000
--- a/import-layers/yocto-poky/documentation/ref-manual/usingpoky.xml
+++ /dev/null
@@ -1,2091 +0,0 @@
-<!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='usingpoky'>
-<title>Using the Yocto Project</title>
-
- <para>
- This chapter describes common usage for the Yocto Project.
- The information is introductory in nature as other manuals in the Yocto Project
- documentation set provide more details on how to use the Yocto Project.
- </para>
-
-<section id='usingpoky-build'>
- <title>Running a Build</title>
-
- <para>
- This section provides a summary of the build process and provides information
- for less obvious aspects of the build process.
- For general information on how to build an image using the OpenEmbedded build
- system, see the
- "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
- section of the Yocto Project Quick Start.
- </para>
-
- <section id='build-overview'>
- <title>Build Overview</title>
-
- <para>
- In the development environment you will need to build an image whenever you change hardware
- support, add or change system libraries, or add or change services that have dependencies.
- </para>
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="figures/building-an-image.png" format="PNG" align='center' scalefit='1'/>
- </imageobject>
- <caption>
- <para>Building an Image</para>
- </caption>
- </mediaobject>
-
- <para>
- The first thing you need to do is set up the OpenEmbedded build
- environment by sourcing the environment setup script
- (i.e.
- <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>).
- Here is an example:
- <literallayout class='monospaced'>
- $ source &OE_INIT_FILE; [<replaceable>build_dir</replaceable>]
- </literallayout>
- </para>
-
- <para>
- The <replaceable>build_dir</replaceable> argument is optional and specifies the directory the
- OpenEmbedded build system uses for the build -
- the
- <link linkend='build-directory'>Build Directory</link>.
- If you do not specify a Build Directory, it defaults to a directory
- named <filename>build</filename> in your current working directory.
- A common practice is to use a different Build Directory for different targets.
- For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
- target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
- </para>
-
- <para>
- Once the build environment is set up, you can build a target using:
- <literallayout class='monospaced'>
- $ bitbake <replaceable>target</replaceable>
- </literallayout>
- <note>
- <para>
- If you experience a build error due to resources
- temporarily being unavailable and it appears you
- should not be having this issue, it might be due
- to the combination of a 4.3+ Linux kernel and
- <filename>systemd</filename> version 228+
- (i.e. see this
- <ulink url='http://unix.stackexchange.com/questions/253903/creating-threads-fails-with-resource-temporarily-unavailable-with-4-3-kernel'>link</ulink>
- for information).
- </para>
-
- <para>
- To work around this issue, you can try either
- of the following:
- <itemizedlist>
- <listitem><para>
- Try the build again.
- </para></listitem>
- <listitem><para>
- Modify the "DefaultTasksMax"
- <filename>systemd</filename> parameter
- by uncommenting it and setting it to
- "infinity".
- You can find this parameter in the
- <filename>system.conf</filename> file
- located in
- <filename>/etc/systemd</filename>
- on most systems.
- </para></listitem>
- </itemizedlist>
- </para>
- </note>
- </para>
-
- <para>
- The <replaceable>target</replaceable> is the name of the recipe you want to build.
- Common targets are the images in <filename>meta/recipes-core/images</filename>,
- <filename>meta/recipes-sato/images</filename>, etc. all found in the
- <link linkend='source-directory'>Source Directory</link>.
- Or, the target can be the name of a recipe for a specific piece of software such as
- BusyBox.
- For more details about the images the OpenEmbedded build system supports, see the
- "<link linkend="ref-images">Images</link>" chapter.
- </para>
-
- <note>
- Building an image without GNU General Public License Version
- 3 (GPLv3), or similarly licensed, components is supported for
- only minimal and base images.
- See the "<link linkend='ref-images'>Images</link>" chapter for more information.
- </note>
- </section>
-
- <section id='building-an-image-using-gpl-components'>
- <title>Building an Image Using GPL Components</title>
-
- <para>
- When building an image using GPL components, you need to maintain your original
- settings and not switch back and forth applying different versions of the GNU
- General Public License.
- If you rebuild using different versions of GPL, dependency errors might occur
- due to some components not being rebuilt.
- </para>
- </section>
-</section>
-
-<section id='usingpoky-install'>
- <title>Installing and Using the Result</title>
-
- <para>
- Once an image has been built, it often needs to be installed.
- The images and kernels built by the OpenEmbedded build system are placed in the
- <link linkend='build-directory'>Build Directory</link> in
- <filename class="directory">tmp/deploy/images</filename>.
- For information on how to run pre-built images such as <filename>qemux86</filename>
- and <filename>qemuarm</filename>, see the
- <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
- manual.
- For information about how to install these images, see the documentation for your
- particular board or machine.
- </para>
-</section>
-
-<section id='usingpoky-debugging-tools-and-techniques'>
- <title>Debugging Tools and Techniques</title>
-
- <para>
- The exact method for debugging build failures depends on the nature of
- the problem and on the system's area from which the bug originates.
- Standard debugging practices such as comparison against the last
- known working version with examination of the changes and the
- re-application of steps to identify the one causing the problem are
- valid for the Yocto Project just as they are for any other system.
- Even though it is impossible to detail every possible potential failure,
- this section provides some general tips to aid in debugging.
- </para>
-
- <para>
- A useful feature for debugging is the error reporting tool.
- Configuring the Yocto Project to use this tool causes the
- OpenEmbedded build system to produce error reporting commands as
- part of the console output.
- You can enter the commands after the build completes
- to log error information
- into a common database, that can help you figure out what might be
- going wrong.
- For information on how to enable and use this feature, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool'>Using the Error Reporting Tool</ulink>"
- section in the Yocto Project Development Tasks Manual.
- </para>
-
- <para>
- For discussions on debugging, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>" section
- in the Yocto Project Development Tasks Manual
- and the
- "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working within Eclipse</ulink>"
- section in the Yocto Project Application Development and the
- Extensible Software Development Kit (eSDK) manual.
- </para>
-
- <note>
- The remainder of this section presents many examples of the
- <filename>bitbake</filename> command.
- You can learn about BitBake by reading the
- <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
- </note>
-
- <section id='usingpoky-debugging-viewing-logs-from-failed-tasks'>
- <title>Viewing Logs from Failed Tasks</title>
-
- <para>
- You can find the log for a task in the file
- <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/temp/log.do_</filename><replaceable>taskname</replaceable>.
- For example, the log for the
- <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
- task of the QEMU minimal image for the x86 machine
- (<filename>qemux86</filename>) might be in
- <filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile</filename>.
- To see the commands
- <link linkend='bitbake-term'>BitBake</link> ran
- to generate a log, look at the corresponding
- <filename>run.do_</filename><replaceable>taskname</replaceable>
- file in the same directory.
- </para>
-
- <para>
- <filename>log.do_</filename><replaceable>taskname</replaceable> and
- <filename>run.do_</filename><replaceable>taskname</replaceable>
- are actually symbolic links to
- <filename>log.do_</filename><replaceable>taskname</replaceable><filename>.</filename><replaceable>pid</replaceable>
- and
- <filename>log.run_</filename><replaceable>taskname</replaceable><filename>.</filename><replaceable>pid</replaceable>,
- where <replaceable>pid</replaceable> is the PID the task had when
- it ran.
- The symlinks always point to the files corresponding to the most
- recent run.
- </para>
- </section>
-
- <section id='usingpoky-debugging-viewing-variable-values'>
- <title>Viewing Variable Values</title>
- <para>
- BitBake's <filename>-e</filename> option is used to display
- variable values after parsing.
- The following command displays the variable values after the
- configuration files (i.e. <filename>local.conf</filename>,
- <filename>bblayers.conf</filename>,
- <filename>bitbake.conf</filename> and so forth) have been
- parsed:
- <literallayout class='monospaced'>
- $ bitbake -e
- </literallayout>
- The following command displays variable values after a specific
- recipe has been parsed.
- The variables include those from the configuration as well:
- <literallayout class='monospaced'>
- $ bitbake -e recipename
- </literallayout>
- <note><para>
- Each recipe has its own private set of variables (datastore).
- Internally, after parsing the configuration, a copy of the
- resulting datastore is made prior to parsing each recipe.
- This copying implies that variables set in one recipe will
- not be visible to other recipes.</para>
-
- <para>Likewise, each task within a recipe gets a private
- datastore based on the recipe datastore, which means that
- variables set within one task will not be visible to
- other tasks.</para>
- </note>
- </para>
-
- <para>
- In the output of <filename>bitbake -e</filename>, each variable is
- preceded by a description of how the variable got its value,
- including temporary values that were later overriden.
- This description also includes variable flags (varflags) set on
- the variable.
- The output can be very helpful during debugging.
- </para>
-
- <para>
- Variables that are exported to the environment are preceded by
- <filename>export</filename> in the output of
- <filename>bitbake -e</filename>.
- See the following example:
- <literallayout class='monospaced'>
- export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/ulf/poky/build/tmp/sysroots/qemux86"
- </literallayout>
- </para>
-
- <para>
- In addition to variable values, the output of the
- <filename>bitbake -e</filename> and
- <filename>bitbake -e</filename> <replaceable>recipe</replaceable>
- commands includes the following information:
- <itemizedlist>
- <listitem><para>
- The output starts with a tree listing all configuration
- files and classes included globally, recursively listing
- the files they include or inherit in turn.
- Much of the behavior of the OpenEmbedded build system
- (including the behavior of the
- <link linkend='normal-recipe-build-tasks'>normal recipe build tasks</link>)
- is implemented in the
- <link linkend='ref-classes-base'><filename>base</filename></link>
- class and the classes it inherits, rather than being built
- into BitBake itself.
- </para></listitem>
- <listitem><para>
- After the variable values, all functions appear in the
- output.
- For shell functions, variables referenced within the
- function body are expanded.
- If a function has been modified using overrides or
- using override-style operators like
- <filename>_append</filename> and
- <filename>_prepend</filename>, then the final assembled
- function body appears in the output.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='viewing-package-information-with-oe-pkgdata-util'>
- <title>Viewing Package Information with <filename>oe-pkgdata-util</filename></title>
-
- <para>
- You can use the <filename>oe-pkgdata-util</filename> command-line
- utility to query
- <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
- and display various package-related information.
- When you use the utility, you must use it to view information
- on packages that have already been built.
- </para>
-
- <para>
- Following are a few of the available
- <filename>oe-pkgdata-util</filename> subcommands.
- <note>
- You can use the standard * and ? globbing wildcards as part of
- package names and paths.
- </note>
- <itemizedlist>
- <listitem><para>
- <filename>oe-pkgdata-util list-pkgs [</filename><replaceable>pattern</replaceable><filename>]</filename>:
- Lists all packages that have been built, optionally
- limiting the match to packages that match
- <replaceable>pattern</replaceable>.
- </para></listitem>
- <listitem><para>
- <filename>oe-pkgdata-util list-pkg-files </filename><replaceable>package</replaceable><filename> ...</filename>:
- Lists the files and directories contained in the given
- packages.
- <note>
- <para>
- A different way to view the contents of a package is
- to look at the
- <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/packages-split</filename>
- directory of the recipe that generates the
- package.
- This directory is created by the
- <link linkend='ref-tasks-package'><filename>do_package</filename></link>
- task and has one subdirectory for each package the
- recipe generates, which contains the files stored in
- that package.</para>
- <para>
- If you want to inspect the
- <filename>${WORKDIR}/packages-split</filename>
- directory, make sure that
- <link linkend='ref-classes-rm-work'><filename>rm_work</filename></link>
- is not enabled when you build the recipe.
- </para>
- </note>
- </para></listitem>
- <listitem><para>
- <filename>oe-pkgdata-util find-path </filename><replaceable>path</replaceable><filename> ...</filename>:
- Lists the names of the packages that contain the given
- paths.
- For example, the following tells us that
- <filename>/usr/share/man/man1/make.1</filename>
- is contained in the <filename>make-doc</filename>
- package:
- <literallayout class='monospaced'>
- $ oe-pkgdata-util find-path /usr/share/man/man1/make.1
- make-doc: /usr/share/man/man1/make.1
- </literallayout>
- </para></listitem>
- <listitem><para>
- <filename>oe-pkgdata-util lookup-recipe </filename><replaceable>package</replaceable><filename> ...</filename>:
- Lists the name of the recipes that
- produce the given packages.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- For more information on the <filename>oe-pkgdata-util</filename>
- command, use the help facility:
- <literallayout class='monospaced'>
- $ oe-pkgdata-util ‐‐help
- $ oe-pkgdata-util <replaceable>subcommand</replaceable> --help
- </literallayout>
- </para>
- </section>
-
- <section id='usingpoky-viewing-dependencies-between-recipes-and-tasks'>
- <title>Viewing Dependencies Between Recipes and Tasks</title>
-
- <para>
- Sometimes it can be hard to see why BitBake wants to build other
- recipes before the one you have specified.
- Dependency information can help you understand why a recipe is
- built.
- </para>
-
- <para>
- To generate dependency information for a recipe, run the following
- command:
- <literallayout class='monospaced'>
- $ bitbake -g <replaceable>recipename</replaceable>
- </literallayout>
- This command writes the following files in the current directory:
- <itemizedlist>
- <listitem><para>
- <filename>pn-buildlist</filename>: A list of
- recipes/targets involved in building
- <replaceable>recipename</replaceable>.
- "Involved" here means that at least one task from the
- recipe needs to run when building
- <replaceable>recipename</replaceable> from scratch.
- Targets that are in
- <link linkend='var-ASSUME_PROVIDED'><filename>ASSUME_PROVIDED</filename></link>
- are not listed.
- </para></listitem>
- <listitem><para>
- <filename>task-depends.dot</filename>: A graph showing
- dependencies between tasks.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- The graphs are in
- <ulink url='https://en.wikipedia.org/wiki/DOT_%28graph_description_language%29'>DOT</ulink>
- format and can be converted to images (e.g. using the
- <filename>dot</filename> tool from
- <ulink url='http://www.graphviz.org/'>Graphviz</ulink>).
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- DOT files use a plain text format.
- The graphs generated using the
- <filename>bitbake -g</filename> command are often so
- large as to be difficult to read without special
- pruning (e.g. with Bitbake's
- <filename>-I</filename> option) and processing.
- Despite the form and size of the graphs, the
- corresponding <filename>.dot</filename> files can still
- be possible to read and provide useful information.
- </para>
-
- <para>As an example, the
- <filename>task-depends.dot</filename> file contains
- lines such as the following:
- <literallayout class='monospaced'>
- "libxslt.do_configure" -> "libxml2.do_populate_sysroot"
- </literallayout>
- The above example line reveals that the
- <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
- task in <filename>libxslt</filename> depends on the
- <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
- task in <filename>libxml2</filename>, which is a normal
- <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
- dependency between the two recipes.
- </para></listitem>
- <listitem><para>
- For an example of how <filename>.dot</filename> files
- can be processed, see the
- <filename>scripts/contrib/graph-tool</filename> Python
- script, which finds and displays paths between graph
- nodes.
- </para></listitem>
- </itemizedlist>
- </note>
- </para>
-
- <para>
- You can use a different method to view dependency information
- by using the following command:
- <literallayout class='monospaced'>
- $ bitbake -g -u taskexp <replaceable>recipename</replaceable>
- </literallayout>
- This command displays a GUI window from which you can view
- build-time and runtime dependencies for the recipes involved in
- building <replaceable>recipename</replaceable>.
- </para>
- </section>
-
- <section id='usingpoky-viewing-task-variable-dependencies'>
- <title>Viewing Task Variable Dependencies</title>
-
- <para>
- As mentioned in the
- "<ulink url='&YOCTO_DOCS_BB_URL;#checksums'>Checksums (Signatures)</ulink>"
- section of the BitBake User Manual, BitBake tries to automatically
- determine what variables a task depends on so that it can rerun
- the task if any values of the variables change.
- This determination is usually reliable.
- However, if you do things like construct variable names at runtime,
- then you might have to manually declare dependencies on those
- variables using <filename>vardeps</filename> as described in the
- "<ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'>Variable Flags</ulink>"
- section of the BitBake User Manual.
- </para>
-
- <para>
- If you are unsure whether a variable dependency is being picked up
- automatically for a given task, you can list the variable
- dependencies BitBake has determined by doing the following:
- <orderedlist>
- <listitem><para>
- Build the recipe containing the task:
- <literallayout class='monospaced'>
- $ bitbake <replaceable>recipename</replaceable>
- </literallayout>
- </para></listitem>
- <listitem><para>
- Inside the
- <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>
- directory, find the signature data
- (<filename>sigdata</filename>) file that corresponds to the
- task.
- The <filename>sigdata</filename> files contain a pickled
- Python database of all the metadata that went into creating
- the input checksum for the task.
- As an example, for the
- <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
- task of the <filename>db</filename> recipe, the
- <filename>sigdata</filename> file might be found in the
- following location:
- <literallayout class='monospaced'>
- ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
- </literallayout>
- For tasks that are accelerated through the shared state
- (<link linkend='shared-state-cache'>sstate</link>)
- cache, an additional <filename>siginfo</filename> file is
- written into
- <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
- along with the cached task output.
- The <filename>siginfo</filename> files contain exactly the
- same information as <filename>sigdata</filename> files.
- </para></listitem>
- <listitem><para>
- Run <filename>bitbake-dumpsig</filename> on the
- <filename>sigdata</filename> or
- <filename>siginfo</filename> file.
- Here is an example:
- <literallayout class='monospaced'>
- $ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
- </literallayout>
- In the output of the above command, you will find a line
- like the following, which lists all the (inferred) variable
- dependencies for the task.
- This list also includes indirect dependencies from
- variables depending on other variables, recursively.
- <literallayout class='monospaced'>
- Task dependencies: ['PV', 'SRCREV', 'SRC_URI', 'SRC_URI[md5sum]', 'SRC_URI[sha256sum]', 'base_do_fetch']
- </literallayout>
- <note>
- Functions (e.g. <filename>base_do_fetch</filename>)
- also count as variable dependencies.
- These functions in turn depend on the variables they
- reference.
- </note>
- The output of <filename>bitbake-dumpsig</filename> also includes
- the value each variable had, a list of dependencies for each
- variable, and
- <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_HASHBASE_WHITELIST'><filename>BB_HASHBASE_WHITELIST</filename></ulink>
- information.
- </para></listitem>
- </orderedlist>
- </para>
-
- <para>
- There is also a <filename>bitbake-diffsigs</filename> command for
- comparing two <filename>siginfo</filename> or
- <filename>sigdata</filename> files.
- This command can be helpful when trying to figure out what changed
- between two versions of a task.
- If you call <filename>bitbake-diffsigs</filename> with just one
- file, the command behaves like
- <filename>bitbake-dumpsig</filename>.
- </para>
-
- <para>
- You can also use BitBake to dump out the signature construction
- information without executing tasks by using either of the
- following BitBake command-line options:
- <literallayout class='monospaced'>
- ‐‐dump-signatures=<replaceable>SIGNATURE_HANDLER</replaceable>
- -S <replaceable>SIGNATURE_HANDLER</replaceable>
- </literallayout>
- <note>
- Two common values for
- <replaceable>SIGNATURE_HANDLER</replaceable> are "none" and
- "printdiff", which dump only the signature or compare the
- dumped signature with the cached one, respectively.
- </note>
- Using BitBake with either of these options causes BitBake to dump
- out <filename>sigdata</filename> files in the
- <filename>stamps</filename> directory for every task it would have
- executed instead of building the specified target package.
- </para>
- </section>
-
- <section id='usingpoky-debugging-taskrunning'>
- <title>Running Specific Tasks</title>
-
- <para>
- Any given recipe consists of a set of tasks.
- The standard BitBake behavior in most cases is:
- <filename>do_fetch</filename>,
- <filename>do_unpack</filename>,
- <filename>do_patch</filename>, <filename>do_configure</filename>,
- <filename>do_compile</filename>, <filename>do_install</filename>,
- <filename>do_package</filename>,
- <filename>do_package_write_*</filename>, and
- <filename>do_build</filename>.
- The default task is <filename>do_build</filename> and any tasks
- on which it depends build first.
- Some tasks, such as <filename>do_devshell</filename>, are not part
- of the default build chain.
- If you wish to run a task that is not part of the default build
- chain, you can use the <filename>-c</filename> option in BitBake.
- Here is an example:
- <literallayout class='monospaced'>
- $ bitbake matchbox-desktop -c devshell
- </literallayout>
- </para>
-
- <para>
- The <filename>-c</filename> option respects task dependencies,
- which means that all other tasks (including tasks from other
- recipes) that the specified task depends on will be run before the
- task.
- Even when you manually specify a task to run with
- <filename>-c</filename>, BitBake will only run the task if it
- considers it "out of date".
- See the
- "<link linkend='stamp-files-and-the-rerunning-of-tasks'>Stamp Files and the Rerunning of Tasks</link>"
- section for how BitBake determines whether a task is "out of date".
- </para>
-
- <para>
- If you want to force an up-to-date task to be rerun (e.g.
- because you made manual modifications to the recipe's
- <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
- that you want to try out), then you can use the
- <filename>-f</filename> option.
- <note>
- The reason <filename>-f</filename> is never required when
- running the
- <link linkend='ref-tasks-devshell'><filename>do_devshell</filename></link>
- task is because the
- <filename>[</filename><ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'><filename>nostamp</filename></ulink><filename>]</filename>
- variable flag is already set for the task.
- </note>
- The following example shows one way you can use the
- <filename>-f</filename> option:
- <literallayout class='monospaced'>
- $ bitbake matchbox-desktop
- .
- .
- make some changes to the source code in the work directory
- .
- .
- $ bitbake matchbox-desktop -c compile -f
- $ bitbake matchbox-desktop
- </literallayout>
- </para>
-
- <para>
- This sequence first builds and then recompiles
- <filename>matchbox-desktop</filename>.
- The last command reruns all tasks (basically the packaging tasks)
- after the compile.
- BitBake recognizes that the <filename>do_compile</filename>
- task was rerun and therefore understands that the other tasks
- also need to be run again.
- </para>
-
- <para>
- Another, shorter way to rerun a task and all
- <link linkend='normal-recipe-build-tasks'>normal recipe build tasks</link>
- that depend on it is to use the <filename>-C</filename>
- option.
- <note>
- This option is upper-cased and is separate from the
- <filename>-c</filename> option, which is lower-cased.
- </note>
- Using this option invalidates the given task and then runs the
- <link linkend='ref-tasks-build'><filename>do_build</filename></link>
- task, which is the default task if no task is given, and the
- tasks on which it depends.
- You could replace the final two commands in the previous example
- with the following single command:
- <literallayout class='monospaced'>
- $ bitbake matchbox-desktop -C compile
- </literallayout>
- Internally, the <filename>-f</filename> and
- <filename>-C</filename> options work by tainting (modifying) the
- input checksum of the specified task.
- This tainting indirectly causes the task and its
- dependent tasks to be rerun through the normal task dependency
- mechanisms.
- <note>
- BitBake explicitly keeps track of which tasks have been
- tainted in this fashion, and will print warnings such as the
- following for builds involving such tasks:
- <literallayout class='monospaced'>
- WARNING: /home/ulf/poky/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run
- </literallayout>
- The purpose of the warning is to let you know that the work
- directory and build output might not be in the clean state they
- would be in for a "normal" build, depending on what actions
- you took.
- To get rid of such warnings, you can remove the work directory
- and rebuild the recipe, as follows:
- <literallayout class='monospaced'>
- $ bitbake matchbox-desktop -c clean
- $ bitbake matchbox-desktop
- </literallayout>
- </note>
- </para>
-
- <para>
- You can view a list of tasks in a given package by running the
- <filename>do_listtasks</filename> task as follows:
- <literallayout class='monospaced'>
- $ bitbake matchbox-desktop -c listtasks
- </literallayout>
- The results appear as output to the console and are also in the
- file <filename>${WORKDIR}/temp/log.do_listtasks</filename>.
- </para>
- </section>
-
- <section id='usingpoky-debugging-bitbake'>
- <title>General BitBake Problems</title>
-
- <para>
- You can see debug output from BitBake by using the <filename>-D</filename> option.
- The debug output gives more information about what BitBake
- is doing and the reason behind it.
- Each <filename>-D</filename> option you use increases the logging level.
- The most common usage is <filename>-DDD</filename>.
- </para>
-
- <para>
- The output from <filename>bitbake -DDD -v</filename> <replaceable>targetname</replaceable> can reveal why
- BitBake chose a certain version of a package or why BitBake
- picked a certain provider.
- This command could also help you in a situation where you think BitBake did something
- unexpected.
- </para>
- </section>
-
- <section id='development-host-system-issues'>
- <title>Development Host System Issues</title>
-
- <para>
- Sometimes issues on the host development system can cause your
- build to fail.
- Following are known, host-specific problems.
- Be sure to always consult the
- <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
- for a look at all release-related issues.
- <itemizedlist>
- <listitem><para><emphasis><filename>glibc-initial</filename> fails to build</emphasis>:
- If your development host system has the unpatched
- <filename>GNU Make 3.82</filename>,
- the
- <link linkend='ref-tasks-install'><filename>do_install</filename></link>
- task fails for <filename>glibc-initial</filename> during
- the build.</para>
- <para>Typically, every distribution that ships
- <filename>GNU Make 3.82</filename> as
- the default already has the patched version.
- However, some distributions, such as Debian, have
- <filename>GNU Make 3.82</filename> as an option, which
- is unpatched.
- You will see this error on these types of distributions.
- Switch to <filename>GNU Make 3.81</filename> or patch
- your <filename>make</filename> to solve the problem.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='usingpoky-debugging-buildfile'>
- <title>Building with No Dependencies</title>
- <para>
- To build a specific recipe (<filename>.bb</filename> file),
- you can use the following command form:
- <literallayout class='monospaced'>
- $ bitbake -b <replaceable>somepath</replaceable>/<replaceable>somerecipe</replaceable>.bb
- </literallayout>
- This command form does not check for dependencies.
- Consequently, you should use it
- only when you know existing dependencies have been met.
- <note>
- You can also specify fragments of the filename.
- In this case, BitBake checks for a unique match.
- </note>
- </para>
- </section>
-
- <section id='recipe-logging-mechanisms'>
- <title>Recipe Logging Mechanisms</title>
- <para>
- The Yocto Project provides several logging functions for producing
- debugging output and reporting errors and warnings.
- For Python functions, the following logging functions exist.
- All of these functions log to
- <filename>${T}/log.do_</filename><replaceable>task</replaceable>,
- and can also log to standard output (stdout) with the right
- settings:
- <itemizedlist>
- <listitem><para>
- <filename>bb.plain(</filename><replaceable>msg</replaceable><filename>)</filename>:
- Writes <replaceable>msg</replaceable> as is to the log while
- also logging to stdout.
- </para></listitem>
- <listitem><para>
- <filename>bb.note(</filename><replaceable>msg</replaceable><filename>)</filename>:
- Writes "NOTE: <replaceable>msg</replaceable>" to the log.
- Also logs to stdout if BitBake is called with "-v".
- </para></listitem>
- <listitem><para>
- <filename>bb.debug(</filename><replaceable>level</replaceable><filename>, </filename><replaceable>msg</replaceable><filename>)</filename>:
- Writes "DEBUG: <replaceable>msg</replaceable>" to the log.
- Also logs to stdout if the log level is greater than or
- equal to <replaceable>level</replaceable>.
- See the
- "<ulink url='&YOCTO_DOCS_BB_URL;#usage-and-syntax'>-D</ulink>"
- option in the BitBake User Manual for more information.
- </para></listitem>
- <listitem><para>
- <filename>bb.warn(</filename><replaceable>msg</replaceable><filename>)</filename>:
- Writes "WARNING: <replaceable>msg</replaceable>" to the log
- while also logging to stdout.
- </para></listitem>
- <listitem><para>
- <filename>bb.error(</filename><replaceable>msg</replaceable><filename>)</filename>:
- Writes "ERROR: <replaceable>msg</replaceable>" to the log
- while also logging to stdout.
- <note>
- Calling this function does not cause the task to fail.
- </note>
- </para></listitem>
- <listitem><para>
- <filename>bb.fatal(</filename><replaceable>msg</replaceable><filename>)</filename>:
- This logging function is similar to
- <filename>bb.error(</filename><replaceable>msg</replaceable><filename>)</filename>
- but also causes the calling task to fail.
- <note>
- <filename>bb.fatal()</filename> raises an exception,
- which means you do not need to put a "return"
- statement after the function.
- </note>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- The same logging functions are also available in shell functions,
- under the names
- <filename>bbplain</filename>, <filename>bbnote</filename>,
- <filename>bbdebug</filename>, <filename>bbwarn</filename>,
- <filename>bberror</filename>, and <filename>bbfatal</filename>.
- The
- <link linkend='ref-classes-logging'><filename>logging</filename></link>
- class implements these functions.
- See that class in the
- <filename>meta/classes</filename> folder of the
- <link linkend='source-directory'>Source Directory</link>
- for information.
- </para>
-
- <section id='logging-with-python'>
- <title>Logging With Python</title>
- <para>
- When creating recipes using Python and inserting code that handles build logs,
- keep in mind the goal is to have informative logs while keeping the console as
- "silent" as possible.
- Also, if you want status messages in the log, use the "debug" loglevel.
- </para>
-
- <para>
- Following is an example written in Python.
- The code handles logging for a function that determines the
- number of tasks needed to be run.
- See the
- "<link linkend='ref-tasks-listtasks'><filename>do_listtasks</filename></link>"
- section for additional information:
- <literallayout class='monospaced'>
- python do_listtasks() {
- bb.debug(2, "Starting to figure out the task list")
- if noteworthy_condition:
- bb.note("There are 47 tasks to run")
- bb.debug(2, "Got to point xyz")
- if warning_trigger:
- bb.warn("Detected warning_trigger, this might be a problem later.")
- if recoverable_error:
- bb.error("Hit recoverable_error, you really need to fix this!")
- if fatal_error:
- bb.fatal("fatal_error detected, unable to print the task list")
- bb.plain("The tasks present are abc")
- bb.debug(2, "Finished figuring out the tasklist")
- }
- </literallayout>
- </para>
- </section>
-
- <section id='logging-with-bash'>
- <title>Logging With Bash</title>
- <para>
- When creating recipes using Bash and inserting code that handles build
- logs, you have the same goals - informative with minimal console output.
- The syntax you use for recipes written in Bash is similar to that of
- recipes written in Python described in the previous section.
- </para>
-
- <para>
- Following is an example written in Bash.
- The code logs the progress of the <filename>do_my_function</filename> function.
- <literallayout class='monospaced'>
- do_my_function() {
- bbdebug 2 "Running do_my_function"
- if [ exceptional_condition ]; then
- bbnote "Hit exceptional_condition"
- fi
- bbdebug 2 "Got to point xyz"
- if [ warning_trigger ]; then
- bbwarn "Detected warning_trigger, this might cause a problem later."
- fi
- if [ recoverable_error ]; then
- bberror "Hit recoverable_error, correcting"
- fi
- if [ fatal_error ]; then
- bbfatal "fatal_error detected"
- fi
- bbdebug 2 "Completed do_my_function"
- }
- </literallayout>
- </para>
- </section>
- </section>
-
- <section id='usingpoky-debugging-others'>
- <title>Other Tips</title>
-
- <para>
- Here are some other tips that you might find useful:
- <itemizedlist>
- <listitem><para>
- When adding new packages, it is worth watching for
- undesirable items making their way into compiler command
- lines.
- For example, you do not want references to local system
- files like
- <filename>/usr/lib/</filename> or
- <filename>/usr/include/</filename>.
- </para></listitem>
- <listitem><para>
- If you want to remove the <filename>psplash</filename>
- boot splashscreen,
- add <filename>psplash=false</filename> to the kernel
- command line.
- Doing so prevents <filename>psplash</filename> from loading
- and thus allows you to see the console.
- It is also possible to switch out of the splashscreen by
- switching the virtual console (e.g. Fn+Left or Fn+Right
- on a Zaurus).
- </para></listitem>
- <listitem><para>
- Removing
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
- (usually <filename>tmp/</filename>, within the
- <link linkend='build-directory'>Build Directory</link>)
- can often fix temporary build issues.
- Removing <filename>TMPDIR</filename> is usually a
- relatively cheap operation, because task output will be
- cached in
- <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
- (usually <filename>sstate-cache/</filename>, which is
- also in the Build Directory).
- <note>
- Removing <filename>TMPDIR</filename> might be a
- workaround rather than a fix.
- Consequently, trying to determine the underlying cause
- of an issue before removing the directory is a good
- idea.
- </note>
- </para></listitem>
- <listitem><para>
- Understanding how a feature is used in practice within
- existing recipes can be very helpful.
- It is recommended that you configure some method that
- allows you to quickly search through files.</para>
-
- <para>Using GNU Grep, you can use the following shell
- function to recursively search through common
- recipe-related files, skipping binary files,
- <filename>.git</filename> directories, and the
- Build Directory (assuming its name starts with
- "build"):
- <literallayout class='monospaced'>
- g() {
- grep -Ir \
- --exclude-dir=.git \
- --exclude-dir='build*' \
- --include='*.bb*' \
- --include='*.inc*' \
- --include='*.conf*' \
- --include='*.py*' \
- "$@"
- }
- </literallayout>
- Following are some usage examples:
- <literallayout class='monospaced'>
- $ g FOO # Search recursively for "FOO"
- $ g -i foo # Search recursively for "foo", ignoring case
- $ g -w FOO # Search recursively for "FOO" as a word, ignoring e.g. "FOOBAR"
- </literallayout>
- If figuring out how some feature works requires a lot of
- searching, it might indicate that the documentation should
- be extended or improved.
- In such cases, consider filing a documentation bug using
- the Yocto Project implementation of
- <ulink url='https://bugzilla.yoctoproject.org/'>Bugzilla</ulink>.
- For general information on how to submit a bug against
- the Yocto Project, see the Yocto Project Bugzilla
- <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>wiki page</ulink>"
- or the
- <ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project'>Submitting a Defect Against the Yocto Project</ulink>"
- section, which is in the Yocto Project Development Tasks
- Manual.
- <note>
- The manuals might not be the right place to document
- variables that are purely internal and have a limited
- scope (e.g. internal variables used to implement a
- single <filename>.bbclass</filename> file).
- </note>
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-</section>
-
-<section id='ref-quick-emulator-qemu'>
- <title>Quick EMUlator (QEMU)</title>
-
- <para>
- The Yocto Project uses an implementation of the Quick EMUlator (QEMU)
- Open Source project as part of the Yocto Project development "tool
- set".
- </para>
-
- <para>
- Within the context of the Yocto Project, QEMU is an
- emulator and virtualization machine that allows you to run a complete
- image you have built using the Yocto Project as just another task
- on your build system.
- QEMU is useful for running and testing images and applications on
- supported Yocto Project architectures without having actual hardware.
- Among other things, the Yocto Project uses QEMU to run automated
- Quality Assurance (QA) tests on final images shipped with each
- release.
- <note>
- This implementation is not the same as QEMU in general.
- </note>
- This section provides a brief reference for the Yocto Project
- implementation of QEMU.
- </para>
-
- <para>
- For official information and documentation on QEMU in general, see the
- following references:
- <itemizedlist>
- <listitem><para>
- <emphasis><ulink url='http://wiki.qemu.org/Main_Page'>QEMU Website</ulink>:</emphasis>
- The official website for the QEMU Open Source project.
- </para></listitem>
- <listitem><para>
- <emphasis><ulink url='http://wiki.qemu.org/Manual'>Documentation</ulink>:</emphasis>
- The QEMU user manual.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- For information on how to use the Yocto Project implementation of
- QEMU, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
- chapter in the Yocto Project Development Tasks Manual.
- </para>
-
- <section id='qemu-availability'>
- <title>QEMU Availability</title>
-
- <para>
- QEMU is made available with the Yocto Project a number of ways.
- One method is to install a Software Development Kit (SDK).
- For more information on how to make sure you have
- QEMU available, see
- "<ulink url='&YOCTO_DOCS_SDK_URL;#the-qemu-emulator'>The QEMU Emulator</ulink>"
- section in the Yocto Project Application Development and the
- Extensible Software Development Kit (eSDK) manual.
- </para>
- </section>
-
- <section id='qemu-performance'>
- <title>QEMU Performance</title>
-
- <para>
- Using QEMU to emulate your hardware can result in speed issues
- depending on the target and host architecture mix.
- For example, using the <filename>qemux86</filename> image in the
- emulator on an Intel-based 32-bit (x86) host machine is fast
- because the target and host architectures match.
- On the other hand, using the <filename>qemuarm</filename> image
- on the same Intel-based host can be slower.
- But, you still achieve faithful emulation of ARM-specific issues.
- </para>
-
- <para>
- To speed things up, the QEMU images support using
- <filename>distcc</filename> to call a cross-compiler outside the
- emulated system.
- If you used <filename>runqemu</filename> to start QEMU, and the
- <filename>distccd</filename> application is present on the host
- system, any BitBake cross-compiling toolchain available from the
- build system is automatically used from within QEMU simply by
- calling <filename>distcc</filename>.
- You can accomplish this by defining the cross-compiler variable
- (e.g. <filename>export CC="distcc"</filename>).
- Alternatively, if you are using a suitable SDK image or the
- appropriate stand-alone toolchain is present, the toolchain is
- also automatically used.
- </para>
-
- <note>
- Several mechanisms exist that let you connect to the system
- running on the QEMU emulator:
- <itemizedlist>
- <listitem><para>
- QEMU provides a framebuffer interface that makes standard
- consoles available.
- </para></listitem>
- <listitem><para>
- Generally, headless embedded devices have a serial port.
- If so, you can configure the operating system of the
- running image to use that port to run a console.
- The connection uses standard IP networking.
- </para></listitem>
- <listitem><para>
- SSH servers exist in some QEMU images.
- The <filename>core-image-sato</filename> QEMU image has a
- Dropbear secure shell (SSH) server that runs with the root
- password disabled.
- The <filename>core-image-full-cmdline</filename> and
- <filename>core-image-lsb</filename> QEMU images
- have OpenSSH instead of Dropbear.
- Including these SSH servers allow you to use standard
- <filename>ssh</filename> and <filename>scp</filename>
- commands.
- The <filename>core-image-minimal</filename> QEMU image,
- however, contains no SSH server.
- </para></listitem>
- <listitem><para>
- You can use a provided, user-space NFS server to boot
- the QEMU session using a local copy of the root
- filesystem on the host.
- In order to make this connection, you must extract a
- root filesystem tarball by using the
- <filename>runqemu-extract-sdk</filename> command.
- After running the command, you must then point the
- <filename>runqemu</filename>
- script to the extracted directory instead of a root
- filesystem image file.
- See the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-running-under-a-network-file-system-nfs-server'>Running Under a Network File System (NFS) Server</ulink>"
- section in the Yocto Project Development Tasks Manual for
- more information.
- </para></listitem>
- </itemizedlist>
- </note>
- </section>
-
- <section id='qemu-command-line-syntax'>
- <title>QEMU Command-Line Syntax</title>
-
- <para>
- The basic <filename>runqemu</filename> command syntax is as
- follows:
- <literallayout class='monospaced'>
- $ runqemu [<replaceable>option</replaceable> ] [...]
- </literallayout>
- Based on what you provide on the command line,
- <filename>runqemu</filename> does a good job of figuring out what
- you are trying to do.
- For example, by default, QEMU looks for the most recently built
- image according to the timestamp when it needs to look for an
- image.
- Minimally, through the use of options, you must provide either
- a machine name, a virtual machine image
- (<filename>*wic.vmdk</filename>), or a kernel image
- (<filename>*.bin</filename>).
- </para>
-
- <para>
- Following is the command-line help output for the
- <filename>runqemu</filename> command:
- <literallayout class='monospaced'>
- $ runqemu --help
-
- Usage: you can run this script with any valid combination
- of the following environment variables (in any order):
- KERNEL - the kernel image file to use
- ROOTFS - the rootfs image file or nfsroot directory to use
- MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified)
- Simplified QEMU command-line options can be passed with:
- nographic - disable video console
- serial - enable a serial console on /dev/ttyS0
- slirp - enable user networking, no root privileges is required
- kvm - enable KVM when running x86/x86_64 (VT-capable CPU required)
- kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU required)
- publicvnc - enable a VNC server open to all hosts
- audio - enable audio
- [*/]ovmf* - OVMF firmware file or base name for booting with UEFI
- tcpserial=<port> - specify tcp serial port number
- biosdir=<dir> - specify custom bios dir
- biosfilename=<filename> - specify bios filename
- qemuparams=<xyz> - specify custom parameters to QEMU
- bootparams=<xyz> - specify custom kernel parameters during boot
- help, -h, --help: print this text
-
- Examples:
- runqemu
- runqemu qemuarm
- runqemu tmp/deploy/images/qemuarm
- runqemu tmp/deploy/images/qemux86/<qemuboot.conf>
- runqemu qemux86-64 core-image-sato ext4
- runqemu qemux86-64 wic-image-minimal wic
- runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial
- runqemu qemux86 iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz...
- runqemu qemux86 qemuparams="-m 256"
- runqemu qemux86 bootparams="psplash=false"
- runqemu path/to/<image>-<machine>.wic
- runqemu path/to/<image>-<machine>.wic.vmdk
- </literallayout>
- </para>
- </section>
-
- <section id='runqemu-command-line-options'>
- <title><filename>runqemu</filename> Command-Line Options</title>
-
- <para>
- Following is a description of <filename>runqemu</filename>
- options you can provide on the command line:
- <note><title>Tip</title>
- If you do provide some "illegal" option combination or perhaps
- you do not provide enough in the way of options,
- <filename>runqemu</filename> provides appropriate error
- messaging to help you correct the problem.
- </note>
- <itemizedlist>
- <listitem><para>
- <replaceable>QEMUARCH</replaceable>:
- The QEMU machine architecture, which must be "qemuarm",
- "qemuarm64", "qemumips", "qemumips64", "qemuppc",
- "qemux86", or "qemux86-64".
- </para></listitem>
- <listitem><para>
- <filename><replaceable>VM</replaceable></filename>:
- The virtual machine image, which must be a
- <filename>.wic.vmdk</filename> file.
- Use this option when you want to boot a
- <filename>.wic.vmdk</filename> image.
- The image filename you provide must contain one of the
- following strings: "qemux86-64", "qemux86", "qemuarm",
- "qemumips64", "qemumips", "qemuppc", or "qemush4".
- </para></listitem>
- <listitem><para>
- <replaceable>ROOTFS</replaceable>:
- A root filesystem that has one of the following
- filetype extensions: "ext2", "ext3", "ext4", "jffs2",
- "nfs", or "btrfs".
- If the filename you provide for this option uses “nfs”, it
- must provide an explicit root filesystem path.
- </para></listitem>
- <listitem><para>
- <replaceable>KERNEL</replaceable>:
- A kernel image, which is a <filename>.bin</filename> file.
- When you provide a <filename>.bin</filename> file,
- <filename>runqemu</filename> detects it and assumes the
- file is a kernel image.
- </para></listitem>
- <listitem><para>
- <replaceable>MACHINE</replaceable>:
- The architecture of the QEMU machine, which must be one
- of the following: "qemux86", "qemux86-64", "qemuarm",
- "qemuarm64", "qemumips", “qemumips64", or "qemuppc".
- The <replaceable>MACHINE</replaceable> and
- <replaceable>QEMUARCH</replaceable> options are basically
- identical.
- If you do not provide a <replaceable>MACHINE</replaceable>
- option, <filename>runqemu</filename> tries to determine
- it based on other options.
- </para></listitem>
- <listitem><para>
- <filename>ramfs</filename>:
- Indicates you are booting an initial RAM disk (initramfs)
- image, which means the <filename>FSTYPE</filename> is
- <filename>cpio.gz</filename>.
- </para></listitem>
- <listitem><para>
- <filename>iso</filename>:
- Indicates you are booting an ISO image, which means the
- <filename>FSTYPE</filename> is
- <filename>.iso</filename>.
- </para></listitem>
- <listitem><para>
- <filename>nographic</filename>:
- Disables the video console, which sets the console to
- "ttys0".
- </para></listitem>
- <listitem><para>
- <filename>serial</filename>:
- Enables a serial console on
- <filename>/dev/ttyS0</filename>.
- </para></listitem>
- <listitem><para>
- <filename>biosdir</filename>:
- Establishes a custom directory for BIOS, VGA BIOS and
- keymaps.
- </para></listitem>
- <listitem><para>
- <filename>biosfilename</filename>:
- Establishes a custom BIOS name.
- </para></listitem>
- <listitem><para>
- <filename>qemuparams=\"<replaceable>xyz</replaceable>\"</filename>:
- Specifies custom QEMU parameters.
- Use this option to pass options other than the simple
- "kvm" and "serial" options.
- </para></listitem>
- <listitem><para><filename>bootparams=\"<replaceable>xyz</replaceable>\"</filename>:
- Specifies custom boot parameters for the kernel.
- </para></listitem>
- <listitem><para>
- <filename>audio</filename>:
- Enables audio in QEMU.
- The <replaceable>MACHINE</replaceable> option must be
- either "qemux86" or "qemux86-64" in order for audio to be
- enabled.
- Additionally, the <filename>snd_intel8x0</filename>
- or <filename>snd_ens1370</filename> driver must be
- installed in linux guest.
- </para></listitem>
- <listitem><para>
- <filename>slirp</filename>:
- Enables "slirp" networking, which is a different way
- of networking that does not need root access
- but also is not as easy to use or comprehensive
- as the default.
- </para></listitem>
- <listitem><para id='kvm-cond'>
- <filename>kvm</filename>:
- Enables KVM when running "qemux86" or "qemux86-64"
- QEMU architectures.
- For KVM to work, all the following conditions must be met:
- <itemizedlist>
- <listitem><para>
- Your <replaceable>MACHINE</replaceable> must be either
-qemux86" or "qemux86-64".
- </para></listitem>
- <listitem><para>
- Your build host has to have the KVM modules
- installed, which are
- <filename>/dev/kvm</filename>.
- </para></listitem>
- <listitem><para>
- The build host <filename>/dev/kvm</filename>
- directory has to be both writable and readable.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <filename>kvm-vhost</filename>:
- Enables KVM with VHOST support when running "qemux86"
- or "qemux86-64" QEMU architectures.
- For KVM with VHOST to work, the following conditions must
- be met:
- <itemizedlist>
- <listitem><para>
- <link linkend='kvm-cond'>kvm</link> option
- conditions must be met.
- </para></listitem>
- <listitem><para>
- Your build host has to have virtio net device, which
- are <filename>/dev/vhost-net</filename>.
- </para></listitem>
- <listitem><para>
- The build host <filename>/dev/vhost-net</filename>
- directory has to be either readable or writable
- and “slirp-enabled”.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <filename>publicvnc</filename>:
- Enables a VNC server open to all hosts.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-</section>
-
-<section id='maintaining-build-output-quality'>
- <title>Maintaining Build Output Quality</title>
-
- <para>
- Many factors can influence the quality of a build.
- For example, if you upgrade a recipe to use a new version of an upstream software
- package or you experiment with some new configuration options, subtle changes
- can occur that you might not detect until later.
- Consider the case where your recipe is using a newer version of an upstream package.
- In this case, a new version of a piece of software might introduce an optional
- dependency on another library, which is auto-detected.
- If that library has already been built when the software is building,
- the software will link to the built library and that library will be pulled
- into your image along with the new software even if you did not want the
- library.
- </para>
-
- <para>
- The
- <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
- class exists to help you maintain
- the quality of your build output.
- You can use the class to highlight unexpected and possibly unwanted
- changes in the build output.
- When you enable build history, it records information about the contents of
- each package and image and then commits that information to a local Git
- repository where you can examine the information.
- </para>
-
- <para>
- The remainder of this section describes the following:
- <itemizedlist>
- <listitem><para>How you can enable and disable
- build history</para></listitem>
- <listitem><para>How to understand what the build history contains
- </para></listitem>
- <listitem><para>How to limit the information used for build history
- </para></listitem>
- <listitem><para>How to examine the build history from both a
- command-line and web interface</para></listitem>
- </itemizedlist>
- </para>
-
- <section id='enabling-and-disabling-build-history'>
- <title>Enabling and Disabling Build History</title>
-
- <para>
- Build history is disabled by default.
- To enable it, add the following <filename>INHERIT</filename>
- statement and set the
- <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
- variable to "1" at the end of your
- <filename>conf/local.conf</filename> file found in the
- <link linkend='build-directory'>Build Directory</link>:
- <literallayout class='monospaced'>
- INHERIT += "buildhistory"
- BUILDHISTORY_COMMIT = "1"
- </literallayout>
- Enabling build history as previously described causes the
- OpenEmbedded build system to collect build output information and
- commit it as a single commit to a local
- <link linkend='git'>Git</link> repository.
- <note>
- Enabling build history increases your build times slightly,
- particularly for images, and increases the amount of disk
- space used during the build.
- </note>
- </para>
-
- <para>
- You can disable build history by removing the previous statements
- from your <filename>conf/local.conf</filename> file.
- </para>
- </section>
-
- <section id='understanding-what-the-build-history-contains'>
- <title>Understanding What the Build History Contains</title>
-
- <para>
- Build history information is kept in
- <filename>${</filename><link linkend='var-TOPDIR'><filename>TOPDIR</filename></link><filename>}/buildhistory</filename>
- in the Build Directory as defined by the
- <link linkend='var-BUILDHISTORY_DIR'><filename>BUILDHISTORY_DIR</filename></link>
- variable.
- The following is an example abbreviated listing:
- <imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
- </para>
-
- <para>
- At the top level, there is a <filename>metadata-revs</filename> file
- that lists the revisions of the repositories for the layers enabled
- when the build was produced.
- The rest of the data splits into separate
- <filename>packages</filename>, <filename>images</filename> and
- <filename>sdk</filename> directories, the contents of which are
- described below.
- </para>
-
- <section id='build-history-package-information'>
- <title>Build History Package Information</title>
-
- <para>
- The history for each package contains a text file that has
- name-value pairs with information about the package.
- For example, <filename>buildhistory/packages/i586-poky-linux/busybox/busybox/latest</filename>
- contains the following:
- <literallayout class='monospaced'>
- PV = 1.22.1
- PR = r32
- RPROVIDES =
- RDEPENDS = glibc (>= 2.20) update-alternatives-opkg
- RRECOMMENDS = busybox-syslog busybox-udhcpc update-rc.d
- PKGSIZE = 540168
- FILES = /usr/bin/* /usr/sbin/* /usr/lib/busybox/* /usr/lib/lib*.so.* \
- /etc /com /var /bin/* /sbin/* /lib/*.so.* /lib/udev/rules.d \
- /usr/lib/udev/rules.d /usr/share/busybox /usr/lib/busybox/* \
- /usr/share/pixmaps /usr/share/applications /usr/share/idl \
- /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
- FILELIST = /bin/busybox /bin/busybox.nosuid /bin/busybox.suid /bin/sh \
- /etc/busybox.links.nosuid /etc/busybox.links.suid
- </literallayout>
- Most of these name-value pairs correspond to variables used
- to produce the package.
- The exceptions are <filename>FILELIST</filename>, which is the
- actual list of files in the package, and
- <filename>PKGSIZE</filename>, which is the total size of files
- in the package in bytes.
- </para>
-
- <para>
- There is also a file corresponding to the recipe from which the
- package came (e.g.
- <filename>buildhistory/packages/i586-poky-linux/busybox/latest</filename>):
- <literallayout class='monospaced'>
- PV = 1.22.1
- PR = r32
- DEPENDS = initscripts kern-tools-native update-rc.d-native \
- virtual/i586-poky-linux-compilerlibs virtual/i586-poky-linux-gcc \
- virtual/libc virtual/update-alternatives
- PACKAGES = busybox-ptest busybox-httpd busybox-udhcpd busybox-udhcpc \
- busybox-syslog busybox-mdev busybox-hwclock busybox-dbg \
- busybox-staticdev busybox-dev busybox-doc busybox-locale busybox
- </literallayout>
- </para>
-
- <para>
- Finally, for those recipes fetched from a version control
- system (e.g., Git), a file exists that lists source revisions
- that are specified in the recipe and lists the actual revisions
- used during the build.
- Listed and actual revisions might differ when
- <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
- is set to
- <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>.
- Here is an example assuming
- <filename>buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev</filename>):
- <literallayout class='monospaced'>
- # SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
- SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
- # SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
- SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
- </literallayout>
- You can use the <filename>buildhistory-collect-srcrevs</filename>
- command with the <filename>-a</filename> option to
- collect the stored <filename>SRCREV</filename> values
- from build history and report them in a format suitable for
- use in global configuration (e.g.,
- <filename>local.conf</filename> or a distro include file) to
- override floating <filename>AUTOREV</filename> values to a
- fixed set of revisions.
- Here is some example output from this command:
- <literallayout class='monospaced'>
- $ buildhistory-collect-srcrevs -a
- # i586-poky-linux
- SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
- SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
- SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
- SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
- # x86_64-linux
- SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
- SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
- SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
- SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
- SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
- SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
- SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
- SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
- SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
- # qemux86-poky-linux
- SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
- SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
- # all-poky-linux
- SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
- </literallayout>
- <note>
- Here are some notes on using the
- <filename>buildhistory-collect-srcrevs</filename> command:
- <itemizedlist>
- <listitem><para>By default, only values where the
- <filename>SRCREV</filename> was
- not hardcoded (usually when <filename>AUTOREV</filename>
- was used) are reported.
- Use the <filename>-a</filename> option to see all
- <filename>SRCREV</filename> values.
- </para></listitem>
- <listitem><para>The output statements might not have any effect
- if overrides are applied elsewhere in the build system
- configuration.
- Use the <filename>-f</filename> option to add the
- <filename>forcevariable</filename> override to each output line
- if you need to work around this restriction.
- </para></listitem>
- <listitem><para>The script does apply special handling when
- building for multiple machines.
- However, the script does place a
- comment before each set of values that specifies
- which triplet to which they belong as shown above
- (e.g., <filename>i586-poky-linux</filename>).
- </para></listitem>
- </itemizedlist>
- </note>
- </para>
- </section>
-
- <section id='build-history-image-information'>
- <title>Build History Image Information</title>
-
- <para>
- The files produced for each image are as follows:
- <itemizedlist>
- <listitem><para><filename>image-files:</filename>
- A directory containing selected files from the root
- filesystem.
- The files are defined by
- <link linkend='var-BUILDHISTORY_IMAGE_FILES'><filename>BUILDHISTORY_IMAGE_FILES</filename></link>.
- </para></listitem>
- <listitem><para><filename>build-id.txt:</filename>
- Human-readable information about the build configuration
- and metadata source revisions.
- This file contains the full build header as printed
- by BitBake.</para></listitem>
- <listitem><para><filename>*.dot:</filename>
- Dependency graphs for the image that are
- compatible with <filename>graphviz</filename>.
- </para></listitem>
- <listitem><para><filename>files-in-image.txt:</filename>
- A list of files in the image with permissions,
- owner, group, size, and symlink information.
- </para></listitem>
- <listitem><para><filename>image-info.txt:</filename>
- A text file containing name-value pairs with information
- about the image.
- See the following listing example for more information.
- </para></listitem>
- <listitem><para><filename>installed-package-names.txt:</filename>
- A list of installed packages by name only.</para></listitem>
- <listitem><para><filename>installed-package-sizes.txt:</filename>
- A list of installed packages ordered by size.
- </para></listitem>
- <listitem><para><filename>installed-packages.txt:</filename>
- A list of installed packages with full package
- filenames.</para></listitem>
- </itemizedlist>
- <note>
- Installed package information is able to be gathered and
- produced even if package management is disabled for the final
- image.
- </note>
- </para>
-
- <para>
- Here is an example of <filename>image-info.txt</filename>:
- <literallayout class='monospaced'>
- DISTRO = poky
- DISTRO_VERSION = 1.7
- USER_CLASSES = buildstats image-mklibs image-prelink
- IMAGE_CLASSES = image_types
- IMAGE_FEATURES = debug-tweaks
- IMAGE_LINGUAS =
- IMAGE_INSTALL = packagegroup-core-boot run-postinsts
- BAD_RECOMMENDATIONS =
- NO_RECOMMENDATIONS =
- PACKAGE_EXCLUDE =
- ROOTFS_POSTPROCESS_COMMAND = write_package_manifest; license_create_manifest; \
- write_image_manifest ; buildhistory_list_installed_image ; \
- buildhistory_get_image_installed ; ssh_allow_empty_password; \
- postinst_enable_logging; rootfs_update_timestamp ; ssh_disable_dns_lookup ;
- IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
- IMAGESIZE = 6900
- </literallayout>
- Other than <filename>IMAGESIZE</filename>, which is the
- total size of the files in the image in Kbytes, the
- name-value pairs are variables that may have influenced the
- content of the image.
- This information is often useful when you are trying to determine
- why a change in the package or file listings has occurred.
- </para>
- </section>
-
- <section id='using-build-history-to-gather-image-information-only'>
- <title>Using Build History to Gather Image Information Only</title>
-
- <para>
- As you can see, build history produces image information,
- including dependency graphs, so you can see why something
- was pulled into the image.
- If you are just interested in this information and not
- interested in collecting specific package or SDK information,
- you can enable writing only image information without
- any history by adding the following to your
- <filename>conf/local.conf</filename> file found in the
- <link linkend='build-directory'>Build Directory</link>:
- <literallayout class='monospaced'>
- INHERIT += "buildhistory"
- BUILDHISTORY_COMMIT = "0"
- BUILDHISTORY_FEATURES = "image"
- </literallayout>
- Here, you set the
- <link linkend='var-BUILDHISTORY_FEATURES'><filename>BUILDHISTORY_FEATURES</filename></link>
- variable to use the image feature only.
- </para>
- </section>
-
- <section id='build-history-sdk-information'>
- <title>Build History SDK Information</title>
-
- <para>
- Build history collects similar information on the contents
- of SDKs
- (e.g. <filename>bitbake -c populate_sdk imagename</filename>)
- as compared to information it collects for images.
- Furthermore, this information differs depending on whether an
- extensible or standard SDK is being produced.
- </para>
-
- <para>
- The following list shows the files produced for SDKs:
- <itemizedlist>
- <listitem><para><filename>files-in-sdk.txt:</filename>
- A list of files in the SDK with permissions,
- owner, group, size, and symlink information.
- This list includes both the host and target parts
- of the SDK.
- </para></listitem>
- <listitem><para><filename>sdk-info.txt:</filename>
- A text file containing name-value pairs with information
- about the SDK.
- See the following listing example for more information.
- </para></listitem>
- <listitem><para><filename>sstate-task-sizes.txt:</filename>
- A text file containing name-value pairs with information
- about task group sizes
- (e.g. <filename>do_populate_sysroot</filename> tasks
- have a total size).
- The <filename>sstate-task-sizes.txt</filename> file
- exists only when an extensible SDK is created.
- </para></listitem>
- <listitem><para><filename>sstate-package-sizes.txt:</filename>
- A text file containing name-value pairs with information
- for the shared-state packages and sizes in the SDK.
- The <filename>sstate-package-sizes.txt</filename> file
- exists only when an extensible SDK is created.
- </para></listitem>
- <listitem><para><filename>sdk-files:</filename>
- A folder that contains copies of the files mentioned in
- <filename>BUILDHISTORY_SDK_FILES</filename> if the
- files are present in the output.
- Additionally, the default value of
- <filename>BUILDHISTORY_SDK_FILES</filename> is specific
- to the extensible SDK although you can set it
- differently if you would like to pull in specific files
- from the standard SDK.</para>
- <para>The default files are
- <filename>conf/local.conf</filename>,
- <filename>conf/bblayers.conf</filename>,
- <filename>conf/auto.conf</filename>,
- <filename>conf/locked-sigs.inc</filename>, and
- <filename>conf/devtool.conf</filename>.
- Thus, for an extensible SDK, these files get copied
- into the <filename>sdk-files</filename> directory.
- </para></listitem>
- <listitem><para>The following information appears under
- each of the <filename>host</filename>
- and <filename>target</filename> directories
- for the portions of the SDK that run on the host and
- on the target, respectively:
- <note>
- The following files for the most part are empty
- when producing an extensible SDK because this
- type of SDK is not constructed from packages as is
- the standard SDK.
- </note>
- <itemizedlist>
- <listitem><para><filename>depends.dot:</filename>
- Dependency graph for the SDK that is
- compatible with <filename>graphviz</filename>.
- </para></listitem>
- <listitem><para><filename>installed-package-names.txt:</filename>
- A list of installed packages by name only.
- </para></listitem>
- <listitem><para><filename>installed-package-sizes.txt:</filename>
- A list of installed packages ordered by size.
- </para></listitem>
- <listitem><para><filename>installed-packages.txt:</filename>
- A list of installed packages with full package
- filenames.</para></listitem>
- </itemizedlist>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Here is an example of <filename>sdk-info.txt</filename>:
- <literallayout class='monospaced'>
- DISTRO = poky
- DISTRO_VERSION = 1.3+snapshot-20130327
- SDK_NAME = poky-glibc-i686-arm
- SDK_VERSION = 1.3+snapshot
- SDKMACHINE =
- SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
- BAD_RECOMMENDATIONS =
- SDKSIZE = 352712
- </literallayout>
- Other than <filename>SDKSIZE</filename>, which is the
- total size of the files in the SDK in Kbytes, the
- name-value pairs are variables that might have influenced the
- content of the SDK.
- This information is often useful when you are trying to
- determine why a change in the package or file listings
- has occurred.
- </para>
- </section>
-
- <section id='examining-build-history-information'>
- <title>Examining Build History Information</title>
-
- <para>
- You can examine build history output from the command line or
- from a web interface.
- </para>
-
- <para>
- To see any changes that have occurred (assuming you have
- <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT = "1"</filename></link>),
- you can simply
- use any Git command that allows you to view the history of
- a repository.
- Here is one method:
- <literallayout class='monospaced'>
- $ git log -p
- </literallayout>
- You need to realize, however, that this method does show
- changes that are not significant (e.g. a package's size
- changing by a few bytes).
- </para>
-
- <para>
- A command-line tool called <filename>buildhistory-diff</filename>
- does exist, though, that queries the Git repository and prints just
- the differences that might be significant in human-readable form.
- Here is an example:
- <literallayout class='monospaced'>
- $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
- Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
- /etc/anotherpkg.conf was added
- /sbin/anotherpkg was added
- * (installed-package-names.txt):
- * anotherpkg was added
- Changes to images/qemux86_64/glibc/core-image-minimal (installed-package-names.txt):
- anotherpkg was added
- packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
- * PR changed from "r0" to "r1"
- * PV changed from "0.1.10" to "0.1.12"
- packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
- * PR changed from "r0" to "r1"
- * PV changed from "0.1.10" to "0.1.12"
- </literallayout>
- <note>
- The <filename>buildhistory-diff</filename> tool requires
- the <filename>GitPython</filename> package.
- Be sure to install it using Pip3 as follows:
- <literallayout class='monospaced'>
- $ pip3 install GitPython --user
- </literallayout>
- Alternatively, you can install
- <filename>python3-git</filename> using the appropriate
- distribution package manager (e.g.
- <filename>apt-get</filename>, <filename>dnf</filename>, or
- <filename>zipper</filename>).
- </note>
- </para>
-
- <para>
- To see changes to the build history using a web interface, follow
- the instruction in the <filename>README</filename> file here.
- <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/'></ulink>.
- </para>
-
- <para>
- Here is a sample screenshot of the interface:
- <imagedata fileref="figures/buildhistory-web.png" align="center" scalefit="1" width="130%" contentdepth="130%" />
- </para>
- </section>
- </section>
-</section>
-
-<section id='speeding-up-the-build'>
- <title>Speeding Up the Build</title>
-
- <para>
- Build time can be an issue.
- By default, the build system uses simple controls to try and maximize
- build efficiency.
- In general, the default settings for all the following variables
- result in the most efficient build times when dealing with single
- socket systems (i.e. a single CPU).
- If you have multiple CPUs, you might try increasing the default
- values to gain more speed.
- See the descriptions in the glossary for each variable for more
- information:
- <itemizedlist>
- <listitem><para>
- <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename>:</link>
- The maximum number of threads BitBake simultaneously executes.
- </para></listitem>
- <listitem><para>
- <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS'><filename>BB_NUMBER_PARSE_THREADS</filename>:</ulink>
- The number of threads BitBake uses during parsing.
- </para></listitem>
- <listitem><para>
- <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename>:</link>
- Extra options passed to the <filename>make</filename> command
- during the
- <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
- task in order to specify parallel compilation on the
- local build host.
- </para></listitem>
- <listitem><para>
- <link linkend='var-PARALLEL_MAKEINST'><filename>PARALLEL_MAKEINST</filename>:</link>
- Extra options passed to the <filename>make</filename> command
- during the
- <link linkend='ref-tasks-install'><filename>do_install</filename></link>
- task in order to specify parallel installation on the
- local build host.
- </para></listitem>
- </itemizedlist>
- As mentioned, these variables all scale to the number of processor
- cores available on the build system.
- For single socket systems, this auto-scaling ensures that the build
- system fundamentally takes advantage of potential parallel operations
- during the build based on the build machine's capabilities.
- </para>
-
- <para>
- Following are additional factors that can affect build speed:
- <itemizedlist>
- <listitem><para>
- File system type:
- The file system type that the build is being performed on can
- also influence performance.
- Using <filename>ext4</filename> is recommended as compared
- to <filename>ext2</filename> and <filename>ext3</filename>
- due to <filename>ext4</filename> improved features
- such as extents.
- </para></listitem>
- <listitem><para>
- Disabling the updating of access time using
- <filename>noatime</filename>:
- The <filename>noatime</filename> mount option prevents the
- build system from updating file and directory access times.
- </para></listitem>
- <listitem><para>
- Setting a longer commit:
- Using the "commit=" mount option increases the interval
- in seconds between disk cache writes.
- Changing this interval from the five second default to
- something longer increases the risk of data loss but decreases
- the need to write to the disk, thus increasing the build
- performance.
- </para></listitem>
- <listitem><para>
- Choosing the packaging backend:
- Of the available packaging backends, IPK is the fastest.
- Additionally, selecting a singular packaging backend also
- helps.
- </para></listitem>
- <listitem><para>
- Using <filename>tmpfs</filename> for
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
- as a temporary file system:
- While this can help speed up the build, the benefits are
- limited due to the compiler using
- <filename>-pipe</filename>.
- The build system goes to some lengths to avoid
- <filename>sync()</filename> calls into the
- file system on the principle that if there was a significant
- failure, the
- <link linkend='build-directory'>Build Directory</link>
- contents could easily be rebuilt.
- </para></listitem>
- <listitem><para>
- Inheriting the
- <link linkend='ref-classes-rm-work'><filename>rm_work</filename></link>
- class:
- Inheriting this class has shown to speed up builds due to
- significantly lower amounts of data stored in the data
- cache as well as on disk.
- Inheriting this class also makes cleanup of
- <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
- faster, at the expense of being easily able to dive into the
- source code.
- File system maintainers have recommended that the fastest way
- to clean up large numbers of files is to reformat partitions
- rather than delete files due to the linear nature of partitions.
- This, of course, assumes you structure the disk partitions and
- file systems in a way that this is practical.
- </para></listitem>
- </itemizedlist>
- Aside from the previous list, you should keep some trade offs in
- mind that can help you speed up the build:
- <itemizedlist>
- <listitem><para>
- Remove items from
- <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
- that you might not need.
- </para></listitem>
- <listitem><para>
- Exclude debug symbols and other debug information:
- If you do not need these symbols and other debug information,
- disabling the <filename>*-dbg</filename> package generation
- can speed up the build.
- You can disable this generation by setting the
- <link linkend='var-INHIBIT_PACKAGE_DEBUG_SPLIT'><filename>INHIBIT_PACKAGE_DEBUG_SPLIT</filename></link>
- variable to "1".
- </para></listitem>
- <listitem><para>
- Disable static library generation for recipes derived from
- <filename>autoconf</filename> or <filename>libtool</filename>:
- Following is an example showing how to disable static
- libraries and still provide an override to handle exceptions:
- <literallayout class='monospaced'>
- STATICLIBCONF = "--disable-static"
- STATICLIBCONF_sqlite3-native = ""
- EXTRA_OECONF += "${STATICLIBCONF}"
- </literallayout>
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- Some recipes need static libraries in order to work
- correctly (e.g. <filename>pseudo-native</filename>
- needs <filename>sqlite3-native</filename>).
- Overrides, as in the previous example, account for
- these kinds of exceptions.
- </para></listitem>
- <listitem><para>
- Some packages have packaging code that assumes the
- presence of the static libraries.
- If so, you might need to exclude them as well.
- </para></listitem>
- </itemizedlist>
- </note>
- </para></listitem>
- </itemizedlist>
- </para>
-</section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
