documentation: Rename of poky-ref-manual folder to ref-manual.
Changing the folder that holds the YP Reference Manual to be "ref-manual". This will help with confustion over the manual's intended purpose. (From yocto-docs rev: 1106442964b5080cb0b6b3bd3af32e9407c0f7c1) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
af19d889ef
commit
ed0a240e16
|
@ -0,0 +1,11 @@
|
|||
Handbook Todo List:
|
||||
|
||||
* Document adding a new IMAGE_FEATURE to the customising images section
|
||||
* Add instructions about using zaurus/openmoko emulation
|
||||
* Add component overview/block diagrams
|
||||
* Software Deevelopment intro should mention its software development for
|
||||
intended target and could be a different arch etc and thus special case.
|
||||
* Expand insane.bbclass documentation to cover tests
|
||||
* Document remaining classes (see list in ref-classes)
|
||||
* Document formfactor
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
<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>
|
|
@ -0,0 +1,29 @@
|
|||
<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>
|
|
@ -0,0 +1,80 @@
|
|||
<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>
|
|
@ -0,0 +1,58 @@
|
|||
<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 (>= 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>
|
|
@ -0,0 +1,61 @@
|
|||
<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 <target>
|
||||
</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>
|
|
@ -0,0 +1,23 @@
|
|||
<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>
|
|
@ -0,0 +1,69 @@
|
|||
<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>
|
|
@ -0,0 +1,164 @@
|
|||
<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-<taskname> - the base hashes for each task in the recipe
|
||||
BB_BASEHASH_<filename:taskname> - the base hashes for each dependent task
|
||||
BBHASHDEPS_<filename:taskname> - The task dependencies for each task
|
||||
BB_TASKHASH - the hash of the currently running task
|
||||
</pre>
|
||||
<p>
|
||||
</p>
|
||||
</div></body>
|
||||
</html>
|
|
@ -0,0 +1,43 @@
|
|||
<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>
|
|
@ -0,0 +1,45 @@
|
|||
<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>
|
|
@ -0,0 +1,62 @@
|
|||
<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>
|
|
@ -0,0 +1,85 @@
|
|||
<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>
|
|
@ -0,0 +1,70 @@
|
|||
<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>
|
|
@ -0,0 +1,791 @@
|
|||
<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’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’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>
|
|
@ -0,0 +1,62 @@
|
|||
<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>
|
Binary file not shown.
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
After Width: | Height: | Size: 11 KiB |
|
@ -0,0 +1,33 @@
|
|||
<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>
|
|
@ -0,0 +1,25 @@
|
|||
<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>
|
|
@ -0,0 +1,327 @@
|
|||
<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"><<a class="email" href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>></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 & 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>
|
|
@ -0,0 +1,2 @@
|
|||
<?xml version="1.0" encoding="utf-8" standalone="no"?>
|
||||
<index/>
|
|
@ -0,0 +1,26 @@
|
|||
<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>
|
|
@ -0,0 +1,35 @@
|
|||
<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>
|
|
@ -0,0 +1,73 @@
|
|||
<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>
|
|
@ -0,0 +1,23 @@
|
|||
<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>
|
|
@ -0,0 +1,30 @@
|
|||
<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>
|
|
@ -0,0 +1,30 @@
|
|||
<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>
|
|
@ -0,0 +1,53 @@
|
|||
<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>
|
|
@ -0,0 +1,91 @@
|
|||
<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>
|
|
@ -0,0 +1,28 @@
|
|||
<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>
|
|
@ -0,0 +1,47 @@
|
|||
<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>
|
|
@ -0,0 +1,45 @@
|
|||
<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>
|
|
@ -0,0 +1,53 @@
|
|||
<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>
|
|
@ -0,0 +1,27 @@
|
|||
<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>
|
|
@ -0,0 +1,26 @@
|
|||
<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>
|
|
@ -0,0 +1,25 @@
|
|||
<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>
|
|
@ -0,0 +1,32 @@
|
|||
<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>
|
|
@ -0,0 +1,29 @@
|
|||
<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>
|
|
@ -0,0 +1,64 @@
|
|||
<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>
|
|
@ -0,0 +1,36 @@
|
|||
<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>
|
|
@ -0,0 +1,39 @@
|
|||
<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>
|
|
@ -0,0 +1,31 @@
|
|||
<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>
|
|
@ -0,0 +1,20 @@
|
|||
<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>
|
|
@ -0,0 +1,60 @@
|
|||
<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>
|
|
@ -0,0 +1,60 @@
|
|||
<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>
|
|
@ -0,0 +1,31 @@
|
|||
<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>
|
|
@ -0,0 +1,41 @@
|
|||
<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>
|
|
@ -0,0 +1,79 @@
|
|||
<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>
|
|
@ -0,0 +1,34 @@
|
|||
<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>
|
|
@ -0,0 +1,43 @@
|
|||
<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>
|
|
@ -0,0 +1,93 @@
|
|||
<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>
|
|
@ -0,0 +1,63 @@
|
|||
<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>
|
|
@ -0,0 +1,86 @@
|
|||
<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>
|
|
@ -0,0 +1,54 @@
|
|||
<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>
|
|
@ -0,0 +1,48 @@
|
|||
<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>
|
|
@ -0,0 +1,52 @@
|
|||
<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> ‐ 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> ‐ 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> ‐ 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>
|
|
@ -0,0 +1,28 @@
|
|||
<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>
|
|
@ -0,0 +1,30 @@
|
|||
<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>
|
|
@ -0,0 +1,22 @@
|
|||
<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>
|
|
@ -0,0 +1,24 @@
|
|||
<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>
|
|
@ -0,0 +1,31 @@
|
|||
<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>
|
|
@ -0,0 +1,72 @@
|
|||
<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>
|
|
@ -0,0 +1,31 @@
|
|||
<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>
|
|
@ -0,0 +1,105 @@
|
|||
<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>
|
|
@ -0,0 +1,36 @@
|
|||
<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>
|
|
@ -0,0 +1,24 @@
|
|||
<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>
|
|
@ -0,0 +1,73 @@
|
|||
<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>
|
|
@ -0,0 +1,33 @@
|
|||
<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>
|
|
@ -0,0 +1,31 @@
|
|||
<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>
|
|
@ -0,0 +1,27 @@
|
|||
<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>
|
|
@ -0,0 +1,25 @@
|
|||
<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>
|
|
@ -0,0 +1,39 @@
|
|||
<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>
|
|
@ -0,0 +1,43 @@
|
|||
<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>
|
|
@ -0,0 +1,48 @@
|
|||
<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> ‐ 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> ‐ 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> ‐ 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> ‐ 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>
|
|
@ -0,0 +1,28 @@
|
|||
<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>
|
|
@ -0,0 +1,28 @@
|
|||
<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>
|
|
@ -0,0 +1,61 @@
|
|||
<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>
|
|
@ -0,0 +1,88 @@
|
|||
<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>
|
|
@ -0,0 +1,68 @@
|
|||
<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>
|
|
@ -0,0 +1,73 @@
|
|||
<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>
|
|
@ -0,0 +1,63 @@
|
|||
<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>
|
|
@ -0,0 +1,60 @@
|
|||
<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.*<feature>'
|
||||
</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>
|
|
@ -0,0 +1,137 @@
|
|||
<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 “top-level” 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 “init” 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>
|
|
@ -0,0 +1,98 @@
|
|||
<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>
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,40 @@
|
|||
<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>
|
|
@ -0,0 +1,42 @@
|
|||
<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>
|
|
@ -0,0 +1,41 @@
|
|||
<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>
|
|
@ -0,0 +1,20 @@
|
|||
<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>
|
|
@ -0,0 +1,33 @@
|
|||
<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>
|
|
@ -0,0 +1,33 @@
|
|||
<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>
|
|
@ -0,0 +1,29 @@
|
|||
<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>
|
|
@ -0,0 +1,30 @@
|
|||
<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>
|
|
@ -0,0 +1,20 @@
|
|||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>11.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="ref-varlocality.html" title="Chapter 11. Variable Context">
|
||||
<link rel="prev" href="ref-varlocality-config-local.html" title="11.1.3. Local">
|
||||
<link rel="next" href="ref-varlocality-recipe-required.html" title="11.2.1. Required">
|
||||
</head>
|
||||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="11.2. Recipes">
|
||||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||||
<a name="ref-varlocality-recipes"></a>11.2. Recipes</h2></div></div></div>
|
||||
<p>
|
||||
The following subsections provide lists of variables whose context is
|
||||
recipes: required, dependencies, path, and extra build information.
|
||||
</p>
|
||||
</div></body>
|
||||
</html>
|
|
@ -0,0 +1,41 @@
|
|||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Chapter 11. Variable Context</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-variables-glos.html" title="Chapter 10. Variables Glossary">
|
||||
<link rel="next" href="ref-varlocality-configuration.html" title="11.1. Configuration">
|
||||
</head>
|
||||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 11. Variable Context">
|
||||
<div class="titlepage"><div><div><h2 class="title">
|
||||
<a name="ref-varlocality"></a>Chapter 11. Variable Context</h2></div></div></div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<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>
|
||||
</div>
|
||||
<p>
|
||||
While most variables can be used in almost any context such as
|
||||
<code class="filename">.conf</code>, <code class="filename">.bbclass</code>,
|
||||
<code class="filename">.inc</code>, and <code class="filename">.bb</code> files,
|
||||
some variables are often associated with a particular locality or context.
|
||||
This chapter describes some common associations.
|
||||
</p>
|
||||
</div></body>
|
||||
</html>
|
|
@ -0,0 +1,22 @@
|
|||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>1.3.2. Required Packages for the Host Development System</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="detailed-supported-distros.html" title="1.3.1. Supported Linux Distributions">
|
||||
<link rel="next" href="ubuntu-packages.html" title="1.3.2.1. Ubuntu">
|
||||
</head>
|
||||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.3.2. Required Packages for the Host Development System">
|
||||
<div class="titlepage"><div><div><h3 class="title">
|
||||
<a name="required-packages-for-the-host-development-system"></a>1.3.2. Required Packages for the Host Development System</h3></div></div></div>
|
||||
<p>
|
||||
The list of packages you need on the host development system can
|
||||
be large when covering all build scenarios using the Yocto Project.
|
||||
This section provides required packages by Linux distribution and
|
||||
further categorized by function.
|
||||
</p>
|
||||
</div></body>
|
||||
</html>
|
|
@ -0,0 +1,20 @@
|
|||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>13.2. Tracking Bugs</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="resources.html" title="Chapter 13. Contributing to the Yocto Project">
|
||||
<link rel="prev" href="resources-intro.html" title="13.1. Introduction">
|
||||
<link rel="next" href="resources-mailinglist.html" title="13.3. Mailing lists">
|
||||
</head>
|
||||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="13.2. Tracking Bugs">
|
||||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||||
<a name="resources-bugtracker"></a>13.2. Tracking Bugs</h2></div></div></div>
|
||||
<p>
|
||||
If you find problems with the Yocto Project, you should report them using the
|
||||
Bugzilla application at <a class="ulink" href="http://bugzilla.yoctoproject.org" target="_self">http://bugzilla.yoctoproject.org</a>.
|
||||
</p>
|
||||
</div></body>
|
||||
</html>
|
|
@ -0,0 +1,23 @@
|
|||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>13.6. Contributions</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="resources.html" title="Chapter 13. Contributing to the Yocto Project">
|
||||
<link rel="prev" href="resources-links.html" title="13.5. Links">
|
||||
</head>
|
||||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="13.6. Contributions">
|
||||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||||
<a name="resources-contributions"></a>13.6. Contributions</h2></div></div></div>
|
||||
<p>
|
||||
The Yocto Project gladly accepts contributions.
|
||||
You can submit changes to the project either by creating and sending pull requests,
|
||||
or by submitting patches through email.
|
||||
For information on how to do both, see the
|
||||
"<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">How to Submit a Change</a>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</p>
|
||||
</div></body>
|
||||
</html>
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue