documentation: Part 1 of 2 updates to integrating docs to Eclipse help.

Hi,

the generation of eclipse help files has been merged from the timo
branch to the master. Since the creation of the timo branch there have
been some changes to the master branch (e.g. new documentation,
renamed documentation).

This patch set does some cleanup for the renamed documentation and
adds eclipse help generation support to the new documentation.

01: Removes the 'the' from the document titles
02..04: Cleanup obsolete artifacts resulting from the merge
05..08: Add eclipse help generation for ref-manual
09..13: Add eclipse help generation for kernel-dev
14..18: Add eclipse help generation for profile-manual

Best regards,
Timo

This patch set originally contained 18 patches. I (Scott Rifenbark)
had to push these changes as two parts.  This is the first part.
It does not include creation of the three cusomization files.

(From yocto-docs rev: 9b1889f6e31ee70dae704fa08763fb9196616dad)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Timo Mueller 2013-02-08 09:16:33 -06:00 committed by Richard Purdie
parent 7681523408
commit a41a805500
194 changed files with 35 additions and 11175 deletions

View File

@ -227,13 +227,8 @@ STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),profile-manual)
XSLTOPTS = --stringparam html.stylesheet profile-manual-style.css \
--stringparam chapter.autolabel 1 \
--stringparam appendix.autolabel A \
--stringparam section.autolabel 1 \
--stringparam section.label.includes.component.label 1 \
--xinclude
ALLPREQ = html pdf tarball
XSLTOPTS = --xinclude
ALLPREQ = html pdf eclipse tarball
TARFILES = profile-manual.html profile-manual.pdf profile-manual-style.css \
figures/profile-title.png figures/kernelshark-all.png \
figures/kernelshark-choose-events.png figures/kernelshark-i915-display.png \
@ -323,9 +318,17 @@ eclipse: eclipse-generate eclipse-resolve-links
.PHONY : eclipse-generate eclipse-resolve-links
eclipse-generate:
ifeq ($(DOC),mega-manual)
ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual yocto-project-qs),)
@echo " "
@echo "ERROR: You cannot generate eclipse documentation for the mega-manual"
@echo "ERROR: You can only create eclipse documentation"
@echo " of the following documentation parts:"
@echo " - adt-manual"
@echo " - bsp-guide"
@echo " - dev-manual"
@echo " - kernel-dev"
@echo " - profile-manual"
@echo " - ref-manual"
@echo " - yocto-project-qs"
@echo " "
else
@echo " "

View File

@ -17,7 +17,7 @@
</mediaobject>
<title>
The Yocto Project Application Developer's Guide
Yocto Project Application Developer's Guide
</title>
<authorgroup>

View File

@ -17,7 +17,7 @@
</mediaobject>
<title>
The Yocto Project Board Support Package Developer's Guide
Yocto Project Board Support Package Developer's Guide
</title>
<authorgroup>

View File

@ -17,7 +17,7 @@
</mediaobject>
<title>
The Yocto Project Development Manual
Yocto Project Development Manual
</title>
<authorgroup>

View File

@ -1,8 +1,11 @@
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
<!-- <xsl:param name="generate.toc" select="'article nop'"></xsl:param> -->
<xsl:param name="html.stylesheet" select="'kernel-dev-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel">A</xsl:param>
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
</xsl:stylesheet>

View File

@ -16,7 +16,9 @@
</imageobject>
</mediaobject>
<title></title>
<title>
Yocto Project Linux Kernel Development Manual
</title>
<authorgroup>
<author>

View File

@ -1,27 +0,0 @@
<?xml version='1.0'?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
version="1.0">
<xsl:import
href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
<xsl:param name="chunker.output.indent" select="'yes'"/>
<xsl:param name="chunk.quietly" select="1"/>
<xsl:param name="chunk.first.sections" select="1"/>
<xsl:param name="chunk.section.depth" select="10"/>
<xsl:param name="use.id.as.filename" select="1"/>
<xsl:param name="ulink.target" select="'_self'" />
<xsl:param name="base.dir" select="'html/poky-ref-manual/'"/>
<xsl:param name="html.stylesheet" select="'../book.css'"/>
<xsl:param name="eclipse.manifest" select="0"/>
<xsl:param name="create.plugin.xml" select="0"/>
<xsl:param name="suppress.navigation" select="1"/>
<xsl:param name="generate.index" select="0"/>
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel" select="A" />
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
</xsl:stylesheet>

View File

@ -1,8 +1,11 @@
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
<!-- <xsl:param name="generate.toc" select="'article nop'"></xsl:param> -->
<xsl:param name="html.stylesheet" select="'profile-manual-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel">A</xsl:param>
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
</xsl:stylesheet>

View File

@ -16,7 +16,9 @@
</imageobject>
</mediaobject>
<title></title>
<title>
Yocto Project Profiling and Tracing Manual
</title>
<authorgroup>
<author>

View File

@ -1,21 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.1. Local Configuration</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="moving-to-the-yocto-project-1.3-release.html" title="4.1. Moving to the Yocto Project 1.3 Release">
<link rel="prev" href="moving-to-the-yocto-project-1.3-release.html" title="4.1. Moving to the Yocto Project 1.3 Release">
<link rel="next" href="migration-1.3-sstate-mirrors.html" title="4.1.1.1. SSTATE_MIRRORS">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.1. Local Configuration">
<div class="titlepage"><div><div><h3 class="title">
<a name="1.3-local-configuration"></a>4.1.1. Local Configuration</h3></div></div></div>
<p>
Differences include changes for
<a class="link" href="ref-variables-glos.html#var-SSTATE_MIRRORS" title="SSTATE_MIRRORS"><code class="filename">SSTATE_MIRRORS</code></a>
and <code class="filename">bblayers.conf</code>.
</p>
</div></body>
</html>

View File

@ -1,29 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2. Recipes</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="moving-to-the-yocto-project-1.3-release.html" title="4.1. Moving to the Yocto Project 1.3 Release">
<link rel="prev" href="migration-1.3-bblayers-conf.html" title="4.1.1.2. bblayers.conf">
<link rel="next" href="migration-1.3-python-function-whitespace.html" title="4.1.2.1. Python Function Whitespace">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2. Recipes">
<div class="titlepage"><div><div><h3 class="title">
<a name="1.3-recipes"></a>4.1.2. Recipes</h3></div></div></div>
<p>
Differences include changes for the following:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>Python function whitespace</p></li>
<li class="listitem"><p><code class="filename">proto=</code> in <code class="filename">SRC_URI</code></p></li>
<li class="listitem"><p><code class="filename">nativesdk</code></p></li>
<li class="listitem"><p>Task recipes</p></li>
<li class="listitem"><p><code class="filename">IMAGE_FEATURES</code></p></li>
<li class="listitem"><p>Removed recipes</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,80 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.4.2.2. Build History Image Information</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="understanding-what-the-build-history-contains.html" title="2.4.2. Understanding What the Build History Contains">
<link rel="prev" href="build-history-package-information.html" title="2.4.2.1. Build History Package Information">
<link rel="next" href="using-build-history-to-gather-image-information-only.html" title="2.4.2.3. Using Build History to Gather Image Information Only">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.2.2. Build History Image Information">
<div class="titlepage"><div><div><h4 class="title">
<a name="build-history-image-information"></a>2.4.2.2. Build History Image Information</h4></div></div></div>
<p>
The files produced for each image are as follows:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>build-id:</em></span>
Human-readable information about the build configuration
and metadata source revisions.</p></li>
<li class="listitem"><p><span class="emphasis"><em>*.dot:</em></span>
Dependency graphs for the image that are
compatible with <code class="filename">graphviz</code>.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>files-in-image.txt:</em></span>
A list of files in the image with permissions,
owner, group, size, and symlink information.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>image-info.txt:</em></span>
A text file containing name-value pairs with information
about the image.
See the following listing example for more information.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>installed-package-names.txt:</em></span>
A list of installed packages by name only.</p></li>
<li class="listitem"><p><span class="emphasis"><em>installed-package-sizes.txt:</em></span>
A list of installed packages ordered by size.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>installed-packages.txt:</em></span>
A list of installed packages with fuill package
filenames.</p></li>
</ul></div>
<p>
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Installed package information is able to be gathered and
produced even if package management is disabled for the final
image.
</div>
<p>
</p>
<p>
Here is an example of <code class="filename">image-info.txt</code>:
</p>
<pre class="literallayout">
DISTRO = poky
DISTRO_VERSION = 1.1+snapshot-20120207
USER_CLASSES = image-mklibs image-prelink
IMAGE_CLASSES = image_types
IMAGE_FEATURES = debug-tweaks x11-base apps-x11-core \
package-management ssh-server-dropbear package-management
IMAGE_LINGUAS = en-us en-gb
IMAGE_INSTALL = task-core-boot task-base-extended
BAD_RECOMMENDATIONS =
ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ; rootfs_update_timestamp ;
IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
IMAGESIZE = 171816
</pre>
<p>
Other than <code class="filename">IMAGESIZE</code>, 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.
</p>
</div></body>
</html>

View File

@ -1,58 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.4.2.1. Build History Package Information</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="understanding-what-the-build-history-contains.html" title="2.4.2. Understanding What the Build History Contains">
<link rel="prev" href="understanding-what-the-build-history-contains.html" title="2.4.2. Understanding What the Build History Contains">
<link rel="next" href="build-history-image-information.html" title="2.4.2.2. Build History Image Information">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.2.1. Build History Package Information">
<div class="titlepage"><div><div><h4 class="title">
<a name="build-history-package-information"></a>2.4.2.1. Build History Package Information</h4></div></div></div>
<p>
The history for each package contains a text file that has
name-value pairs with information about the package.
For example, <code class="filename">buildhistory/packages/core2-poky-linux/busybox/busybox/latest</code>
contains the following:
</p>
<pre class="literallayout">
PV = 1.19.3
PR = r3
RDEPENDS = update-rc.d eglibc (&gt;= 2.13)
RRECOMMENDS = busybox-syslog busybox-udhcpc
PKGSIZE = 564701
FILES = /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* \
/etc /com /var /bin/* /sbin/* /lib/*.so.* /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 = /etc/busybox.links /etc/init.d/hwclock.sh /bin/busybox /bin/sh
</pre>
<p>
Most of these name-value pairs corresponds to variables used
to produce the package.
The exceptions are <code class="filename">FILELIST</code>, which is the
actual list of files in the package, and
<code class="filename">PKGSIZE</code>, which is the total size of files
in the package in bytes.
</p>
<p>
There is also a file corresponding to the recipe from which the
package came (e.g.
<code class="filename">buildhistory/packages/core2-poky-linux/busybox/latest</code>):
</p>
<pre class="literallayout">
PV = 1.19.3
PR = r3
DEPENDS = virtual/i586-poky-linux-gcc virtual/i586-poky-linux-compilerlibs \
virtual/libc update-rc.d-native
PACKAGES = busybox-httpd busybox-udhcpd busybox-udhcpc busybox-syslog \
busybox-mdev busybox-dbg busybox busybox-doc busybox-dev \
busybox-staticdev busybox-locale
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,61 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.1.1. Build Overview</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="usingpoky-build.html" title="2.1. Running a Build">
<link rel="prev" href="usingpoky-build.html" title="2.1. Running a Build">
<link rel="next" href="building-an-image-using-gpl-components.html" title="2.1.2. Building an Image Using GPL Components">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.1.1. Build Overview">
<div class="titlepage"><div><div><h3 class="title">
<a name="build-overview"></a>2.1.1. Build Overview</h3></div></div></div>
<p>
The first thing you need to do is set up the OpenEmbedded build environment by sourcing
the <a class="link" href="structure-core-script.html" title="5.1.10. oe-init-build-env">environment setup script</a> as follows:
</p>
<pre class="literallayout">
$ source oe-init-build-env [build_dir]
</pre>
<p>
</p>
<p>
The <code class="filename">build_dir</code> is optional and specifies the directory the
OpenEmbedded build system uses for the build -
the <a class="link" href="../dev-manual/build-directory.html" target="_self">Build Directory</a>.
If you do not specify a Build Directory it defaults to <code class="filename">build</code>
in your current working directory.
A common practice is to use a different Build Directory for different targets.
For example, <code class="filename">~/build/x86</code> for a <code class="filename">qemux86</code>
target, and <code class="filename">~/build/arm</code> for a <code class="filename">qemuarm</code> target.
See <a class="link" href="structure-core-script.html" title="5.1.10. oe-init-build-env">oe-init-build-env</a>
for more information on this script.
</p>
<p>
Once the build environment is set up, you can build a target using:
</p>
<pre class="literallayout">
$ bitbake &lt;target&gt;
</pre>
<p>
</p>
<p>
The <code class="filename">target</code> is the name of the recipe you want to build.
Common targets are the images in <code class="filename">meta/recipes-core/images</code>,
<code class="filename">/meta/recipes-sato/images</code>, etc. all found in the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
Or, the target can be the name of a recipe for a specific piece of software such as
<span class="application">busybox</span>.
For more details about the images the OpenEmbedded build system supports, see the
"<a class="link" href="ref-images.html" title="Chapter 8. Images">Images</a>" chapter.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Building an image without GNU General Public License Version 3 (GPLv3) components
is only supported for minimal and base images.
See the "<a class="link" href="ref-images.html" title="Chapter 8. Images">Images</a>" chapter for more information.
</div>
</div></body>
</html>

View File

@ -1,23 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.1.2. Building an Image Using GPL Components</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="usingpoky-build.html" title="2.1. Running a Build">
<link rel="prev" href="build-overview.html" title="2.1.1. Build Overview">
<link rel="next" href="usingpoky-install.html" title="2.2. Installing and Using the Result">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.1.2. Building an Image Using GPL Components">
<div class="titlepage"><div><div><h3 class="title">
<a name="building-an-image-using-gpl-components"></a>2.1.2. Building an Image Using GPL Components</h3></div></div></div>
<p>
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.
</p>
</div></body>
</html>

View File

@ -1,69 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.3.2.4. CentOS Packages</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="required-packages-for-the-host-development-system.html" title="1.3.2. Required Packages for the Host Development System">
<link rel="prev" href="opensuse-packages.html" title="1.3.2.3. OpenSUSE Packages">
<link rel="next" href="intro-getit.html" title="1.4. Obtaining the Yocto Project">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.3.2.4. CentOS Packages">
<div class="titlepage"><div><div><h4 class="title">
<a name="centos-packages"></a>1.3.2.4. CentOS Packages</h4></div></div></div>
<p>
The following list shows the required packages by function
given a supported CentOS Linux distribution:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p><span class="emphasis"><em>Essentials:</em></span>
Packages needed to build an image for a headless
system:
</p>
<pre class="literallayout">
$ sudo yum -y install gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Graphical Extras:</em></span>
Packages recommended if the host system has graphics support:
</p>
<pre class="literallayout">
$ sudo yum -y install SDL-devel xterm
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Documentation:</em></span>
Packages needed if you are going to build out the
Yocto Project documentation manuals:
</p>
<pre class="literallayout">
$ sudo yum -y install make docbook-style-dsssl docbook-style-xsl \
docbook-dtds docbook-utils fop libxslt
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>ADT Installer Extras:</em></span>
Packages needed if you are going to be using the
<a class="link" href="../adt-manual/using-the-adt-installer.html" target="_self">Application Development Toolkit (ADT) Installer</a>:
</p>
<pre class="literallayout">
$ sudo yum -y install autoconf automake libtool glib2-devel
</pre>
</li>
</ul></div>
<p>
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>Depending on the CentOS version you are using, other requirements
and dependencies might exist.
For details, you should look at the CentOS sections on the
<a class="ulink" href="https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies" target="_self">Poky/GettingStarted/Dependencies</a>
wiki page.</div>
<p>
</p>
</div></body>
</html>

View File

@ -1,164 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.2.2. Checksums (Signatures)</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="shared-state-cache.html" title="3.2. Shared State Cache">
<link rel="prev" href="overall-architecture.html" title="3.2.1. Overall Architecture">
<link rel="next" href="shared-state.html" title="3.2.3. Shared State">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2.2. Checksums (Signatures)">
<div class="titlepage"><div><div><h3 class="title">
<a name="checksums"></a>3.2.2. Checksums (Signatures)</h3></div></div></div>
<p>
The shared state code uses a checksum, which is a unique signature of a task's
inputs, to determine if a task needs to be run again.
Because it is a change in a task's inputs that triggers a rerun, the process
needs to detect all the inputs to a given task.
For shell tasks, this turns out to be fairly easy because
the build process generates a "run" shell script for each task and
it is possible to create a checksum that gives you a good idea of when
the task's data changes.
</p>
<p>
To complicate the problem, there are things that should not be included in
the checksum.
First, there is the actual specific build path of a given task -
the <code class="filename">WORKDIR</code>.
It does not matter if the working directory changes because it should not
affect the output for target packages.
Also, the build process has the objective of making native/cross packages relocatable.
The checksum therefore needs to exclude <code class="filename">WORKDIR</code>.
The simplistic approach for excluding the working directory is to set
<code class="filename">WORKDIR</code> to some fixed value and create the checksum
for the "run" script.
</p>
<p>
Another problem results from the "run" scripts containing functions that
might or might not get called.
The incremental build solution contains code that figures out dependencies
between shell functions.
This code is used to prune the "run" scripts down to the minimum set,
thereby alleviating this problem and making the "run" scripts much more
readable as a bonus.
</p>
<p>
So far we have solutions for shell scripts.
What about python tasks?
The same approach applies even though these tasks are more difficult.
The process needs to figure out what variables a python function accesses
and what functions it calls.
Again, the incremental build solution contains code that first figures out
the variable and function dependencies, and then creates a checksum for the data
used as the input to the task.
</p>
<p>
Like the <code class="filename">WORKDIR</code> case, situations exist where dependencies
should be ignored.
For these cases, you can instruct the build process to ignore a dependency
by using a line like the following:
</p>
<pre class="literallayout">
PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
</pre>
<p>
This example ensures that the <code class="filename">PACKAGE_ARCHS</code> variable does not
depend on the value of <code class="filename">MACHINE</code>, even if it does reference it.
</p>
<p>
Equally, there are cases where we need to add dependencies BitBake is not able to find.
You can accomplish this by using a line like the following:
</p>
<pre class="literallayout">
PACKAGE_ARCHS[vardeps] = "MACHINE"
</pre>
<p>
This example explicitly adds the <code class="filename">MACHINE</code> variable as a
dependency for <code class="filename">PACKAGE_ARCHS</code>.
</p>
<p>
Consider a case with inline python, for example, where BitBake is not
able to figure out dependencies.
When running in debug mode (i.e. using <code class="filename">-DDD</code>), BitBake
produces output when it discovers something for which it cannot figure out
dependencies.
The Yocto Project team has currently not managed to cover those dependencies
in detail and is aware of the need to fix this situation.
</p>
<p>
Thus far, this section has limited discussion to the direct inputs into a task.
Information based on direct inputs is referred to as the "basehash" in the
code.
However, there is still the question of a task's indirect inputs - the
things that were already built and present in the Build Directory.
The checksum (or signature) for a particular task needs to add the hashes
of all the tasks on which the particular task depends.
Choosing which dependencies to add is a policy decision.
However, the effect is to generate a master checksum that combines the basehash
and the hashes of the task's dependencies.
</p>
<p>
At the code level, there are a variety of ways both the basehash and the
dependent task hashes can be influenced.
Within the BitBake configuration file, we can give BitBake some extra information
to help it construct the basehash.
The following statements effectively result in a list of global variable
dependency excludes - variables never included in any checksum:
</p>
<pre class="literallayout">
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
</pre>
<p>
The previous example actually excludes
<a class="link" href="ref-variables-glos.html#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>
since it is actually constructed as a path within
<a class="link" href="ref-variables-glos.html#var-TMPDIR" title="TMPDIR"><code class="filename">TMPDIR</code></a>, which is on
the whitelist.
</p>
<p>
The rules for deciding which hashes of dependent tasks to include through
dependency chains are more complex and are generally accomplished with a
python function.
The code in <code class="filename">meta/lib/oe/sstatesig.py</code> shows two examples
of this and also illustrates how you can insert your own policy into the system
if so desired.
This file defines the two basic signature generators <code class="filename">OE-Core</code>
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.
<code class="filename">OE-Core</code> uses the "OEBasic" signature handler by default
through this setting in the <code class="filename">bitbake.conf</code> file:
</p>
<pre class="literallayout">
BB_SIGNATURE_HANDLER ?= "OEBasic"
</pre>
<p>
The "OEBasicHash" <code class="filename">BB_SIGNATURE_HANDLER</code> is the same as the
"OEBasic" version but adds the task hash to the stamp files.
This results in any metadata change that changes the task hash, automatically
causing the task to be run again.
This removes the need to bump <a class="link" href="ref-variables-glos.html#var-PR" title="PR"><code class="filename">PR</code></a>
values and changes to metadata automatically ripple across the build.
Currently, this behavior is not the default behavior for <code class="filename">OE-Core</code>
but is the default in <code class="filename">poky</code>.
</p>
<p>
It is also worth noting that the end result of these signature generators is to
make some dependency and hash information available to the build.
This information includes:
</p>
<pre class="literallayout">
BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
BB_TASKHASH - the hash of the currently running task
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,43 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.2.4.1. Debugging</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="tips-and-tricks.html" title="3.2.4. Tips and Tricks">
<link rel="prev" href="tips-and-tricks.html" title="3.2.4. Tips and Tricks">
<link rel="next" href="invalidating-shared-state.html" title="3.2.4.2. Invalidating Shared State">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2.4.1. Debugging">
<div class="titlepage"><div><div><h4 class="title">
<a name="debugging"></a>3.2.4.1. Debugging</h4></div></div></div>
<p>
When things go wrong, debugging needs to be straightforward.
Because of this, the Yocto Project team included strong debugging
tools:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>Whenever a shared state package is written out, so is a
corresponding <code class="filename">.siginfo</code> file.
This practice results in a pickled python database of all
the metadata that went into creating the hash for a given shared state
package.</p></li>
<li class="listitem"><p>If BitBake is run with the <code class="filename">--dump-signatures</code>
(or <code class="filename">-S</code>) option, BitBake dumps out
<code class="filename">.siginfo</code> files in
the stamp directory for every task it would have executed instead of
building the specified target package.</p></li>
<li class="listitem"><p>There is a <code class="filename">bitbake-diffsigs</code> command that
can process these <code class="filename">.siginfo</code> files.
If one file is specified, it will dump out the dependency
information in the file.
If two files are specified, it will compare the two files and dump out
the differences between the two.
This allows the question of "What changed between X and Y?" to be
answered easily.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,45 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.3.1. Supported Linux Distributions</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="intro-requirements.html" title="1.3. System Requirements">
<link rel="prev" href="intro-requirements.html" title="1.3. System Requirements">
<link rel="next" href="required-packages-for-the-host-development-system.html" title="1.3.2. Required Packages for the Host Development System">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.3.1. Supported Linux Distributions">
<div class="titlepage"><div><div><h3 class="title">
<a name="detailed-supported-distros"></a>1.3.1. Supported Linux Distributions</h3></div></div></div>
<p>
Currently, the Yocto Project is supported on the following distributions:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>Ubuntu 10.04.4 LTS</p></li>
<li class="listitem"><p>Ubuntu 11.10</p></li>
<li class="listitem"><p>Ubuntu 12.04.1 LTS</p></li>
<li class="listitem"><p>Ubuntu 12.04.1 LTS</p></li>
<li class="listitem"><p>Ubuntu 12.10</p></li>
<li class="listitem"><p>Fedora release 16 (Verne)</p></li>
<li class="listitem"><p>Fedora release 17 (Beefy Miracle)</p></li>
<li class="listitem"><p>Fedora release 18 (Spherical Cow)</p></li>
<li class="listitem"><p>CentOS release 5.6 (Final)</p></li>
<li class="listitem"><p>CentOS release 5.7 (Final)</p></li>
<li class="listitem"><p>CentOS release 5.8 (Final)</p></li>
<li class="listitem"><p>CentOS release 6.3 (Final)</p></li>
<li class="listitem"><p>Debian GNU/Linux 6.0.6 (squeeze)</p></li>
<li class="listitem"><p>openSUSE 11.4</p></li>
<li class="listitem"><p>openSUSE 12.1</p></li>
<li class="listitem"><p>openSUSE 12.2</p></li>
</ul></div>
<p>
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
For additional information on distributions that support the
Yocto Project, see the
<a class="ulink" href="https://wiki.yoctoproject.org/wiki/Distribution_Support" target="_self">Distribution Support</a> wiki page.
</div>
</div></body>
</html>

View File

@ -1,62 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.4.1. Enabling and Disabling Build History</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="maintaining-build-output-quality.html" title="2.4. Maintaining Build Output Quality">
<link rel="prev" href="maintaining-build-output-quality.html" title="2.4. Maintaining Build Output Quality">
<link rel="next" href="understanding-what-the-build-history-contains.html" title="2.4.2. Understanding What the Build History Contains">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.1. Enabling and Disabling Build History">
<div class="titlepage"><div><div><h3 class="title">
<a name="enabling-and-disabling-build-history"></a>2.4.1. Enabling and Disabling Build History</h3></div></div></div>
<p>
Build history is disabled by default.
To enable it, add the following statements to the end of your
<code class="filename">conf/local.conf</code> file found in the
<a class="link" href="../dev-manual/build-directory.html" target="_self">Build Directory</a>:
</p>
<pre class="literallayout">
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
</pre>
<p>
Enabling build history as previously described
causes the build process to collect build
output information and commit it to a local
<a class="link" href="../dev-manual/git.html" target="_self">Git</a> repository.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Enabling build history increases your build times slightly,
particularly for images, and increases the amount of disk
space used during the build.
</div>
<p>
</p>
<p>
You can disable build history by removing the previous statements
from your <code class="filename">conf/local.conf</code> file.
However, you should realize that enabling and disabling
build history in this manner can change the
<code class="filename">do_package</code> task checksums, which if you
are using the OEBasicHash signature generator (the default
for many current distro configurations including
<code class="filename">DISTRO = "poky"</code> and
<code class="filename">DISTRO = ""</code>) will result in the packaging
tasks being re-run during the subsequent build.
</p>
<p>
To disable the build history functionality without causing the
packaging tasks to be re-run, add just this statement to your
<code class="filename">conf/local.conf</code> file:
</p>
<pre class="literallayout">
BUILDHISTORY_FEATURES = ""
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,85 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.4.2. Enabling Commercially Licensed Recipes</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="licenses.html" title="3.4. Licenses">
<link rel="prev" href="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html" title="3.4.1.2. Explanation of Syntax">
<link rel="next" href="license-flag-matching.html" title="3.4.2.1. License Flag Matching">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4.2. Enabling Commercially Licensed Recipes">
<div class="titlepage"><div><div><h3 class="title">
<a name="enabling-commercially-licensed-recipes"></a>3.4.2. Enabling Commercially Licensed Recipes</h3></div></div></div>
<p>
By default, the OpenEmbedded build system disables
components that have commercial or other special licensing
requirements.
Such requirements are defined on a
recipe-by-recipe basis through the <code class="filename">LICENSE_FLAGS</code> variable
definition in the affected recipe.
For instance, the
<code class="filename">$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
recipe contains the following statement:
</p>
<pre class="literallayout">
LICENSE_FLAGS = "commercial"
</pre>
<p>
Here is a slightly more complicated example that contains both an
explicit recipe name and version (after variable expansion):
</p>
<pre class="literallayout">
LICENSE_FLAGS = "license_${PN}_${PV}"
</pre>
<p>
In order for a component restricted by a <code class="filename">LICENSE_FLAGS</code>
definition to be enabled and included in an image, it
needs to have a matching entry in the global
<code class="filename">LICENSE_FLAGS_WHITELIST</code> variable, which is a variable
typically defined in your <code class="filename">local.conf</code> file.
For example, to enable
the <code class="filename">$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code>
package, you could add either the string
"commercial_gst-plugins-ugly" or the more general string
"commercial" to <code class="filename">LICENSE_FLAGS_WHITELIST</code>.
See the
"<a class="link" href="license-flag-matching.html" title="3.4.2.1. License Flag Matching">License Flag Matching</a>" section
for a full explanation of how <code class="filename">LICENSE_FLAGS</code> matching works.
Here is the example:
</p>
<pre class="literallayout">
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
</pre>
<p>
Likewise, to additionally enable the package built from the recipe containing
<code class="filename">LICENSE_FLAGS = "license_${PN}_${PV}"</code>, and assuming
that the actual recipe name was <code class="filename">emgd_1.10.bb</code>,
the following string would enable that package as well as
the original <code class="filename">gst-plugins-ugly</code> package:
</p>
<pre class="literallayout">
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
</pre>
<p>
As a convenience, you do not need to specify the complete license string
in the whitelist for every package.
you can use an abbreviated form, which consists
of just the first portion or portions of the license string before
the initial underscore character or characters.
A partial string will match
any license that contains the given string as the first
portion of its license.
For example, the following
whitelist string will also match both of the packages
previously mentioned as well as any other packages that have
licenses starting with "commercial" or "license".
</p>
<pre class="literallayout">
LICENSE_FLAGS_WHITELIST = "commercial license"
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,70 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.4.2.4. Examining Build History Information</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="understanding-what-the-build-history-contains.html" title="2.4.2. Understanding What the Build History Contains">
<link rel="prev" href="using-build-history-to-gather-image-information-only.html" title="2.4.2.3. Using Build History to Gather Image Information Only">
<link rel="next" href="technical-details.html" title="Chapter 3. Technical Details">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.2.4. Examining Build History Information">
<div class="titlepage"><div><div><h4 class="title">
<a name="examining-build-history-information"></a>2.4.2.4. Examining Build History Information</h4></div></div></div>
<p>
You can examine build history output from the command line or
from a web interface.
</p>
<p>
To see any changes that have occurred (assuming you have
<code class="filename">BUILDHISTORY_COMMIT = "1"</code>), you can simply
use any Git command that allows you to view the history of
a repository.
Here is one method:
</p>
<pre class="literallayout">
$ git log -p
</pre>
<p>
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).
</p>
<p>
A command-line tool called <code class="filename">buildhistory-diff</code>
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:
</p>
<pre class="literallayout">
$ ~/poky/poky/scripts/buildhistory-diff . HEAD^
Changes to images/qemux86_64/eglibc/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/eglibc/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"
</pre>
<p>
</p>
<p>
To see changes to the build history using a web interface, follow
the instruction in the <code class="filename">README</code> file here.
<a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/" target="_self">http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/</a>.
</p>
<p>
Here is a sample screenshot of the interface:
</p>
<table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="130%"><tr><td align="center"><img src="figures/buildhistory-web.png" align="middle" height="468"></td></tr></table>
<p>
</p>
</div></body>
</html>

View File

@ -1,791 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 12. FAQ</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="ref-varlocality-recipe-build.html" title="11.2.4. Extra Build Information">
<link rel="next" href="resources.html" title="Chapter 13. Contributing to the Yocto Project">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 12. FAQ">
<div class="titlepage"><div><div><h2 class="title">
<a name="faq"></a>Chapter 12. FAQ</h2></div></div></div>
<div class="qandaset" title="Frequently Asked Questions">
<a name="idm1966160"></a><dl>
<dt>12.1. <a href="faq.html#idm1965696">
How does Poky differ from OpenEmbedded?
</a>
</dt>
<dt>12.2. <a href="faq.html#idm1961792">
I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7.
Can I still use the Yocto Project?
</a>
</dt>
<dt>12.3. <a href="faq.html#idm2605168">
How can you claim Poky / OpenEmbedded-Core is stable?
</a>
</dt>
<dt>12.4. <a href="faq.html#idm3232752">
How do I get support for my board added to the Yocto Project?
</a>
</dt>
<dt>12.5. <a href="faq.html#idm3230416">
Are there any products built using the OpenEmbedded build system?
</a>
</dt>
<dt>12.6. <a href="faq.html#idm3227696">
What does the OpenEmbedded build system produce as output?
</a>
</dt>
<dt>12.7. <a href="faq.html#idm5359408">
How do I add my package to the Yocto Project?
</a>
</dt>
<dt>12.8. <a href="faq.html#idm5357680">
Do I have to reflash my entire board with a new Yocto Project image when recompiling
a package?
</a>
</dt>
<dt>12.9. <a href="faq.html#idm5354224">
What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
</a>
</dt>
<dt>12.10. <a href="faq.html#idm2088960">
I see the error 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'.
What is wrong?
</a>
</dt>
<dt>12.11. <a href="faq.html#idm2085168">
How do I make the Yocto Project work in RHEL/CentOS?
</a>
</dt>
<dt>12.12. <a href="faq.html#idm3829808">
I see lots of 404 responses for files on
http://www.yoctoproject.org/sources/*. Is something wrong?
</a>
</dt>
<dt>12.13. <a href="faq.html#idm3827408">
I have machine-specific data in a package for one machine only but the package is
being marked as machine-specific in all cases, how do I prevent this?
</a>
</dt>
<dt>12.14. <a href="faq.html#idm5331776">
I'm behind a firewall and need to use a proxy server. How do I do that?
</a>
</dt>
<dt>12.15. <a href="faq.html#idm1524432">
What&#8217;s the difference between foo and foo-native?
</a>
</dt>
<dt>12.16. <a href="faq.html#idm1520336">
I'm seeing random build failures. Help?!
</a>
</dt>
<dt>12.17. <a href="faq.html#idm4636672">
What do we need to ship for license compliance?
</a>
</dt>
<dt>12.18. <a href="faq.html#idm4635216">
How do I disable the cursor on my touchscreen device?
</a>
</dt>
<dt>12.19. <a href="faq.html#idm4631744">
How do I make sure connected network interfaces are brought up by default?
</a>
</dt>
<dt>12.20. <a href="faq.html#idm3888832">
How do I create images with more free space?
</a>
</dt>
<dt>12.21. <a href="faq.html#idm619504">
Why don't you support directories with spaces in the pathnames?
</a>
</dt>
<dt>12.22. <a href="faq.html#idm617456">
How do I use an external toolchain?
</a>
</dt>
<dt>12.23. <a href="faq.html#idm4577168">
How does the OpenEmbedded build system obtain source code and will it work behind my
firewall or proxy server?
</a>
</dt>
<dt>12.24. <a href="faq.html#idm3953616">
Can I get rid of build output so I can start over?
</a>
</dt>
</dl>
<table border="0" width="100%" summary="Q and A Set">
<col align="left" width="1%">
<col>
<tbody>
<tr class="question" title="12.1.">
<td align="left" valign="top">
<a name="idm1965696"></a><a name="idm1965568"></a><p><b>12.1.</b></p>
</td>
<td align="left" valign="top"><p>
How does Poky differ from <a class="ulink" href="http://www.openembedded.org" target="_self">OpenEmbedded</a>?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
The term "Poky" refers to the specific reference build system that
the Yocto Project provides.
Poky is based on <a class="link" href="../dev-manual/oe-core.html" target="_self">OE-Core</a>
and BitBake.
Thus, the generic term used here for the build system is
the "OpenEmbedded build system."
Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
changes always being merged to OE-Core or BitBake first before being pulled back
into Poky.
This practice benefits both projects immediately.
For a fuller description of the term "Poky", see the
<a class="link" href="../dev-manual/poky.html" target="_self">poky</a> term in the Yocto Project
Development Manual.
</p></td>
</tr>
<tr class="question" title="12.2.">
<td align="left" valign="top">
<a name="idm1961792"></a><a name="idm1961664"></a><p><b>12.2.</b></p>
</td>
<td align="left" valign="top"><p>
I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7.
Can I still use the Yocto Project?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
You can use a stand-alone tarball to provide Python 2.6.
You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><a class="ulink" href="http://downloads.yoctoproject.org/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2" target="_self">32-bit tarball</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://downloads.yoctoproject.org/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2" target="_self">64-bit tarball</a></p></li>
</ul></div>
<p>
</p>
<p>
These tarballs are self-contained with all required libraries and should work
on most Linux systems.
To use the tarballs extract them into the root
directory and run the appropriate command:
</p>
<pre class="literallayout">
$ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
$ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
</pre>
<p>
</p>
<p>
Once you run the command, BitBake uses Python 2.6.
</p>
</td>
</tr>
<tr class="question" title="12.3.">
<td align="left" valign="top">
<a name="idm2605168"></a><a name="idm2605040"></a><p><b>12.3.</b></p>
</td>
<td align="left" valign="top"><p>
How can you claim Poky / OpenEmbedded-Core is stable?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
There are three areas that help with stability;
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>The Yocto Project team keeps
<a class="link" href="../dev-manual/oe-core.html" target="_self">OE-Core</a> small
and focused, containing around 830 recipes as opposed to the thousands
available in other OpenEmbedded community layers.
Keeping it small makes it easy to test and maintain.</p></li>
<li class="listitem"><p>The Yocto Project team runs manual and automated tests
using a small, fixed set of reference hardware as well as emulated
targets.</p></li>
<li class="listitem"><p>The Yocto Project uses an an autobuilder,
which provides continuous build and integration tests.</p></li>
</ul></div>
<p>
</p>
</td>
</tr>
<tr class="question" title="12.4.">
<td align="left" valign="top">
<a name="idm3232752"></a><a name="idm3232624"></a><p><b>12.4.</b></p>
</td>
<td align="left" valign="top"><p>
How do I get support for my board added to the Yocto Project?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
Support for an additional board is added by creating a BSP layer for it.
For more information on how to create a BSP layer, see the
<a class="link" href="../bsp-guide/index.html" target="_self">Yocto Project Board Support Package (BSP) Developer's Guide</a>.
</p>
<p>
Usually, if the board is not completely exotic, adding support in
the Yocto Project is fairly straightforward.
</p>
</td>
</tr>
<tr class="question" title="12.5.">
<td align="left" valign="top">
<a name="idm3230416"></a><a name="idm3230288"></a><p><b>12.5.</b></p>
</td>
<td align="left" valign="top"><p>
Are there any products built using the OpenEmbedded build system?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
The software running on the <a class="ulink" href="http://vernier.com/labquest/" target="_self">Vernier LabQuest</a>
is built using the OpenEmbedded build system.
See the <a class="ulink" href="http://www.vernier.com/products/interfaces/labq/" target="_self">Vernier LabQuest</a>
website for more information.
There are a number of pre-production devices using the OpenEmbedded build system
and the Yocto Project team
announces them as soon as they are released.
</p></td>
</tr>
<tr class="question" title="12.6.">
<td align="left" valign="top">
<a name="idm3227696"></a><a name="idm3227568"></a><p><b>12.6.</b></p>
</td>
<td align="left" valign="top"><p>
What does the OpenEmbedded build system produce as output?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
Because the same set of recipes can be used to create output of various formats, the
output of an OpenEmbedded build depends on how it was started.
Usually, the output is a flashable image ready for the target device.
</p></td>
</tr>
<tr class="question" title="12.7.">
<td align="left" valign="top">
<a name="idm5359408"></a><a name="idm5359280"></a><p><b>12.7.</b></p>
</td>
<td align="left" valign="top"><p>
How do I add my package to the Yocto Project?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
To add a package, you need to create a BitBake recipe.
For information on how to add a package, see the section
"<a class="link" href="../dev-manual/usingpoky-extend-addpkg.html" target="_self">Adding a Package</a>"
in the Yocto Project Development Manual.
</p></td>
</tr>
<tr class="question" title="12.8.">
<td align="left" valign="top">
<a name="idm5357680"></a><a name="idm5357552"></a><p><b>12.8.</b></p>
</td>
<td align="left" valign="top"><p>
Do I have to reflash my entire board with a new Yocto Project image when recompiling
a package?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
The OpenEmbedded build system can build packages in various formats such as
<code class="filename">ipk</code> for <code class="filename">opkg</code>,
Debian package (<code class="filename">.deb</code>), or RPM.
The packages can then be upgraded using the package tools on the device, much like
on a desktop distribution such as Ubuntu or Fedora.
</p></td>
</tr>
<tr class="question" title="12.9.">
<td align="left" valign="top">
<a name="idm5354224"></a><a name="idm5354096"></a><p><b>12.9.</b></p>
</td>
<td align="left" valign="top"><p>
What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
GNOME Mobile is a subset of the <a class="ulink" href="http://www.gnome.org" target="_self">GNOME</a>
platform targeted at mobile and embedded devices.
The the main difference between GNOME Mobile and standard GNOME is that
desktop-orientated libraries have been removed, along with deprecated libraries,
creating a much smaller footprint.
</p></td>
</tr>
<tr class="question" title="12.10.">
<td align="left" valign="top">
<a name="idm2088960"></a><a name="idm2088832"></a><p><b>12.10.</b></p>
</td>
<td align="left" valign="top"><p>
I see the error '<code class="filename">chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</code>'.
What is wrong?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
You are probably running the build on an NTFS filesystem.
Use <code class="filename">ext2</code>, <code class="filename">ext3</code>, or <code class="filename">ext4</code> instead.
</p></td>
</tr>
<tr class="question" title="12.11.">
<td align="left" valign="top">
<a name="idm2085168"></a><a name="idm2085040"></a><p><b>12.11.</b></p>
</td>
<td align="left" valign="top"><p>
How do I make the Yocto Project work in RHEL/CentOS?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
To get the Yocto Project working under RHEL/CentOS 5.1 you need to first
install some required packages.
The standard CentOS packages needed are:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>"Development tools" (selected during installation)</p></li>
<li class="listitem"><p><code class="filename">texi2html</code></p></li>
<li class="listitem"><p><code class="filename">compat-gcc-34</code></p></li>
</ul></div>
<p>
On top of these, you need the following external packages:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename">python-sqlite2</code> from
<a class="ulink" href="http://dag.wieers.com/rpm/packages/python-sqlite2/" target="_self">DAG repository</a>
</p></li>
<li class="listitem"><p><code class="filename">help2man</code> from
<a class="ulink" href="http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html" target="_self">Karan repository</a></p></li>
</ul></div>
<p>
</p>
<p>
Once these packages are installed, the OpenEmbedded build system will be able
to build standard images.
However, there might be a problem with the QEMU emulator segfaulting.
You can either disable the generation of binary locales by setting
<code class="filename"><a class="link" href="ref-variables-glos.html#var-ENABLE_BINARY_LOCALE_GENERATION" title="ENABLE_BINARY_LOCALE_GENERATION">ENABLE_BINARY_LOCALE_GENERATION</a>
</code> to "0" or by removing the <code class="filename">linux-2.6-execshield.patch</code>
from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
</p>
</td>
</tr>
<tr class="question" title="12.12.">
<td align="left" valign="top">
<a name="idm3829808"></a><a name="idm3829680"></a><p><b>12.12.</b></p>
</td>
<td align="left" valign="top"><p>
I see lots of 404 responses for files on
<code class="filename">http://www.yoctoproject.org/sources/*</code>. Is something wrong?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
Nothing is wrong.
The OpenEmbedded build system checks any configured source mirrors before downloading
from the upstream sources.
The build system does this searching for both source archives and
pre-checked out versions of SCM managed software.
These checks help in large installations because it can reduce load on the SCM servers
themselves.
The address above is one of the default mirrors configured into the
build system.
Consequently, if an upstream source disappears, the team
can place sources there so builds continue to work.
</p></td>
</tr>
<tr class="question" title="12.13.">
<td align="left" valign="top">
<a name="idm3827408"></a><a name="idm3827280"></a><p><b>12.13.</b></p>
</td>
<td align="left" valign="top"><p>
I have machine-specific data in a package for one machine only but the package is
being marked as machine-specific in all cases, how do I prevent this?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
Set <code class="filename"><a class="link" href="ref-variables-glos.html#var-SRC_URI_OVERRIDES_PACKAGE_ARCH" title="SRC_URI_OVERRIDES_PACKAGE_ARCH">SRC_URI_OVERRIDES_PACKAGE_ARCH</a>
</code> = "0" in the <code class="filename">.bb</code> file but make sure the package is
manually marked as
machine-specific in the case that needs it.
The code that handles <code class="filename">SRC_URI_OVERRIDES_PACKAGE_ARCH</code> is in <code class="filename">base.bbclass</code>.
</p></td>
</tr>
<tr class="question" title="12.14.">
<td align="left" valign="top">
<a name="idm5331776"></a><a name="idm5331648"></a><p><b>12.14.</b></p>
</td>
<td align="left" valign="top"><p>
I'm behind a firewall and need to use a proxy server. How do I do that?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
Most source fetching by the OpenEmbedded build system is done by <code class="filename">wget</code>
and you therefore need to specify the proxy settings in a
<code class="filename">.wgetrc</code> file in your home directory.
Example settings in that file would be
</p>
<pre class="literallayout">
http_proxy = http://proxy.yoyodyne.com:18023/
ftp_proxy = http://proxy.yoyodyne.com:18023/
</pre>
<p>
The Yocto Project also includes a <code class="filename">site.conf.sample</code>
file that shows how to configure CVS and Git proxy servers
if needed.
</p>
</td>
</tr>
<tr class="question" title="12.15.">
<td align="left" valign="top">
<a name="idm1524432"></a><a name="idm1524304"></a><p><b>12.15.</b></p>
</td>
<td align="left" valign="top"><p>
What&#8217;s the difference between <code class="filename">foo</code> and <code class="filename">foo-native</code>?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
The <code class="filename">*-native</code> targets are designed to run on the system
being used for the build.
These are usually tools that are needed to assist the build in some way such as
<code class="filename">quilt-native</code>, which is used to apply patches.
The non-native version is the one that runs on the target device.
</p></td>
</tr>
<tr class="question" title="12.16.">
<td align="left" valign="top">
<a name="idm1520336"></a><a name="idm1520208"></a><p><b>12.16.</b></p>
</td>
<td align="left" valign="top"><p>
I'm seeing random build failures. Help?!
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
If the same build is failing in totally different and random ways,
the most likely explanation is that either the hardware you're running the
build on has some problem, or, if you are running the build under virtualisation,
the virtualisation probably has bugs.
The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and
CPU activity and is sensitive to even single bit failures in any of these areas.
True random failures have always been traced back to hardware or virtualisation issues.
</p></td>
</tr>
<tr class="question" title="12.17.">
<td align="left" valign="top">
<a name="idm4636672"></a><a name="idm4636544"></a><p><b>12.17.</b></p>
</td>
<td align="left" valign="top"><p>
What do we need to ship for license compliance?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
This is a difficult question and you need to consult your lawyer for the answer
for your specific case.
It is worth bearing in mind that for GPL compliance there needs to be enough
information shipped to allow someone else to rebuild the same end result
you are shipping.
This means sharing the source code, any patches applied to it, and also any
configuration information about how that package was configured and built.
</p></td>
</tr>
<tr class="question" title="12.18.">
<td align="left" valign="top">
<a name="idm4635216"></a><a name="idm4635088"></a><p><b>12.18.</b></p>
</td>
<td align="left" valign="top"><p>
How do I disable the cursor on my touchscreen device?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
You need to create a form factor file as described in the
"<a class="link" href="../bsp-guide/bsp-filelayout-misc-recipes.html" target="_self">Miscellaneous Recipe Files</a>"
section and set the <code class="filename">HAVE_TOUCHSCREEN</code> variable equal to one as follows:
</p>
<pre class="literallayout">
HAVE_TOUCHSCREEN=1
</pre>
<p>
</p>
</td>
</tr>
<tr class="question" title="12.19.">
<td align="left" valign="top">
<a name="idm4631744"></a><a name="idm4631616"></a><p><b>12.19.</b></p>
</td>
<td align="left" valign="top"><p>
How do I make sure connected network interfaces are brought up by default?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
The default interfaces file provided by the netbase recipe does not
automatically bring up network interfaces.
Therefore, you will need to add a BSP-specific netbase that includes an interfaces
file.
See the "<a class="link" href="../bsp-guide/bsp-filelayout-misc-recipes.html" target="_self">Miscellaneous Recipe Files</a>"
section for information on creating these types of miscellaneous recipe files.
</p>
<p>
For example, add the following files to your layer:
</p>
<pre class="literallayout">
meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
</pre>
<p>
</p>
</td>
</tr>
<tr class="question" title="12.20.">
<td align="left" valign="top">
<a name="idm3888832"></a><a name="idm3888704"></a><p><b>12.20.</b></p>
</td>
<td align="left" valign="top"><p>
How do I create images with more free space?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
Images are created to be 1.2 times the size of the populated root filesystem.
To modify this ratio so that there is more free space available, you need to
set the configuration value <code class="filename">IMAGE_OVERHEAD_FACTOR</code>.
For example, setting <code class="filename">IMAGE_OVERHEAD_FACTOR</code> to 1.5 sets
the image size ratio to one and a half times the size of the populated
root filesystem.
</p>
<pre class="literallayout">
IMAGE_OVERHEAD_FACTOR = "1.5"
</pre>
<p>
</p>
</td>
</tr>
<tr class="question" title="12.21.">
<td align="left" valign="top">
<a name="idm619504"></a><a name="idm619376"></a><p><b>12.21.</b></p>
</td>
<td align="left" valign="top"><p>
Why don't you support directories with spaces in the pathnames?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top"><p>
The Yocto Project team has tried to do this before but too many of the tools
the OpenEmbedded build system depends on such as <code class="filename">autoconf</code>
break when they find spaces in pathnames.
Until that situation changes, the team will not support spaces in pathnames.
</p></td>
</tr>
<tr class="question" title="12.22.">
<td align="left" valign="top">
<a name="idm617456"></a><a name="idm617328"></a><p><b>12.22.</b></p>
</td>
<td align="left" valign="top"><p>
How do I use an external toolchain?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
The toolchain configuration is very flexible and customizable.
It is primarily controlled with the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-TCMODE" title="TCMODE">TCMODE</a></code> variable.
This variable controls which <code class="filename">tcmode-*.inc</code> file to include
from the <code class="filename">meta/conf/distro/include</code> directory within the
<a class="link" href="../dev-manual/source-directory.html" target="_self">source directory</a>.
</p>
<p>
The default value of <code class="filename">TCMODE</code> is "default"
(i.e. <code class="filename">tcmode-default.inc</code>).
However, other patterns are accepted.
In particular, "external-*" refers to external toolchains of which there are some
basic examples included in the OpenEmbedded Core (<code class="filename">meta</code>).
You can use your own custom toolchain definition in your own layer
(or as defined in the <code class="filename">local.conf</code> file) at the location
<code class="filename">conf/distro/include/tcmode-*.inc</code>.
</p>
<p>
In addition to the toolchain configuration, you also need a corresponding toolchain recipe file.
This recipe file needs to package up any pre-built objects in the toolchain such as
<code class="filename">libgcc</code>, <code class="filename">libstdcc++</code>,
any locales, and <code class="filename">libc</code>.
An example is the <code class="filename">external-sourcery-toolchain.bb</code>, which is located
in <code class="filename">meta/recipes-core/meta/</code> within the source directory.
</p>
</td>
</tr>
<tr class="question" title="12.23.">
<td align="left" valign="top">
<a name="idm4577168"></a><a name="idm5139136"></a><p><b>12.23.</b></p>
</td>
<td align="left" valign="top"><p><a name="how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server"></a>
How does the OpenEmbedded build system obtain source code and will it work behind my
firewall or proxy server?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
The way the build system obtains source code is highly configurable.
You can setup the build system to get source code in most environments if
HTTP transport is available.
</p>
<p>
When the build system searches for source code, it first tries the local download directory.
If that location fails, Poky tries PREMIRRORS, the upstream source,
and then MIRRORS in that order.
</p>
<p>
By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS
for SCM-based sources,
upstreams for normal tarballs, and then falls back to a number of other mirrors
including the Yocto Project source mirror if those fail.
</p>
<p>
As an example, you could add a specific server for Poky to attempt before any
others by adding something like the following to the <code class="filename">local.conf</code>
configuration file:
</p>
<pre class="literallayout">
PREMIRRORS_prepend = "\
git://.*/.* http://www.yoctoproject.org/sources/ \n \
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
https://.*/.* http://www.yoctoproject.org/sources/ \n"
</pre>
<p>
</p>
<p>
These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS
requests and direct them to the <code class="filename">http://</code> sources mirror.
You can use <code class="filename">file://</code> URLs to point to local directories
or network shares as well.
</p>
<p>
Aside from the previous technique, these options also exist:
</p>
<pre class="literallayout">
BB_NO_NETWORK = "1"
</pre>
<p>
This statement tells BitBake to throw an error instead of trying to access the
Internet.
This technique is useful if you want to ensure code builds only from local sources.
</p>
<p>
Here is another technique:
</p>
<pre class="literallayout">
BB_FETCH_PREMIRRORONLY = "1"
</pre>
<p>
This statement limits Poky to pulling source from the PREMIRRORS only.
Again, this technique is useful for reproducing builds.
</p>
<p>
Here is another technique:
</p>
<pre class="literallayout">
BB_GENERATE_MIRROR_TARBALLS = "1"
</pre>
<p>
This statement tells Poky to generate mirror tarballs.
This technique is useful if you want to create a mirror server.
If not, however, the technique can simply waste time during the build.
</p>
<p>
Finally, consider an example where you are behind an HTTP-only firewall.
You could make the following changes to the <code class="filename">local.conf</code>
configuration file as long as the PREMIRROR server is up to date:
</p>
<pre class="literallayout">
PREMIRRORS_prepend = "\
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
https://.*/.* http://www.yoctoproject.org/sources/ \n"
BB_FETCH_PREMIRRORONLY = "1"
</pre>
<p>
These changes would cause Poky to successfully fetch source over HTTP and
any network accesses to anything other than the PREMIRROR would fail.
</p>
<p>
The build system also honors the standard shell environment variables
<code class="filename">http_proxy</code>, <code class="filename">ftp_proxy</code>,
<code class="filename">https_proxy</code>, and <code class="filename">all_proxy</code>
to redirect requests through proxy servers.
</p>
</td>
</tr>
<tr class="question" title="12.24.">
<td align="left" valign="top">
<a name="idm3953616"></a><a name="idm3685632"></a><p><b>12.24.</b></p>
</td>
<td align="left" valign="top"><p>
Can I get rid of build output so I can start over?
</p></td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>
Yes - you can easily do this.
When you use BitBake to build an image, all the build output goes into the
directory created when you source the <code class="filename">oe-init-build-env</code>
setup file.
By default, this <a class="link" href="../dev-manual/build-directory.html" target="_self">build directory</a>
is named <code class="filename">build</code> but can be named
anything you want.
</p>
<p>
Within the build directory is the <code class="filename">tmp</code> directory.
To remove all the build output yet preserve any source code or downloaded files
from previous builds, simply remove the <code class="filename">tmp</code> directory.
</p>
</td>
</tr>
</tbody>
</table>
</div>
</div></body>
</html>

View File

@ -1,62 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.3.2.2. Fedora Packages</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="required-packages-for-the-host-development-system.html" title="1.3.2. Required Packages for the Host Development System">
<link rel="prev" href="ubuntu-packages.html" title="1.3.2.1. Ubuntu">
<link rel="next" href="opensuse-packages.html" title="1.3.2.3. OpenSUSE Packages">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.3.2.2. Fedora Packages">
<div class="titlepage"><div><div><h4 class="title">
<a name="fedora-packages"></a>1.3.2.2. Fedora Packages</h4></div></div></div>
<p>
The following list shows the required packages by function
given a supported Fedora Linux distribution:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p><span class="emphasis"><em>Essentials:</em></span>
Packages needed to build an image for a headless
system:
</p>
<pre class="literallayout">
$ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
ccache
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Graphical Extras:</em></span>
Packages recommended if the host system has graphics support:
</p>
<pre class="literallayout">
$ sudo yum install SDL-devel xterm
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Documentation:</em></span>
Packages needed if you are going to build out the
Yocto Project documentation manuals:
</p>
<pre class="literallayout">
$ sudo yum install make docbook-style-dsssl docbook-style-xsl \
docbook-dtds docbook-utils fop libxslt
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>ADT Installer Extras:</em></span>
Packages needed if you are going to be using the
<a class="link" href="../adt-manual/using-the-adt-installer.html" target="_self">Application Development Toolkit (ADT) Installer</a>:
</p>
<pre class="literallayout">
$ sudo yum install autoconf automake libtool glib2-devel
</pre>
</li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,33 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.3.2. Future Development and Limitations</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="x32.html" title="3.3. x32">
<link rel="prev" href="support.html" title="3.3.1. Support">
<link rel="next" href="using-x32-right-now.html" title="3.3.3. Using x32 Right Now">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.2. Future Development and Limitations">
<div class="titlepage"><div><div><h3 class="title">
<a name="future-development-and-limitations"></a>3.3.2. Future Development and Limitations</h3></div></div></div>
<p>
As of this Yocto Project release, the x32 psABI kernel and library interfaces
specifications are not finalized.
</p>
<p>
Future Plans for the x32 psABI in the Yocto Project include the following:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>Enhance and fix the few remaining recipes so they
work with and support x32 toolchains.</p></li>
<li class="listitem"><p>Enhance RPM Package Manager (RPM) support for x32 binaries.</p></li>
<li class="listitem"><p>Support larger images.</p></li>
<li class="listitem"><p>Integrate x32 recipes, toolchain, and kernel changes from
<code class="filename">experimental/meta-x32</code> into OE-core.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,25 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>5.1.3. documentation</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="structure-core.html" title="5.1. Top level core components">
<link rel="prev" href="structure-core-build.html" title="5.1.2. build/">
<link rel="next" href="structure-core-meta.html" title="5.1.4. meta/">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="5.1.3. documentation">
<div class="titlepage"><div><div><h3 class="title">
<a name="handbook"></a>5.1.3. <code class="filename">documentation</code>
</h3></div></div></div>
<p>
This directory holds the source for the Yocto Project documentation
as well as templates and tools that allow you to generate PDF and HTML
versions of the manuals.
Each manual is contained in a sub-folder.
For example, the files for this manual reside in
<code class="filename">poky-ref-manual</code>.
</p>
</div></body>
</html>

View File

@ -1,327 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>The Yocto Project Reference Manual</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="next" href="intro.html" title="Chapter 1. Introduction">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div lang="en" class="book" title="The Yocto Project Reference Manual">
<div class="titlepage">
<div>
<div><h1 class="title">
<a name="poky-ref-manual"></a>
The Yocto Project Reference Manual
</h1></div>
<div><div class="authorgroup">
<div class="author">
<h3 class="author">
<span class="firstname">Richard</span> <span class="surname">Purdie</span>
</h3>
<div class="affiliation">
<span class="orgname">Linux Foundation<br></span>
</div>
<code class="email">&lt;<a class="email" href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>&gt;</code>
</div>
</div></div>
<div><p class="copyright">Copyright © 2010-2013 Linux Foundation</p></div>
<div><div class="legalnotice" title="Legal Notice">
<a name="idm3374608"></a>
<p>
Permission is granted to copy, distribute and/or modify this document under
the terms of the <a class="ulink" href="http://creativecommons.org/licenses/by-sa/2.0/uk/" target="_self">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</a> as published by Creative Commons.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and the
<a class="link" href="../poky-ref-manual/index.html" target="_self">Yocto Project Reference Manual</a> on
the <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project</a> website.
For the latest version of this manual, see the manual on the website.
</div>
</div></div>
<div><div class="revhistory"><table border="1" width="100%" summary="Revision history">
<tr><th align="left" valign="top" colspan="2"><b>Revision History</b></th></tr>
<tr>
<td align="left">Revision 4.0+git</td>
<td align="left">24 November 2010</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 0.9 Release</td></tr>
<tr>
<td align="left">Revision 1.0</td>
<td align="left">6 April 2011</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 1.0 Release.</td></tr>
<tr>
<td align="left">Revision 1.0.1</td>
<td align="left">23 May 2011</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 1.0.1 Release.</td></tr>
<tr>
<td align="left">Revision 1.1</td>
<td align="left">6 October 2011</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 1.1 Release.</td></tr>
<tr>
<td align="left">Revision 1.2</td>
<td align="left">April 2012</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 1.2 Release.</td></tr>
<tr>
<td align="left">Revision 1.3</td>
<td align="left">October 2012</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 1.3 Release.</td></tr>
<tr>
<td align="left">Revision 1.4</td>
<td align="left">Sometime in 2013</td>
</tr>
<tr><td align="left" colspan="2">Released with the Yocto Project 1.4 Release.</td></tr>
</table></div></div>
</div>
<hr>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="chapter"><a href="intro.html">1. Introduction</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="intro-welcome.html">1.1. Introduction</a></span></dt>
<dt><span class="section"><a href="intro-manualoverview.html">1.2. Documentation Overview</a></span></dt>
<dt><span class="section"><a href="intro-requirements.html">1.3. System Requirements</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="detailed-supported-distros.html">1.3.1. Supported Linux Distributions</a></span></dt>
<dt><span class="section"><a href="required-packages-for-the-host-development-system.html">1.3.2. Required Packages for the Host Development System</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="intro-getit.html">1.4. Obtaining the Yocto Project</a></span></dt>
<dt><span class="section"><a href="intro-getit-dev.html">1.5. Development Checkouts</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="usingpoky.html">2. Using the Yocto Project</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="usingpoky-build.html">2.1. Running a Build</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="build-overview.html">2.1.1. Build Overview</a></span></dt>
<dt><span class="section"><a href="building-an-image-using-gpl-components.html">2.1.2. Building an Image Using GPL Components</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="usingpoky-install.html">2.2. Installing and Using the Result</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging.html">2.3. Debugging Build Failures</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="usingpoky-debugging-taskfailures.html">2.3.1. Task Failures</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging-taskrunning.html">2.3.2. Running Specific Tasks</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging-dependencies.html">2.3.3. Dependency Graphs</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging-bitbake.html">2.3.4. General BitBake Problems</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging-buildfile.html">2.3.5. Building with No Dependencies</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging-variables.html">2.3.6. Variables</a></span></dt>
<dt><span class="section"><a href="recipe-logging-mechanisms.html">2.3.7. Recipe Logging Mechanisms</a></span></dt>
<dt><span class="section"><a href="usingpoky-debugging-others.html">2.3.8. Other Tips</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="maintaining-build-output-quality.html">2.4. Maintaining Build Output Quality</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="enabling-and-disabling-build-history.html">2.4.1. Enabling and Disabling Build History</a></span></dt>
<dt><span class="section"><a href="understanding-what-the-build-history-contains.html">2.4.2. Understanding What the Build History Contains</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="technical-details.html">3. Technical Details</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="usingpoky-components.html">3.1. Yocto Project Components</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="usingpoky-components-bitbake.html">3.1.1. BitBake</a></span></dt>
<dt><span class="section"><a href="usingpoky-components-metadata.html">3.1.2. Metadata (Recipes)</a></span></dt>
<dt><span class="section"><a href="usingpoky-components-classes.html">3.1.3. Classes</a></span></dt>
<dt><span class="section"><a href="usingpoky-components-configuration.html">3.1.4. Configuration</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="shared-state-cache.html">3.2. Shared State Cache</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="overall-architecture.html">3.2.1. Overall Architecture</a></span></dt>
<dt><span class="section"><a href="checksums.html">3.2.2. Checksums (Signatures)</a></span></dt>
<dt><span class="section"><a href="shared-state.html">3.2.3. Shared State</a></span></dt>
<dt><span class="section"><a href="tips-and-tricks.html">3.2.4. Tips and Tricks</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="x32.html">3.3. x32</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="support.html">3.3.1. Support</a></span></dt>
<dt><span class="section"><a href="future-development-and-limitations.html">3.3.2. Future Development and Limitations</a></span></dt>
<dt><span class="section"><a href="using-x32-right-now.html">3.3.3. Using x32 Right Now</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="licenses.html">3.4. Licenses</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="usingpoky-configuring-LIC_FILES_CHKSUM.html">3.4.1. Tracking License Changes</a></span></dt>
<dt><span class="section"><a href="enabling-commercially-licensed-recipes.html">3.4.2. Enabling Commercially Licensed Recipes</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="migration.html">4. Migrating to a Newer Yocto Project Release</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="moving-to-the-yocto-project-1.3-release.html">4.1. Moving to the Yocto Project 1.3 Release</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="1.3-local-configuration.html">4.1.1. Local Configuration</a></span></dt>
<dt><span class="section"><a href="1.3-recipes.html">4.1.2. Recipes</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="ref-structure.html">5. Source Directory Structure</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-core.html">5.1. Top level core components</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-core-bitbake.html">5.1.1. <code class="filename">bitbake/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-build.html">5.1.2. <code class="filename">build/</code></a></span></dt>
<dt><span class="section"><a href="handbook.html">5.1.3. <code class="filename">documentation</code></a></span></dt>
<dt><span class="section"><a href="structure-core-meta.html">5.1.4. <code class="filename">meta/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-meta-yocto.html">5.1.5. <code class="filename">meta-yocto/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-meta-yocto-bsp.html">5.1.6. <code class="filename">meta-yocto-bsp/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-hob.html">5.1.7. <code class="filename">meta-hob/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-skeleton.html">5.1.8. <code class="filename">meta-skeleton/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-scripts.html">5.1.9. <code class="filename">scripts/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-script.html">5.1.10. <code class="filename">oe-init-build-env</code></a></span></dt>
<dt><span class="section"><a href="structure-basic-top-level.html">5.1.11. <code class="filename">LICENSE, README, and README.hardware</code></a></span></dt>
</dl></dd>
<dt><span class="section"><a href="structure-build.html">5.2. The Build Directory - <code class="filename">build/</code></a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-build-pseudodone.html">5.2.1. <code class="filename">build/pseudodone</code></a></span></dt>
<dt><span class="section"><a href="structure-build-conf-local.conf.html">5.2.2. <code class="filename">build/conf/local.conf</code></a></span></dt>
<dt><span class="section"><a href="structure-build-conf-bblayers.conf.html">5.2.3. <code class="filename">build/conf/bblayers.conf</code></a></span></dt>
<dt><span class="section"><a href="structure-build-conf-sanity_info.html">5.2.4. <code class="filename">build/conf/sanity_info</code></a></span></dt>
<dt><span class="section"><a href="structure-build-downloads.html">5.2.5. <code class="filename">build/downloads/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-sstate-cache.html">5.2.6. <code class="filename">build/sstate-cache/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp.html">5.2.7. <code class="filename">build/tmp/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-buildstats.html">5.2.8. <code class="filename">build/tmp/buildstats/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-cache.html">5.2.9. <code class="filename">build/tmp/cache/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy.html">5.2.10. <code class="filename">build/tmp/deploy/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-deb.html">5.2.11. <code class="filename">build/tmp/deploy/deb/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-rpm.html">5.2.12. <code class="filename">build/tmp/deploy/rpm/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-licenses.html">5.2.13. <code class="filename">build/tmp/deploy/licenses/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-images.html">5.2.14. <code class="filename">build/tmp/deploy/images/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-ipk.html">5.2.15. <code class="filename">build/tmp/deploy/ipk/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-sysroots.html">5.2.16. <code class="filename">build/tmp/sysroots/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-stamps.html">5.2.17. <code class="filename">build/tmp/stamps/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-log.html">5.2.18. <code class="filename">build/tmp/log/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-pkgdata.html">5.2.19. <code class="filename">build/tmp/pkgdata/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-work.html">5.2.20. <code class="filename">build/tmp/work/</code></a></span></dt>
</dl></dd>
<dt><span class="section"><a href="structure-meta.html">5.3. The Metadata - <code class="filename">meta/</code></a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-meta-classes.html">5.3.1. <code class="filename">meta/classes/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-conf.html">5.3.2. <code class="filename">meta/conf/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-conf-machine.html">5.3.3. <code class="filename">meta/conf/machine/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-conf-distro.html">5.3.4. <code class="filename">meta/conf/distro/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-bsp.html">5.3.5. <code class="filename">meta/recipes-bsp/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-connectivity.html">5.3.6. <code class="filename">meta/recipes-connectivity/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-core.html">5.3.7. <code class="filename">meta/recipes-core/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-devtools.html">5.3.8. <code class="filename">meta/recipes-devtools/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-extended.html">5.3.9. <code class="filename">meta/recipes-extended/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-gnome.html">5.3.10. <code class="filename">meta/recipes-gnome/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-graphics.html">5.3.11. <code class="filename">meta/recipes-graphics/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-kernel.html">5.3.12. <code class="filename">meta/recipes-kernel/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-multimedia.html">5.3.13. <code class="filename">meta/recipes-multimedia/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-qt.html">5.3.14. <code class="filename">meta/recipes-qt/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-rt.html">5.3.15. <code class="filename">meta/recipes-rt/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-sato.html">5.3.16. <code class="filename">meta/recipes-sato/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-support.html">5.3.17. <code class="filename">meta/recipes-support/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-site.html">5.3.18. <code class="filename">meta/site/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-txt.html">5.3.19. <code class="filename">meta/recipes.txt</code></a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="ref-bitbake.html">6. BitBake</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="ref-bitbake-parsing.html">6.1. Parsing</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-providers.html">6.2. Preferences and Providers</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-dependencies.html">6.3. Dependencies</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-tasklist.html">6.4. The Task List</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-runtask.html">6.5. Running a Task</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-commandline.html">6.6. BitBake Command Line</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-fetchers.html">6.7. Fetchers</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="ref-classes.html">7. Classes</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="ref-classes-base.html">7.1. The base class - <code class="filename">base.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-autotools.html">7.2. Autotooled Packages - <code class="filename">autotools.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-update-alternatives.html">7.3. Alternatives - <code class="filename">update-alternatives.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-update-rc.d.html">7.4. Initscripts - <code class="filename">update-rc.d.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-binconfig.html">7.5. Binary config scripts - <code class="filename">binconfig.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-debian.html">7.6. Debian renaming - <code class="filename">debian.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-pkgconfig.html">7.7. Pkg-config - <code class="filename">pkgconfig.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-src-distribute.html">7.8. Distribution of sources - <code class="filename">src_distribute_local.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-perl.html">7.9. Perl modules - <code class="filename">cpan.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-distutils.html">7.10. Python extensions - <code class="filename">distutils.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-devshell.html">7.11. Developer Shell - <code class="filename">devshell.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-packagegroup.html">7.12. Package Groups - <code class="filename">packagegroup.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-package.html">7.13. Packaging - <code class="filename">package*.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-kernel.html">7.14. Building kernels - <code class="filename">kernel.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-image.html">7.15. Creating images - <code class="filename">image.bbclass</code> and <code class="filename">rootfs*.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-sanity.html">7.16. Host System sanity checks - <code class="filename">sanity.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-insane.html">7.17. Generated output quality assurance checks - <code class="filename">insane.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-siteinfo.html">7.18. Autotools configuration data cache - <code class="filename">siteinfo.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-useradd.html">7.19. Adding Users - <code class="filename">useradd.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-externalsrc.html">7.20. Using External Source - <code class="filename">externalsrc.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-others.html">7.21. Other Classes</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="ref-images.html">8. Images</a></span></dt>
<dt><span class="chapter"><a href="ref-features.html">9. Reference: Features</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="ref-features-distro.html">9.1. Distro</a></span></dt>
<dt><span class="section"><a href="ref-features-machine.html">9.2. Machine</a></span></dt>
<dt><span class="section"><a href="ref-features-image.html">9.3. Images</a></span></dt>
<dt><span class="section"><a href="ref-features-backfill.html">9.4. Feature Backfilling</a></span></dt>
</dl></dd>
<dt><span class="chapter"><a href="ref-variables-glos.html">10. Variables Glossary</a></span></dt>
<dd><dl><dt><span class="glossary"><a href="ref-variables-glos.html#ref-variables-glossary">Glossary</a></span></dt></dl></dd>
<dt><span class="chapter"><a href="ref-varlocality.html">11. Variable Context</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="ref-varlocality-configuration.html">11.1. Configuration</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="ref-varlocality-config-distro.html">11.1.1. Distribution (Distro)</a></span></dt>
<dt><span class="section"><a href="ref-varlocality-config-machine.html">11.1.2. Machine</a></span></dt>
<dt><span class="section"><a href="ref-varlocality-config-local.html">11.1.3. Local</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="ref-varlocality-recipes.html">11.2. Recipes</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="ref-varlocality-recipe-required.html">11.2.1. Required</a></span></dt>
<dt><span class="section"><a href="ref-varlocality-recipe-dependencies.html">11.2.2. Dependencies</a></span></dt>
<dt><span class="section"><a href="ref-varlocality-recipe-paths.html">11.2.3. Paths</a></span></dt>
<dt><span class="section"><a href="ref-varlocality-recipe-build.html">11.2.4. Extra Build Information</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="chapter"><a href="faq.html">12. FAQ</a></span></dt>
<dt><span class="chapter"><a href="resources.html">13. Contributing to the Yocto Project</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="resources-intro.html">13.1. Introduction</a></span></dt>
<dt><span class="section"><a href="resources-bugtracker.html">13.2. Tracking Bugs</a></span></dt>
<dt><span class="section"><a href="resources-mailinglist.html">13.3. Mailing lists</a></span></dt>
<dt><span class="section"><a href="resources-irc.html">13.4. Internet Relay Chat (IRC)</a></span></dt>
<dt><span class="section"><a href="resources-links.html">13.5. Links</a></span></dt>
<dt><span class="section"><a href="resources-contributions.html">13.6. Contributions</a></span></dt>
</dl></dd>
</dl>
</div>
</div></body>
</html>

View File

@ -1,2 +0,0 @@
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<index/>

View File

@ -1,26 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.5. Development Checkouts</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="intro.html" title="Chapter 1. Introduction">
<link rel="prev" href="intro-getit.html" title="1.4. Obtaining the Yocto Project">
<link rel="next" href="usingpoky.html" title="Chapter 2. Using the Yocto Project">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.5. Development Checkouts">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="intro-getit-dev"></a>1.5. Development Checkouts</h2></div></div></div>
<p>
Development using the Yocto Project requires a local
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
You can set up the source directory by downloading a Yocto Project release tarball and unpacking it,
or by cloning a copy of the upstream
<a class="link" href="../dev-manual/poky.html" target="_self">Poky</a> Git repository.
For information on both these methods, see the
"<a class="link" href="../dev-manual/getting-setup.html" target="_self">Getting Setup</a>"
section in the Yocto Project Development Manual.
</p>
</div></body>
</html>

View File

@ -1,35 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.4. Obtaining the Yocto Project</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="intro.html" title="Chapter 1. Introduction">
<link rel="prev" href="centos-packages.html" title="1.3.2.4. CentOS Packages">
<link rel="next" href="intro-getit-dev.html" title="1.5. Development Checkouts">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.4. Obtaining the Yocto Project">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="intro-getit"></a>1.4. Obtaining the Yocto Project</h2></div></div></div>
<p>
The Yocto Project development team makes the Yocto Project available through a number
of methods:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>Releases:</em></span> Stable, tested releases are available through
<a class="ulink" href="http://downloads.yoctoproject.org/releases/yocto/" target="_self">http://downloads.yoctoproject.org/releases/yocto/</a>.</p></li>
<li class="listitem"><p><span class="emphasis"><em>Nightly Builds:</em></span> These releases are available at
<a class="ulink" href="http://autobuilder.yoctoproject.org/nightly" target="_self">http://autobuilder.yoctoproject.org/nightly</a>.
These builds include Yocto Project releases, meta-toolchain tarball installation scripts, and
experimental builds.</p></li>
<li class="listitem"><p><span class="emphasis"><em>Yocto Project Website:</em></span> You can find releases
of the Yocto Project and supported BSPs at the
<a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project website</a>.
Along with these downloads, you can find lots of other information at this site.
</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,73 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.2. Documentation Overview</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="intro.html" title="Chapter 1. Introduction">
<link rel="prev" href="intro-welcome.html" title="1.1. Introduction">
<link rel="next" href="intro-requirements.html" title="1.3. System Requirements">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.2. Documentation Overview">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="intro-manualoverview"></a>1.2. Documentation Overview</h2></div></div></div>
<p>
This reference manual consists of the following:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="usingpoky.html" title="Chapter 2. Using the Yocto Project">Using the Yocto Project</a>:</em></span> This chapter
provides an overview of the components that make up the Yocto Project
followed by information about debugging images created in the Yocto Project.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="technical-details.html" title="Chapter 3. Technical Details">Technical Details</a>:</em></span>
This chapter describes fundamental Yocto Project components as well as an explanation
behind how the Yocto Project uses shared state (sstate) cache to speed build time.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-structure.html" title="Chapter 5. Source Directory Structure">Directory Structure</a>:</em></span>
This chapter describes the
<a class="link" href="../dev-manual/source-directory.html" target="_self">source directory</a> created
either by unpacking a released Yocto Project tarball on your host development system,
or by cloning the upstream
<a class="link" href="../dev-manual/poky.html" target="_self">Poky</a> Git repository.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-bitbake.html" title="Chapter 6. BitBake">BitBake</a>:</em></span>
This chapter provides an overview of the BitBake tool and its role within
the Yocto Project.</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-classes.html" title="Chapter 7. Classes">Classes</a>:</em></span>
This chapter describes the classes used in the Yocto Project.</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-images.html" title="Chapter 8. Images">Images</a>:</em></span>
This chapter describes the standard images that the Yocto Project supports.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-features.html" title="Chapter 9. Reference: Features">Features</a>:</em></span>
This chapter describes mechanisms for creating distribution, machine, and image
features during the build process using the OpenEmbedded build system.</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-variables-glos.html" title="Chapter 10. Variables Glossary">Variables Glossary</a>:</em></span>
This chapter presents most variables used by the OpenEmbedded build system, which
using BitBake.
Entries describe the function of the variable and how to apply them.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="ref-varlocality.html" title="Chapter 11. Variable Context">Variable Context</a>:</em></span>
This chapter provides variable locality or context.</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="faq.html" title="Chapter 12. FAQ">FAQ</a>:</em></span>
This chapter provides answers for commonly asked questions in the Yocto Project
development environment.</p></li>
<li class="listitem"><p><span class="emphasis"><em>
<a class="link" href="resources.html" title="Chapter 13. Contributing to the Yocto Project">Contributing to the Yocto Project</a>:</em></span>
This chapter provides guidance on how you can contribute back to the Yocto
Project.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,23 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.3. System Requirements</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="intro.html" title="Chapter 1. Introduction">
<link rel="prev" href="intro-manualoverview.html" title="1.2. Documentation Overview">
<link rel="next" href="detailed-supported-distros.html" title="1.3.1. Supported Linux Distributions">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.3. System Requirements">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="intro-requirements"></a>1.3. System Requirements</h2></div></div></div>
<p>
For general Yocto Project system requirements, see the
"<a class="link" href="../yocto-project-qs/yp-resources.html" target="_self">What You Need and How You Get It</a>" 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.
</p>
</div></body>
</html>

View File

@ -1,30 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.1. Introduction</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="intro.html" title="Chapter 1. Introduction">
<link rel="prev" href="intro.html" title="Chapter 1. Introduction">
<link rel="next" href="intro-manualoverview.html" title="1.2. Documentation Overview">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.1. Introduction">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="intro-welcome"></a>1.1. Introduction</h2></div></div></div>
<p>
This manual provides reference information for the current release of the Yocto Project.
The Yocto Project is an open-source collaboration project focused on embedded Linux
developers.
Amongst other things, the Yocto Project uses the OpenEmbedded build system, which
is based on the Poky project, to construct complete Linux images.
You can find complete introductory and getting started information on the Yocto Project
by reading the
<a class="link" href="../yocto-project-qs/index.html" target="_self">Yocto Project Quick Start</a>.
For task-based information using the Yocto Project, see the
<a class="link" href="../dev-manual/index.html" target="_self">Yocto Project Development Manual</a>.
You can also find lots of information on the Yocto Project on the
<a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project website</a>.
</p>
</div></body>
</html>

View File

@ -1,30 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 1. Introduction</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="index.html" title="The Yocto Project Reference Manual">
<link rel="next" href="intro-welcome.html" title="1.1. Introduction">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 1. Introduction">
<div class="titlepage"><div><div><h2 class="title">
<a name="intro"></a>Chapter 1. Introduction</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="section"><a href="intro-welcome.html">1.1. Introduction</a></span></dt>
<dt><span class="section"><a href="intro-manualoverview.html">1.2. Documentation Overview</a></span></dt>
<dt><span class="section"><a href="intro-requirements.html">1.3. System Requirements</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="detailed-supported-distros.html">1.3.1. Supported Linux Distributions</a></span></dt>
<dt><span class="section"><a href="required-packages-for-the-host-development-system.html">1.3.2. Required Packages for the Host Development System</a></span></dt>
</dl></dd>
<dt><span class="section"><a href="intro-getit.html">1.4. Obtaining the Yocto Project</a></span></dt>
<dt><span class="section"><a href="intro-getit-dev.html">1.5. Development Checkouts</a></span></dt>
</dl>
</div>
</div></body>
</html>

View File

@ -1,53 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.2.4.2. Invalidating Shared State</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="tips-and-tricks.html" title="3.2.4. Tips and Tricks">
<link rel="prev" href="debugging.html" title="3.2.4.1. Debugging">
<link rel="next" href="x32.html" title="3.3. x32">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2.4.2. Invalidating Shared State">
<div class="titlepage"><div><div><h4 class="title">
<a name="invalidating-shared-state"></a>3.2.4.2. Invalidating Shared State</h4></div></div></div>
<p>
The shared state code uses checksums and shared state
cache to avoid unnecessarily rebuilding tasks.
As with all schemes, this one has some drawbacks.
It is possible that you could make implicit changes that are not factored
into the checksum calculation, but do affect a task's output.
A good example is perhaps when a tool changes its output.
Let's say that the output of <code class="filename">rpmdeps</code> needed to change.
The result of the change should be that all the "package", "package_write_rpm",
and "package_deploy-rpm" shared state cache items would become invalid.
But, because this is a change that is external to the code and therefore implicit,
the associated shared state cache items do not become invalidated.
In this case, the build process would use the cached items rather than running the
task again.
Obviously, these types of implicit changes can cause problems.
</p>
<p>
To avoid these problems during the build, you need to understand the effects of any
change you make.
Note that any changes you make directly to a function automatically are factored into
the checksum calculation and thus, will invalidate the associated area of sstate cache.
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.
Once you are aware of such a change, you can take steps to invalidate the cache
and force the task to run.
The step to take is 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 <code class="filename">do_package</code> or the comments of one of the functions it calls.
The change is purely cosmetic, but it causes the checksum to be recalculated and
forces the task to be run again.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
For an example of a commit that makes a cosmetic change to invalidate
a shared state, see this
<a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54" target="_self">commit</a>.
</div>
</div></body>
</html>

View File

@ -1,91 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.4.2.1. License Flag Matching</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes">
<link rel="prev" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes">
<link rel="next" href="other-variables-related-to-commercial-licenses.html" title="3.4.2.2. Other Variables Related to Commercial Licenses">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4.2.1. License Flag Matching">
<div class="titlepage"><div><div><h4 class="title">
<a name="license-flag-matching"></a>3.4.2.1. License Flag Matching</h4></div></div></div>
<p>
The definition of 'matching' in reference to a
recipe's <code class="filename">LICENSE_FLAGS</code> setting is simple.
However, some things exist that you should know about in order to
correctly and effectively use it.
</p>
<p>
Before a flag
defined by a particular recipe is tested against the
contents of the <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable, the
string <code class="filename">_${PN}</code> (with
<a class="link" href="ref-variables-glos.html#var-PN" title="PN"><code class="filename">PN</code></a> expanded of course) is
appended to the flag, thus automatically making each
<code class="filename">LICENSE_FLAGS</code> value recipe-specific.
That string is
then matched against the whitelist.
So if you specify <code class="filename">LICENSE_FLAGS = "commercial"</code> in recipe
"foo" for example, the string <code class="filename">"commercial_foo"</code>
would normally be what is specified in the whitelist in order for it to
match.
</p>
<p>
You can broaden the match by
putting any "_"-separated beginning subset of a
<code class="filename">LICENSE_FLAGS</code> flag in the whitelist, which will also
match.
For example, simply specifying "commercial" in
the whitelist would match any expanded <code class="filename">LICENSE_FLAGS</code>
definition starting with "commercial" such as
"commercial_foo" and "commercial_bar", which are the
strings that would be automatically generated for
hypothetical "foo" and "bar" recipes assuming those
recipes had simply specified the following:
</p>
<pre class="literallayout">
LICENSE_FLAGS = "commercial"
</pre>
<p>
</p>
<p>
Broadening the match allows for a range of specificity for the items
in the whitelist, from more general to perfectly
specific.
So you have the choice of exhaustively
enumerating each license flag in the whitelist to
allow only those specific recipes into the image, or
of using a more general string to pick up anything
matching just the first component or components of the specified
string.
</p>
<p>
This scheme works even if the flag already
has <code class="filename">_${PN}</code> appended - the extra <code class="filename">_${PN}</code> is
redundant, but does not affect the outcome.
For example, a license flag of "commercial_1.2_foo" would
turn into "commercial_1.2_foo_foo" and would match
both the general "commercial" and the specific
"commercial_1.2_foo", as expected.
The flag would also match
"commercial_1.2_foo_foo" and "commercial_1.2", which
does not make much sense regarding use in the whitelist.
</p>
<p>
For a versioned string, you could instead specify
"commercial_foo_1.2", which would turn into
"commercial_foo_1.2_foo".
And, as expected, this flag allows
you to pick up this package along with
anything else "commercial" when you specify "commercial"
in the whitelist.
Or, the flag allows you to pick up this package along with anything "commercial_foo"
regardless of version when you use "commercial_foo" in the whitelist.
Finally, you can be completely specific about the package and version and specify
"commercial_foo_1.2" package and version.
</p>
</div></body>
</html>

View File

@ -1,28 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.4. Licenses</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="technical-details.html" title="Chapter 3. Technical Details">
<link rel="prev" href="using-x32-right-now.html" title="3.3.3. Using x32 Right Now">
<link rel="next" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.4.1. Tracking License Changes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4. Licenses">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="licenses"></a>3.4. Licenses</h2></div></div></div>
<p>
This section describes the mechanism by which the OpenEmbedded build system
tracks changes to licensing text.
The section also describes how to enable commercially licensed recipes,
which by default are disabled.
</p>
<p>
For information that can help you maintain compliance with various open
source licensing during the lifecycle of the product, see the
"<a class="link" href="../dev-manual/maintaining-open-source-license-compliance-during-your-products-lifecycle.html" target="_self">Maintaining Open Source License Compliance During Your Project's Lifecycle</a>" section
in the Yocto Project Development Manual.
</p>
</div></body>
</html>

View File

@ -1,47 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.3.7.2. Logging With Bash</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="recipe-logging-mechanisms.html" title="2.3.7. Recipe Logging Mechanisms">
<link rel="prev" href="logging-with-python.html" title="2.3.7.1. Logging With Python">
<link rel="next" href="usingpoky-debugging-others.html" title="2.3.8. Other Tips">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.3.7.2. Logging With Bash">
<div class="titlepage"><div><div><h4 class="title">
<a name="logging-with-bash"></a>2.3.7.2. Logging With Bash</h4></div></div></div>
<p>
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.
</p>
<p>
Following is an example written in Bash.
The code logs the progress of the <code class="filename">do_my_function</code> function.
</p>
<pre class="literallayout">
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"
}
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,45 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.3.7.1. Logging With Python</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="recipe-logging-mechanisms.html" title="2.3.7. Recipe Logging Mechanisms">
<link rel="prev" href="recipe-logging-mechanisms.html" title="2.3.7. Recipe Logging Mechanisms">
<link rel="next" href="logging-with-bash.html" title="2.3.7.2. Logging With Bash">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.3.7.1. Logging With Python">
<div class="titlepage"><div><div><h4 class="title">
<a name="logging-with-python"></a>2.3.7.1. Logging With Python</h4></div></div></div>
<p>
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.
</p>
<p>
Following is an example written in Python.
The code handles logging for a function that determines the number of tasks
needed to be run:
</p>
<pre class="literallayout">
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")
}
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,53 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.4. Maintaining Build Output Quality</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="usingpoky.html" title="Chapter 2. Using the Yocto Project">
<link rel="prev" href="usingpoky-debugging-others.html" title="2.3.8. Other Tips">
<link rel="next" href="enabling-and-disabling-build-history.html" title="2.4.1. Enabling and Disabling Build History">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4. Maintaining Build Output Quality">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="maintaining-build-output-quality"></a>2.4. Maintaining Build Output Quality</h2></div></div></div>
<p>
A build's quality can be influenced by many things.
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,
then 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.
</p>
<p>
The <code class="filename">buildhistory</code> 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.
</p>
<p>
The remainder of this section describes the following:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>How you can enable and disable
build history</p></li>
<li class="listitem"><p>How to understand what the build history contains
</p></li>
<li class="listitem"><p>How to limit the information used for build history
</p></li>
<li class="listitem"><p>How to examine the build history from both a
command-line and web interface</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,27 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.1.2. bblayers.conf</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-local-configuration.html" title="4.1.1. Local Configuration">
<link rel="prev" href="migration-1.3-sstate-mirrors.html" title="4.1.1.1. SSTATE_MIRRORS">
<link rel="next" href="1.3-recipes.html" title="4.1.2. Recipes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.1.2. bblayers.conf">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-bblayers-conf"></a>4.1.1.2. bblayers.conf</h4></div></div></div>
<p>
The <code class="filename">meta-yocto</code> layer has been split into
two parts: <code class="filename">meta-yocto</code> and
<code class="filename">meta-yocto-bsp</code>, corresponding to the
Poky reference distro configuration and the reference
hardware Board Support Packages (BSPs), respectively.
When running BitBake or Hob for the first time after upgrading,
your <code class="filename">conf/bblayers.conf</code> file will be
updated to handle this change and you will be asked to
re-run/restart for the changes to take effect.
</p>
</div></body>
</html>

View File

@ -1,26 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2.5. IMAGE_FEATURES</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="prev" href="migration-1.3-task-recipes.html" title="4.1.2.4. Task Recipes">
<link rel="next" href="migration-1.3-removed-recipes.html" title="4.1.2.6. Removed Recipes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2.5. IMAGE_FEATURES">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-image-features"></a>4.1.2.5. IMAGE_FEATURES</h4></div></div></div>
<p>
Image recipes that previously included "apps-console-core"
in <a class="link" href="ref-variables-glos.html#var-IMAGE_FEATURES" title="IMAGE_FEATURES"><code class="filename">IMAGE_FEATURES</code></a>
should now include "splash" instead to enable the boot-up
splash screen.
Retaining "apps-console-core" will still include the splash
screen generates a warning.
The "apps-x11-core" and "apps-x11-games"
<code class="filename">IMAGE_FEATURES</code> features have been removed.
</p>
</div></body>
</html>

View File

@ -1,25 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2.3. nativesdk</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="prev" href="migration-1.3-proto=-in-src-uri.html" title="4.1.2.2. proto= in SRC_URI">
<link rel="next" href="migration-1.3-task-recipes.html" title="4.1.2.4. Task Recipes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2.3. nativesdk">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-nativesdk"></a>4.1.2.3. nativesdk</h4></div></div></div>
<p>
The suffix <code class="filename">nativesdk</code> is now implemented
as a prefix, which simplifies a lot of the packaging code for
<code class="filename">nativesdk</code> recipes.
All custom <code class="filename">nativesdk</code> recipes and any
references need to be updated to use
<code class="filename">nativesdk-*</code> instead of
<code class="filename">*-nativesdk</code>.
</p>
</div></body>
</html>

View File

@ -1,32 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2.2. proto= in SRC_URI</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="prev" href="migration-1.3-python-function-whitespace.html" title="4.1.2.1. Python Function Whitespace">
<link rel="next" href="migration-1.3-nativesdk.html" title="4.1.2.3. nativesdk">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2.2. proto= in SRC_URI">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-proto=-in-src-uri"></a>4.1.2.2. proto= in SRC_URI</h4></div></div></div>
<p>
Any use of <code class="filename">proto=</code> in
<a class="link" href="ref-variables-glos.html#var-SRC_URI" title="SRC_URI"><code class="filename">SRC_URI</code></a>
needs to be changed to <code class="filename">protocol=</code>.
In particular, this applies to the following URIs:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename">svn://</code></p></li>
<li class="listitem"><p><code class="filename">bzr://</code></p></li>
<li class="listitem"><p><code class="filename">hg://</code></p></li>
<li class="listitem"><p><code class="filename">osc://</code></p></li>
</ul></div>
<p>
Other URIs were already using <code class="filename">protocol=</code>.
This change improves consistency.
</p>
</div></body>
</html>

View File

@ -1,29 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2.1. Python Function Whitespace</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="prev" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="next" href="migration-1.3-proto=-in-src-uri.html" title="4.1.2.2. proto= in SRC_URI">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2.1. Python Function Whitespace">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-python-function-whitespace"></a>4.1.2.1. Python Function Whitespace</h4></div></div></div>
<p>
All Python functions must now use four spaces for indentation.
Previously, an inconsistent mix of spaces and tabs existed,
which made extending these functions using
<code class="filename">_append</code> or <code class="filename">_prepend</code>
complicated given that Python treats whitespace as
syntactically significant.
If you are defining or extending any Python functions (e.g.
<code class="filename">populate_packages</code>, <code class="filename">do_unpack</code>,
<code class="filename">do_patch</code> and so forth) in custom recipes
or classes, you need to ensure you are using consistent
four-space indentation.
</p>
</div></body>
</html>

View File

@ -1,64 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2.6. Removed Recipes</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="prev" href="migration-1.3-image-features.html" title="4.1.2.5. IMAGE_FEATURES">
<link rel="next" href="ref-structure.html" title="Chapter 5. Source Directory Structure">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2.6. Removed Recipes">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-removed-recipes"></a>4.1.2.6. Removed Recipes</h4></div></div></div>
<p>
The following recipes have been removed.
For most of them, it is unlikely that you would have any
references to them in your own metadata.
However, you should check your metadata against this list to be sure:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em><code class="filename">libx11-trim</code></em></span>:
Replaced by <code class="filename">libx11</code>, which has a negligible
size difference with modern Xorg.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">xserver-xorg-lite</code></em></span>:
Use <code class="filename">xserver-xorg</code>, which has a negligible
size difference when DRI and GLX modules are not installed.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">xserver-kdrive</code></em></span>:
Effectively unmaintained for many years.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">mesa-xlib</code></em></span>:
No longer serves any purpose.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">galago</code></em></span>:
Replaced by telepathy.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">gail</code></em></span>:
Functionality was integrated into GTK+ 2.13.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">eggdbus</code></em></span>:
No longer needed.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">gcc-*-intermediate</code></em></span>:
The build has been restructured to avoid the need for
this step.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">libgsmd</code></em></span>:
Unmaintained for many years.
Functionality now provided by
<code class="filename">ofono</code> instead.</p></li>
<li class="listitem"><p><span class="emphasis"><em>contacts, dates, tasks, eds-tools</em></span>:
Largely unmaintained PIM application suite.
It has been moved to <code class="filename">meta-gnome</code>
in <code class="filename">meta-openembedded</code>.</p></li>
</ul></div>
<p>
In addition to the previously listed changes, the
<code class="filename">meta-demoapps</code> directory has also been removed
because the recipes in it were not being maintained and many
had become obsolete or broken.
Additionally, these recipes were not parsed in the default configuration.
Many of these recipes are already provided in an updated and
maintained form within OpenEmbedded community layers such as
<code class="filename">meta-oe</code> and <code class="filename">meta-gnome</code>.
For the remainder, you can now find them in the
<code class="filename">meta-extras</code> repository, which is in the
Yocto Project source repositories.
</p>
</div></body>
</html>

View File

@ -1,36 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.1.1. SSTATE_MIRRORS</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-local-configuration.html" title="4.1.1. Local Configuration">
<link rel="prev" href="1.3-local-configuration.html" title="4.1.1. Local Configuration">
<link rel="next" href="migration-1.3-bblayers-conf.html" title="4.1.1.2. bblayers.conf">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.1.1. SSTATE_MIRRORS">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-sstate-mirrors"></a>4.1.1.1. SSTATE_MIRRORS</h4></div></div></div>
<p>
The shared state cache (sstate-cache) as pointed to by
<a class="link" href="ref-variables-glos.html#var-SSTATE_DIR" title="SSTATE_DIR"><code class="filename">SSTATE_DIR</code></a> by default
now has two-character subdirectories to prevent there being an issue with too
many files in the same directory.
Also, native sstate-cache packages will go into a subdirectory named using
the distro ID string.
If you copy the newly structured sstate-cache to a mirror location
(either local or remote) and then point to it in
<a class="link" href="ref-variables-glos.html#var-SSTATE_MIRRORS" title="SSTATE_MIRRORS"><code class="filename">SSTATE_MIRRORS</code></a>,
you need to append "PATH" to the end of the mirror URL so that
the path used by BitBake before the mirror substitution is
appended to the path used to access the mirror.
Here is an example:
</p>
<pre class="literallayout">
SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
</pre>
<p>
</p>
</div></body>
</html>

View File

@ -1,39 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1.2.4. Task Recipes</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="1.3-recipes.html" title="4.1.2. Recipes">
<link rel="prev" href="migration-1.3-nativesdk.html" title="4.1.2.3. nativesdk">
<link rel="next" href="migration-1.3-image-features.html" title="4.1.2.5. IMAGE_FEATURES">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1.2.4. Task Recipes">
<div class="titlepage"><div><div><h4 class="title">
<a name="migration-1.3-task-recipes"></a>4.1.2.4. Task Recipes</h4></div></div></div>
<p>
"Task" recipes are now known as "Package groups" and have
been renamed from <code class="filename">task-*.bb</code> to
<code class="filename">packagegroup-*.bb</code>.
Existing references to the previous <code class="filename">task-*</code>
names should work in most cases as there is an automatic
upgrade path for most packages.
However, you should update references in your own recipes and
configurations as they could be removed in future releases.
You should also rename any custom <code class="filename">task-*</code>
recipes to <code class="filename">packagegroup-*</code>, and change
them to inherit <code class="filename">packagegroup</code> instead of
<code class="filename">task</code>, as well as taking the opportunity
to remove anything now handled by
<code class="filename">packagegroup.bbclass</code>, such as providing
<code class="filename">-dev</code> and <code class="filename">-dbg</code>
packages, setting
<a class="link" href="ref-variables-glos.html#var-LIC_FILES_CHKSUM" title="LIC_FILES_CHKSUM"><code class="filename">LIC_FILES_CHKSUM</code></a>,
and so forth.
See the
"<a class="link" href="ref-classes-packagegroup.html" title="7.12. Package Groups - packagegroup.bbclass">Package Groups - packagegroup.bbclass</a>"
section for further details.
</p>
</div></body>
</html>

View File

@ -1,31 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 4. Migrating to a Newer Yocto Project Release</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="other-variables-related-to-commercial-licenses.html" title="3.4.2.2. Other Variables Related to Commercial Licenses">
<link rel="next" href="moving-to-the-yocto-project-1.3-release.html" title="4.1. Moving to the Yocto Project 1.3 Release">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 4. Migrating to a Newer Yocto Project Release">
<div class="titlepage"><div><div><h2 class="title">
<a name="migration"></a>Chapter 4. Migrating to a Newer Yocto Project Release</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="section"><a href="moving-to-the-yocto-project-1.3-release.html">4.1. Moving to the Yocto Project 1.3 Release</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="1.3-local-configuration.html">4.1.1. Local Configuration</a></span></dt>
<dt><span class="section"><a href="1.3-recipes.html">4.1.2. Recipes</a></span></dt>
</dl></dd>
</dl>
</div>
<p>
This chapter provides information you can use to migrate work to a
newer Yocto Project release. You can find the same information in the
release notes for a given release.
</p>
</div></body>
</html>

View File

@ -1,20 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>4.1. Moving to the Yocto Project 1.3 Release</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="migration.html" title="Chapter 4. Migrating to a Newer Yocto Project Release">
<link rel="prev" href="migration.html" title="Chapter 4. Migrating to a Newer Yocto Project Release">
<link rel="next" href="1.3-local-configuration.html" title="4.1.1. Local Configuration">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="4.1. Moving to the Yocto Project 1.3 Release">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="moving-to-the-yocto-project-1.3-release"></a>4.1. Moving to the Yocto Project 1.3 Release</h2></div></div></div>
<p>
This section provides migration information for moving to the
Yocto Project 1.3 Release.
</p>
</div></body>
</html>

View File

@ -1,60 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>1.3.2.3. OpenSUSE Packages</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="required-packages-for-the-host-development-system.html" title="1.3.2. Required Packages for the Host Development System">
<link rel="prev" href="fedora-packages.html" title="1.3.2.2. Fedora Packages">
<link rel="next" href="centos-packages.html" title="1.3.2.4. CentOS Packages">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.3.2.3. OpenSUSE Packages">
<div class="titlepage"><div><div><h4 class="title">
<a name="opensuse-packages"></a>1.3.2.3. OpenSUSE Packages</h4></div></div></div>
<p>
The following list shows the required packages by function
given a supported OpenSUSE Linux distribution:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p><span class="emphasis"><em>Essentials:</em></span>
Packages needed to build an image for a headless
system:
</p>
<pre class="literallayout">
$ sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml \
diffstat texinfo python-curses
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Graphical Extras:</em></span>
Packages recommended if the host system has graphics support:
</p>
<pre class="literallayout">
$ sudo zypper install libSDL-devel xterm
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Documentation:</em></span>
Packages needed if you are going to build out the
Yocto Project documentation manuals:
</p>
<pre class="literallayout">
$ sudo zypper install make fop xsltproc
</pre>
</li>
<li class="listitem">
<p><span class="emphasis"><em>ADT Installer Extras:</em></span>
Packages needed if you are going to be using the
<a class="link" href="../adt-manual/using-the-adt-installer.html" target="_self">Application Development Toolkit (ADT) Installer</a>:
</p>
<pre class="literallayout">
$ sudo zypper install autoconf automake libtool glib2-devel
</pre>
</li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,60 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.4.2.2. Other Variables Related to Commercial Licenses</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="enabling-commercially-licensed-recipes.html" title="3.4.2. Enabling Commercially Licensed Recipes">
<link rel="prev" href="license-flag-matching.html" title="3.4.2.1. License Flag Matching">
<link rel="next" href="migration.html" title="Chapter 4. Migrating to a Newer Yocto Project Release">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4.2.2. Other Variables Related to Commercial Licenses">
<div class="titlepage"><div><div><h4 class="title">
<a name="other-variables-related-to-commercial-licenses"></a>3.4.2.2. Other Variables Related to Commercial Licenses</h4></div></div></div>
<p>
Other helpful variables related to commercial
license handling exist and are defined in the
<code class="filename">$HOME/poky/meta/conf/distro/include/default-distrovars.inc</code> file:
</p>
<pre class="literallayout">
COMMERCIAL_AUDIO_PLUGINS ?= ""
COMMERCIAL_VIDEO_PLUGINS ?= ""
COMMERCIAL_QT = ""
</pre>
<p>
If you want to enable these components, you can do so by making sure you have
the following statements in your <code class="filename">local.conf</code> configuration file:
</p>
<pre class="literallayout">
COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
gst-plugins-ugly-mpegaudioparse"
COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
COMMERCIAL_QT ?= "qmmp"
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
</pre>
<p>
Of course, you could also create a matching whitelist
for those components using the more general "commercial"
in the whitelist, but that would also enable all the
other packages with <code class="filename">LICENSE_FLAGS</code> containing
"commercial", which you may or may not want:
</p>
<pre class="literallayout">
LICENSE_FLAGS_WHITELIST = "commercial"
</pre>
<p>
</p>
<p>
Specifying audio and video plug-ins as part of the
<code class="filename">COMMERCIAL_AUDIO_PLUGINS</code> and
<code class="filename">COMMERCIAL_VIDEO_PLUGINS</code> statements
or commercial qt components as part of
the <code class="filename">COMMERCIAL_QT</code> statement (along
with the enabling <code class="filename">LICENSE_FLAGS_WHITELIST</code>) includes the
plug-ins or components into built images, thus adding
support for media formats or components.
</p>
</div></body>
</html>

View File

@ -1,31 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>3.2.1. Overall Architecture</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="shared-state-cache.html" title="3.2. Shared State Cache">
<link rel="prev" href="shared-state-cache.html" title="3.2. Shared State Cache">
<link rel="next" href="checksums.html" title="3.2.2. Checksums (Signatures)">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2.1. Overall Architecture">
<div class="titlepage"><div><div><h3 class="title">
<a name="overall-architecture"></a>3.2.1. Overall Architecture</h3></div></div></div>
<p>
When determining what parts of the system need to be built, BitBake
uses a per-task basis and does not use 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, <code class="filename">do_install</code> and <code class="filename">do_package</code>
output are still valid.
However, with a per-recipe approach, the build would not include the
<code class="filename">.deb</code> files.
Consequently, you would have to invalidate the whole build and rerun it.
Rerunning everything is not the best situation.
Also in this case, the core must be "taught" much about specific tasks.
This methodology does not scale well and does not allow users to easily add new tasks
in layers or as external recipes without touching the packaged-staging core.
</p>
</div></body>
</html>

View File

@ -1,41 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>2.3.7. Recipe Logging Mechanisms</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="usingpoky-debugging.html" title="2.3. Debugging Build Failures">
<link rel="prev" href="usingpoky-debugging-variables.html" title="2.3.6. Variables">
<link rel="next" href="logging-with-python.html" title="2.3.7.1. Logging With Python">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.3.7. Recipe Logging Mechanisms">
<div class="titlepage"><div><div><h3 class="title">
<a name="recipe-logging-mechanisms"></a>2.3.7. Recipe Logging Mechanisms</h3></div></div></div>
<p>
Best practices exist while writing recipes that both log build progress and
act on build conditions such as warnings and errors.
Both Python and Bash language bindings exist for the logging mechanism:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>Python:</em></span> For Python functions, BitBake
supports several loglevels: <code class="filename">bb.fatal</code>,
<code class="filename">bb.error</code>, <code class="filename">bb.warn</code>,
<code class="filename">bb.note</code>, <code class="filename">bb.plain</code>,
and <code class="filename">bb.debug</code>.</p></li>
<li class="listitem"><p><span class="emphasis"><em>Bash:</em></span> For Bash functions, the same set
of loglevels exist and are accessed with a similar syntax:
<code class="filename">bbfatal</code>, <code class="filename">bberror</code>,
<code class="filename">bbwarn</code>, <code class="filename">bbnote</code>,
<code class="filename">bbplain</code>, and <code class="filename">bbdebug</code>.</p></li>
</ul></div>
<p>
</p>
<p>
For guidance on how logging is handled in both Python and Bash recipes, see the
<code class="filename">logging.bbclass</code> file in the
<code class="filename">meta/classes</code> folder of the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
</p>
</div></body>
</html>

View File

@ -1,79 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.6. BitBake Command Line</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake-runtask.html" title="6.5. Running a Task">
<link rel="next" href="ref-bitbake-fetchers.html" title="6.7. Fetchers">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.6. BitBake Command Line">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-commandline"></a>6.6. BitBake Command Line</h2></div></div></div>
<p>
Following is the BitBake help output:
</p>
<pre class="screen">
$ bitbake --help
Usage: bitbake [options] [package ...]
Executes the specified task (default is 'build') for a given set of BitBake files.
It expects that BBFILES is defined, which is a space separated list of files to
be executed. BBFILES does support wildcards.
Default BBFILES are the .bb files in the current directory.
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-b BUILDFILE, --buildfile=BUILDFILE
execute the task against this .bb file, rather than a
package from BBFILES. Does not handle any
dependencies.
-k, --continue continue as much as possible after an error. While the
target that failed, and those that depend on it,
cannot be remade, the other dependencies of these
targets can be processed all the same.
-a, --tryaltconfigs continue with builds by trying to use alternative
providers where possible.
-f, --force force run of specified cmd, regardless of stamp status
-c CMD, --cmd=CMD Specify task to execute. Note that this only executes
the specified task for the providee and the packages
it depends on, i.e. 'compile' does not implicitly call
stage for the dependencies (IOW: use only if you know
what you are doing). Depending on the base.bbclass a
listtasks tasks is defined and will show available
tasks
-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 chit-chat 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 files (developers only)
-s, --show-versions show current and preferred versions of all packages
-e, --environment show the global or per-package environment (this is
what used to be bbread)
-g, --graphviz emit the dependency trees of the specified packages 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 print a report
-u UI, --ui=UI userinterface to use
-t SERVERTYPE, --servertype=SERVERTYPE
Choose which server to use, none, process or xmlrpc
--revisions-changed Set the exit code depending on whether upstream
floating revisions have changed or not
</pre>
</div></body>
</html>

View File

@ -1,34 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.3. Dependencies</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake-providers.html" title="6.2. Preferences and Providers">
<link rel="next" href="ref-bitbake-tasklist.html" title="6.4. The Task List">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.3. Dependencies">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-dependencies"></a>6.3. Dependencies</h2></div></div></div>
<p>
Each target BitBake builds consists of multiple tasks such as
<code class="filename">fetch</code>, <code class="filename">unpack</code>,
<code class="filename">patch</code>, <code class="filename">configure</code>,
and <code class="filename">compile</code>.
For best performance on multi-core systems, BitBake considers each task as an independent
entity with its own set of dependencies.
</p>
<p>
Dependencies are defined through several variables.
You can find information about variables BitBake uses in the BitBake documentation,
which is found in the <code class="filename">bitbake/doc/manual</code> directory within the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
At a basic level, it is sufficient to know that BitBake uses the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-DEPENDS" title="DEPENDS">DEPENDS</a></code> and
<code class="filename"><a class="link" href="ref-variables-glos.html#var-RDEPENDS" title="RDEPENDS">RDEPENDS</a></code> variables when
calculating dependencies.
</p>
</div></body>
</html>

View File

@ -1,43 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.7. Fetchers</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake-commandline.html" title="6.6. BitBake Command Line">
<link rel="next" href="ref-classes.html" title="Chapter 7. Classes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.7. Fetchers">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-fetchers"></a>6.7. Fetchers</h2></div></div></div>
<p>
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 <code class="filename">cvs/subversion/git</code>.
</p>
<p>
Fetchers are usually triggered by entries in
<code class="filename"><a class="link" href="ref-variables-glos.html#var-SRC_URI" title="SRC_URI">SRC_URI</a></code>.
You can find information about the options and formats of entries for specific
fetchers in the BitBake manual located in the
<code class="filename">bitbake/doc/manual</code> directory of the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
</p>
<p>
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 <code class="filename"><a class="link" href="ref-variables-glos.html#var-SRCREV" title="SRCREV">SRCREV</a></code>
variable.
See the
"<a class="link" href="../dev-manual/platdev-appdev-srcrev.html" target="_self">Using an External SCM</a>" section
in the Yocto Project Development Manual for more information.
</p>
</div></body>
</html>

View File

@ -1,93 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.1. Parsing</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="next" href="ref-bitbake-providers.html" title="6.2. Preferences and Providers">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.1. Parsing">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-parsing"></a>6.1. Parsing</h2></div></div></div>
<p>
BitBake parses configuration files, classes, and <code class="filename">.bb</code> files.
</p>
<p>
The first thing BitBake does is look for the <code class="filename">bitbake.conf</code> file.
This file resides in the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>
within the <code class="filename">meta/conf/</code> directory.
BitBake finds it by examining its
<a class="link" href="ref-variables-glos.html#var-BBPATH" title="BBPATH"><code class="filename">BBPATH</code></a> environment
variable and looking for the <code class="filename">meta/conf/</code>
directory.
</p>
<p>
The <code class="filename">bitbake.conf</code> file lists other configuration
files to include from a <code class="filename">conf/</code>
directory below the directories listed in <code class="filename">BBPATH</code>.
In general, the most important configuration file from a user's perspective
is <code class="filename">local.conf</code>, which contains a user's customized
settings for the OpenEmbedded build environment.
Other notable configuration files are the distribution
configuration file (set by the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-DISTRO" title="DISTRO">DISTRO</a></code> variable)
and the machine configuration file
(set by the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE" title="MACHINE">MACHINE</a></code> variable).
The <code class="filename">DISTRO</code> and <code class="filename">MACHINE</code> BitBake environment
variables are both usually set in
the <code class="filename">local.conf</code> file.
Valid distribution
configuration files are available in the <code class="filename">meta/conf/distro/</code> directory
and valid machine configuration
files in the <code class="filename">meta/conf/machine/</code> directory.
Within the <code class="filename">meta/conf/machine/include/</code>
directory are various <code class="filename">tune-*.inc</code> configuration files that provide common
"tuning" settings specific to and shared between particular architectures and machines.
</p>
<p>
After the parsing of the configuration files, some standard classes are included.
The <code class="filename">base.bbclass</code> file is always included.
Other classes that are specified in the configuration using the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-INHERIT" title="INHERIT">INHERIT</a></code>
variable are also included.
Class files are searched for in a <code class="filename">classes</code> subdirectory
under the paths in <code class="filename">BBPATH</code> in the same way as
configuration files.
</p>
<p>
After classes are included, the variable
<code class="filename"><a class="link" href="ref-variables-glos.html#var-BBFILES" title="BBFILES">BBFILES</a></code>
is set, usually in
<code class="filename">local.conf</code>, and defines the list of places to search for
<code class="filename">.bb</code> files.
By default, the <code class="filename">BBFILES</code> variable specifies the
<code class="filename">meta/recipes-*/</code> directory within Poky.
Adding extra content to <code class="filename">BBFILES</code> is best achieved through the use of
BitBake layers as described in the
"<a class="link" href="../dev-manual/understanding-and-creating-layers.html" target="_self">Understanding and
Creating Layers</a>" section of the Yocto Project Development Manual.
</p>
<p>
BitBake parses each <code class="filename">.bb</code> file in <code class="filename">BBFILES</code> and
stores the values of various variables.
In summary, for each <code class="filename">.bb</code>
file the configuration plus the base class of variables are set, followed
by the data in the <code class="filename">.bb</code> file
itself, followed by any inherit commands that
<code class="filename">.bb</code> file might contain.
</p>
<p>
Because parsing <code class="filename">.bb</code> files is a time
consuming process, a cache is kept to speed up subsequent parsing.
This cache is invalid if the timestamp of the <code class="filename">.bb</code>
file itself changes, or if the timestamps of any of the include,
configuration or class files the <code class="filename">.bb</code>
file depends on changes.
</p>
</div></body>
</html>

View File

@ -1,63 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.2. Preferences and Providers</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake-parsing.html" title="6.1. Parsing">
<link rel="next" href="ref-bitbake-dependencies.html" title="6.3. Dependencies">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.2. Preferences and Providers">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-providers"></a>6.2. Preferences and Providers</h2></div></div></div>
<p>
Once all the <code class="filename">.bb</code> files have been
parsed, BitBake starts to build the target (<code class="filename">core-image-sato</code>
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 <code class="filename">core-image-sato</code>, it would lead to
<code class="filename">packagegroup-core-x11-sato</code>,
which in turn leads to recipes like <code class="filename">matchbox-terminal</code>,
<code class="filename">pcmanfm</code> and <code class="filename">gthumb</code>.
These recipes in turn depend on <code class="filename">eglibc</code> and the toolchain.
</p>
<p>
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:
</p>
<pre class="literallayout">
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
</pre>
<p>
The default <code class="filename"><a class="link" href="ref-variables-glos.html#var-PREFERRED_PROVIDER" title="PREFERRED_PROVIDER">PREFERRED_PROVIDER</a></code>
is the provider with the same name as the target.
</p>
<p>
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
<code class="filename"><a class="link" href="ref-variables-glos.html#var-PREFERRED_VERSION" title="PREFERRED_VERSION">PREFERRED_VERSION</a></code>
variable to specify a particular version (usually in the distro configuration).
You can influence the order by using the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-DEFAULT_PREFERENCE" title="DEFAULT_PREFERENCE">DEFAULT_PREFERENCE</a></code>
variable.
By default, files have a preference of "0".
Setting the <code class="filename">DEFAULT_PREFERENCE</code> to "-1" makes the
package unlikely to be used unless it is explicitly referenced.
Setting the <code class="filename">DEFAULT_PREFERENCE</code> to "1" makes it likely the package is used.
<code class="filename">PREFERRED_VERSION</code> overrides any <code class="filename">DEFAULT_PREFERENCE</code> setting.
<code class="filename">DEFAULT_PREFERENCE</code> is often used to mark newer and more experimental package
versions until they have undergone sufficient testing to be considered stable.
</p>
<p>
In summary, BitBake has created a list of providers, which is prioritized, for each target.
</p>
</div></body>
</html>

View File

@ -1,86 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.5. Running a Task</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake-tasklist.html" title="6.4. The Task List">
<link rel="next" href="ref-bitbake-commandline.html" title="6.6. BitBake Command Line">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.5. Running a Task">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-runtask"></a>6.5. Running a Task</h2></div></div></div>
<p>
Tasks can either be a shell task or a Python task.
For shell tasks, BitBake writes a shell script to
<code class="filename">${WORKDIR}/temp/run.do_taskname.pid</code> 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 <code class="filename">${WORKDIR}/temp/log.do_taskname.pid</code>.
Looking at the expanded shell functions in the run file and the output in the log files
is a useful debugging technique.
</p>
<p>
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 way similar to shell tasks as well.
</p>
<p>
Once all the tasks have been completed BitBake exits.
</p>
<p>
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:
</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
<p>Tell BitBake to load what you want from the environment
into the data store.
You can do so through the <code class="filename">BB_ENV_EXTRAWHITE</code>
variable.
For example, assume you want to prevent the build system from
accessing your <code class="filename">$HOME/.ccache</code> directory.
The following command tells BitBake to load
<code class="filename">CCACHE_DIR</code> from the environment into the data
store:
</p>
<pre class="literallayout">
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
</pre>
</li>
<li class="listitem">
<p>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
<code class="filename">local.conf</code> or distro configuration file:
</p>
<pre class="literallayout">
export CCACHE_DIR
</pre>
</li>
</ol></div>
<p>
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
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 <code class="filename">BB_HASHBASE_WHITELIST</code>
example in the "<a class="link" href="checksums.html" title="3.2.2. Checksums (Signatures)">Checksums (Signatures)</a>" section.
</div>
</div></body>
</html>

View File

@ -1,54 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>6.4. The Task List</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-bitbake.html" title="Chapter 6. BitBake">
<link rel="prev" href="ref-bitbake-dependencies.html" title="6.3. Dependencies">
<link rel="next" href="ref-bitbake-runtask.html" title="6.5. Running a Task">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="6.4. The Task List">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-bitbake-tasklist"></a>6.4. The Task List</h2></div></div></div>
<p>
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
<code class="filename"><a class="link" href="ref-variables-glos.html#var-BB_NUMBER_THREADS" title="BB_NUMBER_THREADS">BB_NUMBER_THREADS</a></code> 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.
</p>
<p>
It is worth noting that you can greatly speed up the build time by properly setting
the <code class="filename">BB_NUMBER_THREADS</code> variable.
See the
"<a class="link" href="../yocto-project-qs/building-image.html" target="_self">Building an Image</a>"
section in the Yocto Project Quick Start for more information.
</p>
<p>
As each task completes, a timestamp is written to the directory specified by the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-STAMP" title="STAMP">STAMP</a></code> variable (usually
<code class="filename">build/tmp/stamps/*/</code>).
On subsequent runs, BitBake looks at the <code class="filename">/build/tmp/stamps</code>
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
<code class="filename">.bb</code> 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.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Some tasks are marked as "nostamp" tasks.
No timestamp file is created when these tasks are run.
Consequently, "nostamp" tasks are always rerun.
</div>
</div></body>
</html>

View File

@ -1,48 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 6. BitBake</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="structure-meta-recipes-txt.html" title="5.3.19. meta/recipes.txt">
<link rel="next" href="ref-bitbake-parsing.html" title="6.1. Parsing">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 6. BitBake">
<div class="titlepage"><div><div><h2 class="title">
<a name="ref-bitbake"></a>Chapter 6. BitBake</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="section"><a href="ref-bitbake-parsing.html">6.1. Parsing</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-providers.html">6.2. Preferences and Providers</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-dependencies.html">6.3. Dependencies</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-tasklist.html">6.4. The Task List</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-runtask.html">6.5. Running a Task</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-commandline.html">6.6. BitBake Command Line</a></span></dt>
<dt><span class="section"><a href="ref-bitbake-fetchers.html">6.7. Fetchers</a></span></dt>
</dl>
</div>
<p>
BitBake is a program written in Python that interprets the metadata used by the OpenEmbedded
build system.
At some point, developers wonder what actually happens when you enter:
</p>
<pre class="literallayout">
$ bitbake core-image-sato
</pre>
<p>
</p>
<p>
This chapter provides an overview of what happens behind the scenes from BitBake's perspective.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
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 metadata
that consists of variables in a certain format that get passed to the tasks.
</div>
</div></body>
</html>

View File

@ -1,52 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.2. Autotooled Packages - autotools.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-base.html" title="7.1. The base class - base.bbclass">
<link rel="next" href="ref-classes-update-alternatives.html" title="7.3. Alternatives - update-alternatives.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.2. Autotooled Packages - autotools.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-autotools"></a>7.2. Autotooled Packages - <code class="filename">autotools.bbclass</code>
</h2></div></div></div>
<p>
Autotools (<code class="filename">autoconf</code>, <code class="filename">automake</code>,
and <code class="filename">libtool</code>) bring standardization.
This class defines a set of tasks (configure, compile etc.) that
work for all Autotooled packages.
It should usually be enough to define a few standard variables
and then simply <code class="filename">inherit autotools</code>.
This class can also work with software that emulates Autotools.
For more information, see the
"<a class="link" href="../dev-manual/usingpoky-extend-addpkg-autotools.html" target="_self">Autotooled Package</a>"
section in the Yocto Project Development Manual.
</p>
<p>
It's useful to have some idea of how the tasks defined by this class work
and what they do behind the scenes.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename">do_configure</code> &#8208; regenerates the
configure script (using <code class="filename">autoreconf</code>) and then launches it
with a standard set of arguments used during cross-compilation.
You can pass additional parameters to <code class="filename">configure</code> through the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_OECONF" title="EXTRA_OECONF">EXTRA_OECONF</a></code> variable.
</p></li>
<li class="listitem"><p><code class="filename">do_compile</code> &#8208; runs <code class="filename">make</code> with
arguments that specify the compiler and linker.
You can pass additional arguments through
the <code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_OEMAKE" title="EXTRA_OEMAKE">EXTRA_OEMAKE</a></code> variable.
</p></li>
<li class="listitem"><p><code class="filename">do_install</code> &#8208; runs <code class="filename">make install</code>
and passes a DESTDIR option, which takes its value from the standard
<code class="filename"><a class="link" href="ref-variables-glos.html#var-DESTDIR" title="DESTDIR">DESTDIR</a></code> variable.
</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,28 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.1. The base class - base.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="next" href="ref-classes-autotools.html" title="7.2. Autotooled Packages - autotools.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.1. The base class - base.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-base"></a>7.1. The base class - <code class="filename">base.bbclass</code>
</h2></div></div></div>
<p>
The base class is special in that every <code class="filename">.bb</code>
file inherits it automatically.
This class contains definitions for standard basic
tasks such as fetching, unpacking, configuring (empty by default), compiling
(runs any <code class="filename">Makefile</code> present), installing (empty by default) and packaging
(empty by default).
These classes are often overridden or extended by other classes
such as <code class="filename">autotools.bbclass</code> or <code class="filename">package.bbclass</code>.
The class also contains some commonly used functions such as <code class="filename">oe_runmake</code>.
</p>
</div></body>
</html>

View File

@ -1,30 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.5. Binary config scripts - binconfig.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-update-rc.d.html" title="7.4. Initscripts - update-rc.d.bbclass">
<link rel="next" href="ref-classes-debian.html" title="7.6. Debian renaming - debian.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.5. Binary config scripts - binconfig.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-binconfig"></a>7.5. Binary config scripts - <code class="filename">binconfig.bbclass</code>
</h2></div></div></div>
<p>
Before <code class="filename">pkg-config</code> had become widespread, libraries shipped shell
scripts to give information about the libraries and include paths needed
to build software (usually named <code class="filename">LIBNAME-config</code>).
This class assists any recipe using such scripts.
</p>
<p>
During staging, BitBake installs such scripts into the
<code class="filename">sysroots/</code> directory.
BitBake also changes all paths to point into the <code class="filename">sysroots/</code>
directory so all builds that use the script will use the correct
directories for the cross compiling layout.
</p>
</div></body>
</html>

View File

@ -1,22 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.6. Debian renaming - debian.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-binconfig.html" title="7.5. Binary config scripts - binconfig.bbclass">
<link rel="next" href="ref-classes-pkgconfig.html" title="7.7. Pkg-config - pkgconfig.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.6. Debian renaming - debian.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-debian"></a>7.6. Debian renaming - <code class="filename">debian.bbclass</code>
</h2></div></div></div>
<p>
This class renames packages so that they follow the Debian naming
policy (i.e. <code class="filename">eglibc</code> becomes <code class="filename">libc6</code>
and <code class="filename">eglibc-devel</code> becomes <code class="filename">libc6-dev</code>.
</p>
</div></body>
</html>

View File

@ -1,24 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.11. Developer Shell - devshell.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-distutils.html" title="7.10. Python extensions - distutils.bbclass">
<link rel="next" href="ref-classes-packagegroup.html" title="7.12. Package Groups - packagegroup.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.11. Developer Shell - devshell.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-devshell"></a>7.11. Developer Shell - <code class="filename">devshell.bbclass</code>
</h2></div></div></div>
<p>
This class adds the <code class="filename">devshell</code> task.
Distribution policy dictates whether to include this class.
See the
"<a class="link" href="../dev-manual/platdev-appdev-devshell.html" target="_self">Using a Development Shell</a>" section
in the Yocto Project Development Manual for more information about using <code class="filename">devshell</code>.
</p>
</div></body>
</html>

View File

@ -1,31 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.10. Python extensions - distutils.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-perl.html" title="7.9. Perl modules - cpan.bbclass">
<link rel="next" href="ref-classes-devshell.html" title="7.11. Developer Shell - devshell.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.10. Python extensions - distutils.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-distutils"></a>7.10. Python extensions - <code class="filename">distutils.bbclass</code>
</h2></div></div></div>
<p>
Recipes for Python extensions are simple.
These recipes usually only need to point to the source's archive and then inherit
the proper <code class="filename">.bbclass</code> file.
Building is split into two methods dependling on which method the module authors used.
</p>
<p>
Extensions that use an Autotools-based build system require Autotools and
<code class="filename">distutils</code>-based <code class="filename">.bbclasse</code> files in their recipes.
</p>
<p>
Extensions that use <code class="filename">distutils</code>-based build systems require
<code class="filename">distutils.bbclass</code> in their recipes.
</p>
</div></body>
</html>

View File

@ -1,72 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.20. Using External Source - externalsrc.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-useradd.html" title="7.19. Adding Users - useradd.bbclass">
<link rel="next" href="ref-classes-others.html" title="7.21. Other Classes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.20. Using External Source - externalsrc.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-externalsrc"></a>7.20. Using External Source - <code class="filename">externalsrc.bbclass</code>
</h2></div></div></div>
<p>
You can use this class to build software from source code that is external to the
OpenEmbedded build system.
In other words, your source code resides in an external tree outside of the Yocto Project.
Building software from an external source tree means that the normal fetch, unpack, and
patch process is not used.
</p>
<p>
To use the class, you need to define the
<a class="link" href="ref-variables-glos.html#var-S" title="S"><code class="filename">S</code></a> variable to point to the directory that contains the source files.
You also need to have your recipe inherit the <code class="filename">externalsrc.bbclass</code> class.
</p>
<p>
This class expects the source code to support recipe builds that use the
<a class="link" href="ref-variables-glos.html#var-B" title="B"><code class="filename">B</code></a> variable to point to the directory in
which the OpenEmbedded build system places the generated objects built from the recipes.
By default, the <code class="filename">B</code> directory is set to the following, which is separate from the
Source Directory (<code class="filename">S</code>):
</p>
<pre class="literallayout">
${WORKDIR}/${BPN}-{PV}/
</pre>
<p>
See the glossary entries for the
<a class="link" href="ref-variables-glos.html#var-WORKDIR" title="WORKDIR"><code class="filename">WORKDIR</code></a>,
<a class="link" href="ref-variables-glos.html#var-BPN" title="BPN"><code class="filename">BPN</code></a>,
<a class="link" href="ref-variables-glos.html#var-PV" title="PV"><code class="filename">PV</code></a>,
<a class="link" href="ref-variables-glos.html#var-S" title="S"><code class="filename">S</code></a>, and
<a class="link" href="ref-variables-glos.html#var-B" title="B"><code class="filename">B</code></a> for more information.
</p>
<p>
You can build object files in the external tree by setting the
<code class="filename">B</code> variable equal to <code class="filename">"${S}"</code>.
However, this practice does not work well if you use the source for more than one variant
(i.e., "natives" such as <code class="filename">quilt-native</code>,
or "crosses" such as <code class="filename">gcc-cross</code>).
So, be sure there are no "native", "cross", or "multilib" variants of the recipe.
</p>
<p>
If you do want to build different variants of a recipe, you can use the
<a class="link" href="ref-variables-glos.html#var-BBCLASSEXTEND" title="BBCLASSEXTEND"><code class="filename">BBCLASSEXTEND</code></a> variable.
When you do, the <a class="link" href="ref-variables-glos.html#var-B" title="B"><code class="filename">B</code></a> variable must support the
recipe's ability to build variants in different working directories.
Most autotools-based recipes support separating these directories.
The OpenEmbedded build system defaults to using separate directories for <code class="filename">gcc</code>
and some kernel recipes.
Alternatively, you can make sure that separate recipes exist that each
use the <code class="filename">BBCLASSEXTEND</code> variable to build each variant.
The separate recipes can inherit a single target recipe.
</p>
<p>
For information on how to use this class, see the
"<a class="link" href="../dev-manual/building-software-from-an-external-source.html" target="_self">Building
Software from an External Source</a>" section in the Yocto Project Development Manual.
</p>
</div></body>
</html>

View File

@ -1,31 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.15. Creating images - image.bbclass and rootfs*.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-kernel.html" title="7.14. Building kernels - kernel.bbclass">
<link rel="next" href="ref-classes-sanity.html" title="7.16. Host System sanity checks - sanity.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.15. Creating images - image.bbclass and rootfs*.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-image"></a>7.15. Creating images - <code class="filename">image.bbclass</code> and <code class="filename">rootfs*.bbclass</code>
</h2></div></div></div>
<p>
These classes add support for creating images in several formats.
First, the root filesystem is created from packages using
one of the <code class="filename">rootfs_*.bbclass</code>
files (depending on the package format used) and then the image is created.
</p>
<p>
The <code class="filename"><a class="link" href="ref-variables-glos.html#var-IMAGE_FSTYPES" title="IMAGE_FSTYPES">IMAGE_FSTYPES</a></code>
variable controls the types of images to generate.
</p>
<p>
The <code class="filename"><a class="link" href="ref-variables-glos.html#var-IMAGE_INSTALL" title="IMAGE_INSTALL">IMAGE_INSTALL</a></code>
variable controls the list of packages to install into the image.
</p>
</div></body>
</html>

View File

@ -1,105 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.17. Generated output quality assurance checks - insane.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-sanity.html" title="7.16. Host System sanity checks - sanity.bbclass">
<link rel="next" href="ref-classes-siteinfo.html" title="7.18. Autotools configuration data cache - siteinfo.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.17. Generated output quality assurance checks - insane.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-insane"></a>7.17. Generated output quality assurance checks - <code class="filename">insane.bbclass</code>
</h2></div></div></div>
<p>
This class adds a step to the package generation process that sanity checks the
packages generated by the OpenEmbedded build system.
A range of checks are performed that check the build's output
for common problems that show up during runtime.
Distribution policy usually dictates whether to include this class.
</p>
<p>
You can configure the sanity checks so that specific test failures either raise a warning or
an error message.
Typically, failures for new tests generate a warning.
Subsequent failures for the same test would then generate an error message
once the metadata is in a known and good condition.
You use the <code class="filename">WARN_QA</code> variable to specify tests for which you
want to generate a warning message on failure.
You use the <code class="filename">ERROR_QA</code> variable to specify tests for which you
want to generate an error message on failure.
</p>
<p>
The following list shows the tests you can list with the <code class="filename">WARN_QA</code>
and <code class="filename">ERROR_QA</code> variables:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em><code class="filename">ldflags:</code></em></span>
Ensures that the binaries were linked with the
<code class="filename">LDFLAGS</code> options provided by the build system.
If this test fails, check that the <code class="filename">LDFLAGS</code> variable
is being passed to the linker command.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">useless-rpaths:</code></em></span>
Checks for dynamic library load paths (rpaths) in the binaries that
by default on a standard system are searched by the linker (e.g.
<code class="filename">/lib</code> and <code class="filename">/usr/lib</code>).
While these paths will not cause any breakage, they do waste space and
are unnecessary.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">rpaths:</code></em></span>
Checks for rpaths in the binaries that contain build system paths such
as <code class="filename">TMPDIR</code>.
If this test fails, bad <code class="filename">-rpath</code> options are being
passed to the linker commands and your binaries have potential security
issues.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">dev-so:</code></em></span>
Checks that the <code class="filename">.so</code> symbolic links are in the
<code class="filename">-dev</code> package and not in any of the other packages.
In general, these symlinks are only useful for development purposes.
Thus, the <code class="filename">-dev</code> package is the correct location for
them.
Some very rare cases do exist for dynamically loaded modules where
these symlinks are needed instead in the main package.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">debug-files:</code></em></span>
Checks for <code class="filename">.debug</code> directories in anything but the
<code class="filename">-dbg</code> package.
The debug files should all be in the <code class="filename">-dbg</code> package.
Thus, anything packaged elsewhere is incorrect packaging.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">arch:</code></em></span>
Checks the Executable and Linkable Format (ELF) type, bit size and endianness
of any binaries to ensure it matches the target architecture.
This test fails if any binaries don't match the type since there would be an
incompatibility.
Sometimes software, like bootloaders, might need to bypass this check.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">debug-deps:</code></em></span>
Checks that <code class="filename">-dbg</code> packages only depend on other
<code class="filename">-dbg</code> packages and not on any other types of packages,
which would cause a packaging bug.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">dev-deps:</code></em></span>
Checks that <code class="filename">-dev</code> packages only depend on other
<code class="filename">-dev</code> packages and not on any other types of packages,
which would be a packaging bug.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">pkgconfig:</code></em></span>
Checks <code class="filename">.pc</code> files for any
<code class="filename">TMPDIR/WORKDIR</code> paths.
Any <code class="filename">.pc</code> file containing these paths is incorrect
since <code class="filename">pkg-config</code> itself adds the correct sysroot prefix
when the files are accessed.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">la:</code></em></span>
Checks <code class="filename">.la</code> files for any <code class="filename">TMPDIR</code>
paths.
Any <code class="filename">.la</code> file continaing these paths is incorrect since
<code class="filename">libtool</code> adds the correct sysroot prefix when using the
files automatically itself.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">desktop:</code></em></span>
Runs the <code class="filename">desktop-file-validate</code> program against any
<code class="filename">.desktop</code> files to validate their contents against
the specification for <code class="filename">.desktop</code> files.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,36 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.14. Building kernels - kernel.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-package.html" title="7.13. Packaging - package*.bbclass">
<link rel="next" href="ref-classes-image.html" title="7.15. Creating images - image.bbclass and rootfs*.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.14. Building kernels - kernel.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-kernel"></a>7.14. Building kernels - <code class="filename">kernel.bbclass</code>
</h2></div></div></div>
<p>
This class handles building Linux kernels.
The class contains code to build all kernel trees.
All needed headers are staged into the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-STAGING_KERNEL_DIR" title="STAGING_KERNEL_DIR">STAGING_KERNEL_DIR</a></code>
directory to allow out-of-tree module builds using <code class="filename">module.bbclass</code>.
</p>
<p>
This means that each built kernel module is packaged separately and inter-module
dependencies are created by parsing the <code class="filename">modinfo</code> output.
If all modules are required, then installing the <code class="filename">kernel-modules</code>
package installs all packages with modules and various other kernel packages
such as <code class="filename">kernel-vmlinux</code>.
</p>
<p>
Various other classes are used by the kernel and module classes internally including
<code class="filename">kernel-arch.bbclass</code>, <code class="filename">module_strip.bbclass</code>,
<code class="filename">module-base.bbclass</code>, and <code class="filename">linux-kernel-base.bbclass</code>.
</p>
</div></body>
</html>

View File

@ -1,24 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.21. Other Classes</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-externalsrc.html" title="7.20. Using External Source - externalsrc.bbclass">
<link rel="next" href="ref-images.html" title="Chapter 8. Images">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.21. Other Classes">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-others"></a>7.21. Other Classes</h2></div></div></div>
<p>
Thus far, this chapter has discussed only the most useful and important
classes.
However, other classes exist within the <code class="filename">meta/classes</code> directory
in the <a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
You can examine the <code class="filename">.bbclass</code> files directly for more
information.
</p>
</div></body>
</html>

View File

@ -1,73 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.13. Packaging - package*.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-packagegroup.html" title="7.12. Package Groups - packagegroup.bbclass">
<link rel="next" href="ref-classes-kernel.html" title="7.14. Building kernels - kernel.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.13. Packaging - package*.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-package"></a>7.13. Packaging - <code class="filename">package*.bbclass</code>
</h2></div></div></div>
<p>
The packaging classes add support for generating packages from a build's
output.
The core generic functionality is in <code class="filename">package.bbclass</code>.
The code specific to particular package types is contained in various sub-classes such as
<code class="filename">package_deb.bbclass</code>, <code class="filename">package_ipk.bbclass</code>,
and <code class="filename">package_rpm.bbclass</code>.
Most users will want one or more of these classes.
</p>
<p>
You can control the list of resulting package formats by using the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES">PACKAGE_CLASSES</a></code>
variable defined in the <code class="filename">local.conf</code> configuration file,
which is located in the <code class="filename">conf</code> folder of the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
When defining the variable, you can specify one or more package types.
Since images are generated from packages, a packaging class is
needed to enable image generation.
The first class listed in this variable is used for image generation.
</p>
<p>
The package class you choose can affect build-time performance and has space
ramifications.
In general, building a package with RPM takes about thirty percent more time as
compared to using IPK to build the same or similar package.
This comparison takes into account a complete build of the package with all
dependencies previously built.
The reason for this discrepancy is because the RPM package manager creates and
processes more metadata than the IPK package manager.
Consequently, you might consider setting <code class="filename">PACKAGE_CLASSES</code>
to "package_ipk" if you are building smaller systems.
</p>
<p>
Keep in mind, however, that RPM starts to provide more abilities than IPK due to
the fact that it processes more metadata.
For example, this information includes individual file types, file checksum generation
and evaluation on install, sparse file support, conflict detection and resolution
for multilib systems, ACID style upgrade, and repackaging abilities for rollbacks.
</p>
<p>
Another consideration for packages built using the RPM package manager is space.
For smaller systems, the extra space used for the Berkley Database and the amount
of metadata can affect your ability to do on-device upgrades.
</p>
<p>
You can find additional information on the effects of the package class at these
two Yocto Project mailing list links:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html" target="_self">
https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html" target="_self">
https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</a></p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,33 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.12. Package Groups - packagegroup.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-devshell.html" title="7.11. Developer Shell - devshell.bbclass">
<link rel="next" href="ref-classes-package.html" title="7.13. Packaging - package*.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.12. Package Groups - packagegroup.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-packagegroup"></a>7.12. Package Groups - <code class="filename">packagegroup.bbclass</code>
</h2></div></div></div>
<p>
This class sets default values appropriate for package group recipes (such as
<code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGES" title="PACKAGES">PACKAGES</a></code>,
<code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGE_ARCH" title="PACKAGE_ARCH">PACKAGE_ARCH</a></code>,
<code class="filename"><a class="link" href="ref-variables-glos.html#var-ALLOW_EMPTY" title="ALLOW_EMPTY">ALLOW_EMPTY</a></code>,
and so forth.
It is highly recommended that all package group recipes inherit this class.
</p>
<p>
For information on how to use this class, see the
"<a class="link" href="../dev-manual/usingpoky-extend-customimage-customtasks.html" target="_self">Customizing Images Using Custom Package Tasks</a>"
section in the Yocto Project Development Manual.
</p>
<p>
Previously, this class was named <code class="filename">task.bbclass</code>.
</p>
</div></body>
</html>

View File

@ -1,31 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.9. Perl modules - cpan.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-src-distribute.html" title="7.8. Distribution of sources - src_distribute_local.bbclass">
<link rel="next" href="ref-classes-distutils.html" title="7.10. Python extensions - distutils.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.9. Perl modules - cpan.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-perl"></a>7.9. Perl modules - <code class="filename">cpan.bbclass</code>
</h2></div></div></div>
<p>
Recipes for Perl modules are simple.
These recipes usually only need to point to the source's archive and then inherit the
proper <code class="filename">.bbclass</code> file.
Building is split into two methods depending on which method the module authors used.
</p>
<p>
Modules that use old <code class="filename">Makefile.PL</code>-based build system require
<code class="filename">cpan.bbclass</code> in their recipes.
</p>
<p>
Modules that use <code class="filename">Build.PL</code>-based build system require
using <code class="filename">cpan_build.bbclass</code> in their recipes.
</p>
</div></body>
</html>

View File

@ -1,27 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.7. Pkg-config - pkgconfig.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-debian.html" title="7.6. Debian renaming - debian.bbclass">
<link rel="next" href="ref-classes-src-distribute.html" title="7.8. Distribution of sources - src_distribute_local.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.7. Pkg-config - pkgconfig.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-pkgconfig"></a>7.7. Pkg-config - <code class="filename">pkgconfig.bbclass</code>
</h2></div></div></div>
<p>
<code class="filename">pkg-config</code> brought standardization and this class aims to make its
integration smooth for all libraries that make use of it.
</p>
<p>
During staging, BitBake installs <code class="filename">pkg-config</code> data into the
<code class="filename">sysroots/</code> directory.
By making use of sysroot functionality within <code class="filename">pkg-config</code>,
this class no longer has to manipulate the files.
</p>
</div></body>
</html>

View File

@ -1,25 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.16. Host System sanity checks - sanity.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-image.html" title="7.15. Creating images - image.bbclass and rootfs*.bbclass">
<link rel="next" href="ref-classes-insane.html" title="7.17. Generated output quality assurance checks - insane.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.16. Host System sanity checks - sanity.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-sanity"></a>7.16. Host System sanity checks - <code class="filename">sanity.bbclass</code>
</h2></div></div></div>
<p>
This class checks to see if prerequisite software is present so that
users can be notified of potential problems that might affect their build.
The class also performs basic user configuration checks from
the <code class="filename">local.conf</code> configuration file to
prevent common mistakes that cause build failures.
Distribution policy usually determines whether to include this class.
</p>
</div></body>
</html>

View File

@ -1,39 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.18. Autotools configuration data cache - siteinfo.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-insane.html" title="7.17. Generated output quality assurance checks - insane.bbclass">
<link rel="next" href="ref-classes-useradd.html" title="7.19. Adding Users - useradd.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.18. Autotools configuration data cache - siteinfo.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-siteinfo"></a>7.18. Autotools configuration data cache - <code class="filename">siteinfo.bbclass</code>
</h2></div></div></div>
<p>
Autotools can require tests that must execute on the target hardware.
Since this is not possible in general when cross compiling, site information is
used to provide cached test results so these tests can be skipped over but
still make the correct values available.
The <code class="filename"><a class="link" href="structure-meta-site.html" title="5.3.18. meta/site/">meta/site directory</a></code>
contains test results sorted into different categories such as architecture, endianness, and
the <code class="filename">libc</code> used.
Site information provides a list of files containing data relevant to
the current build in the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-CONFIG_SITE" title="CONFIG_SITE">CONFIG_SITE</a></code> variable
that Autotools automatically picks up.
</p>
<p>
The class also provides variables like
<code class="filename"><a class="link" href="ref-variables-glos.html#var-SITEINFO_ENDIANNESS" title="SITEINFO_ENDIANNESS">SITEINFO_ENDIANNESS</a></code>
and <code class="filename"><a class="link" href="ref-variables-glos.html#var-SITEINFO_BITS" title="SITEINFO_BITS">SITEINFO_BITS</a></code>
that can be used elsewhere in the metadata.
</p>
<p>
Because this class is included from <code class="filename">base.bbclass</code>, it is always active.
</p>
</div></body>
</html>

View File

@ -1,43 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.8. Distribution of sources - src_distribute_local.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-pkgconfig.html" title="7.7. Pkg-config - pkgconfig.bbclass">
<link rel="next" href="ref-classes-perl.html" title="7.9. Perl modules - cpan.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.8. Distribution of sources - src_distribute_local.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-src-distribute"></a>7.8. Distribution of sources - <code class="filename">src_distribute_local.bbclass</code>
</h2></div></div></div>
<p>
Many software licenses require that source files be provided along with the binaries.
To simplify this process, two classes were created:
<code class="filename">src_distribute.bbclass</code> and
<code class="filename">src_distribute_local.bbclass</code>.
</p>
<p>
The results of these classes are <code class="filename">tmp/deploy/source/</code>
subdirs with sources sorted by
<code class="filename"><a class="link" href="ref-variables-glos.html#var-LICENSE" title="LICENSE">LICENSE</a></code> field.
If recipes list few licenses (or have entries like "Bitstream Vera"),
the source archive is placed in each license directory.
</p>
<p>
This class operates using three modes:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>copy:</em></span> Copies the files to the
distribute directory.</p></li>
<li class="listitem"><p><span class="emphasis"><em>symlink:</em></span> Symlinks the files to the
distribute directory.</p></li>
<li class="listitem"><p><span class="emphasis"><em>move+symlink:</em></span> Moves the files into
the distribute directory and then symlinks them back.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,48 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.3. Alternatives - update-alternatives.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-autotools.html" title="7.2. Autotooled Packages - autotools.bbclass">
<link rel="next" href="ref-classes-update-rc.d.html" title="7.4. Initscripts - update-rc.d.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.3. Alternatives - update-alternatives.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-update-alternatives"></a>7.3. Alternatives - <code class="filename">update-alternatives.bbclass</code>
</h2></div></div></div>
<p>
Several programs can fulfill the same or similar function and be installed with the same name.
For example, the <code class="filename">ar</code> command is available from the
<code class="filename">busybox</code>, <code class="filename">binutils</code> and
<code class="filename">elfutils</code> packages.
The <code class="filename">update-alternatives.bbclass</code> class handles renaming the
binaries so that multiple packages can be installed without conflicts.
The <code class="filename">ar</code> command still works regardless of which packages are installed
or subsequently removed.
The class renames the conflicting binary in each package and symlinks the highest
priority binary during installation or removal of packages.
</p>
<p>
Four variables control this class:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename">ALTERNATIVE_NAME</code> &#8208; The name of the
binary that is replaced (<code class="filename">ar</code> in this example).</p></li>
<li class="listitem"><p><code class="filename">ALTERNATIVE_LINK</code> &#8208; The path to
the resulting binary (<code class="filename">/bin/ar</code> in this example).</p></li>
<li class="listitem"><p><code class="filename">ALTERNATIVE_PATH</code> &#8208; The path to the
real binary (<code class="filename">/usr/bin/ar.binutils</code> in this example).</p></li>
<li class="listitem"><p><code class="filename">ALTERNATIVE_PRIORITY</code> &#8208; The priority of
the binary.
The version with the most features should have the highest priority.</p></li>
</ul></div>
<p>
</p>
<p>
Currently, the OpenEmbedded build system supports only one binary per package.
</p>
</div></body>
</html>

View File

@ -1,28 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.4. Initscripts - update-rc.d.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-update-alternatives.html" title="7.3. Alternatives - update-alternatives.bbclass">
<link rel="next" href="ref-classes-binconfig.html" title="7.5. Binary config scripts - binconfig.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.4. Initscripts - update-rc.d.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-update-rc.d"></a>7.4. Initscripts - <code class="filename">update-rc.d.bbclass</code>
</h2></div></div></div>
<p>
This class uses <code class="filename">update-rc.d</code> to safely install an
initialization script on behalf of the package.
The OpenEmbedded build system takes care of details such as making sure the script is stopped before
a package is removed and started when the package is installed.
Three variables control this class:
<code class="filename"><a class="link" href="ref-variables-glos.html#var-INITSCRIPT_PACKAGES" title="INITSCRIPT_PACKAGES">INITSCRIPT_PACKAGES</a></code>,
<code class="filename"><a class="link" href="ref-variables-glos.html#var-INITSCRIPT_NAME" title="INITSCRIPT_NAME">INITSCRIPT_NAME</a></code> and
<code class="filename"><a class="link" href="ref-variables-glos.html#var-INITSCRIPT_PARAMS" title="INITSCRIPT_PARAMS">INITSCRIPT_PARAMS</a></code>.
See the variable links for details.
</p>
</div></body>
</html>

View File

@ -1,28 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>7.19. Adding Users - useradd.bbclass</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-classes.html" title="Chapter 7. Classes">
<link rel="prev" href="ref-classes-siteinfo.html" title="7.18. Autotools configuration data cache - siteinfo.bbclass">
<link rel="next" href="ref-classes-externalsrc.html" title="7.20. Using External Source - externalsrc.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="7.19. Adding Users - useradd.bbclass">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-classes-useradd"></a>7.19. Adding Users - <code class="filename">useradd.bbclass</code>
</h2></div></div></div>
<p>
If you have packages that install files that are owned by custom users or groups,
you can use this class to specify those packages and associate the users and groups
with those packages.
The <code class="filename">meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</code>
recipe in the <a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>
provides a simple exmample that shows how to add three
users and groups to two packages.
See the <code class="filename">useradd-example.bb</code> for more information on how to
use this class.
</p>
</div></body>
</html>

View File

@ -1,61 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 7. Classes</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="ref-bitbake-fetchers.html" title="6.7. Fetchers">
<link rel="next" href="ref-classes-base.html" title="7.1. The base class - base.bbclass">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 7. Classes">
<div class="titlepage"><div><div><h2 class="title">
<a name="ref-classes"></a>Chapter 7. Classes</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="section"><a href="ref-classes-base.html">7.1. The base class - <code class="filename">base.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-autotools.html">7.2. Autotooled Packages - <code class="filename">autotools.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-update-alternatives.html">7.3. Alternatives - <code class="filename">update-alternatives.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-update-rc.d.html">7.4. Initscripts - <code class="filename">update-rc.d.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-binconfig.html">7.5. Binary config scripts - <code class="filename">binconfig.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-debian.html">7.6. Debian renaming - <code class="filename">debian.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-pkgconfig.html">7.7. Pkg-config - <code class="filename">pkgconfig.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-src-distribute.html">7.8. Distribution of sources - <code class="filename">src_distribute_local.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-perl.html">7.9. Perl modules - <code class="filename">cpan.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-distutils.html">7.10. Python extensions - <code class="filename">distutils.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-devshell.html">7.11. Developer Shell - <code class="filename">devshell.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-packagegroup.html">7.12. Package Groups - <code class="filename">packagegroup.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-package.html">7.13. Packaging - <code class="filename">package*.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-kernel.html">7.14. Building kernels - <code class="filename">kernel.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-image.html">7.15. Creating images - <code class="filename">image.bbclass</code> and <code class="filename">rootfs*.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-sanity.html">7.16. Host System sanity checks - <code class="filename">sanity.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-insane.html">7.17. Generated output quality assurance checks - <code class="filename">insane.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-siteinfo.html">7.18. Autotools configuration data cache - <code class="filename">siteinfo.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-useradd.html">7.19. Adding Users - <code class="filename">useradd.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-externalsrc.html">7.20. Using External Source - <code class="filename">externalsrc.bbclass</code></a></span></dt>
<dt><span class="section"><a href="ref-classes-others.html">7.21. Other Classes</a></span></dt>
</dl>
</div>
<p>
Class files are used to abstract common functionality and share it amongst multiple
<code class="filename">.bb</code> files.
Any metadata usually found in a <code class="filename">.bb</code> file can also be placed in a class
file.
Class files are identified by the extension <code class="filename">.bbclass</code> and are usually placed
in a <code class="filename">classes/</code> directory beneath the
<code class="filename">meta*/</code> directory found in the
<a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a>.
Class files can also be pointed to by BUILDDIR (e.g. <code class="filename">build/</code>)in the same way as
<code class="filename">.conf</code> files in the <code class="filename">conf</code> directory.
Class files are searched for in <a class="link" href="ref-variables-glos.html#var-BBPATH" title="BBPATH"><code class="filename">BBPATH</code></a>
using the same method by which <code class="filename">.conf</code> files are searched.
</p>
<p>
In most cases inheriting the class is enough to enable its features, although
for some classes you might need to set variables or override some of the
default behaviour.
</p>
</div></body>
</html>

View File

@ -1,88 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>9.4. Feature Backfilling</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-features.html" title="Chapter 9. Reference: Features">
<link rel="prev" href="ref-features-image.html" title="9.3. Images">
<link rel="next" href="ref-variables-glos.html" title="Chapter 10. Variables Glossary">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="9.4. Feature Backfilling">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-features-backfill"></a>9.4. Feature Backfilling</h2></div></div></div>
<p>
Sometimes it is necessary in the OpenEmbedded build system to extend
<a class="link" href="ref-variables-glos.html#var-MACHINE_FEATURES" title="MACHINE_FEATURES"><code class="filename">MACHINE_FEATURES</code></a>
or <a class="link" href="ref-variables-glos.html#var-DISTRO_FEATURES" title="DISTRO_FEATURES"><code class="filename">DISTRO_FEATURES</code></a>
to control functionality that was previously enabled and not able
to be disabled.
For these cases, we need to add an
additional feature item to appear in one of these variables,
but we do not want to force developers who have existing values
of the variables in their configuration to add the new feature
in order to retain the same overall level of functionality.
Thus, the OpenEmbedded build system has a mechanism to
automatically "backfill" these added features into existing
distro or machine configurations.
You can see the list of features for which this is done by
finding the
<a class="link" href="ref-variables-glos.html#var-DISTRO_FEATURES_BACKFILL" title="DISTRO_FEATURES_BACKFILL"><code class="filename">DISTRO_FEATURES_BACKFILL</code></a>
and <a class="link" href="ref-variables-glos.html#var-MACHINE_FEATURES_BACKFILL" title="MACHINE_FEATURES_BACKFILL"><code class="filename">MACHINE_FEATURES_BACKFILL</code></a>
variables in the <code class="filename">meta/conf/bitbake.conf</code> file.
</p>
<p>
Because such features are backfilled by default into all
configurations as described in the previous paragraph, developers
who wish to disable the new features need to be able to selectively
prevent the backfilling from occurring.
They can do this by adding the undesired feature or features to the
<a class="link" href="ref-variables-glos.html#var-DISTRO_FEATURES_BACKFILL_CONSIDERED" title="DISTRO_FEATURES_BACKFILL_CONSIDERED"><code class="filename">DISTRO_FEATURES_BACKFILL_CONSIDERED</code></a>
or <a class="link" href="ref-variables-glos.html#var-MACHINE_FEATURES_BACKFILL_CONSIDERED" title="MACHINE_FEATURES_BACKFILL_CONSIDERED"><code class="filename">MACHINE_FEATURES_BACKFILL_CONSIDERED</code></a>
variables for distro features and machine features respectively.
</p>
<p>
Here are two examples to help illustrate feature backfilling:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>The "pulseaudio" distro feature option</em></span>:
Previously, PulseAudio support was enabled within the Qt and
GStreamer frameworks.
Because of this, the feature is backfilled and thus
enabled for all distros through the
<code class="filename">DISTRO_FEATURES_BACKFILL</code>
variable in the <code class="filename">meta/conf/bitbake.conf</code> file.
However, your distro needs to disable the feature.
You can disable the feature without affecting
other existing distro configurations that need PulseAudio support
by adding "pulseaudio" to
<code class="filename">DISTRO_FEATURES_BACKFILL_CONSIDERED</code>
in your distro's <code class="filename">.conf</code> file.
Adding the feature to this variable when it also
exists in the <code class="filename">DISTRO_FEATURES_BACKFILL</code>
variable prevents the build system from adding the feature to
your configuration's <code class="filename">DISTRO_FEATURES</code>, effectively disabling
the feature for that particular distro.</p></li>
<li class="listitem"><p><span class="emphasis"><em>The "rtc" machine feature option</em></span>:
Previously, real time clock (RTC) support was enabled for all
target devices.
Because of this, the feature is backfilled and thus enabled
for all machines through the <code class="filename">MACHINE_FEATURES_BACKFILL</code>
variable in the <code class="filename">meta/conf/bitbake.conf</code> file.
However, your target device does not have this capability.
You can disable RTC support for your device without
affecting other machines that need RTC support
by adding the feature to your machine's
<code class="filename">MACHINE_FEATURES_BACKFILL_CONSIDERED</code>
list in the machine's <code class="filename">.conf</code> file.
Adding the feature to this variable when it also
exists in the <code class="filename">MACHINE_FEATURES_BACKFILL</code>
variable prevents the build system from adding the feature to
your configuration's <code class="filename">MACHINE_FEATURES</code>, effectively
disabling RTC support for that particular machine.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,68 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>9.1. Distro</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-features.html" title="Chapter 9. Reference: Features">
<link rel="prev" href="ref-features.html" title="Chapter 9. Reference: Features">
<link rel="next" href="ref-features-machine.html" title="9.2. Machine">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="9.1. Distro">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-features-distro"></a>9.1. Distro</h2></div></div></div>
<p>
The items below are features you can use with
<a class="link" href="ref-variables-glos.html#var-DISTRO_FEATURES" title="DISTRO_FEATURES"><code class="filename">DISTRO_FEATURES</code></a>.
Features do not have a one-to-one correspondence to packages, and they can
go beyond simply controlling the installation of a package or packages.
Sometimes a feature can influence how certain recipes are built.
For example, a feature might determine whether a particular configure option
is specified within <code class="filename">do_configure</code> for a particular
recipe.
</p>
<p>
This list only represents features as shipped with the Yocto Project metadata:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>alsa:</em></span> ALSA support will be included (OSS compatibility
kernel modules will be installed if available).</p></li>
<li class="listitem"><p><span class="emphasis"><em>bluetooth:</em></span> Include bluetooth support (integrated BT only)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>ext2:</em></span> Include tools for supporting for devices with internal
HDD/Microdrive for storing files (instead of Flash only devices)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>irda:</em></span> Include Irda support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>keyboard:</em></span> Include keyboard support (e.g. keymaps will be
loaded during boot).
</p></li>
<li class="listitem"><p><span class="emphasis"><em>pci:</em></span> Include PCI bus support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>pcmcia:</em></span> Include PCMCIA/CompactFlash support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>usbgadget:</em></span> USB Gadget Device support (for USB
networking/serial/storage)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>usbhost:</em></span> USB Host support (allows to connect external
keyboard, mouse, storage, network etc)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>wifi:</em></span> WiFi support (integrated only)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>cramfs:</em></span> CramFS support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>ipsec:</em></span> IPSec support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>ipv6:</em></span> IPv6 support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>nfs:</em></span> NFS client support (for mounting NFS exports on
device)</p></li>
<li class="listitem"><p><span class="emphasis"><em>ppp:</em></span> PPP dialup support</p></li>
<li class="listitem"><p><span class="emphasis"><em>smbfs:</em></span> SMB networks client support (for mounting
Samba/Microsoft Windows shares on device)</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,73 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>9.3. Images</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-features.html" title="Chapter 9. Reference: Features">
<link rel="prev" href="ref-features-machine.html" title="9.2. Machine">
<link rel="next" href="ref-features-backfill.html" title="9.4. Feature Backfilling">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="9.3. Images">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-features-image"></a>9.3. Images</h2></div></div></div>
<p>
The contents of images generated by the OpenEmbedded build system can be controlled by the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-IMAGE_FEATURES" title="IMAGE_FEATURES">IMAGE_FEATURES</a></code>
and <code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_IMAGE_FEATURES" title="EXTRA_IMAGE_FEATURES">EXTRA_IMAGE_FEATURES</a></code>
variables that you typically configure in your image recipes.
Through these variables you can add several different
predefined packages such as development utilities or packages with debug
information needed to investigate application problems or profile applications.
</p>
<p>
Current list of
<code class="filename">IMAGE_FEATURES</code> contains the following:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>splash:</em></span> Enables showing a splash screen during boot.
By default, this screen is provided by <code class="filename">psplash</code>, which does
allow customization.
If you prefer to use an alternative splash screen package, you can do so by
setting the <code class="filename">SPLASH</code> variable
to a different package name (or names) within the image recipe or at the distro
configuration level.</p></li>
<li class="listitem"><p><span class="emphasis"><em>ssh-server-dropbear:</em></span> Installs the Dropbear minimal
SSH server.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>ssh-server-openssh:</em></span> Installs the OpenSSH SSH server,
which is more full-featured than Dropbear.
Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server
are present in <code class="filename">IMAGE_FEATURES</code>, then OpenSSH will take
precedence and Dropbear will not be installed.</p></li>
<li class="listitem"><p><span class="emphasis"><em>x11:</em></span> Installs the X server</p></li>
<li class="listitem"><p><span class="emphasis"><em>x11-base:</em></span> Installs the X server with a
minimal environment.</p></li>
<li class="listitem"><p><span class="emphasis"><em>x11-sato:</em></span> Installs the OpenedHand Sato environment.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>tools-sdk:</em></span> Installs a full SDK that runs on the device.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>tools-debug:</em></span> Installs debugging tools such as
<code class="filename">strace</code> and <code class="filename">gdb</code>.
</p></li>
<li class="listitem"><p><span class="emphasis"><em>tools-profile:</em></span> Installs profiling tools such as
<code class="filename">oprofile</code>, <code class="filename">exmap</code>, and
<code class="filename">LTTng</code>.</p></li>
<li class="listitem"><p><span class="emphasis"><em>tools-testapps:</em></span> Installs device testing tools (e.g.
touchscreen debugging).</p></li>
<li class="listitem"><p><span class="emphasis"><em>nfs-server:</em></span> Installs an NFS server.</p></li>
<li class="listitem"><p><span class="emphasis"><em>dev-pkgs:</em></span> Installs development packages (headers and
extra library links) for all packages installed in a given image.</p></li>
<li class="listitem"><p><span class="emphasis"><em>staticdev-pkgs:</em></span> Installs static development
packages (i.e. static libraries containing <code class="filename">*.a</code> files) for all
packages installed in a given image.</p></li>
<li class="listitem"><p><span class="emphasis"><em>dbg-pkgs:</em></span> Installs debug symbol packages for all packages
installed in a given image.</p></li>
<li class="listitem"><p><span class="emphasis"><em>doc-pkgs:</em></span> Installs documentation packages for all packages
installed in a given image.</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,63 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>9.2. Machine</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-features.html" title="Chapter 9. Reference: Features">
<link rel="prev" href="ref-features-distro.html" title="9.1. Distro">
<link rel="next" href="ref-features-image.html" title="9.3. Images">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="9.2. Machine">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-features-machine"></a>9.2. Machine</h2></div></div></div>
<p>
The items below are features you can use with
<a class="link" href="ref-variables-glos.html#var-MACHINE_FEATURES" title="MACHINE_FEATURES"><code class="filename">MACHINE_FEATURES</code></a>.
Features do not have a one-to-one correspondence to packages, and they can
go beyond simply controlling the installation of a package or packages.
Sometimes a feature can influence how certain recipes are built.
For example, a feature might determine whether a particular configure option
is specified within <code class="filename">do_configure</code> for a particular
recipe.
</p>
<p>
This feature list only represents features as shipped with the Yocto Project metadata:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em>acpi:</em></span> Hardware has ACPI (x86/x86_64 only)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>alsa:</em></span> Hardware has ALSA audio drivers
</p></li>
<li class="listitem"><p><span class="emphasis"><em>apm:</em></span> Hardware uses APM (or APM emulation)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>bluetooth:</em></span> Hardware has integrated BT
</p></li>
<li class="listitem"><p><span class="emphasis"><em>ext2:</em></span> Hardware HDD or Microdrive
</p></li>
<li class="listitem"><p><span class="emphasis"><em>irda:</em></span> Hardware has Irda support
</p></li>
<li class="listitem"><p><span class="emphasis"><em>keyboard:</em></span> Hardware has a keyboard
</p></li>
<li class="listitem"><p><span class="emphasis"><em>pci:</em></span> Hardware has a PCI bus
</p></li>
<li class="listitem"><p><span class="emphasis"><em>pcmcia:</em></span> Hardware has PCMCIA or CompactFlash sockets
</p></li>
<li class="listitem"><p><span class="emphasis"><em>screen:</em></span> Hardware has a screen
</p></li>
<li class="listitem"><p><span class="emphasis"><em>serial:</em></span> Hardware has serial support (usually RS232)
</p></li>
<li class="listitem"><p><span class="emphasis"><em>touchscreen:</em></span> Hardware has a touchscreen
</p></li>
<li class="listitem"><p><span class="emphasis"><em>usbgadget:</em></span> Hardware is USB gadget device capable
</p></li>
<li class="listitem"><p><span class="emphasis"><em>usbhost:</em></span> Hardware is USB Host capable
</p></li>
<li class="listitem"><p><span class="emphasis"><em>wifi:</em></span> Hardware has integrated WiFi
</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,60 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 9. Reference: Features</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="ref-images.html" title="Chapter 8. Images">
<link rel="next" href="ref-features-distro.html" title="9.1. Distro">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 9. Reference: Features">
<div class="titlepage"><div><div><h2 class="title">
<a name="ref-features"></a>Chapter 9. Reference: Features</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="section"><a href="ref-features-distro.html">9.1. Distro</a></span></dt>
<dt><span class="section"><a href="ref-features-machine.html">9.2. Machine</a></span></dt>
<dt><span class="section"><a href="ref-features-image.html">9.3. Images</a></span></dt>
<dt><span class="section"><a href="ref-features-backfill.html">9.4. Feature Backfilling</a></span></dt>
</dl>
</div>
<p>
Features provide a mechanism for working out which packages
should be included in the generated images.
Distributions can select which features they want to support through the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-DISTRO_FEATURES" title="DISTRO_FEATURES">DISTRO_FEATURES</a></code>
variable, which is set in the <code class="filename">poky.conf</code> distribution configuration file.
Machine features are set in the
<code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE_FEATURES" title="MACHINE_FEATURES">MACHINE_FEATURES</a></code>
variable, which is set in the machine configuration file and
specifies the hardware features for a given machine.
</p>
<p>
These two variables combine to work out which kernel modules,
utilities, and other packages to include.
A given distribution can support a selected subset of features so some machine features might not
be included if the distribution itself does not support them.
</p>
<p>
One method you can use to determine which recipes are checking to see if a
particular feature is contained or not is to <code class="filename">grep</code> through
the metadata for the feature.
Here is an example that discovers the recipes whose build is potentially
changed based on a given feature:
</p>
<pre class="literallayout">
$ cd $HOME/poky
$ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
</pre>
<p>
</p>
<p>
This chapter provides a reference of shipped machine and distro features
you can include as part of the image, a reference on image types you can
build, and a reference on feature backfilling.
</p>
</div></body>
</html>

View File

@ -1,137 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 8. Images</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="ref-classes-others.html" title="7.21. Other Classes">
<link rel="next" href="ref-features.html" title="Chapter 9. Reference: Features">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 8. Images">
<div class="titlepage"><div><div><h2 class="title">
<a name="ref-images"></a>Chapter 8. Images</h2></div></div></div>
<p>
The OpenEmbedded build process supports several types of images to satisfy different needs.
When you issue the <code class="filename">bitbake</code> command you provide a &#8220;top-level&#8221; recipe
that essentially begins the build for the type of image you want.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Building an image without GNU General Public License Version 3 (GPLv3) components
is only supported for minimal and base images.
Furthermore, if you are going to build an image using non-GPLv3 components,
you must make the following changes in the <code class="filename">local.conf</code> file
before using the BitBake command to build the minimal or base image:
<pre class="literallayout">
1. Comment out the EXTRA_IMAGE_FEATURES line
2. Set INCOMPATIBLE_LICENSE = "GPLv3"
</pre>
</div>
<p>
From within the <code class="filename">poky</code> Git repository, use the following command to list
the supported images:
</p>
<pre class="literallayout">
$ ls meta*/recipes*/images/*.bb
</pre>
<p>
These recipes reside in the <code class="filename">meta/recipes-core/images</code>,
<code class="filename">meta/recipes-extended/images</code>,
<code class="filename">meta/recipes-graphics/images</code>, and
<code class="filename">meta/recipes-sato/images</code> directories
within the <a class="link" href="../dev-manual/source-directory.html" target="_self">source directory</a>.
Although the recipe names are somewhat explanatory, here is a list that describes them:
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-base</code>:</em></span>
A console-only image that fully supports the target device hardware.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal</code>:</em></span>
A small image just capable of allowing a device to boot.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal-dev</code>:</em></span>
A <code class="filename">core-image-minimal</code> image suitable for development work
using the host.
The image includes headers and libraries you can use in a host development
environment.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal-initramfs</code>:</em></span>
A <code class="filename">core-image-minimal</code> image that has the Minimal RAM-based
Initial Root Filesystem (<code class="filename">initramfs</code>) as part of the kernel,
which allows the system to find the first &#8220;init&#8221; program more efficiently.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-minimal-mtdutils</code>:</em></span>
A <code class="filename">core-image-minimal</code> image that has support
for the Minimal MTD Utilities, which let the user interact with the
MTD subsystem in the kernel to perform operations on flash devices.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-x11</code>:</em></span>
A very basic X11 image with a terminal.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-basic</code>:</em></span>
A console-only image with more full-featured Linux system
functionality installed.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-lsb</code>:</em></span>
An image that conforms to the Linux Standard Base (LSB) specification.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-lsb-dev</code>:</em></span>
A <code class="filename">core-image-lsb</code> image that is suitable for development work
using the host.
The image includes headers and libraries you can use in a host development
environment.
</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-lsb-sdk</code>:</em></span>
A <code class="filename">core-image-lsb</code> that includes everything in meta-toolchain
but also includes development headers and libraries to form a complete standalone SDK.
This image is suitable for development using the target.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-clutter</code>:</em></span>
An image with support for the Open GL-based toolkit Clutter, which enables development of
rich and animated graphical user interfaces.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-sato</code>:</em></span>
An image with Sato support, a mobile environment and visual style that works well
with mobile devices.
The image supports X11 with a Sato theme and applications such as
a terminal, editor, file manager, media player, and so forth.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-sato-dev</code>:</em></span>
A <code class="filename">core-image-sato</code> image suitable for development
using the host.
The image includes libraries needed to build applications on the device itself,
testing and profiling tools, and debug symbols.
This image was formerly <code class="filename">core-image-sdk</code>.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-sato-sdk</code>:</em></span>
A <code class="filename">core-image-sato</code> image that includes everything in meta-toolchain.
The image also includes development headers and libraries to form a complete standalone SDK
and is suitable for development using the target.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-rt</code>:</em></span>
A <code class="filename">core-image-minimal</code> image plus a real-time test suite and
tools appropriate for real-time use.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-rt-sdk</code>:</em></span>
A <code class="filename">core-image-rt</code> image that includes everything in
<code class="filename">meta-toolchain</code>.
The image also includes development headers and libraries to form a complete
stand-alone SDK and is suitable for development using the target.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">core-image-gtk-directfb</code>:</em></span>
An image that uses <code class="filename">gtk+</code> over <code class="filename">directfb</code>
instead of X11.
In order to build, this image requires specific distro configuration that enables
<code class="filename">gtk</code> over <code class="filename">directfb</code>.</p></li>
<li class="listitem"><p><span class="emphasis"><em><code class="filename">build-appliance-image</code>:</em></span>
An image you can boot and run using either the
<a class="ulink" href="http://www.vmware.com/products/player/overview.html" target="_self">VMware Player</a>
or <a class="ulink" href="http://www.vmware.com/products/workstation/overview.html" target="_self">VMware Workstation</a>.
For more information on this image, see the
<a class="ulink" href="http://www.yoctoproject.org/documentation/build-appliance" target="_self">Build Appliance</a> page on
the Yocto Project website.</p></li>
</ul></div>
<div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Tip</h3>
From the Yocto Project release 1.1 onwards, <code class="filename">-live</code> and
<code class="filename">-directdisk</code> images have been replaced by a "live"
option in <code class="filename">IMAGE_FSTYPES</code> that will work with any image to produce an
image file that can be
copied directly to a CD or USB device and run as is.
To build a live image, simply add
"live" to <code class="filename">IMAGE_FSTYPES</code> within the <code class="filename">local.conf</code>
file or wherever appropriate and then build the desired image as normal.
</div>
</div></body>
</html>

View File

@ -1,98 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter 5. Source Directory Structure</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="index.html" title="The Yocto Project Reference Manual">
<link rel="prev" href="migration-1.3-removed-recipes.html" title="4.1.2.6. Removed Recipes">
<link rel="next" href="structure-core.html" title="5.1. Top level core components">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 5. Source Directory Structure">
<div class="titlepage"><div><div><h2 class="title">
<a name="ref-structure"></a>Chapter 5. Source Directory Structure</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="section"><a href="structure-core.html">5.1. Top level core components</a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-core-bitbake.html">5.1.1. <code class="filename">bitbake/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-build.html">5.1.2. <code class="filename">build/</code></a></span></dt>
<dt><span class="section"><a href="handbook.html">5.1.3. <code class="filename">documentation</code></a></span></dt>
<dt><span class="section"><a href="structure-core-meta.html">5.1.4. <code class="filename">meta/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-meta-yocto.html">5.1.5. <code class="filename">meta-yocto/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-meta-yocto-bsp.html">5.1.6. <code class="filename">meta-yocto-bsp/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-hob.html">5.1.7. <code class="filename">meta-hob/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-skeleton.html">5.1.8. <code class="filename">meta-skeleton/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-scripts.html">5.1.9. <code class="filename">scripts/</code></a></span></dt>
<dt><span class="section"><a href="structure-core-script.html">5.1.10. <code class="filename">oe-init-build-env</code></a></span></dt>
<dt><span class="section"><a href="structure-basic-top-level.html">5.1.11. <code class="filename">LICENSE, README, and README.hardware</code></a></span></dt>
</dl></dd>
<dt><span class="section"><a href="structure-build.html">5.2. The Build Directory - <code class="filename">build/</code></a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-build-pseudodone.html">5.2.1. <code class="filename">build/pseudodone</code></a></span></dt>
<dt><span class="section"><a href="structure-build-conf-local.conf.html">5.2.2. <code class="filename">build/conf/local.conf</code></a></span></dt>
<dt><span class="section"><a href="structure-build-conf-bblayers.conf.html">5.2.3. <code class="filename">build/conf/bblayers.conf</code></a></span></dt>
<dt><span class="section"><a href="structure-build-conf-sanity_info.html">5.2.4. <code class="filename">build/conf/sanity_info</code></a></span></dt>
<dt><span class="section"><a href="structure-build-downloads.html">5.2.5. <code class="filename">build/downloads/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-sstate-cache.html">5.2.6. <code class="filename">build/sstate-cache/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp.html">5.2.7. <code class="filename">build/tmp/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-buildstats.html">5.2.8. <code class="filename">build/tmp/buildstats/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-cache.html">5.2.9. <code class="filename">build/tmp/cache/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy.html">5.2.10. <code class="filename">build/tmp/deploy/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-deb.html">5.2.11. <code class="filename">build/tmp/deploy/deb/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-rpm.html">5.2.12. <code class="filename">build/tmp/deploy/rpm/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-licenses.html">5.2.13. <code class="filename">build/tmp/deploy/licenses/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-images.html">5.2.14. <code class="filename">build/tmp/deploy/images/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-deploy-ipk.html">5.2.15. <code class="filename">build/tmp/deploy/ipk/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-sysroots.html">5.2.16. <code class="filename">build/tmp/sysroots/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-stamps.html">5.2.17. <code class="filename">build/tmp/stamps/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-log.html">5.2.18. <code class="filename">build/tmp/log/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-pkgdata.html">5.2.19. <code class="filename">build/tmp/pkgdata/</code></a></span></dt>
<dt><span class="section"><a href="structure-build-tmp-work.html">5.2.20. <code class="filename">build/tmp/work/</code></a></span></dt>
</dl></dd>
<dt><span class="section"><a href="structure-meta.html">5.3. The Metadata - <code class="filename">meta/</code></a></span></dt>
<dd><dl>
<dt><span class="section"><a href="structure-meta-classes.html">5.3.1. <code class="filename">meta/classes/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-conf.html">5.3.2. <code class="filename">meta/conf/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-conf-machine.html">5.3.3. <code class="filename">meta/conf/machine/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-conf-distro.html">5.3.4. <code class="filename">meta/conf/distro/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-bsp.html">5.3.5. <code class="filename">meta/recipes-bsp/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-connectivity.html">5.3.6. <code class="filename">meta/recipes-connectivity/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-core.html">5.3.7. <code class="filename">meta/recipes-core/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-devtools.html">5.3.8. <code class="filename">meta/recipes-devtools/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-extended.html">5.3.9. <code class="filename">meta/recipes-extended/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-gnome.html">5.3.10. <code class="filename">meta/recipes-gnome/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-graphics.html">5.3.11. <code class="filename">meta/recipes-graphics/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-kernel.html">5.3.12. <code class="filename">meta/recipes-kernel/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-multimedia.html">5.3.13. <code class="filename">meta/recipes-multimedia/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-qt.html">5.3.14. <code class="filename">meta/recipes-qt/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-rt.html">5.3.15. <code class="filename">meta/recipes-rt/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-sato.html">5.3.16. <code class="filename">meta/recipes-sato/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-support.html">5.3.17. <code class="filename">meta/recipes-support/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-site.html">5.3.18. <code class="filename">meta/site/</code></a></span></dt>
<dt><span class="section"><a href="structure-meta-recipes-txt.html">5.3.19. <code class="filename">meta/recipes.txt</code></a></span></dt>
</dl></dd>
</dl>
</div>
<p>
The <a class="link" href="../dev-manual/source-directory.html" target="_self">Source Directory</a> consists of several components.
Understanding them and knowing where they are located is key to using the Yocto Project well.
This chapter describes the Source Directory and gives information about the various
files and directories.
</p>
<p>
For information on how to establish a local Source Directory on your development system, see the
"<a class="link" href="../dev-manual/getting-setup.html" target="_self">Getting Set Up</a>"
section in the Yocto Project Development Manual.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
The OpenEmbedded build system does not support file or directory names that
contain spaces.
Be sure that the Source Directory you use does not contain these types
of names.
</div>
</div></body>
</html>

View File

@ -1,40 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.1.1. Distribution (Distro)</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-configuration.html" title="11.1. Configuration">
<link rel="prev" href="ref-varlocality-configuration.html" title="11.1. Configuration">
<link rel="next" href="ref-varlocality-config-machine.html" title="11.1.2. Machine">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.1.1. Distribution (Distro)">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-config-distro"></a>11.1.1. Distribution (Distro)</h3></div></div></div>
<p>
This section lists variables whose context is the distribution, or distro.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DISTRO" title="DISTRO">DISTRO</a></code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DISTRO_NAME" title="DISTRO_NAME">DISTRO_NAME</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DISTRO_VERSION" title="DISTRO_VERSION">DISTRO_VERSION</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MAINTAINER" title="MAINTAINER">MAINTAINER</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES">PACKAGE_CLASSES</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-TARGET_OS" title="TARGET_OS">TARGET_OS</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-TARGET_FPU" title="TARGET_FPU">TARGET_FPU</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-TCMODE" title="TCMODE">TCMODE</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-TCLIBC" title="TCLIBC">TCLIBC</a></code>
</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,42 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.1.3. Local</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-configuration.html" title="11.1. Configuration">
<link rel="prev" href="ref-varlocality-config-machine.html" title="11.1.2. Machine">
<link rel="next" href="ref-varlocality-recipes.html" title="11.2. Recipes">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.1.3. Local">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-config-local"></a>11.1.3. Local</h3></div></div></div>
<p>
This section lists variables whose context is the local configuration through the
<code class="filename">local.conf</code> file.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DISTRO" title="DISTRO">DISTRO</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE" title="MACHINE">MACHINE</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DL_DIR" title="DL_DIR">DL_DIR</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-BBFILES" title="BBFILES">BBFILES</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_IMAGE_FEATURES" title="EXTRA_IMAGE_FEATURES">EXTRA_IMAGE_FEATURES
</a></code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGE_CLASSES" title="PACKAGE_CLASSES">PACKAGE_CLASSES</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-BB_NUMBER_THREADS" title="BB_NUMBER_THREADS">BB_NUMBER_THREADS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-BBINCLUDELOGS" title="BBINCLUDELOGS">BBINCLUDELOGS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-ENABLE_BINARY_LOCALE_GENERATION" title="ENABLE_BINARY_LOCALE_GENERATION">
ENABLE_BINARY_LOCALE_GENERATION</a></code></p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,41 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.1.2. Machine</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-configuration.html" title="11.1. Configuration">
<link rel="prev" href="ref-varlocality-config-distro.html" title="11.1.1. Distribution (Distro)">
<link rel="next" href="ref-varlocality-config-local.html" title="11.1.3. Local">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.1.2. Machine">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-config-machine"></a>11.1.2. Machine</h3></div></div></div>
<p>
This section lists variables whose context is the machine.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-TARGET_ARCH" title="TARGET_ARCH">TARGET_ARCH</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-SERIAL_CONSOLE" title="SERIAL_CONSOLE">SERIAL_CONSOLE</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGE_EXTRA_ARCHS" title="PACKAGE_EXTRA_ARCHS">PACKAGE_EXTRA_ARCHS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-IMAGE_FSTYPES" title="IMAGE_FSTYPES">IMAGE_FSTYPES</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE_FEATURES" title="MACHINE_FEATURES">MACHINE_FEATURES</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE_EXTRA_RDEPENDS" title="MACHINE_EXTRA_RDEPENDS">MACHINE_EXTRA_RDEPENDS
</a></code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE_EXTRA_RRECOMMENDS" title="MACHINE_EXTRA_RRECOMMENDS">MACHINE_EXTRA_RRECOMMENDS
</a></code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS" title="MACHINE_ESSENTIAL_EXTRA_RDEPENDS">MACHINE_ESSENTIAL_EXTRA_RDEPENDS
</a></code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS" title="MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS">
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</a></code></p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,20 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.1. Configuration</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality.html" title="Chapter 11. Variable Context">
<link rel="prev" href="ref-varlocality.html" title="Chapter 11. Variable Context">
<link rel="next" href="ref-varlocality-config-distro.html" title="11.1.1. Distribution (Distro)">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.1. Configuration">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ref-varlocality-configuration"></a>11.1. Configuration</h2></div></div></div>
<p>
The following subsections provide lists of variables whose context is
configuration: distribution, machine, and local.
</p>
</div></body>
</html>

View File

@ -1,33 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.2.4. Extra Build Information</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-recipes.html" title="11.2. Recipes">
<link rel="prev" href="ref-varlocality-recipe-paths.html" title="11.2.3. Paths">
<link rel="next" href="faq.html" title="Chapter 12. FAQ">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.2.4. Extra Build Information">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-recipe-build"></a>11.2.4. Extra Build Information</h3></div></div></div>
<p>
This section lists variables that define extra build information for recipes.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_OECMAKE" title="EXTRA_OECMAKE">EXTRA_OECMAKE</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_OECONF" title="EXTRA_OECONF">EXTRA_OECONF</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-EXTRA_OEMAKE" title="EXTRA_OEMAKE">EXTRA_OEMAKE</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-PACKAGES" title="PACKAGES">PACKAGES</a></code>
</p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DEFAULT_PREFERENCE" title="DEFAULT_PREFERENCE">DEFAULT_PREFERENCE
</a></code></p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,33 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.2.2. Dependencies</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-recipes.html" title="11.2. Recipes">
<link rel="prev" href="ref-varlocality-recipe-required.html" title="11.2.1. Required">
<link rel="next" href="ref-varlocality-recipe-paths.html" title="11.2.3. Paths">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.2.2. Dependencies">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-recipe-dependencies"></a>11.2.2. Dependencies</h3></div></div></div>
<p>
This section lists variables that define recipe dependencies.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-DEPENDS" title="DEPENDS">DEPENDS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-RDEPENDS" title="RDEPENDS">RDEPENDS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-RRECOMMENDS" title="RRECOMMENDS">RRECOMMENDS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-RCONFLICTS" title="RCONFLICTS">RCONFLICTS</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-RREPLACES" title="RREPLACES">RREPLACES</a>
</code></p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,29 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.2.3. Paths</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-recipes.html" title="11.2. Recipes">
<link rel="prev" href="ref-varlocality-recipe-dependencies.html" title="11.2.2. Dependencies">
<link rel="next" href="ref-varlocality-recipe-build.html" title="11.2.4. Extra Build Information">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.2.3. Paths">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-recipe-paths"></a>11.2.3. Paths</h3></div></div></div>
<p>
This section lists variables that define recipe paths.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-WORKDIR" title="WORKDIR">WORKDIR</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-S" title="S">S</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-FILES" title="FILES">FILES</a>
</code></p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

View File

@ -1,30 +0,0 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.2.1. Required</title>
<link rel="stylesheet" type="text/css" href="../book.css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="index.html" title="The Yocto Project Reference Manual">
<link rel="up" href="ref-varlocality-recipes.html" title="11.2. Recipes">
<link rel="prev" href="ref-varlocality-recipes.html" title="11.2. Recipes">
<link rel="next" href="ref-varlocality-recipe-dependencies.html" title="11.2.2. Dependencies">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.2.1. Required">
<div class="titlepage"><div><div><h3 class="title">
<a name="ref-varlocality-recipe-required"></a>11.2.1. Required</h3></div></div></div>
<p>
This section lists variables that are required for recipes.
</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-LICENSE" title="LICENSE">LICENSE</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-LIC_FILES_CHKSUM" title="LIC_FILES_CHKSUM">LIC_FILES_CHKSUM</a>
</code></p></li>
<li class="listitem"><p><code class="filename"><a class="link" href="ref-variables-glos.html#var-SRC_URI" title="SRC_URI">SRC_URI</a></code> - used
in recipes that fetch local or remote files.
</p></li>
</ul></div>
<p>
</p>
</div></body>
</html>

Some files were not shown because too many files have changed in this diff Show More