Documentation: ref-manual - removing old poky-ref-manual files
Removed the old poky-ref-manuals from the new ref-manual structure. (From yocto-docs rev: b5db4ddea205875ed3acacb90f46efd557337e0d) 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
bb8e9d0599
commit
8753c6b288
|
@ -1,11 +0,0 @@
|
|||
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
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
DESCRIPTION = "GNU Helloworld application"
|
||||
SECTION = "examples"
|
||||
LICENSE = "GPLv3"
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=adefda309052235aa5d1e99ce7557010"
|
||||
|
||||
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2"
|
||||
|
||||
inherit autotools
|
|
@ -1,8 +0,0 @@
|
|||
#include <stdio.h>
|
||||
|
||||
int main(void)
|
||||
{
|
||||
printf("Hello world!\n");
|
||||
|
||||
return 0;
|
||||
}
|
|
@ -1,17 +0,0 @@
|
|||
DESCRIPTION = "Simple helloworld application"
|
||||
SECTION = "examples"
|
||||
LICENSE = "MIT"
|
||||
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
|
||||
|
||||
SRC_URI = "file://helloworld.c"
|
||||
|
||||
S = "${WORKDIR}"
|
||||
|
||||
do_compile() {
|
||||
${CC} helloworld.c -o helloworld
|
||||
}
|
||||
|
||||
do_install() {
|
||||
install -d ${D}${bindir}
|
||||
install -m 0755 helloworld ${D}${bindir}
|
||||
}
|
|
@ -1,14 +0,0 @@
|
|||
require xorg-lib-common.inc
|
||||
|
||||
DESCRIPTION = "X11 Pixmap library"
|
||||
LICENSE = "X-BSD"
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5"
|
||||
DEPENDS += "libxext"
|
||||
PR = "r2"
|
||||
PE = "1"
|
||||
|
||||
XORG_PN = "libXpm"
|
||||
|
||||
PACKAGES =+ "sxpm cxpm"
|
||||
FILES_cxpm = "${bindir}/cxpm"
|
||||
FILES_sxpm = "${bindir}/sxpm"
|
|
@ -1,15 +0,0 @@
|
|||
DESCRIPTION = "Tools for managing memory technology devices."
|
||||
SECTION = "base"
|
||||
DEPENDS = "zlib"
|
||||
HOMEPAGE = "http://www.linux-mtd.infradead.org/"
|
||||
LICENSE = "GPLv2"
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
|
||||
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
|
||||
|
||||
SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz"
|
||||
|
||||
CFLAGS_prepend = "-I ${S}/include "
|
||||
|
||||
do_install() {
|
||||
oe_runmake install DESTDIR=${D}
|
||||
}
|
|
@ -1,606 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='faq'>
|
||||
<title>FAQ</title>
|
||||
<qandaset>
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The term "Poky" refers to the specific reference build system that
|
||||
the Yocto Project provides.
|
||||
Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
|
||||
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
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> term in the Yocto Project
|
||||
Development Manual.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
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?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem>
|
||||
<listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
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:
|
||||
<literallayout class='monospaced'>
|
||||
$ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
|
||||
$ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
|
||||
</literallayout>
|
||||
</para>
|
||||
<para>
|
||||
Once you run the command, BitBake uses Python 2.6.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How can you claim Poky / OpenEmbedded-Core is stable?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
There are three areas that help with stability;
|
||||
<itemizedlist>
|
||||
<listitem><para>The Yocto Project team keeps
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> 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.</para></listitem>
|
||||
<listitem><para>The Yocto Project team runs manual and automated tests
|
||||
using a small, fixed set of reference hardware as well as emulated
|
||||
targets.</para></listitem>
|
||||
<listitem><para>The Yocto Project uses an an autobuilder,
|
||||
which provides continuous build and integration tests.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I get support for my board added to the Yocto Project?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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
|
||||
<ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
|
||||
</para>
|
||||
<para>
|
||||
Usually, if the board is not completely exotic, adding support in
|
||||
the Yocto Project is fairly straightforward.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
Are there any products built using the OpenEmbedded build system?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink>
|
||||
is built using the OpenEmbedded build system.
|
||||
See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
|
||||
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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
What does the OpenEmbedded build system produce as output?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I add my package to the Yocto Project?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
To add a package, you need to create a BitBake recipe.
|
||||
For information on how to add a package, see the section
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Adding a Package</ulink>"
|
||||
in the Yocto Project Development Manual.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
Do I have to reflash my entire board with a new Yocto Project image when recompiling
|
||||
a package?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The OpenEmbedded build system can build packages in various formats such as
|
||||
<filename>ipk</filename> for <filename>opkg</filename>,
|
||||
Debian package (<filename>.deb</filename>), 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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink>
|
||||
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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
I see the error '<filename>chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</filename>'.
|
||||
What is wrong?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You are probably running the build on an NTFS filesystem.
|
||||
Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I make the Yocto Project work in RHEL/CentOS?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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:
|
||||
<itemizedlist>
|
||||
<listitem><para>"Development tools" (selected during installation)</para></listitem>
|
||||
<listitem><para><filename>texi2html</filename></para></listitem>
|
||||
<listitem><para><filename>compat-gcc-34</filename></para></listitem>
|
||||
</itemizedlist>
|
||||
On top of these, you need the following external packages:
|
||||
<itemizedlist>
|
||||
<listitem><para><filename>python-sqlite2</filename> from
|
||||
<ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink>
|
||||
</para></listitem>
|
||||
<listitem><para><filename>help2man</filename> from
|
||||
<ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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
|
||||
<filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
|
||||
</filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
|
||||
from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
I see lots of 404 responses for files on
|
||||
<filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
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?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
|
||||
</filename> = "0" in the <filename>.bb</filename> file but make sure the package is
|
||||
manually marked as
|
||||
machine-specific in the case that needs it.
|
||||
The code that handles <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in <filename>base.bbclass</filename>.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
I'm behind a firewall and need to use a proxy server. How do I do that?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
|
||||
and you therefore need to specify the proxy settings in a
|
||||
<filename>.wgetrc</filename> file in your home directory.
|
||||
Example settings in that file would be
|
||||
<literallayout class='monospaced'>
|
||||
http_proxy = http://proxy.yoyodyne.com:18023/
|
||||
ftp_proxy = http://proxy.yoyodyne.com:18023/
|
||||
</literallayout>
|
||||
The Yocto Project also includes a <filename>site.conf.sample</filename>
|
||||
file that shows how to configure CVS and Git proxy servers
|
||||
if needed.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
What’s the difference between <filename>foo</filename> and <filename>foo-native</filename>?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The <filename>*-native</filename> 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
|
||||
<filename>quilt-native</filename>, which is used to apply patches.
|
||||
The non-native version is the one that runs on the target device.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
I'm seeing random build failures. Help?!
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
What do we need to ship for license compliance?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I disable the cursor on my touchscreen device?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
You need to create a form factor file as described in the
|
||||
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
|
||||
section and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
|
||||
<literallayout class='monospaced'>
|
||||
HAVE_TOUCHSCREEN=1
|
||||
</literallayout>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I make sure connected network interfaces are brought up by default?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
|
||||
section for information on creating these types of miscellaneous recipe files.
|
||||
</para>
|
||||
<para>
|
||||
For example, add the following files to your layer:
|
||||
<literallayout class='monospaced'>
|
||||
meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
|
||||
meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
|
||||
</literallayout>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I create images with more free space?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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 <filename>IMAGE_OVERHEAD_FACTOR</filename>.
|
||||
For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets
|
||||
the image size ratio to one and a half times the size of the populated
|
||||
root filesystem.
|
||||
<literallayout class='monospaced'>
|
||||
IMAGE_OVERHEAD_FACTOR = "1.5"
|
||||
</literallayout>
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
Why don't you support directories with spaces in the pathnames?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The Yocto Project team has tried to do this before but too many of the tools
|
||||
the OpenEmbedded build system depends on such as <filename>autoconf</filename>
|
||||
break when they find spaces in pathnames.
|
||||
Until that situation changes, the team will not support spaces in pathnames.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
How do I use an external toolchain?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The toolchain configuration is very flexible and customizable.
|
||||
It is primarily controlled with the
|
||||
<filename><link linkend='var-TCMODE'>TCMODE</link></filename> variable.
|
||||
This variable controls which <filename>tcmode-*.inc</filename> file to include
|
||||
from the <filename>meta/conf/distro/include</filename> directory within the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The default value of <filename>TCMODE</filename> is "default"
|
||||
(i.e. <filename>tcmode-default.inc</filename>).
|
||||
However, other patterns are accepted.
|
||||
In particular, "external-*" refers to external toolchains of which there are some
|
||||
basic examples included in the OpenEmbedded Core (<filename>meta</filename>).
|
||||
You can use your own custom toolchain definition in your own layer
|
||||
(or as defined in the <filename>local.conf</filename> file) at the location
|
||||
<filename>conf/distro/include/tcmode-*.inc</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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
|
||||
<filename>libgcc</filename>, <filename>libstdcc++</filename>,
|
||||
any locales, and <filename>libc</filename>.
|
||||
An example is the <filename>external-sourcery-toolchain.bb</filename>, which is located
|
||||
in <filename>meta/recipes-core/meta/</filename> within the source directory.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
|
||||
How does the OpenEmbedded build system obtain source code and will it work behind my
|
||||
firewall or proxy server?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
As an example, you could add a specific server for Poky to attempt before any
|
||||
others by adding something like the following to the <filename>local.conf</filename>
|
||||
configuration file:
|
||||
<literallayout class='monospaced'>
|
||||
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"
|
||||
</literallayout>
|
||||
</para>
|
||||
<para>
|
||||
These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS
|
||||
requests and direct them to the <filename>http://</filename> sources mirror.
|
||||
You can use <filename>file://</filename> URLs to point to local directories
|
||||
or network shares as well.
|
||||
</para>
|
||||
<para>
|
||||
Aside from the previous technique, these options also exist:
|
||||
<literallayout class='monospaced'>
|
||||
BB_NO_NETWORK = "1"
|
||||
</literallayout>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
Here is another technique:
|
||||
<literallayout class='monospaced'>
|
||||
BB_FETCH_PREMIRRORONLY = "1"
|
||||
</literallayout>
|
||||
This statement limits Poky to pulling source from the PREMIRRORS only.
|
||||
Again, this technique is useful for reproducing builds.
|
||||
</para>
|
||||
<para>
|
||||
Here is another technique:
|
||||
<literallayout class='monospaced'>
|
||||
BB_GENERATE_MIRROR_TARBALLS = "1"
|
||||
</literallayout>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
Finally, consider an example where you are behind an HTTP-only firewall.
|
||||
You could make the following changes to the <filename>local.conf</filename>
|
||||
configuration file as long as the PREMIRROR server is up to date:
|
||||
<literallayout class='monospaced'>
|
||||
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"
|
||||
</literallayout>
|
||||
These changes would cause Poky to successfully fetch source over HTTP and
|
||||
any network accesses to anything other than the PREMIRROR would fail.
|
||||
</para>
|
||||
<para>
|
||||
The build system also honors the standard shell environment variables
|
||||
<filename>http_proxy</filename>, <filename>ftp_proxy</filename>,
|
||||
<filename>https_proxy</filename>, and <filename>all_proxy</filename>
|
||||
to redirect requests through proxy servers.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
Can I get rid of build output so I can start over?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
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 <filename>oe-init-build-env</filename>
|
||||
setup file.
|
||||
By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
|
||||
is named <filename>build</filename> but can be named
|
||||
anything you want.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Within the build directory is the <filename>tmp</filename> directory.
|
||||
To remove all the build output yet preserve any source code or downloaded files
|
||||
from previous builds, simply remove the <filename>tmp</filename> directory.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
||||
</qandaset>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
Binary file not shown.
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
Before Width: | Height: | Size: 11 KiB |
|
@ -1,322 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='intro'>
|
||||
<title>Introduction</title>
|
||||
|
||||
<section id='intro-welcome'>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
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
|
||||
<ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
|
||||
For task-based information using the Yocto Project, see the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>.
|
||||
You can also find lots of information on the Yocto Project on the
|
||||
<ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='intro-manualoverview'>
|
||||
<title>Documentation Overview</title>
|
||||
<para>
|
||||
This reference manual consists of the following:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis> 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.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='technical-details'>Technical Details</link>:</emphasis>
|
||||
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.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-structure'>Directory Structure</link>:</emphasis>
|
||||
This chapter describes the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> created
|
||||
either by unpacking a released Yocto Project tarball on your host development system,
|
||||
or by cloning the upstream
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-bitbake'>BitBake</link>:</emphasis>
|
||||
This chapter provides an overview of the BitBake tool and its role within
|
||||
the Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-classes'>Classes</link>:</emphasis>
|
||||
This chapter describes the classes used in the Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-images'>Images</link>:</emphasis>
|
||||
This chapter describes the standard images that the Yocto Project supports.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-features'>Features</link>:</emphasis>
|
||||
This chapter describes mechanisms for creating distribution, machine, and image
|
||||
features during the build process using the OpenEmbedded build system.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-variables-glos'>Variables Glossary</link>:</emphasis>
|
||||
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.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-varlocality'>Variable Context</link>:</emphasis>
|
||||
This chapter provides variable locality or context.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='faq'>FAQ</link>:</emphasis>
|
||||
This chapter provides answers for commonly asked questions in the Yocto Project
|
||||
development environment.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='resources'>Contributing to the Yocto Project</link>:</emphasis>
|
||||
This chapter provides guidance on how you can contribute back to the Yocto
|
||||
Project.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
||||
<section id='intro-requirements'>
|
||||
<title>System Requirements</title>
|
||||
<para>
|
||||
For general Yocto Project system requirements, see the
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>What You Need and How You Get It</ulink>" section
|
||||
in the Yocto Project Quick Start.
|
||||
The remainder of this section provides details on system requirements
|
||||
not covered in the Yocto Project Quick Start.
|
||||
</para>
|
||||
|
||||
<section id='detailed-supported-distros'>
|
||||
<title>Supported Linux Distributions</title>
|
||||
|
||||
<para>
|
||||
Currently, the Yocto Project is supported on the following distributions:
|
||||
<itemizedlist>
|
||||
<listitem><para>Ubuntu 10.04.4 LTS</para></listitem>
|
||||
<listitem><para>Ubuntu 11.10</para></listitem>
|
||||
<listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
|
||||
<listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
|
||||
<listitem><para>Ubuntu 12.10</para></listitem>
|
||||
<listitem><para>Fedora release 16 (Verne)</para></listitem>
|
||||
<listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>
|
||||
<listitem><para>Fedora release 18 (Spherical Cow)</para></listitem>
|
||||
<listitem><para>CentOS release 5.6 (Final)</para></listitem>
|
||||
<listitem><para>CentOS release 5.7 (Final)</para></listitem>
|
||||
<listitem><para>CentOS release 5.8 (Final)</para></listitem>
|
||||
<listitem><para>CentOS release 6.3 (Final)</para></listitem>
|
||||
<listitem><para>Debian GNU/Linux 6.0.6 (squeeze)</para></listitem>
|
||||
<listitem><para>openSUSE 11.4</para></listitem>
|
||||
<listitem><para>openSUSE 12.1</para></listitem>
|
||||
<listitem><para>openSUSE 12.2</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<note>
|
||||
For additional information on distributions that support the
|
||||
Yocto Project, see the
|
||||
<ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink> wiki page.
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='required-packages-for-the-host-development-system'>
|
||||
<title>Required Packages for the Host Development System</title>
|
||||
|
||||
<para>
|
||||
The list of packages you need on the host development system can
|
||||
be large when covering all build scenarios using the Yocto Project.
|
||||
This section provides required packages by Linux distribution and
|
||||
further categorized by function.
|
||||
</para>
|
||||
|
||||
<section id='ubuntu-packages'>
|
||||
<title>Ubuntu</title>
|
||||
|
||||
<para>
|
||||
The following list shows the required packages by function
|
||||
given a supported Ubuntu Linux distribution:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Essentials:</emphasis>
|
||||
Packages needed to build an image on a headless
|
||||
system:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Graphical Extras:</emphasis>
|
||||
Packages recommended if the host system has graphics support:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo apt-get install libsdl1.2-dev xterm
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Documentation:</emphasis>
|
||||
Packages needed if you are going to build out the
|
||||
Yocto Project documentation manuals:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo apt-get install make xsltproc docbook-utils fop
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>ADT Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo apt-get install autoconf automake libtool libglib2.0-dev
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='fedora-packages'>
|
||||
<title>Fedora Packages</title>
|
||||
|
||||
<para>
|
||||
The following list shows the required packages by function
|
||||
given a supported Fedora Linux distribution:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Essentials:</emphasis>
|
||||
Packages needed to build an image for a headless
|
||||
system:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL;
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Graphical Extras:</emphasis>
|
||||
Packages recommended if the host system has graphics support:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum install SDL-devel xterm
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Documentation:</emphasis>
|
||||
Packages needed if you are going to build out the
|
||||
Yocto Project documentation manuals:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum install make docbook-style-dsssl docbook-style-xsl \
|
||||
docbook-dtds docbook-utils fop libxslt
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>ADT Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum install autoconf automake libtool glib2-devel
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='opensuse-packages'>
|
||||
<title>OpenSUSE Packages</title>
|
||||
|
||||
<para>
|
||||
The following list shows the required packages by function
|
||||
given a supported OpenSUSE Linux distribution:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Essentials:</emphasis>
|
||||
Packages needed to build an image for a headless
|
||||
system:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Graphical Extras:</emphasis>
|
||||
Packages recommended if the host system has graphics support:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install libSDL-devel xterm
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Documentation:</emphasis>
|
||||
Packages needed if you are going to build out the
|
||||
Yocto Project documentation manuals:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install make fop xsltproc
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>ADT Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install autoconf automake libtool glib2-devel
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='centos-packages'>
|
||||
<title>CentOS Packages</title>
|
||||
|
||||
<para>
|
||||
The following list shows the required packages by function
|
||||
given a supported CentOS Linux distribution:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Essentials:</emphasis>
|
||||
Packages needed to build an image for a headless
|
||||
system:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum -y install &CENTOS_HOST_PACKAGES_ESSENTIAL;
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Graphical Extras:</emphasis>
|
||||
Packages recommended if the host system has graphics support:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum -y install SDL-devel xterm
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>Documentation:</emphasis>
|
||||
Packages needed if you are going to build out the
|
||||
Yocto Project documentation manuals:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum -y install make docbook-style-dsssl docbook-style-xsl \
|
||||
docbook-dtds docbook-utils fop libxslt
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>ADT Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum -y install autoconf automake libtool glib2-devel
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
<note>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
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
|
||||
wiki page.</note>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='intro-getit'>
|
||||
<title>Obtaining the Yocto Project</title>
|
||||
<para>
|
||||
The Yocto Project development team makes the Yocto Project available through a number
|
||||
of methods:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through
|
||||
<ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
|
||||
<listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
|
||||
<ulink url='http://autobuilder.yoctoproject.org/nightly'/>.
|
||||
These builds include Yocto Project releases, meta-toolchain tarball installation scripts, and
|
||||
experimental builds.</para></listitem>
|
||||
<listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
|
||||
of the Yocto Project and supported BSPs at the
|
||||
<ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
|
||||
Along with these downloads, you can find lots of other information at this site.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='intro-getit-dev'>
|
||||
<title>Development Checkouts</title>
|
||||
<para>
|
||||
Development using the Yocto Project requires a local
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
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
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
|
||||
For information on both these methods, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -1,235 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='migration'>
|
||||
<title>Migrating to a Newer Yocto Project Release</title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<section id='moving-to-the-yocto-project-1.3-release'>
|
||||
<title>Moving to the Yocto Project 1.3 Release</title>
|
||||
|
||||
<para>
|
||||
This section provides migration information for moving to the
|
||||
Yocto Project 1.3 Release.
|
||||
</para>
|
||||
|
||||
<section id='1.3-local-configuration'>
|
||||
<title>Local Configuration</title>
|
||||
|
||||
<para>
|
||||
Differences include changes for
|
||||
<link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
|
||||
and <filename>bblayers.conf</filename>.
|
||||
</para>
|
||||
|
||||
<section id='migration-1.3-sstate-mirrors'>
|
||||
<title>SSTATE_MIRRORS</title>
|
||||
|
||||
<para>
|
||||
The shared state cache (sstate-cache) as pointed to by
|
||||
<link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> 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
|
||||
<link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
|
||||
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:
|
||||
<literallayout class='monospaced'>
|
||||
SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='migration-1.3-bblayers-conf'>
|
||||
<title>bblayers.conf</title>
|
||||
|
||||
<para>
|
||||
The <filename>meta-yocto</filename> layer has been split into
|
||||
two parts: <filename>meta-yocto</filename> and
|
||||
<filename>meta-yocto-bsp</filename>, 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 <filename>conf/bblayers.conf</filename> file will be
|
||||
updated to handle this change and you will be asked to
|
||||
re-run/restart for the changes to take effect.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='1.3-recipes'>
|
||||
<title>Recipes</title>
|
||||
|
||||
<para>
|
||||
Differences include changes for the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>Python function whitespace</para></listitem>
|
||||
<listitem><para><filename>proto=</filename> in <filename>SRC_URI</filename></para></listitem>
|
||||
<listitem><para><filename>nativesdk</filename></para></listitem>
|
||||
<listitem><para>Task recipes</para></listitem>
|
||||
<listitem><para><filename>IMAGE_FEATURES</filename></para></listitem>
|
||||
<listitem><para>Removed recipes</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<section id='migration-1.3-python-function-whitespace'>
|
||||
<title>Python Function Whitespace</title>
|
||||
|
||||
<para>
|
||||
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
|
||||
<filename>_append</filename> or <filename>_prepend</filename>
|
||||
complicated given that Python treats whitespace as
|
||||
syntactically significant.
|
||||
If you are defining or extending any Python functions (e.g.
|
||||
<filename>populate_packages</filename>, <filename>do_unpack</filename>,
|
||||
<filename>do_patch</filename> and so forth) in custom recipes
|
||||
or classes, you need to ensure you are using consistent
|
||||
four-space indentation.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='migration-1.3-proto=-in-src-uri'>
|
||||
<title>proto= in SRC_URI</title>
|
||||
|
||||
<para>
|
||||
Any use of <filename>proto=</filename> in
|
||||
<link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
|
||||
needs to be changed to <filename>protocol=</filename>.
|
||||
In particular, this applies to the following URIs:
|
||||
<itemizedlist>
|
||||
<listitem><para><filename>svn://</filename></para></listitem>
|
||||
<listitem><para><filename>bzr://</filename></para></listitem>
|
||||
<listitem><para><filename>hg://</filename></para></listitem>
|
||||
<listitem><para><filename>osc://</filename></para></listitem>
|
||||
</itemizedlist>
|
||||
Other URIs were already using <filename>protocol=</filename>.
|
||||
This change improves consistency.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='migration-1.3-nativesdk'>
|
||||
<title>nativesdk</title>
|
||||
|
||||
<para>
|
||||
The suffix <filename>nativesdk</filename> is now implemented
|
||||
as a prefix, which simplifies a lot of the packaging code for
|
||||
<filename>nativesdk</filename> recipes.
|
||||
All custom <filename>nativesdk</filename> recipes and any
|
||||
references need to be updated to use
|
||||
<filename>nativesdk-*</filename> instead of
|
||||
<filename>*-nativesdk</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='migration-1.3-task-recipes'>
|
||||
<title>Task Recipes</title>
|
||||
|
||||
<para>
|
||||
"Task" recipes are now known as "Package groups" and have
|
||||
been renamed from <filename>task-*.bb</filename> to
|
||||
<filename>packagegroup-*.bb</filename>.
|
||||
Existing references to the previous <filename>task-*</filename>
|
||||
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 <filename>task-*</filename>
|
||||
recipes to <filename>packagegroup-*</filename>, and change
|
||||
them to inherit <filename>packagegroup</filename> instead of
|
||||
<filename>task</filename>, as well as taking the opportunity
|
||||
to remove anything now handled by
|
||||
<filename>packagegroup.bbclass</filename>, such as providing
|
||||
<filename>-dev</filename> and <filename>-dbg</filename>
|
||||
packages, setting
|
||||
<link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>,
|
||||
and so forth.
|
||||
See the
|
||||
"<link linkend='ref-classes-packagegroup'>Package Groups - packagegroup.bbclass</link>"
|
||||
section for further details.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='migration-1.3-image-features'>
|
||||
<title>IMAGE_FEATURES</title>
|
||||
|
||||
<para>
|
||||
Image recipes that previously included "apps-console-core"
|
||||
in <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
|
||||
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"
|
||||
<filename>IMAGE_FEATURES</filename> features have been removed.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='migration-1.3-removed-recipes'>
|
||||
<title>Removed Recipes</title>
|
||||
|
||||
<para>
|
||||
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:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>libx11-trim</filename></emphasis>:
|
||||
Replaced by <filename>libx11</filename>, which has a negligible
|
||||
size difference with modern Xorg.</para></listitem>
|
||||
<listitem><para><emphasis><filename>xserver-xorg-lite</filename></emphasis>:
|
||||
Use <filename>xserver-xorg</filename>, which has a negligible
|
||||
size difference when DRI and GLX modules are not installed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>xserver-kdrive</filename></emphasis>:
|
||||
Effectively unmaintained for many years.</para></listitem>
|
||||
<listitem><para><emphasis><filename>mesa-xlib</filename></emphasis>:
|
||||
No longer serves any purpose.</para></listitem>
|
||||
<listitem><para><emphasis><filename>galago</filename></emphasis>:
|
||||
Replaced by telepathy.</para></listitem>
|
||||
<listitem><para><emphasis><filename>gail</filename></emphasis>:
|
||||
Functionality was integrated into GTK+ 2.13.</para></listitem>
|
||||
<listitem><para><emphasis><filename>eggdbus</filename></emphasis>:
|
||||
No longer needed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>gcc-*-intermediate</filename></emphasis>:
|
||||
The build has been restructured to avoid the need for
|
||||
this step.</para></listitem>
|
||||
<listitem><para><emphasis><filename>libgsmd</filename></emphasis>:
|
||||
Unmaintained for many years.
|
||||
Functionality now provided by
|
||||
<filename>ofono</filename> instead.</para></listitem>
|
||||
<listitem><para><emphasis>contacts, dates, tasks, eds-tools</emphasis>:
|
||||
Largely unmaintained PIM application suite.
|
||||
It has been moved to <filename>meta-gnome</filename>
|
||||
in <filename>meta-openembedded</filename>.</para></listitem>
|
||||
</itemizedlist>
|
||||
In addition to the previously listed changes, the
|
||||
<filename>meta-demoapps</filename> 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
|
||||
<filename>meta-oe</filename> and <filename>meta-gnome</filename>.
|
||||
For the remainder, you can now find them in the
|
||||
<filename>meta-extras</filename> repository, which is in the
|
||||
Yocto Project source repositories.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -1,6 +0,0 @@
|
|||
<?xml version='1.0'?>
|
||||
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
|
||||
|
||||
<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
|
||||
|
||||
</xsl:stylesheet>
|
|
@ -1,125 +0,0 @@
|
|||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<book id='poky-ref-manual' lang='en'
|
||||
xmlns:xi="http://www.w3.org/2003/XInclude"
|
||||
xmlns="http://docbook.org/ns/docbook"
|
||||
>
|
||||
<bookinfo>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref='figures/poky-title.png'
|
||||
format='SVG'
|
||||
align='left' scalefit='1' width='100%'/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
<title></title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Richard</firstname> <surname>Purdie</surname>
|
||||
<affiliation>
|
||||
<orgname>Linux Foundation</orgname>
|
||||
</affiliation>
|
||||
<email>richard.purdie@linuxfoundation.org</email>
|
||||
</author>
|
||||
|
||||
</authorgroup>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>4.0+git</revnumber>
|
||||
<date>24 November 2010</date>
|
||||
<revremark>Released with the Yocto Project 0.9 Release</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0</revnumber>
|
||||
<date>6 April 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.0.1</revnumber>
|
||||
<date>23 May 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>6 October 2011</date>
|
||||
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.2</revnumber>
|
||||
<date>April 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.2 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.3</revnumber>
|
||||
<date>October 2012</date>
|
||||
<revremark>Released with the Yocto Project 1.3 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.4</revnumber>
|
||||
<date>Sometime in 2013</date>
|
||||
<revremark>Released with the Yocto Project 1.4 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>©RIGHT_YEAR;</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
Permission is granted to copy, distribute and/or modify this document under
|
||||
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England & Wales</ulink> as published by Creative Commons.
|
||||
</para>
|
||||
<note>
|
||||
Due to production processes, there could be differences between the Yocto Project
|
||||
documentation bundled in the release tarball and the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink> on
|
||||
the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
|
||||
For the latest version of this manual, see the manual on the website.
|
||||
</note>
|
||||
</legalnotice>
|
||||
|
||||
</bookinfo>
|
||||
|
||||
<xi:include href="introduction.xml"/>
|
||||
|
||||
<xi:include href="usingpoky.xml"/>
|
||||
|
||||
<xi:include href="technical-details.xml"/>
|
||||
|
||||
<xi:include href="migration.xml"/>
|
||||
|
||||
<xi:include href="ref-structure.xml"/>
|
||||
|
||||
<xi:include href="ref-bitbake.xml"/>
|
||||
|
||||
<xi:include href="ref-classes.xml"/>
|
||||
|
||||
<xi:include href="ref-images.xml"/>
|
||||
|
||||
<xi:include href="ref-features.xml"/>
|
||||
|
||||
<xi:include href="ref-variables.xml"/>
|
||||
|
||||
<xi:include href="ref-varlocality.xml"/>
|
||||
|
||||
<xi:include href="faq.xml"/>
|
||||
|
||||
<xi:include href="resources.xml"/>
|
||||
|
||||
<!-- <index id='index'>
|
||||
<title>Index</title>
|
||||
</index>
|
||||
-->
|
||||
|
||||
</book>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -1,419 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='ref-bitbake'>
|
||||
|
||||
<title>BitBake</title>
|
||||
|
||||
<para>
|
||||
BitBake is a program written in Python that interprets the metadata used by the OpenEmbedded
|
||||
build system.
|
||||
At some point, developers wonder what actually happens when you enter:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake core-image-sato
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This chapter provides an overview of what happens behind the scenes from BitBake's perspective.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
|
||||
As such, it has no real knowledge of what the tasks being executed actually do.
|
||||
BitBake just considers a list of tasks with dependencies and handles metadata
|
||||
that consists of variables in a certain format that get passed to the tasks.
|
||||
</note>
|
||||
|
||||
<section id='ref-bitbake-parsing'>
|
||||
<title>Parsing</title>
|
||||
|
||||
<para>
|
||||
BitBake parses configuration files, classes, and <filename>.bb</filename> files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
|
||||
This file resides in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
within the <filename>meta/conf/</filename> directory.
|
||||
BitBake finds it by examining its
|
||||
<link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
|
||||
variable and looking for the <filename>meta/conf/</filename>
|
||||
directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>bitbake.conf</filename> file lists other configuration
|
||||
files to include from a <filename>conf/</filename>
|
||||
directory below the directories listed in <filename>BBPATH</filename>.
|
||||
In general, the most important configuration file from a user's perspective
|
||||
is <filename>local.conf</filename>, which contains a user's customized
|
||||
settings for the OpenEmbedded build environment.
|
||||
Other notable configuration files are the distribution
|
||||
configuration file (set by the
|
||||
<filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable)
|
||||
and the machine configuration file
|
||||
(set by the
|
||||
<filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable).
|
||||
The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment
|
||||
variables are both usually set in
|
||||
the <filename>local.conf</filename> file.
|
||||
Valid distribution
|
||||
configuration files are available in the <filename>meta/conf/distro/</filename> directory
|
||||
and valid machine configuration
|
||||
files in the <filename>meta/conf/machine/</filename> directory.
|
||||
Within the <filename>meta/conf/machine/include/</filename>
|
||||
directory are various <filename>tune-*.inc</filename> configuration files that provide common
|
||||
"tuning" settings specific to and shared between particular architectures and machines.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After the parsing of the configuration files, some standard classes are included.
|
||||
The <filename>base.bbclass</filename> file is always included.
|
||||
Other classes that are specified in the configuration using the
|
||||
<filename><link linkend='var-INHERIT'>INHERIT</link></filename>
|
||||
variable are also included.
|
||||
Class files are searched for in a <filename>classes</filename> subdirectory
|
||||
under the paths in <filename>BBPATH</filename> in the same way as
|
||||
configuration files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After classes are included, the variable
|
||||
<filename><link linkend='var-BBFILES'>BBFILES</link></filename>
|
||||
is set, usually in
|
||||
<filename>local.conf</filename>, and defines the list of places to search for
|
||||
<filename>.bb</filename> files.
|
||||
By default, the <filename>BBFILES</filename> variable specifies the
|
||||
<filename>meta/recipes-*/</filename> directory within Poky.
|
||||
Adding extra content to <filename>BBFILES</filename> is best achieved through the use of
|
||||
BitBake layers as described in the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
|
||||
Creating Layers</ulink>" section of the Yocto Project Development Manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake parses each <filename>.bb</filename> file in <filename>BBFILES</filename> and
|
||||
stores the values of various variables.
|
||||
In summary, for each <filename>.bb</filename>
|
||||
file the configuration plus the base class of variables are set, followed
|
||||
by the data in the <filename>.bb</filename> file
|
||||
itself, followed by any inherit commands that
|
||||
<filename>.bb</filename> file might contain.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Because parsing <filename>.bb</filename> files is a time
|
||||
consuming process, a cache is kept to speed up subsequent parsing.
|
||||
This cache is invalid if the timestamp of the <filename>.bb</filename>
|
||||
file itself changes, or if the timestamps of any of the include,
|
||||
configuration or class files the <filename>.bb</filename>
|
||||
file depends on changes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-providers'>
|
||||
<title>Preferences and Providers</title>
|
||||
|
||||
<para>
|
||||
Once all the <filename>.bb</filename> files have been
|
||||
parsed, BitBake starts to build the target (<filename>core-image-sato</filename>
|
||||
in the previous section's example) and looks for providers of that target.
|
||||
Once a provider is selected, BitBake resolves all the dependencies for
|
||||
the target.
|
||||
In the case of <filename>core-image-sato</filename>, it would lead to
|
||||
<filename>packagegroup-core-x11-sato</filename>,
|
||||
which in turn leads to recipes like <filename>matchbox-terminal</filename>,
|
||||
<filename>pcmanfm</filename> and <filename>gthumb</filename>.
|
||||
These recipes in turn depend on <filename>eglibc</filename> and the toolchain.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Sometimes a target might have multiple providers.
|
||||
A common example is "virtual/kernel", which is provided by each kernel package.
|
||||
Each machine often selects the best kernel provider by using a line similar to the
|
||||
following in the machine configuration file:
|
||||
</para>
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
|
||||
</literallayout>
|
||||
|
||||
<para>
|
||||
The default <filename><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></filename>
|
||||
is the provider with the same name as the target.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Understanding how providers are chosen is made complicated by the fact
|
||||
that multiple versions might exist.
|
||||
BitBake defaults to the highest version of a provider.
|
||||
Version comparisons are made using the same method as Debian.
|
||||
You can use the
|
||||
<filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
|
||||
variable to specify a particular version (usually in the distro configuration).
|
||||
You can influence the order by using the
|
||||
<filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></filename>
|
||||
variable.
|
||||
By default, files have a preference of "0".
|
||||
Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the
|
||||
package unlikely to be used unless it is explicitly referenced.
|
||||
Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the package is used.
|
||||
<filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting.
|
||||
<filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental package
|
||||
versions until they have undergone sufficient testing to be considered stable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In summary, BitBake has created a list of providers, which is prioritized, for each target.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-dependencies'>
|
||||
<title>Dependencies</title>
|
||||
|
||||
<para>
|
||||
Each target BitBake builds consists of multiple tasks such as
|
||||
<filename>fetch</filename>, <filename>unpack</filename>,
|
||||
<filename>patch</filename>, <filename>configure</filename>,
|
||||
and <filename>compile</filename>.
|
||||
For best performance on multi-core systems, BitBake considers each task as an independent
|
||||
entity with its own set of dependencies.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Dependencies are defined through several variables.
|
||||
You can find information about variables BitBake uses in the BitBake documentation,
|
||||
which is found in the <filename>bitbake/doc/manual</filename> directory within the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
At a basic level, it is sufficient to know that BitBake uses the
|
||||
<filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and
|
||||
<filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when
|
||||
calculating dependencies.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-tasklist'>
|
||||
<title>The Task List</title>
|
||||
|
||||
<para>
|
||||
Based on the generated list of providers and the dependency information,
|
||||
BitBake can now calculate exactly what tasks it needs to run and in what
|
||||
order it needs to run them.
|
||||
The build now starts with BitBake forking off threads up to the limit set in the
|
||||
<filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></filename> variable.
|
||||
BitBake continues to fork threads as long as there are tasks ready to run,
|
||||
those tasks have all their dependencies met, and the thread threshold has not been
|
||||
exceeded.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is worth noting that you can greatly speed up the build time by properly setting
|
||||
the <filename>BB_NUMBER_THREADS</filename> variable.
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
|
||||
section in the Yocto Project Quick Start for more information.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As each task completes, a timestamp is written to the directory specified by the
|
||||
<filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
|
||||
On subsequent runs, BitBake looks within the <filename>/build/tmp/stamps</filename>
|
||||
directory and does not rerun
|
||||
tasks that are already completed unless a timestamp is found to be invalid.
|
||||
Currently, invalid timestamps are only considered on a per
|
||||
<filename>.bb</filename> file basis.
|
||||
So, for example, if the configure stamp has a timestamp greater than the
|
||||
compile timestamp for a given target, then the compile task would rerun.
|
||||
Running the compile task again, however, has no effect on other providers
|
||||
that depend on that target.
|
||||
This behavior could change or become configurable in future versions of BitBake.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
Some tasks are marked as "nostamp" tasks.
|
||||
No timestamp file is created when these tasks are run.
|
||||
Consequently, "nostamp" tasks are always rerun.
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-runtask'>
|
||||
<title>Running a Task</title>
|
||||
|
||||
<para>
|
||||
Tasks can either be a shell task or a Python task.
|
||||
For shell tasks, BitBake writes a shell script to
|
||||
<filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script.
|
||||
The generated shell script contains all the exported variables, and the shell functions
|
||||
with all variables expanded.
|
||||
Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
|
||||
Looking at the expanded shell functions in the run file and the output in the log files
|
||||
is a useful debugging technique.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For Python tasks, BitBake executes the task internally and logs information to the
|
||||
controlling terminal.
|
||||
Future versions of BitBake will write the functions to files similar to the way
|
||||
shell tasks are handled.
|
||||
Logging will be handled in way similar to shell tasks as well.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once all the tasks have been completed BitBake exits.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When running a task, BitBake tightly controls the execution environment
|
||||
of the build tasks to make sure unwanted contamination from the build machine
|
||||
cannot influence the build.
|
||||
Consequently, if you do want something to get passed into the build
|
||||
task's environment, you must take a few steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Tell BitBake to load what you want from the environment
|
||||
into the data store.
|
||||
You can do so through the <filename>BB_ENV_EXTRAWHITE</filename>
|
||||
variable.
|
||||
For example, assume you want to prevent the build system from
|
||||
accessing your <filename>$HOME/.ccache</filename> directory.
|
||||
The following command tells BitBake to load
|
||||
<filename>CCACHE_DIR</filename> from the environment into the data
|
||||
store:
|
||||
<literallayout class='monospaced'>
|
||||
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Tell BitBake to export what you have loaded into the
|
||||
environment store to the task environment of every running task.
|
||||
Loading something from the environment into the data store
|
||||
(previous step) only makes it available in the datastore.
|
||||
To export it to the task environment of every running task,
|
||||
use a command similar to the following in your
|
||||
<filename>local.conf</filename> or distro configuration file:
|
||||
<literallayout class='monospaced'>
|
||||
export CCACHE_DIR
|
||||
</literallayout></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<note>
|
||||
A side effect of the previous steps is that BitBake records the variable
|
||||
as a dependency of the build process in things like the shared state
|
||||
checksums.
|
||||
If doing so results in unnecessary rebuilds of tasks, you can whitelist the
|
||||
variable so that the shared state code ignores the dependency when it creates
|
||||
checksums.
|
||||
For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
|
||||
example in the "<link linkend='checksums'>Checksums (Signatures)</link>" section.
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-commandline'>
|
||||
<title>BitBake Command Line</title>
|
||||
|
||||
<para>
|
||||
Following is the BitBake help output:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
$ bitbake --help
|
||||
Usage: bitbake [options] [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
|
||||
</screen>
|
||||
</section>
|
||||
|
||||
<section id='ref-bitbake-fetchers'>
|
||||
<title>Fetchers</title>
|
||||
|
||||
<para>
|
||||
BitBake also contains a set of "fetcher" modules that allow
|
||||
retrieval of source code from various types of sources.
|
||||
For example, BitBake can get source code from a disk with the metadata, from websites,
|
||||
from remote shell accounts or from Source Code Management (SCM) systems
|
||||
like <filename>cvs/subversion/git</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Fetchers are usually triggered by entries in
|
||||
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>.
|
||||
You can find information about the options and formats of entries for specific
|
||||
fetchers in the BitBake manual located in the
|
||||
<filename>bitbake/doc/manual</filename> directory of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One useful feature for certain Source Code Manager (SCM) fetchers is the ability to
|
||||
"auto-update" when the upstream SCM changes version.
|
||||
Since this ability requires certain functionality from the SCM, not all
|
||||
systems support it.
|
||||
Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update".
|
||||
This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
|
||||
variable.
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>" section
|
||||
in the Yocto Project Development Manual for more information.
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4 spell spelllang=en_gb
|
||||
-->
|
|
@ -1,720 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='ref-classes'>
|
||||
<title>Classes</title>
|
||||
|
||||
<para>
|
||||
Class files are used to abstract common functionality and share it amongst multiple
|
||||
<filename>.bb</filename> files.
|
||||
Any metadata usually found in a <filename>.bb</filename> file can also be placed in a class
|
||||
file.
|
||||
Class files are identified by the extension <filename>.bbclass</filename> and are usually placed
|
||||
in a <filename>classes/</filename> directory beneath the
|
||||
<filename>meta*/</filename> directory found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
|
||||
<filename>.conf</filename> files in the <filename>conf</filename> directory.
|
||||
Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
|
||||
using the same method by which <filename>.conf</filename> files are searched.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<section id='ref-classes-base'>
|
||||
<title>The base class - <filename>base.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
The base class is special in that every <filename>.bb</filename>
|
||||
file inherits it automatically.
|
||||
This class contains definitions for standard basic
|
||||
tasks such as fetching, unpacking, configuring (empty by default), compiling
|
||||
(runs any <filename>Makefile</filename> present), installing (empty by default) and packaging
|
||||
(empty by default).
|
||||
These classes are often overridden or extended by other classes
|
||||
such as <filename>autotools.bbclass</filename> or <filename>package.bbclass</filename>.
|
||||
The class also contains some commonly used functions such as <filename>oe_runmake</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-autotools'>
|
||||
<title>Autotooled Packages - <filename>autotools.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
Autotools (<filename>autoconf</filename>, <filename>automake</filename>,
|
||||
and <filename>libtool</filename>) 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 <filename>inherit autotools</filename>.
|
||||
This class can also work with software that emulates Autotools.
|
||||
For more information, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg-autotools'>Autotooled Package</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It's useful to have some idea of how the tasks defined by this class work
|
||||
and what they do behind the scenes.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename>do_configure</filename> ‐ regenerates the
|
||||
configure script (using <filename>autoreconf</filename>) and then launches it
|
||||
with a standard set of arguments used during cross-compilation.
|
||||
You can pass additional parameters to <filename>configure</filename> through the
|
||||
<filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></filename> variable.
|
||||
</para></listitem>
|
||||
<listitem><para><filename>do_compile</filename> ‐ runs <filename>make</filename> with
|
||||
arguments that specify the compiler and linker.
|
||||
You can pass additional arguments through
|
||||
the <filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></filename> variable.
|
||||
</para></listitem>
|
||||
<listitem><para><filename>do_install</filename> ‐ runs <filename>make install</filename>
|
||||
and passes a DESTDIR option, which takes its value from the standard
|
||||
<filename><link linkend='var-DESTDIR'>DESTDIR</link></filename> variable.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-update-alternatives'>
|
||||
<title>Alternatives - <filename>update-alternatives.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
Several programs can fulfill the same or similar function and be installed with the same name.
|
||||
For example, the <filename>ar</filename> command is available from the
|
||||
<filename>busybox</filename>, <filename>binutils</filename> and
|
||||
<filename>elfutils</filename> packages.
|
||||
The <filename>update-alternatives.bbclass</filename> class handles renaming the
|
||||
binaries so that multiple packages can be installed without conflicts.
|
||||
The <filename>ar</filename> 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.
|
||||
</para>
|
||||
<para>
|
||||
Four variables control this class:
|
||||
<itemizedlist>
|
||||
<listitem><para><filename>ALTERNATIVE_NAME</filename> ‐ The name of the
|
||||
binary that is replaced (<filename>ar</filename> in this example).</para></listitem>
|
||||
<listitem><para><filename>ALTERNATIVE_LINK</filename> ‐ The path to
|
||||
the resulting binary (<filename>/bin/ar</filename> in this example).</para></listitem>
|
||||
<listitem><para><filename>ALTERNATIVE_PATH</filename> ‐ The path to the
|
||||
real binary (<filename>/usr/bin/ar.binutils</filename> in this example).</para></listitem>
|
||||
<listitem><para><filename>ALTERNATIVE_PRIORITY</filename> ‐ The priority of
|
||||
the binary.
|
||||
The version with the most features should have the highest priority.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Currently, the OpenEmbedded build system supports only one binary per package.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-update-rc.d'>
|
||||
<title>Initscripts - <filename>update-rc.d.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
This class uses <filename>update-rc.d</filename> 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:
|
||||
<filename><link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link></filename>,
|
||||
<filename><link linkend='var-INITSCRIPT_NAME'>INITSCRIPT_NAME</link></filename> and
|
||||
<filename><link linkend='var-INITSCRIPT_PARAMS'>INITSCRIPT_PARAMS</link></filename>.
|
||||
See the variable links for details.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-binconfig'>
|
||||
<title>Binary config scripts - <filename>binconfig.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
Before <filename>pkg-config</filename> had become widespread, libraries shipped shell
|
||||
scripts to give information about the libraries and include paths needed
|
||||
to build software (usually named <filename>LIBNAME-config</filename>).
|
||||
This class assists any recipe using such scripts.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During staging, BitBake installs such scripts into the
|
||||
<filename>sysroots/</filename> directory.
|
||||
BitBake also changes all paths to point into the <filename>sysroots/</filename>
|
||||
directory so all builds that use the script will use the correct
|
||||
directories for the cross compiling layout.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-debian'>
|
||||
<title>Debian renaming - <filename>debian.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
This class renames packages so that they follow the Debian naming
|
||||
policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
|
||||
and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-pkgconfig'>
|
||||
<title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
<filename>pkg-config</filename> brought standardization and this class aims to make its
|
||||
integration smooth for all libraries that make use of it.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
During staging, BitBake installs <filename>pkg-config</filename> data into the
|
||||
<filename>sysroots/</filename> directory.
|
||||
By making use of sysroot functionality within <filename>pkg-config</filename>,
|
||||
this class no longer has to manipulate the files.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-src-distribute'>
|
||||
<title>Distribution of sources - <filename>src_distribute_local.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
Many software licenses require that source files be provided along with the binaries.
|
||||
To simplify this process, two classes were created:
|
||||
<filename>src_distribute.bbclass</filename> and
|
||||
<filename>src_distribute_local.bbclass</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The results of these classes are <filename>tmp/deploy/source/</filename>
|
||||
subdirs with sources sorted by
|
||||
<filename><link linkend='var-LICENSE'>LICENSE</link></filename> field.
|
||||
If recipes list few licenses (or have entries like "Bitstream Vera"),
|
||||
the source archive is placed in each license directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This class operates using three modes:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>copy:</emphasis> Copies the files to the
|
||||
distribute directory.</para></listitem>
|
||||
<listitem><para><emphasis>symlink:</emphasis> Symlinks the files to the
|
||||
distribute directory.</para></listitem>
|
||||
<listitem><para><emphasis>move+symlink:</emphasis> Moves the files into
|
||||
the distribute directory and then symlinks them back.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-perl'>
|
||||
<title>Perl modules - <filename>cpan.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
Recipes for Perl modules are simple.
|
||||
These recipes usually only need to point to the source's archive and then inherit the
|
||||
proper <filename>.bbclass</filename> file.
|
||||
Building is split into two methods depending on which method the module authors used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Modules that use old <filename>Makefile.PL</filename>-based build system require
|
||||
<filename>cpan.bbclass</filename> in their recipes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Modules that use <filename>Build.PL</filename>-based build system require
|
||||
using <filename>cpan_build.bbclass</filename> in their recipes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-distutils'>
|
||||
<title>Python extensions - <filename>distutils.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
Recipes for Python extensions are simple.
|
||||
These recipes usually only need to point to the source's archive and then inherit
|
||||
the proper <filename>.bbclass</filename> file.
|
||||
Building is split into two methods dependling on which method the module authors used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Extensions that use an Autotools-based build system require Autotools and
|
||||
<filename>distutils</filename>-based <filename>.bbclasse</filename> files in their recipes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Extensions that use <filename>distutils</filename>-based build systems require
|
||||
<filename>distutils.bbclass</filename> in their recipes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-devshell'>
|
||||
<title>Developer Shell - <filename>devshell.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
This class adds the <filename>devshell</filename> task.
|
||||
Distribution policy dictates whether to include this class.
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
|
||||
in the Yocto Project Development Manual for more information about using <filename>devshell</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-packagegroup'>
|
||||
<title>Package Groups - <filename>packagegroup.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
This class sets default values appropriate for package group recipes (such as
|
||||
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>,
|
||||
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>,
|
||||
<filename><link linkend='var-ALLOW_EMPTY'>ALLOW_EMPTY</link></filename>,
|
||||
and so forth.
|
||||
It is highly recommended that all package group recipes inherit this class.
|
||||
</para>
|
||||
<para>
|
||||
For information on how to use this class, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Tasks</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
<para>
|
||||
Previously, this class was named <filename>task.bbclass</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
||||
<section id='ref-classes-package'>
|
||||
<title>Packaging - <filename>package*.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
The packaging classes add support for generating packages from a build's
|
||||
output.
|
||||
The core generic functionality is in <filename>package.bbclass</filename>.
|
||||
The code specific to particular package types is contained in various sub-classes such as
|
||||
<filename>package_deb.bbclass</filename>, <filename>package_ipk.bbclass</filename>,
|
||||
and <filename>package_rpm.bbclass</filename>.
|
||||
Most users will want one or more of these classes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can control the list of resulting package formats by using the
|
||||
<filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename>
|
||||
variable defined in the <filename>local.conf</filename> configuration file,
|
||||
which is located in the <filename>conf</filename> folder of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 <filename>PACKAGE_CLASSES</filename>
|
||||
to "package_ipk" if you are building smaller systems.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can find additional information on the effects of the package class at these
|
||||
two Yocto Project mailing list links:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'>
|
||||
https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem>
|
||||
<listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html'>
|
||||
https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</ulink></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-kernel'>
|
||||
<title>Building kernels - <filename>kernel.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
This class handles building Linux kernels.
|
||||
The class contains code to build all kernel trees.
|
||||
All needed headers are staged into the
|
||||
<filename><link linkend='var-STAGING_KERNEL_DIR'>STAGING_KERNEL_DIR</link></filename>
|
||||
directory to allow out-of-tree module builds using <filename>module.bbclass</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This means that each built kernel module is packaged separately and inter-module
|
||||
dependencies are created by parsing the <filename>modinfo</filename> output.
|
||||
If all modules are required, then installing the <filename>kernel-modules</filename>
|
||||
package installs all packages with modules and various other kernel packages
|
||||
such as <filename>kernel-vmlinux</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Various other classes are used by the kernel and module classes internally including
|
||||
<filename>kernel-arch.bbclass</filename>, <filename>module_strip.bbclass</filename>,
|
||||
<filename>module-base.bbclass</filename>, and <filename>linux-kernel-base.bbclass</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-image'>
|
||||
<title>Creating images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
These classes add support for creating images in several formats.
|
||||
First, the root filesystem is created from packages using
|
||||
one of the <filename>rootfs_*.bbclass</filename>
|
||||
files (depending on the package format used) and then the image is created.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></filename>
|
||||
variable controls the types of images to generate.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename>
|
||||
variable controls the list of packages to install into the image.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-sanity'>
|
||||
<title>Host System sanity checks - <filename>sanity.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
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 <filename>local.conf</filename> configuration file to
|
||||
prevent common mistakes that cause build failures.
|
||||
Distribution policy usually determines whether to include this class.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-insane'>
|
||||
<title>Generated output quality assurance checks - <filename>insane.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 <filename>WARN_QA</filename> variable to specify tests for which you
|
||||
want to generate a warning message on failure.
|
||||
You use the <filename>ERROR_QA</filename> variable to specify tests for which you
|
||||
want to generate an error message on failure.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following list shows the tests you can list with the <filename>WARN_QA</filename>
|
||||
and <filename>ERROR_QA</filename> variables:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>ldflags:</filename></emphasis>
|
||||
Ensures that the binaries were linked with the
|
||||
<filename>LDFLAGS</filename> options provided by the build system.
|
||||
If this test fails, check that the <filename>LDFLAGS</filename> variable
|
||||
is being passed to the linker command.</para></listitem>
|
||||
<listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
|
||||
Checks for dynamic library load paths (rpaths) in the binaries that
|
||||
by default on a standard system are searched by the linker (e.g.
|
||||
<filename>/lib</filename> and <filename>/usr/lib</filename>).
|
||||
While these paths will not cause any breakage, they do waste space and
|
||||
are unnecessary.</para></listitem>
|
||||
<listitem><para><emphasis><filename>rpaths:</filename></emphasis>
|
||||
Checks for rpaths in the binaries that contain build system paths such
|
||||
as <filename>TMPDIR</filename>.
|
||||
If this test fails, bad <filename>-rpath</filename> options are being
|
||||
passed to the linker commands and your binaries have potential security
|
||||
issues.</para></listitem>
|
||||
<listitem><para><emphasis><filename>dev-so:</filename></emphasis>
|
||||
Checks that the <filename>.so</filename> symbolic links are in the
|
||||
<filename>-dev</filename> package and not in any of the other packages.
|
||||
In general, these symlinks are only useful for development purposes.
|
||||
Thus, the <filename>-dev</filename> 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.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>debug-files:</filename></emphasis>
|
||||
Checks for <filename>.debug</filename> directories in anything but the
|
||||
<filename>-dbg</filename> package.
|
||||
The debug files should all be in the <filename>-dbg</filename> package.
|
||||
Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
|
||||
<listitem><para><emphasis><filename>arch:</filename></emphasis>
|
||||
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.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
|
||||
Checks that <filename>-dbg</filename> packages only depend on other
|
||||
<filename>-dbg</filename> packages and not on any other types of packages,
|
||||
which would cause a packaging bug.</para></listitem>
|
||||
<listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
|
||||
Checks that <filename>-dev</filename> packages only depend on other
|
||||
<filename>-dev</filename> packages and not on any other types of packages,
|
||||
which would be a packaging bug.</para></listitem>
|
||||
<listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
|
||||
Checks <filename>.pc</filename> files for any
|
||||
<filename>TMPDIR/WORKDIR</filename> paths.
|
||||
Any <filename>.pc</filename> file containing these paths is incorrect
|
||||
since <filename>pkg-config</filename> itself adds the correct sysroot prefix
|
||||
when the files are accessed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>la:</filename></emphasis>
|
||||
Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
|
||||
paths.
|
||||
Any <filename>.la</filename> file continaing these paths is incorrect since
|
||||
<filename>libtool</filename> adds the correct sysroot prefix when using the
|
||||
files automatically itself.</para></listitem>
|
||||
<listitem><para><emphasis><filename>desktop:</filename></emphasis>
|
||||
Runs the <filename>desktop-file-validate</filename> program against any
|
||||
<filename>.desktop</filename> files to validate their contents against
|
||||
the specification for <filename>.desktop</filename> files.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-siteinfo'>
|
||||
<title>Autotools configuration data cache - <filename>siteinfo.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
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 <filename><link linkend='structure-meta-site'>meta/site directory</link></filename>
|
||||
contains test results sorted into different categories such as architecture, endianness, and
|
||||
the <filename>libc</filename> used.
|
||||
Site information provides a list of files containing data relevant to
|
||||
the current build in the
|
||||
<filename><link linkend='var-CONFIG_SITE'>CONFIG_SITE</link></filename> variable
|
||||
that Autotools automatically picks up.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The class also provides variables like
|
||||
<filename><link linkend='var-SITEINFO_ENDIANNESS'>SITEINFO_ENDIANNESS</link></filename>
|
||||
and <filename><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link></filename>
|
||||
that can be used elsewhere in the metadata.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Because this class is included from <filename>base.bbclass</filename>, it is always active.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-useradd'>
|
||||
<title>Adding Users - <filename>useradd.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
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 <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
|
||||
recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
provides a simple exmample that shows how to add three
|
||||
users and groups to two packages.
|
||||
See the <filename>useradd-example.bb</filename> for more information on how to
|
||||
use this class.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-externalsrc'>
|
||||
<title>Using External Source - <filename>externalsrc.bbclass</filename></title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To use the class, you need to define the
|
||||
<link linkend='var-S'><filename>S</filename></link> variable to point to the directory that contains the source files.
|
||||
You also need to have your recipe inherit the <filename>externalsrc.bbclass</filename> class.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This class expects the source code to support recipe builds that use the
|
||||
<link linkend='var-B'><filename>B</filename></link> variable to point to the directory in
|
||||
which the OpenEmbedded build system places the generated objects built from the recipes.
|
||||
By default, the <filename>B</filename> directory is set to the following, which is separate from the
|
||||
Source Directory (<filename>S</filename>):
|
||||
<literallayout class='monospaced'>
|
||||
${WORKDIR}/${BPN}/{PV}/
|
||||
</literallayout>
|
||||
See the glossary entries for the
|
||||
<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
|
||||
<link linkend='var-BPN'><filename>BPN</filename></link>,
|
||||
<link linkend='var-PV'><filename>PV</filename></link>,
|
||||
<link linkend='var-S'><filename>S</filename></link>, and
|
||||
<link linkend='var-B'><filename>B</filename></link> for more information.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can build object files in the external tree by setting the
|
||||
<filename>B</filename> variable equal to <filename>"${S}"</filename>.
|
||||
However, this practice does not work well if you use the source for more than one variant
|
||||
(i.e., "natives" such as <filename>quilt-native</filename>,
|
||||
or "crosses" such as <filename>gcc-cross</filename>).
|
||||
So, be sure there are no "native", "cross", or "multilib" variants of the recipe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you do want to build different variants of a recipe, you can use the
|
||||
<link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> variable.
|
||||
When you do, the <link linkend='var-B'><filename>B</filename></link> 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 <filename>gcc</filename>
|
||||
and some kernel recipes.
|
||||
Alternatively, you can make sure that separate recipes exist that each
|
||||
use the <filename>BBCLASSEXTEND</filename> variable to build each variant.
|
||||
The separate recipes can inherit a single target recipe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information on how to use this class, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building
|
||||
Software from an External Source</ulink>" section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-others'>
|
||||
<title>Other Classes</title>
|
||||
|
||||
<para>
|
||||
Thus far, this chapter has discussed only the most useful and important
|
||||
classes.
|
||||
However, other classes exist within the <filename>meta/classes</filename> directory
|
||||
in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
You can examine the <filename>.bbclass</filename> files directly for more
|
||||
information.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<!-- Undocumented classes are:
|
||||
allarch.bbclass
|
||||
archive*.bbclass
|
||||
binconfig.bbclass
|
||||
blacklist.bbclass
|
||||
bootimg.bbclass
|
||||
boot-directdisk.bbclass
|
||||
bugzilla.bbclass
|
||||
buildhistory.bbclass
|
||||
buildstats.bbclass
|
||||
ccache.bbclass
|
||||
chrpath.bbclass
|
||||
cmake.bbclass
|
||||
cml1.bbclass
|
||||
copyleft_compliance.bbclass
|
||||
core-image.bbclass
|
||||
cross.bbclass
|
||||
cross-canadian.bbclass
|
||||
crosssdk.bbclass
|
||||
deploy.bbclass
|
||||
distrodata.bbclass
|
||||
dummy.bbclass
|
||||
gconf.bbclass
|
||||
gettext.bbclass
|
||||
gnomebase.bbclass
|
||||
gnome.bbclass
|
||||
gtk-doc.bbclass
|
||||
gtk-icon-cache.bbclass
|
||||
gzipnative.bbclass
|
||||
icecc.bbclass
|
||||
image-empty.bbclass
|
||||
image-live.bbclass
|
||||
image-vmdk.bbclass
|
||||
image-mklibs.bbclass
|
||||
image-prelink.bbclass
|
||||
image-swab.bbclass
|
||||
imagetest-dummy.bbclass
|
||||
imagetest-qemu.bbclass
|
||||
image_types.bbclass
|
||||
image_types_uboot.bbclass
|
||||
insserv.bbclass
|
||||
kernel-arch.bbclass
|
||||
kernel-yocto.bbclass
|
||||
lib_package.bbclass
|
||||
linux-kernel-base.bbclass
|
||||
license.bbclass
|
||||
logging.bbclass
|
||||
meta.bbclass
|
||||
metadata_scm.bbclass
|
||||
mime.bbclass
|
||||
mirrors.bbclass
|
||||
multilib*.bbclass
|
||||
native.bbclass
|
||||
nativesdk.bbclass
|
||||
oelint.bbclass
|
||||
own-mirrors.bbclass
|
||||
packagedata.bbclass
|
||||
packageinfo.bbclass
|
||||
patch.bbclass
|
||||
perlnative.bbclass
|
||||
pkg_distribute.bbclass
|
||||
pkg_metainfo.bbclass
|
||||
populate_sdk*.bbclass
|
||||
prexport.bbclass
|
||||
primport.bbclass
|
||||
prserv.bbclass
|
||||
python-dir.bbclass
|
||||
pythonnative.bbclass
|
||||
qemu.bbclass
|
||||
qmake*.bbclass
|
||||
qt4*.bbclass
|
||||
recipe_sanity.bbclass
|
||||
relocatable.bbclass
|
||||
rm_work.bbclass
|
||||
scons.bbclass
|
||||
sdl.bbclass
|
||||
setuptools.bbclass
|
||||
sip.bbclass
|
||||
siteconfig.bbclass
|
||||
sourcepkg.bbclass
|
||||
sstate.bbclass
|
||||
staging.bbclass
|
||||
syslinux.bbclass
|
||||
terminal.bbclass
|
||||
tinderclient.bbclass
|
||||
toolchain-scripts.bbclass
|
||||
typecheck.bbclass
|
||||
utility-tasks.bbclass
|
||||
utils.bbclass
|
||||
-->
|
||||
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -1,294 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='ref-features'>
|
||||
<title>Reference: Features</title>
|
||||
|
||||
<para>
|
||||
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
|
||||
<filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>
|
||||
variable, which is set in the <filename>poky.conf</filename> distribution configuration file.
|
||||
Machine features are set in the
|
||||
<filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>
|
||||
variable, which is set in the machine configuration file and
|
||||
specifies the hardware features for a given machine.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One method you can use to determine which recipes are checking to see if a
|
||||
particular feature is contained or not is to <filename>grep</filename> through
|
||||
the metadata for the feature.
|
||||
Here is an example that discovers the recipes whose build is potentially
|
||||
changed based on a given feature:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd $HOME/poky
|
||||
$ git grep 'contains.*MACHINE_FEATURES.*<feature>'
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
|
||||
<section id='ref-features-distro'>
|
||||
<title>Distro</title>
|
||||
|
||||
<para>
|
||||
The items below are features you can use with
|
||||
<link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
|
||||
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 <filename>do_configure</filename> for a particular
|
||||
recipe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This list only represents features as shipped with the Yocto Project metadata:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>alsa:</emphasis> ALSA support will be included (OSS compatibility
|
||||
kernel modules will be installed if available).</para></listitem>
|
||||
<listitem><para><emphasis>bluetooth:</emphasis> Include bluetooth support (integrated BT only)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>ext2:</emphasis> Include tools for supporting for devices with internal
|
||||
HDD/Microdrive for storing files (instead of Flash only devices)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>irda:</emphasis> Include Irda support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>keyboard:</emphasis> Include keyboard support (e.g. keymaps will be
|
||||
loaded during boot).
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>pci:</emphasis> Include PCI bus support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>pcmcia:</emphasis> Include PCMCIA/CompactFlash support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>usbgadget:</emphasis> USB Gadget Device support (for USB
|
||||
networking/serial/storage)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>usbhost:</emphasis> USB Host support (allows to connect external
|
||||
keyboard, mouse, storage, network etc)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>wifi:</emphasis> WiFi support (integrated only)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>cramfs:</emphasis> CramFS support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>ipsec:</emphasis> IPSec support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>ipv6:</emphasis> IPv6 support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>nfs:</emphasis> NFS client support (for mounting NFS exports on
|
||||
device)</para></listitem>
|
||||
<listitem><para><emphasis>ppp:</emphasis> PPP dialup support</para></listitem>
|
||||
<listitem><para><emphasis>smbfs:</emphasis> SMB networks client support (for mounting
|
||||
Samba/Microsoft Windows shares on device)</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-features-machine'>
|
||||
<title>Machine</title>
|
||||
|
||||
<para>
|
||||
The items below are features you can use with
|
||||
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
|
||||
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 <filename>do_configure</filename> for a particular
|
||||
recipe.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This feature list only represents features as shipped with the Yocto Project metadata:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>acpi:</emphasis> Hardware has ACPI (x86/x86_64 only)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>alsa:</emphasis> Hardware has ALSA audio drivers
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>apm:</emphasis> Hardware uses APM (or APM emulation)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>bluetooth:</emphasis> Hardware has integrated BT
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>irda:</emphasis> Hardware has Irda support
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>pci:</emphasis> Hardware has a PCI bus
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>pcmcia:</emphasis> Hardware has PCMCIA or CompactFlash sockets
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>screen:</emphasis> Hardware has a screen
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>serial:</emphasis> Hardware has serial support (usually RS232)
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>touchscreen:</emphasis> Hardware has a touchscreen
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>usbgadget:</emphasis> Hardware is USB gadget device capable
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>usbhost:</emphasis> Hardware is USB Host capable
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>wifi:</emphasis> Hardware has integrated WiFi
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-features-image'>
|
||||
<title>Images</title>
|
||||
|
||||
<para>
|
||||
The contents of images generated by the OpenEmbedded build system can be controlled by the
|
||||
<filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
|
||||
and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Current list of
|
||||
<filename>IMAGE_FEATURES</filename> contains the following:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>splash:</emphasis> Enables showing a splash screen during boot.
|
||||
By default, this screen is provided by <filename>psplash</filename>, which does
|
||||
allow customization.
|
||||
If you prefer to use an alternative splash screen package, you can do so by
|
||||
setting the <filename>SPLASH</filename> variable
|
||||
to a different package name (or names) within the image recipe or at the distro
|
||||
configuration level.</para></listitem>
|
||||
<listitem><para><emphasis>ssh-server-dropbear:</emphasis> Installs the Dropbear minimal
|
||||
SSH server.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>ssh-server-openssh:</emphasis> 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 <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
|
||||
precedence and Dropbear will not be installed.</para></listitem>
|
||||
<listitem><para><emphasis>x11:</emphasis> Installs the X server</para></listitem>
|
||||
<listitem><para><emphasis>x11-base:</emphasis> Installs the X server with a
|
||||
minimal environment.</para></listitem>
|
||||
<listitem><para><emphasis>x11-sato:</emphasis> Installs the OpenedHand Sato environment.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>tools-sdk:</emphasis> Installs a full SDK that runs on the device.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>tools-debug:</emphasis> Installs debugging tools such as
|
||||
<filename>strace</filename> and <filename>gdb</filename>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>tools-profile:</emphasis> Installs profiling tools such as
|
||||
<filename>oprofile</filename>, <filename>exmap</filename>, and
|
||||
<filename>LTTng</filename>.</para></listitem>
|
||||
<listitem><para><emphasis>tools-testapps:</emphasis> Installs device testing tools (e.g.
|
||||
touchscreen debugging).</para></listitem>
|
||||
<listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
|
||||
<listitem><para><emphasis>dev-pkgs:</emphasis> Installs development packages (headers and
|
||||
extra library links) for all packages installed in a given image.</para></listitem>
|
||||
<listitem><para><emphasis>staticdev-pkgs:</emphasis> Installs static development
|
||||
packages (i.e. static libraries containing <filename>*.a</filename> files) for all
|
||||
packages installed in a given image.</para></listitem>
|
||||
<listitem><para><emphasis>dbg-pkgs:</emphasis> Installs debug symbol packages for all packages
|
||||
installed in a given image.</para></listitem>
|
||||
<listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages
|
||||
installed in a given image.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-features-backfill'>
|
||||
<title>Feature Backfilling</title>
|
||||
|
||||
<para>
|
||||
Sometimes it is necessary in the OpenEmbedded build system to extend
|
||||
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
|
||||
or <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
|
||||
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
|
||||
<link linkend='var-DISTRO_FEATURES_BACKFILL'><filename>DISTRO_FEATURES_BACKFILL</filename></link>
|
||||
and <link linkend='var-MACHINE_FEATURES_BACKFILL'><filename>MACHINE_FEATURES_BACKFILL</filename></link>
|
||||
variables in the <filename>meta/conf/bitbake.conf</filename> file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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
|
||||
<link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
|
||||
or <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>
|
||||
variables for distro features and machine features respectively.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here are two examples to help illustrate feature backfilling:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>The "pulseaudio" distro feature option</emphasis>:
|
||||
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
|
||||
<filename>DISTRO_FEATURES_BACKFILL</filename>
|
||||
variable in the <filename>meta/conf/bitbake.conf</filename> 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
|
||||
<filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename>
|
||||
in your distro's <filename>.conf</filename> file.
|
||||
Adding the feature to this variable when it also
|
||||
exists in the <filename>DISTRO_FEATURES_BACKFILL</filename>
|
||||
variable prevents the build system from adding the feature to
|
||||
your configuration's <filename>DISTRO_FEATURES</filename>, effectively disabling
|
||||
the feature for that particular distro.</para></listitem>
|
||||
<listitem><para><emphasis>The "rtc" machine feature option</emphasis>:
|
||||
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 <filename>MACHINE_FEATURES_BACKFILL</filename>
|
||||
variable in the <filename>meta/conf/bitbake.conf</filename> 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
|
||||
<filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename>
|
||||
list in the machine's <filename>.conf</filename> file.
|
||||
Adding the feature to this variable when it also
|
||||
exists in the <filename>MACHINE_FEATURES_BACKFILL</filename>
|
||||
variable prevents the build system from adding the feature to
|
||||
your configuration's <filename>MACHINE_FEATURES</filename>, effectively
|
||||
disabling RTC support for that particular machine.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4 spell spelllang=en_gb
|
||||
-->
|
|
@ -1,132 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='ref-images'>
|
||||
<title>Images</title>
|
||||
|
||||
<para>
|
||||
The OpenEmbedded build process supports several types of images to satisfy different needs.
|
||||
When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe
|
||||
that essentially begins the build for the type of image you want.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
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 <filename>local.conf</filename> file
|
||||
before using the BitBake command to build the minimal or base image:
|
||||
<literallayout class='monospaced'>
|
||||
1. Comment out the EXTRA_IMAGE_FEATURES line
|
||||
2. Set INCOMPATIBLE_LICENSE = "GPLv3"
|
||||
</literallayout>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
From within the <filename>poky</filename> Git repository, use the following command to list
|
||||
the supported images:
|
||||
<literallayout class='monospaced'>
|
||||
$ ls meta*/recipes*/images/*.bb
|
||||
</literallayout>
|
||||
These recipes reside in the <filename>meta/recipes-core/images</filename>,
|
||||
<filename>meta/recipes-extended/images</filename>,
|
||||
<filename>meta/recipes-graphics/images</filename>, and
|
||||
<filename>meta/recipes-sato/images</filename> directories
|
||||
within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
Although the recipe names are somewhat explanatory, here is a list that describes them:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>core-image-base</filename>:</emphasis>
|
||||
A console-only image that fully supports the target device hardware.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
|
||||
A small image just capable of allowing a device to boot.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
|
||||
A <filename>core-image-minimal</filename> image suitable for development work
|
||||
using the host.
|
||||
The image includes headers and libraries you can use in a host development
|
||||
environment.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
|
||||
A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
|
||||
Initial Root Filesystem (<filename>initramfs</filename>) as part of the kernel,
|
||||
which allows the system to find the first “init” program more efficiently.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-minimal-mtdutils</filename>:</emphasis>
|
||||
A <filename>core-image-minimal</filename> 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.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
|
||||
A very basic X11 image with a terminal.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-basic</filename>:</emphasis>
|
||||
A console-only image with more full-featured Linux system
|
||||
functionality installed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-lsb</filename>:</emphasis>
|
||||
An image that conforms to the Linux Standard Base (LSB) specification.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
|
||||
A <filename>core-image-lsb</filename> image that is suitable for development work
|
||||
using the host.
|
||||
The image includes headers and libraries you can use in a host development
|
||||
environment.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
|
||||
A <filename>core-image-lsb</filename> 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.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
|
||||
An image with support for the Open GL-based toolkit Clutter, which enables development of
|
||||
rich and animated graphical user interfaces.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
|
||||
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.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
|
||||
A <filename>core-image-sato</filename> 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 <filename>core-image-sdk</filename>.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
|
||||
A <filename>core-image-sato</filename> 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.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-rt</filename>:</emphasis>
|
||||
A <filename>core-image-minimal</filename> image plus a real-time test suite and
|
||||
tools appropriate for real-time use.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-rt-sdk</filename>:</emphasis>
|
||||
A <filename>core-image-rt</filename> image that includes everything in
|
||||
<filename>meta-toolchain</filename>.
|
||||
The image also includes development headers and libraries to form a complete
|
||||
stand-alone SDK and is suitable for development using the target.</para></listitem>
|
||||
<listitem><para><emphasis><filename>core-image-gtk-directfb</filename>:</emphasis>
|
||||
An image that uses <filename>gtk+</filename> over <filename>directfb</filename>
|
||||
instead of X11.
|
||||
In order to build, this image requires specific distro configuration that enables
|
||||
<filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
|
||||
<listitem><para><emphasis><filename>build-appliance-image</filename>:</emphasis>
|
||||
An image you can boot and run using either the
|
||||
<ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
|
||||
or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
|
||||
For more information on this image, see the
|
||||
<ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
|
||||
the Yocto Project website.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<tip>
|
||||
From the Yocto Project release 1.1 onwards, <filename>-live</filename> and
|
||||
<filename>-directdisk</filename> images have been replaced by a "live"
|
||||
option in <filename>IMAGE_FSTYPES</filename> 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 <filename>IMAGE_FSTYPES</filename> within the <filename>local.conf</filename>
|
||||
file or wherever appropriate and then build the desired image as normal.
|
||||
</tip>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -1,709 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='ref-structure'>
|
||||
|
||||
<title>Source Directory Structure</title>
|
||||
|
||||
<para>
|
||||
The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> 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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information on how to establish a local Source Directory on your development system, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
The OpenEmbedded build system does not support file or directory names that
|
||||
contain spaces.
|
||||
Be sure that the Source Directory you use does not contain these types
|
||||
of names.
|
||||
</note>
|
||||
|
||||
<section id='structure-core'>
|
||||
<title>Top level core components</title>
|
||||
|
||||
<section id='structure-core-bitbake'>
|
||||
<title><filename>bitbake/</filename></title>
|
||||
|
||||
<para>
|
||||
The <ulink url='source-directory'>Source Directory</ulink>
|
||||
includes a copy of BitBake for ease of use.
|
||||
The copy usually matches the current stable BitBake release from the BitBake project.
|
||||
BitBake, a metadata interpreter, reads the Yocto Project metadata and runs the tasks
|
||||
defined by that data.
|
||||
Failures are usually from the metadata and not from BitBake itself.
|
||||
Consequently, most users do not need to worry about BitBake.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When you run the <filename>bitbake</filename> command, the wrapper script in
|
||||
<filename>scripts/</filename> is executed to run the main BitBake executable,
|
||||
which resides in the <filename>bitbake/bin/</filename> directory.
|
||||
Sourcing the <link linkend="structure-core-script">&OE_INIT_FILE;</link>
|
||||
script places the <filename>scripts</filename> and <filename>bitbake/bin</filename>
|
||||
directories (in that order) into the shell's <filename>PATH</filename> environment
|
||||
variable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more information on BitBake, see the BitBake documentation
|
||||
inculded in the <filename>bitbake/doc/manual</filename> directory of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-core-build'>
|
||||
<title><filename>build/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains user configuration files and the output
|
||||
generated by the OpenEmbedded build system in its standard configuration where
|
||||
the source tree is combined with the output.
|
||||
The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
||||
is created initially when you <filename>source</filename>
|
||||
the OpenEmbedded build environment setup script <filename>&OE_INIT_FILE;</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is also possible to place output and configuration
|
||||
files in a directory separate from the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
by providing a directory name when you <filename>source</filename>
|
||||
the setup script.
|
||||
For information on separating output from your local Source Directory files, see <link
|
||||
linkend='structure-core-script'>&OE_INIT_FILE;</link>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='handbook'>
|
||||
<title><filename>documentation</filename></title>
|
||||
|
||||
<para>
|
||||
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
|
||||
<filename>poky-ref-manual</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-core-meta'>
|
||||
<title><filename>meta/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the OpenEmbedded Core metadata.
|
||||
The directory holds recipes, common classes, and machine
|
||||
configuration for emulated targets (qemux86, qemuarm,
|
||||
and so on.)
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-core-meta-yocto'>
|
||||
<title><filename>meta-yocto/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the configuration for the Poky
|
||||
reference distribution.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-core-meta-yocto-bsp'>
|
||||
<title><filename>meta-yocto-bsp/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the Yocto Project reference
|
||||
hardware BSPs.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-hob'>
|
||||
<title><filename>meta-hob/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains template recipes used by the
|
||||
<ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink>
|
||||
build UI.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-skeleton'>
|
||||
<title><filename>meta-skeleton/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains template recipes for BSP and kernel development.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-core-scripts'>
|
||||
<title><filename>scripts/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains various integration scripts that implement
|
||||
extra functionality in the Yocto Project environment (e.g. QEMU scripts).
|
||||
The <link linkend="structure-core-script">&OE_INIT_FILE;</link> script appends this
|
||||
directory to the shell's <filename>PATH</filename> environment variable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>scripts</filename> directory has useful scripts that assist contributing
|
||||
back to the Yocto Project, such as <filename>create_pull_request</filename> and
|
||||
<filename>send_pull_request</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-core-script'>
|
||||
<title><filename>&OE_INIT_FILE;</filename></title>
|
||||
|
||||
<para>
|
||||
This script sets up the OpenEmbedded build environment.
|
||||
Running this script with the <filename>source</filename> command in
|
||||
a shell makes changes to <filename>PATH</filename> and sets other core BitBake variables based on the
|
||||
current working directory.
|
||||
You need to run this script before running BitBake commands.
|
||||
The script uses other scripts within the <filename>scripts</filename> directory to do
|
||||
the bulk of the work.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
By default, running this script without a Build Directory argument creates the
|
||||
<filename>build</filename> directory.
|
||||
If you provide a Build Directory argument when you <filename>source</filename>
|
||||
the script, you direct OpenEmbedded build system to create a
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> of your choice.
|
||||
For example, the following command creates a Build Directory named
|
||||
<filename>mybuilds</filename> that is outside of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
$ source &OE_INIT_FILE; ~/mybuilds
|
||||
</literallayout>
|
||||
<note>
|
||||
The OpenEmbedded build system does not support file or directory names that
|
||||
contain spaces.
|
||||
If you attempt to run the <filename>&OE_INIT_FILE;</filename> script
|
||||
from a Source Directory that contains spaces in either the filenames
|
||||
or directory names, the script returns an error indicating no such
|
||||
file or directory.
|
||||
Be sure to use a Source Directory free of names containing spaces.
|
||||
</note>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-basic-top-level'>
|
||||
<title><filename>LICENSE, README, and README.hardware</filename></title>
|
||||
|
||||
<para>
|
||||
These files are standard top-level files.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='structure-build'>
|
||||
<title>The Build Directory - <filename>build/</filename></title>
|
||||
|
||||
<section id='structure-build-pseudodone'>
|
||||
<title><filename>build/pseudodone</filename></title>
|
||||
|
||||
<para>
|
||||
This tag file indicates that the initial pseudo binary was created.
|
||||
The file is built the first time BitBake is invoked.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-conf-local.conf'>
|
||||
<title><filename>build/conf/local.conf</filename></title>
|
||||
|
||||
<para>
|
||||
This file contains all the local user configuration for your build environment.
|
||||
If there is no <filename>local.conf</filename> present, it is created from
|
||||
<filename>local.conf.sample</filename>.
|
||||
The <filename>local.conf</filename> file contains documentation on the various configuration options.
|
||||
Any variable set here overrides any variable set elsewhere within the environment unless
|
||||
that variable is hard-coded within a file (e.g. by using '=' instead of '?=').
|
||||
Some variables are hard-coded for various reasons but these variables are
|
||||
relatively rare.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Edit this file to set the <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
|
||||
for which you want to build, which package types you wish to use
|
||||
(<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
|
||||
where you want to downloaded files
|
||||
(<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
|
||||
and how you want your host machine to use resources
|
||||
(<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> and
|
||||
<link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-conf-bblayers.conf'>
|
||||
<title><filename>build/conf/bblayers.conf</filename></title>
|
||||
|
||||
<para>
|
||||
This file defines layers, which are directory trees, traversed (or walked) by BitBake.
|
||||
If <filename>bblayers.conf</filename>
|
||||
is not present, it is created from <filename>bblayers.conf.sample</filename> when
|
||||
you <filename>source</filename> the environment setup script.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>bblayers.conf</filename> file uses the
|
||||
<link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link> variable to
|
||||
list the layers BitBake tries to find.
|
||||
The file uses the
|
||||
<link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
|
||||
variable to list layers that must not be removed.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-conf-sanity_info'>
|
||||
<title><filename>build/conf/sanity_info</filename></title>
|
||||
|
||||
<para>
|
||||
This file is created during the build to indicate the state of the sanity checks.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-downloads'>
|
||||
<title><filename>build/downloads/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory is used for the upstream source tarballs.
|
||||
The directory can be reused by multiple builds or moved to another location.
|
||||
You can control the location of this directory through the
|
||||
<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename> variable.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-sstate-cache'>
|
||||
<title><filename>build/sstate-cache/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory is used for the shared state cache.
|
||||
The directory can be reused by multiple builds or moved to another location.
|
||||
You can control the location of this directory through the
|
||||
<filename><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></filename> variable.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp'>
|
||||
<title><filename>build/tmp/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives all the OpenEmbedded build system's output.
|
||||
BitBake creates this directory if it does not exist.
|
||||
As a last resort, to clean up a build and start it from scratch (other than the downloads),
|
||||
you can remove everything in the <filename>tmp</filename> directory or get rid of the
|
||||
directory completely.
|
||||
If you do, you should also completely remove the <filename>build/sstate-cache</filename>
|
||||
directory as well.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-buildstats'>
|
||||
<title><filename>build/tmp/buildstats/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory stores the build statistics.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-cache'>
|
||||
<title><filename>build/tmp/cache/</filename></title>
|
||||
|
||||
<para>
|
||||
When BitBake parses the metadata, it creates a cache file of the result that can
|
||||
be used when subsequently running commands.
|
||||
These results are stored here on a per-machine basis.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-deploy'>
|
||||
<title><filename>build/tmp/deploy/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains any 'end result' output from the OpenEmbedded build process.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-deploy-deb'>
|
||||
<title><filename>build/tmp/deploy/deb/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives any <filename>.deb</filename> packages produced by
|
||||
the build process.
|
||||
The packages are sorted into feeds for different architecture types.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-deploy-rpm'>
|
||||
<title><filename>build/tmp/deploy/rpm/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives any <filename>.rpm</filename> packages produced by
|
||||
the build process.
|
||||
The packages are sorted into feeds for different architecture types.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-deploy-licenses'>
|
||||
<title><filename>build/tmp/deploy/licenses/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives package licensing information.
|
||||
For example, the directory contains sub-directories for <filename>bash</filename>,
|
||||
<filename>busybox</filename>, and <filename>eglibc</filename> (among others) that in turn
|
||||
contain appropriate <filename>COPYING</filename> license files with other licensing information.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-deploy-images'>
|
||||
<title><filename>build/tmp/deploy/images/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives complete filesystem images.
|
||||
If you want to flash the resulting image from a build onto a device, look here for the image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Be careful when deleting files in this directory.
|
||||
You can safely delete old images from this directory (e.g.
|
||||
<filename>core-image-*</filename>, <filename>hob-image-*</filename>,
|
||||
etc.).
|
||||
However, the kernel (<filename>*zImage*</filename>, <filename>*uImage*</filename>, etc.),
|
||||
bootloader and other supplementary files might be deployed here prior to building an
|
||||
image.
|
||||
Because these files, however, are not directly produced from the image, if you
|
||||
delete them they will not be automatically re-created when you build the image again.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you do accidentally delete files here, you will need to force them to be
|
||||
re-created.
|
||||
In order to do that, you will need to know the target that produced them.
|
||||
For example, these commands rebuild and re-create the kernel files:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -c clean virtual/kernel
|
||||
$ bitbake virtual/kernel
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-deploy-ipk'>
|
||||
<title><filename>build/tmp/deploy/ipk/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives <filename>.ipk</filename> packages produced by
|
||||
the build process.</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-sysroots'>
|
||||
<title><filename>build/tmp/sysroots/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains shared header files and libraries as well as other shared
|
||||
data.
|
||||
Packages that need to share output with other packages do so within this directory.
|
||||
The directory is subdivided by architecture so multiple builds can run within
|
||||
the one Build Directory.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-stamps'>
|
||||
<title><filename>build/tmp/stamps/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory holds information that BitBake uses for accounting purposes
|
||||
to track what tasks have run and when they have run.
|
||||
The directory is sub-divided by architecture, package name, and
|
||||
version.
|
||||
Following is an example:
|
||||
<literallayout class='monospaced'>
|
||||
stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
|
||||
</literallayout>
|
||||
Although the files in the directory are empty of data,
|
||||
BitBake uses the filenames and timestamps for tracking purposes.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-log'>
|
||||
<title><filename>build/tmp/log/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains general logs that are not otherwise placed using the
|
||||
package's <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
|
||||
Examples of logs are the output from the <filename>check_pkg</filename> or
|
||||
<filename>distro_check</filename> tasks.
|
||||
Running a build does not necessarily mean this directory is created.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-pkgdata'>
|
||||
<title><filename>build/tmp/pkgdata/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains intermediate packaging data that is used later in the packaging process.
|
||||
For more information, see the "<link linkend='ref-classes-package'>Packaging - package*.bbclass</link>" section.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-work'>
|
||||
<title><filename>build/tmp/work/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains architecture-specific work sub-directories
|
||||
for packages built by BitBake.
|
||||
All tasks execute from the appropriate work directory.
|
||||
For example, the source for a particular package is unpacked,
|
||||
patched, configured and compiled all within its own work directory.
|
||||
Within the work directory, organization is based on the package group
|
||||
and version for which the source is being compiled
|
||||
as defined by the
|
||||
<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is worth considering the structure of a typical work directory.
|
||||
As an example, consider the <filename>linux-yocto-kernel-3.0</filename>
|
||||
on the machine <filename>qemux86</filename>
|
||||
built within the Yocto Project.
|
||||
For this package, a work directory of
|
||||
<filename>tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....></filename>,
|
||||
referred to as the
|
||||
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.
|
||||
Within this directory, the source is unpacked to
|
||||
<filename>linux-qemux86-standard-build</filename> and then patched by Quilt
|
||||
(see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Modifying Package
|
||||
Source Code with Quilt</ulink>" section in the Yocto Project Development Manual.
|
||||
Within the <filename>linux-qemux86-standard-build</filename> directory,
|
||||
standard Quilt directories <filename>linux-3.0/patches</filename>
|
||||
and <filename>linux-3.0/.pc</filename> are created,
|
||||
and standard Quilt commands can be used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are other directories generated within <filename>WORKDIR</filename>.
|
||||
The most important directory is <filename>WORKDIR/temp/</filename>,
|
||||
which has log files for each task (<filename>log.do_*.pid</filename>)
|
||||
and contains the scripts BitBake runs for each task
|
||||
(<filename>run.do_*.pid</filename>).
|
||||
The <filename>WORKDIR/image/</filename> directory is where "make
|
||||
install" places its output that is then split into sub-packages
|
||||
within <filename>WORKDIR/packages-split/</filename>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta'>
|
||||
<title>The Metadata - <filename>meta/</filename></title>
|
||||
|
||||
<para>
|
||||
As mentioned previously, metadata is the core of the Yocto Project.
|
||||
Metadata has several important subdivisions:
|
||||
</para>
|
||||
|
||||
<section id='structure-meta-classes'>
|
||||
<title><filename>meta/classes/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the <filename>*.bbclass</filename> files.
|
||||
Class files are used to abstract common code so it can be reused by multiple
|
||||
packages.
|
||||
Every package inherits the <filename>base.bbclass</filename> file.
|
||||
Examples of other important classes are <filename>autotools.bbclass</filename>, which
|
||||
in theory allows any Autotool-enabled package to work with the Yocto Project with minimal effort.
|
||||
Another example is <filename>kernel.bbclass</filename> that contains common code and functions
|
||||
for working with the Linux kernel.
|
||||
Functions like image generation or packaging also have their specific class files
|
||||
such as <filename>image.bbclass</filename>, <filename>rootfs_*.bbclass</filename> and
|
||||
<filename>package*.bbclass</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-conf'>
|
||||
<title><filename>meta/conf/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the core set of configuration files that start from
|
||||
<filename>bitbake.conf</filename> and from which all other configuration
|
||||
files are included.
|
||||
See the include statements at the end of the file and you will note that even
|
||||
<filename>local.conf</filename> is loaded from there.
|
||||
While <filename>bitbake.conf</filename> sets up the defaults, you can often override
|
||||
these by using the (<filename>local.conf</filename>) file, machine file or
|
||||
the distribution configuration file.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-conf-machine'>
|
||||
<title><filename>meta/conf/machine/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains all the machine configuration files.
|
||||
If you set <filename>MACHINE="qemux86"</filename>,
|
||||
the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this
|
||||
directory.
|
||||
The <filename>include</filename> directory contains various data common to multiple machines.
|
||||
If you want to add support for a new machine to the Yocto Project, look in this directory.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-conf-distro'>
|
||||
<title><filename>meta/conf/distro/</filename></title>
|
||||
|
||||
<para>
|
||||
Any distribution-specific configuration is controlled from this directory.
|
||||
For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here.
|
||||
This directory includes the versions and the
|
||||
<filename>SRCDATE</filename> definitions for applications that are configured here.
|
||||
An example of an alternative configuration might be <filename>poky-bleeding.conf</filename>.
|
||||
Although this file mainly inherits its configuration from Poky.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-bsp'>
|
||||
<title><filename>meta/recipes-bsp/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains anything linking to specific hardware or hardware
|
||||
configuration information such as "u-boot" and "grub".
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-connectivity'>
|
||||
<title><filename>meta/recipes-connectivity/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains libraries and applications related to communication with other devices.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-core'>
|
||||
<title><filename>meta/recipes-core/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains what is needed to build a basic working Linux image
|
||||
including commonly used dependencies.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-devtools'>
|
||||
<title><filename>meta/recipes-devtools/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains tools that are primarily used by the build system.
|
||||
The tools, however, can also be used on targets.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-extended'>
|
||||
<title><filename>meta/recipes-extended/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains non-essential applications that add features compared to the
|
||||
alternatives in core.
|
||||
You might need this directory for full tool functionality or for Linux Standard Base (LSB)
|
||||
compliance.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-gnome'>
|
||||
<title><filename>meta/recipes-gnome/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains all things related to the GTK+ application framework.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-graphics'>
|
||||
<title><filename>meta/recipes-graphics/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains X and other graphically related system libraries
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-kernel'>
|
||||
<title><filename>meta/recipes-kernel/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the kernel and generic applications and libraries that
|
||||
have strong kernel dependencies.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-multimedia'>
|
||||
<title><filename>meta/recipes-multimedia/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains codecs and support utilities for audio, images and video.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-qt'>
|
||||
<title><filename>meta/recipes-qt/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains all things related to the Qt application framework.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-rt'>
|
||||
<title><filename>meta/recipes-rt/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains package and image recipes for using and testing
|
||||
the <filename>PREEMPT_RT</filename> kernel.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-sato'>
|
||||
<title><filename>meta/recipes-sato/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains the Sato demo/reference UI/UX and its associated applications
|
||||
and configuration data.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-support'>
|
||||
<title><filename>meta/recipes-support/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains recipes that used by other recipes, but that are not directly
|
||||
included in images (i.e. dependencies of other recipes).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-site'>
|
||||
<title><filename>meta/site/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains a list of cached results for various architectures.
|
||||
Because certain "autoconf" test results cannot be determined when cross-compiling due to
|
||||
the tests not able to run on a live system, the information in this directory is
|
||||
passed to "autoconf" for the various architectures.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-meta-recipes-txt'>
|
||||
<title><filename>meta/recipes.txt</filename></title>
|
||||
|
||||
<para>
|
||||
This file is a description of the contents of <filename>recipes-*</filename>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -1,979 +0,0 @@
|
|||
/*
|
||||
Generic XHTML / DocBook XHTML CSS Stylesheet.
|
||||
|
||||
Browser wrangling and typographic design by
|
||||
Oyvind Kolas / pippin@gimp.org
|
||||
|
||||
Customised for Poky by
|
||||
Matthew Allum / mallum@o-hand.com
|
||||
|
||||
Thanks to:
|
||||
Liam R. E. Quin
|
||||
William Skaggs
|
||||
Jakub Steiner
|
||||
|
||||
Structure
|
||||
---------
|
||||
|
||||
The stylesheet is divided into the following sections:
|
||||
|
||||
Positioning
|
||||
Margins, paddings, width, font-size, clearing.
|
||||
Decorations
|
||||
Borders, style
|
||||
Colors
|
||||
Colors
|
||||
Graphics
|
||||
Graphical backgrounds
|
||||
Nasty IE tweaks
|
||||
Workarounds needed to make it work in internet explorer,
|
||||
currently makes the stylesheet non validating, but up until
|
||||
this point it is validating.
|
||||
Mozilla extensions
|
||||
Transparency for footer
|
||||
Rounded corners on boxes
|
||||
|
||||
*/
|
||||
|
||||
|
||||
/*************** /
|
||||
/ Positioning /
|
||||
/ ***************/
|
||||
|
||||
body {
|
||||
font-family: Verdana, Sans, sans-serif;
|
||||
|
||||
min-width: 640px;
|
||||
width: 80%;
|
||||
margin: 0em auto;
|
||||
padding: 2em 5em 5em 5em;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
h1,h2,h3,h4,h5,h6,h7 {
|
||||
font-family: Arial, Sans;
|
||||
color: #00557D;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2em;
|
||||
text-align: left;
|
||||
padding: 0em 0em 0em 0em;
|
||||
margin: 2em 0em 0em 0em;
|
||||
}
|
||||
|
||||
h2.subtitle {
|
||||
margin: 0.10em 0em 3.0em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
font-size: 1.8em;
|
||||
padding-left: 20%;
|
||||
font-weight: normal;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
h2 {
|
||||
margin: 2em 0em 0.66em 0em;
|
||||
padding: 0.5em 0em 0em 0em;
|
||||
font-size: 1.5em;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h3.subtitle {
|
||||
margin: 0em 0em 1em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
font-size: 142.14%;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin: 1em 0em 0.5em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 140%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h4 {
|
||||
margin: 1em 0em 0.5em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 120%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h5 {
|
||||
margin: 1em 0em 0.5em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 110%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h6 {
|
||||
margin: 1em 0em 0em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 110%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.authorgroup {
|
||||
background-color: transparent;
|
||||
background-repeat: no-repeat;
|
||||
padding-top: 256px;
|
||||
background-image: url("figures/poky-title.png");
|
||||
background-position: left top;
|
||||
margin-top: -256px;
|
||||
padding-right: 50px;
|
||||
margin-left: 0px;
|
||||
text-align: right;
|
||||
width: 740px;
|
||||
}
|
||||
|
||||
h3.author {
|
||||
margin: 0em 0me 0em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
font-weight: normal;
|
||||
font-size: 100%;
|
||||
color: #333;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.author tt.email {
|
||||
font-size: 66%;
|
||||
}
|
||||
|
||||
.titlepage hr {
|
||||
width: 0em;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.revhistory {
|
||||
padding-top: 2em;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.toc,
|
||||
.list-of-tables,
|
||||
.list-of-examples,
|
||||
.list-of-figures {
|
||||
padding: 1.33em 0em 2.5em 0em;
|
||||
color: #00557D;
|
||||
}
|
||||
|
||||
.toc p,
|
||||
.list-of-tables p,
|
||||
.list-of-figures p,
|
||||
.list-of-examples p {
|
||||
padding: 0em 0em 0em 0em;
|
||||
padding: 0em 0em 0.3em;
|
||||
margin: 1.5em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.toc p b,
|
||||
.list-of-tables p b,
|
||||
.list-of-figures p b,
|
||||
.list-of-examples p b{
|
||||
font-size: 100.0%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.toc dl,
|
||||
.list-of-tables dl,
|
||||
.list-of-figures dl,
|
||||
.list-of-examples dl {
|
||||
margin: 0em 0em 0.5em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.toc dt {
|
||||
margin: 0em 0em 0em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.toc dd {
|
||||
margin: 0em 0em 0em 2.6em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
div.glossary dl,
|
||||
div.variablelist dl {
|
||||
}
|
||||
|
||||
.glossary dl dt,
|
||||
.variablelist dl dt,
|
||||
.variablelist dl dt span.term {
|
||||
font-weight: normal;
|
||||
width: 20em;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
.variablelist dl dt {
|
||||
margin-top: 0.5em;
|
||||
}
|
||||
|
||||
.glossary dl dd,
|
||||
.variablelist dl dd {
|
||||
margin-top: -1em;
|
||||
margin-left: 25.5em;
|
||||
}
|
||||
|
||||
.glossary dd p,
|
||||
.variablelist dd p {
|
||||
margin-top: 0em;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
|
||||
div.calloutlist table td {
|
||||
padding: 0em 0em 0em 0em;
|
||||
margin: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
div.calloutlist table td p {
|
||||
margin-top: 0em;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
div p.copyright {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
div.legalnotice p.legalnotice-title {
|
||||
margin-bottom: 0em;
|
||||
}
|
||||
|
||||
p {
|
||||
line-height: 1.5em;
|
||||
margin-top: 0em;
|
||||
|
||||
}
|
||||
|
||||
dl {
|
||||
padding-top: 0em;
|
||||
}
|
||||
|
||||
hr {
|
||||
border: solid 1px;
|
||||
}
|
||||
|
||||
|
||||
.mediaobject,
|
||||
.mediaobjectco {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
img {
|
||||
border: none;
|
||||
}
|
||||
|
||||
ul {
|
||||
padding: 0em 0em 0em 1.5em;
|
||||
}
|
||||
|
||||
ul li {
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
ul li p {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
table {
|
||||
width :100%;
|
||||
}
|
||||
|
||||
th {
|
||||
padding: 0.25em;
|
||||
text-align: left;
|
||||
font-weight: normal;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
td {
|
||||
padding: 0.25em;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
p a[id] {
|
||||
margin: 0px;
|
||||
padding: 0px;
|
||||
display: inline;
|
||||
background-image: none;
|
||||
}
|
||||
|
||||
a {
|
||||
text-decoration: underline;
|
||||
color: #444;
|
||||
}
|
||||
|
||||
pre {
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
text-decoration: underline;
|
||||
/*font-weight: bold;*/
|
||||
}
|
||||
|
||||
|
||||
div.informalfigure,
|
||||
div.informalexample,
|
||||
div.informaltable,
|
||||
div.figure,
|
||||
div.table,
|
||||
div.example {
|
||||
margin: 1em 0em;
|
||||
padding: 1em;
|
||||
page-break-inside: avoid;
|
||||
}
|
||||
|
||||
|
||||
div.informalfigure p.title b,
|
||||
div.informalexample p.title b,
|
||||
div.informaltable p.title b,
|
||||
div.figure p.title b,
|
||||
div.example p.title b,
|
||||
div.table p.title b{
|
||||
padding-top: 0em;
|
||||
margin-top: 0em;
|
||||
font-size: 100%;
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
.mediaobject .caption,
|
||||
.mediaobject .caption p {
|
||||
text-align: center;
|
||||
font-size: 80%;
|
||||
padding-top: 0.5em;
|
||||
padding-bottom: 0.5em;
|
||||
}
|
||||
|
||||
.epigraph {
|
||||
padding-left: 55%;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
.epigraph p {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.epigraph .quote {
|
||||
font-style: italic;
|
||||
}
|
||||
.epigraph .attribution {
|
||||
font-style: normal;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
span.application {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.programlisting {
|
||||
font-family: monospace;
|
||||
font-size: 80%;
|
||||
white-space: pre;
|
||||
margin: 1.33em 0em;
|
||||
padding: 1.33em;
|
||||
}
|
||||
|
||||
.tip,
|
||||
.warning,
|
||||
.caution,
|
||||
.note {
|
||||
margin-top: 1em;
|
||||
margin-bottom: 1em;
|
||||
|
||||
}
|
||||
|
||||
/* force full width of table within div */
|
||||
.tip table,
|
||||
.warning table,
|
||||
.caution table,
|
||||
.note table {
|
||||
border: none;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
|
||||
.tip table th,
|
||||
.warning table th,
|
||||
.caution table th,
|
||||
.note table th {
|
||||
padding: 0.8em 0.0em 0.0em 0.0em;
|
||||
margin : 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.tip p,
|
||||
.warning p,
|
||||
.caution p,
|
||||
.note p {
|
||||
margin-top: 0.5em;
|
||||
margin-bottom: 0.5em;
|
||||
padding-right: 1em;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.acronym {
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
padding: 0.09em 0.3em;
|
||||
margin: 0em;
|
||||
}
|
||||
|
||||
.itemizedlist li {
|
||||
clear: none;
|
||||
}
|
||||
|
||||
.filename {
|
||||
font-size: medium;
|
||||
font-family: Courier, monospace;
|
||||
}
|
||||
|
||||
|
||||
div.navheader, div.heading{
|
||||
position: absolute;
|
||||
left: 0em;
|
||||
top: 0em;
|
||||
width: 100%;
|
||||
background-color: #cdf;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
div.navfooter, div.footing{
|
||||
position: fixed;
|
||||
left: 0em;
|
||||
bottom: 0em;
|
||||
background-color: #eee;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
|
||||
div.navheader td,
|
||||
div.navfooter td {
|
||||
font-size: 66%;
|
||||
}
|
||||
|
||||
div.navheader table th {
|
||||
/*font-family: Georgia, Times, serif;*/
|
||||
/*font-size: x-large;*/
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
div.navheader table {
|
||||
border-left: 0em;
|
||||
border-right: 0em;
|
||||
border-top: 0em;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
div.navfooter table {
|
||||
border-left: 0em;
|
||||
border-right: 0em;
|
||||
border-bottom: 0em;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
div.navheader table td a,
|
||||
div.navfooter table td a {
|
||||
color: #777;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
/* normal text in the footer */
|
||||
div.navfooter table td {
|
||||
color: black;
|
||||
}
|
||||
|
||||
div.navheader table td a:visited,
|
||||
div.navfooter table td a:visited {
|
||||
color: #444;
|
||||
}
|
||||
|
||||
|
||||
/* links in header and footer */
|
||||
div.navheader table td a:hover,
|
||||
div.navfooter table td a:hover {
|
||||
text-decoration: underline;
|
||||
background-color: transparent;
|
||||
color: #33a;
|
||||
}
|
||||
|
||||
div.navheader hr,
|
||||
div.navfooter hr {
|
||||
display: none;
|
||||
}
|
||||
|
||||
|
||||
.qandaset tr.question td p {
|
||||
margin: 0em 0em 1em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.qandaset tr.answer td p {
|
||||
margin: 0em 0em 1em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
.answer td {
|
||||
padding-bottom: 1.5em;
|
||||
}
|
||||
|
||||
.emphasis {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
|
||||
/************* /
|
||||
/ decorations /
|
||||
/ *************/
|
||||
|
||||
.titlepage {
|
||||
}
|
||||
|
||||
.part .title {
|
||||
}
|
||||
|
||||
.subtitle {
|
||||
border: none;
|
||||
}
|
||||
|
||||
/*
|
||||
h1 {
|
||||
border: none;
|
||||
}
|
||||
|
||||
h2 {
|
||||
border-top: solid 0.2em;
|
||||
border-bottom: solid 0.06em;
|
||||
}
|
||||
|
||||
h3 {
|
||||
border-top: 0em;
|
||||
border-bottom: solid 0.06em;
|
||||
}
|
||||
|
||||
h4 {
|
||||
border: 0em;
|
||||
border-bottom: solid 0.06em;
|
||||
}
|
||||
|
||||
h5 {
|
||||
border: 0em;
|
||||
}
|
||||
*/
|
||||
|
||||
.programlisting {
|
||||
border: solid 1px;
|
||||
}
|
||||
|
||||
div.figure,
|
||||
div.table,
|
||||
div.informalfigure,
|
||||
div.informaltable,
|
||||
div.informalexample,
|
||||
div.example {
|
||||
border: 1px solid;
|
||||
}
|
||||
|
||||
|
||||
|
||||
.tip,
|
||||
.warning,
|
||||
.caution,
|
||||
.note {
|
||||
border: 1px solid;
|
||||
}
|
||||
|
||||
.tip table th,
|
||||
.warning table th,
|
||||
.caution table th,
|
||||
.note table th {
|
||||
border-bottom: 1px solid;
|
||||
}
|
||||
|
||||
.question td {
|
||||
border-top: 1px solid black;
|
||||
}
|
||||
|
||||
.answer {
|
||||
}
|
||||
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
border: 1px solid;
|
||||
}
|
||||
|
||||
|
||||
div.navheader, div.heading{
|
||||
border-bottom: 1px solid;
|
||||
}
|
||||
|
||||
|
||||
div.navfooter, div.footing{
|
||||
border-top: 1px solid;
|
||||
}
|
||||
|
||||
/********* /
|
||||
/ colors /
|
||||
/ *********/
|
||||
|
||||
body {
|
||||
color: #333;
|
||||
background: white;
|
||||
}
|
||||
|
||||
a {
|
||||
background: transparent;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
background-color: #dedede;
|
||||
}
|
||||
|
||||
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
h7,
|
||||
h8 {
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
hr {
|
||||
border-color: #aaa;
|
||||
}
|
||||
|
||||
|
||||
.tip, .warning, .caution, .note {
|
||||
border-color: #fff;
|
||||
}
|
||||
|
||||
|
||||
.tip table th,
|
||||
.warning table th,
|
||||
.caution table th,
|
||||
.note table th {
|
||||
border-bottom-color: #fff;
|
||||
}
|
||||
|
||||
|
||||
.warning {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.caution {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.tip {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.note {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.glossary dl dt,
|
||||
.variablelist dl dt,
|
||||
.variablelist dl dt span.term {
|
||||
color: #044;
|
||||
}
|
||||
|
||||
div.figure,
|
||||
div.table,
|
||||
div.example,
|
||||
div.informalfigure,
|
||||
div.informaltable,
|
||||
div.informalexample {
|
||||
border-color: #aaa;
|
||||
}
|
||||
|
||||
pre.programlisting {
|
||||
color: black;
|
||||
background-color: #fff;
|
||||
border-color: #aaa;
|
||||
border-width: 2px;
|
||||
}
|
||||
|
||||
.guimenu,
|
||||
.guilabel,
|
||||
.guimenuitem {
|
||||
background-color: #eee;
|
||||
}
|
||||
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
background-color: #eee;
|
||||
border-color: #999;
|
||||
}
|
||||
|
||||
|
||||
div.navheader {
|
||||
border-color: black;
|
||||
}
|
||||
|
||||
|
||||
div.navfooter {
|
||||
border-color: black;
|
||||
}
|
||||
|
||||
|
||||
/*********** /
|
||||
/ graphics /
|
||||
/ ***********/
|
||||
|
||||
/*
|
||||
body {
|
||||
background-image: url("images/body_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
.navheader,
|
||||
.note,
|
||||
.tip {
|
||||
background-image: url("images/note_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
.warning,
|
||||
.caution {
|
||||
background-image: url("images/warning_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
.figure,
|
||||
.informalfigure,
|
||||
.example,
|
||||
.informalexample,
|
||||
.table,
|
||||
.informaltable {
|
||||
background-image: url("images/figure_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
*/
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
h7{
|
||||
}
|
||||
|
||||
/*
|
||||
Example of how to stick an image as part of the title.
|
||||
|
||||
div.article .titlepage .title
|
||||
{
|
||||
background-image: url("figures/white-on-black.png");
|
||||
background-position: center;
|
||||
background-repeat: repeat-x;
|
||||
}
|
||||
*/
|
||||
|
||||
div.preface .titlepage .title,
|
||||
div.colophon .title,
|
||||
div.chapter .titlepage .title,
|
||||
div.article .titlepage .title
|
||||
{
|
||||
}
|
||||
|
||||
div.section div.section .titlepage .title,
|
||||
div.sect2 .titlepage .title {
|
||||
background: none;
|
||||
}
|
||||
|
||||
|
||||
h1.title {
|
||||
background-color: transparent;
|
||||
background-image: url("figures/poky-title.png");
|
||||
background-repeat: no-repeat;
|
||||
height: 256px;
|
||||
text-indent: -9000px;
|
||||
overflow:hidden;
|
||||
}
|
||||
|
||||
h2.subtitle {
|
||||
background-color: transparent;
|
||||
text-indent: -9000px;
|
||||
overflow:hidden;
|
||||
width: 0px;
|
||||
display: none;
|
||||
}
|
||||
|
||||
/*************************************** /
|
||||
/ pippin.gimp.org specific alterations /
|
||||
/ ***************************************/
|
||||
|
||||
/*
|
||||
div.heading, div.navheader {
|
||||
color: #777;
|
||||
font-size: 80%;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
text-align: left;
|
||||
position: absolute;
|
||||
top: 0px;
|
||||
left: 0px;
|
||||
width: 100%;
|
||||
height: 50px;
|
||||
background: url('/gfx/heading_bg.png') transparent;
|
||||
background-repeat: repeat-x;
|
||||
background-attachment: fixed;
|
||||
border: none;
|
||||
}
|
||||
|
||||
div.heading a {
|
||||
color: #444;
|
||||
}
|
||||
|
||||
div.footing, div.navfooter {
|
||||
border: none;
|
||||
color: #ddd;
|
||||
font-size: 80%;
|
||||
text-align:right;
|
||||
|
||||
width: 100%;
|
||||
padding-top: 10px;
|
||||
position: absolute;
|
||||
bottom: 0px;
|
||||
left: 0px;
|
||||
|
||||
background: url('/gfx/footing_bg.png') transparent;
|
||||
}
|
||||
*/
|
||||
|
||||
|
||||
|
||||
/****************** /
|
||||
/ nasty ie tweaks /
|
||||
/ ******************/
|
||||
|
||||
/*
|
||||
div.heading, div.navheader {
|
||||
width:expression(document.body.clientWidth + "px");
|
||||
}
|
||||
|
||||
div.footing, div.navfooter {
|
||||
width:expression(document.body.clientWidth + "px");
|
||||
margin-left:expression("-5em");
|
||||
}
|
||||
body {
|
||||
padding:expression("4em 5em 0em 5em");
|
||||
}
|
||||
*/
|
||||
|
||||
/**************************************** /
|
||||
/ mozilla vendor specific css extensions /
|
||||
/ ****************************************/
|
||||
/*
|
||||
div.navfooter, div.footing{
|
||||
-moz-opacity: 0.8em;
|
||||
}
|
||||
|
||||
div.figure,
|
||||
div.table,
|
||||
div.informalfigure,
|
||||
div.informaltable,
|
||||
div.informalexample,
|
||||
div.example,
|
||||
.tip,
|
||||
.warning,
|
||||
.caution,
|
||||
.note {
|
||||
-moz-border-radius: 0.5em;
|
||||
}
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
-moz-border-radius: 0.3em;
|
||||
}
|
||||
*/
|
||||
|
||||
table tr td table tr td {
|
||||
display: none;
|
||||
}
|
||||
|
||||
|
||||
hr {
|
||||
display: none;
|
||||
}
|
||||
|
||||
table {
|
||||
border: 0em;
|
||||
}
|
||||
|
||||
.photo {
|
||||
float: right;
|
||||
margin-left: 1.5em;
|
||||
margin-bottom: 1.5em;
|
||||
margin-top: 0em;
|
||||
max-width: 17em;
|
||||
border: 1px solid gray;
|
||||
padding: 3px;
|
||||
background: white;
|
||||
}
|
||||
.seperator {
|
||||
padding-top: 2em;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
#validators {
|
||||
margin-top: 5em;
|
||||
text-align: right;
|
||||
color: #777;
|
||||
}
|
||||
@media print {
|
||||
body {
|
||||
font-size: 8pt;
|
||||
}
|
||||
.noprint {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
.tip,
|
||||
.note {
|
||||
background: #f0f0f2;
|
||||
color: #333;
|
||||
padding: 20px;
|
||||
margin: 20px;
|
||||
}
|
||||
|
||||
.tip h3,
|
||||
.note h3 {
|
||||
padding: 0em;
|
||||
margin: 0em;
|
||||
font-size: 2em;
|
||||
font-weight: bold;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
.tip a,
|
||||
.note a {
|
||||
color: #333;
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
.footnote {
|
||||
font-size: small;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
/* Changes the announcement text */
|
||||
.tip h3,
|
||||
.warning h3,
|
||||
.caution h3,
|
||||
.note h3 {
|
||||
font-size:large;
|
||||
color: #00557D;
|
||||
}
|
||||
|
File diff suppressed because it is too large
Load Diff
|
@ -1,193 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='ref-varlocality'>
|
||||
<title>Variable Context</title>
|
||||
|
||||
<para>
|
||||
While most variables can be used in almost any context such as
|
||||
<filename>.conf</filename>, <filename>.bbclass</filename>,
|
||||
<filename>.inc</filename>, and <filename>.bb</filename> files,
|
||||
some variables are often associated with a particular locality or context.
|
||||
This chapter describes some common associations.
|
||||
</para>
|
||||
|
||||
<section id='ref-varlocality-configuration'>
|
||||
<title>Configuration</title>
|
||||
|
||||
<para>
|
||||
The following subsections provide lists of variables whose context is
|
||||
configuration: distribution, machine, and local.
|
||||
</para>
|
||||
|
||||
<section id='ref-varlocality-config-distro'>
|
||||
<title>Distribution (Distro)</title>
|
||||
|
||||
<para>
|
||||
This section lists variables whose context is the distribution, or distro.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-DISTRO_NAME'>DISTRO_NAME</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-DISTRO_VERSION'>DISTRO_VERSION</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MAINTAINER'>MAINTAINER</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-TARGET_OS'>TARGET_OS</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-TARGET_FPU'>TARGET_FPU</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-TCMODE'>TCMODE</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-TCLIBC'>TCLIBC</link></filename>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-varlocality-config-machine'>
|
||||
<title>Machine</title>
|
||||
|
||||
<para>
|
||||
This section lists variables whose context is the machine.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-PACKAGE_EXTRA_ARCHS'>PACKAGE_EXTRA_ARCHS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS
|
||||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS
|
||||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS
|
||||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>
|
||||
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-varlocality-config-local'>
|
||||
<title>Local</title>
|
||||
|
||||
<para>
|
||||
This section lists variables whose context is the local configuration through the
|
||||
<filename>local.conf</filename> file.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-MACHINE'>MACHINE</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-BBFILES'>BBFILES</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES
|
||||
</link></filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-BBINCLUDELOGS'>BBINCLUDELOGS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>
|
||||
ENABLE_BINARY_LOCALE_GENERATION</link></filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='ref-varlocality-recipes'>
|
||||
<title>Recipes</title>
|
||||
|
||||
<para>
|
||||
The following subsections provide lists of variables whose context is
|
||||
recipes: required, dependencies, path, and extra build information.
|
||||
</para>
|
||||
|
||||
<section id='ref-varlocality-recipe-required'>
|
||||
<title>Required</title>
|
||||
|
||||
<para>
|
||||
This section lists variables that are required for recipes.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-LICENSE'>LICENSE</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> - used
|
||||
in recipes that fetch local or remote files.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-varlocality-recipe-dependencies'>
|
||||
<title>Dependencies</title>
|
||||
|
||||
<para>
|
||||
This section lists variables that define recipe dependencies.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-DEPENDS'>DEPENDS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-RDEPENDS'>RDEPENDS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-RRECOMMENDS'>RRECOMMENDS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-RREPLACES'>RREPLACES</link>
|
||||
</filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-varlocality-recipe-paths'>
|
||||
<title>Paths</title>
|
||||
|
||||
<para>
|
||||
This section lists variables that define recipe paths.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-WORKDIR'>WORKDIR</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-S'>S</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-FILES'>FILES</link>
|
||||
</filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-varlocality-recipe-build'>
|
||||
<title>Extra Build Information</title>
|
||||
|
||||
<para>
|
||||
This section lists variables that define extra build information for recipes.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><link linkend='var-EXTRA_OECMAKE'>EXTRA_OECMAKE</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
|
||||
</filename></para></listitem>
|
||||
<listitem><para><filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
|
||||
</para></listitem>
|
||||
<listitem><para><filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE
|
||||
</link></filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4 spell spelllang=en_gb
|
||||
-->
|
|
@ -1,114 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='resources'>
|
||||
<title>Contributing to the Yocto Project</title>
|
||||
|
||||
<section id='resources-intro'>
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
The Yocto Project team is happy for people to experiment with the Yocto Project.
|
||||
A number of places exist to find help if you run into difficulties or find bugs.
|
||||
To find out how to download source code,
|
||||
see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
|
||||
list item in the Yocto Project Development Manual.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='resources-bugtracker'>
|
||||
<title>Tracking Bugs</title>
|
||||
|
||||
<para>
|
||||
If you find problems with the Yocto Project, you should report them using the
|
||||
Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='resources-mailinglist'>
|
||||
<title>Mailing lists</title>
|
||||
|
||||
<para>
|
||||
There are a number of mailing lists maintained by the Yocto Project as well as
|
||||
related OpenEmbedded mailing lists for discussion, patch submission and announcements.
|
||||
To subscribe to one of the following mailing lists, click on the appropriate URL
|
||||
in the following list and follow the instructions:
|
||||
<itemizedlist>
|
||||
<listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> -
|
||||
General Yocto Project discussion mailing list. </para></listitem>
|
||||
<listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'></ulink> -
|
||||
Discussion mailing list about OpenEmbedded-Core (the core metadata).</para></listitem>
|
||||
<listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'></ulink> -
|
||||
Discussion mailing list about OpenEmbedded.</para></listitem>
|
||||
<listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> -
|
||||
Discussion mailing list about the BitBake build tool.</para></listitem>
|
||||
<listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
|
||||
Discussion mailing list about Poky.</para></listitem>
|
||||
<listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
|
||||
Mailing list to receive official Yocto Project release and milestone
|
||||
announcements.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='resources-irc'>
|
||||
<title>Internet Relay Chat (IRC)</title>
|
||||
|
||||
<para>
|
||||
Two IRC channels on freenode are available for the Yocto Project and Poky discussions:
|
||||
<itemizedlist>
|
||||
<listitem><para><filename>#yocto</filename></para></listitem>
|
||||
<listitem><para><filename>#poky</filename></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='resources-links'>
|
||||
<title>Links</title>
|
||||
|
||||
<para>
|
||||
Following is a list of resources you will find helpful:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
|
||||
</emphasis> The home site for the Yocto Project.</para></listitem>
|
||||
<!-- <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
|
||||
The company where the Yocto Project build system Poky was first developed.
|
||||
OpenedHand has since been acquired by Intel Corporation.</para></listitem> -->
|
||||
<listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
|
||||
The company who acquired OpenedHand in 2008 and began development on the
|
||||
Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
|
||||
The upstream, generic, embedded distribution used as the basis for the build system in the
|
||||
Yocto Project.
|
||||
Poky derives from and contributes back to the OpenEmbedded project.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
|
||||
BitBake</ulink>:</emphasis> The tool used to process metadata.</para></listitem>
|
||||
<listitem><para><emphasis>BitBake User Manual:</emphasis>
|
||||
A comprehensive guide to the BitBake tool.
|
||||
You can find the BitBake User Manual in the <filename>bitbake/doc/manual</filename>
|
||||
directory, which is found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
|
||||
</emphasis> An open source machine emulator and virtualizer.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='resources-contributions'>
|
||||
<title>Contributions</title>
|
||||
|
||||
<para>
|
||||
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
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
File diff suppressed because it is too large
Load Diff
|
@ -1,651 +0,0 @@
|
|||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
|
||||
<chapter id='usingpoky'>
|
||||
<title>Using the Yocto Project</title>
|
||||
|
||||
<para>
|
||||
This chapter describes common usage for the Yocto Project.
|
||||
The information is introductory in nature as other manuals in the Yocto Project
|
||||
documentation set provide more details on how to use the Yocto Project.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-build'>
|
||||
<title>Running a Build</title>
|
||||
|
||||
<para>
|
||||
This section provides a summary of the build process and provides information
|
||||
for less obvious aspects of the build process.
|
||||
For general information on how to build an image using the OpenEmbedded build
|
||||
system, see the
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
|
||||
section of the Yocto Project Quick Start.
|
||||
</para>
|
||||
|
||||
<section id='build-overview'>
|
||||
<title>Build Overview</title>
|
||||
|
||||
<para>
|
||||
The first thing you need to do is set up the OpenEmbedded build environment by sourcing
|
||||
the <link linkend='structure-core-script'>environment setup script</link> as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ source &OE_INIT_FILE; [build_dir]
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>build_dir</filename> is optional and specifies the directory the
|
||||
OpenEmbedded build system uses for the build -
|
||||
the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
||||
If you do not specify a Build Directory it defaults to <filename>build</filename>
|
||||
in your current working directory.
|
||||
A common practice is to use a different Build Directory for different targets.
|
||||
For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
|
||||
target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
|
||||
See <link linkend="structure-core-script">&OE_INIT_FILE;</link>
|
||||
for more information on this script.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once the build environment is set up, you can build a target using:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake <target>
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>target</filename> is the name of the recipe you want to build.
|
||||
Common targets are the images in <filename>meta/recipes-core/images</filename>,
|
||||
<filename>/meta/recipes-sato/images</filename>, etc. all found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
Or, the target can be the name of a recipe for a specific piece of software such as
|
||||
<application>busybox</application>.
|
||||
For more details about the images the OpenEmbedded build system supports, see the
|
||||
"<link linkend="ref-images">Images</link>" chapter.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
Building an image without GNU General Public License Version 3 (GPLv3) components
|
||||
is only supported for minimal and base images.
|
||||
See the "<link linkend='ref-images'>Images</link>" chapter for more information.
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='building-an-image-using-gpl-components'>
|
||||
<title>Building an Image Using GPL Components</title>
|
||||
|
||||
<para>
|
||||
When building an image using GPL components, you need to maintain your original
|
||||
settings and not switch back and forth applying different versions of the GNU
|
||||
General Public License.
|
||||
If you rebuild using different versions of GPL, dependency errors might occur
|
||||
due to some components not being rebuilt.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-install'>
|
||||
<title>Installing and Using the Result</title>
|
||||
|
||||
<para>
|
||||
Once an image has been built, it often needs to be installed.
|
||||
The images and kernels built by the OpenEmbedded build system are placed in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in
|
||||
<filename class="directory">tmp/deploy/images</filename>.
|
||||
For information on how to run pre-built images such as <filename>qemux86</filename>
|
||||
and <filename>qemuarm</filename>, see the
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
|
||||
section in the Yocto Project Quick Start.
|
||||
For information about how to install these images, see the documentation for your
|
||||
particular board/machine.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging'>
|
||||
<title>Debugging Build Failures</title>
|
||||
|
||||
<para>
|
||||
The exact method for debugging build failures depends on the nature of the
|
||||
problem and on the system's area from which the bug originates.
|
||||
Standard debugging practices such as comparison against the last
|
||||
known working version with examination of the changes and the re-application of steps
|
||||
to identify the one causing the problem are
|
||||
valid for the Yocto Project just as they are for any other system.
|
||||
Even though it is impossible to detail every possible potential failure,
|
||||
this section provides some general tips to aid in debugging.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-debugging-taskfailures'>
|
||||
<title>Task Failures</title>
|
||||
|
||||
<para>The log file for shell tasks is available in
|
||||
<filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
|
||||
For example, the <filename>compile</filename> task for the QEMU minimal image for the x86
|
||||
machine (<filename>qemux86</filename>) might be
|
||||
<filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830</filename>.
|
||||
To see what BitBake runs to generate that log, look at the corresponding
|
||||
<filename>run.do_taskname.pid</filename> file located in the same directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Presently, the output from Python tasks is sent directly to the console.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging-taskrunning'>
|
||||
<title>Running Specific Tasks</title>
|
||||
|
||||
<para>
|
||||
Any given package consists of a set of tasks.
|
||||
The standard BitBake behavior in most cases is: <filename>fetch</filename>,
|
||||
<filename>unpack</filename>,
|
||||
<filename>patch</filename>, <filename>configure</filename>,
|
||||
<filename>compile</filename>, <filename>install</filename>, <filename>package</filename>,
|
||||
<filename>package_write</filename>, and <filename>build</filename>.
|
||||
The default task is <filename>build</filename> and any tasks on which it depends
|
||||
build first.
|
||||
Some tasks exist, such as <filename>devshell</filename>, that are not part of the
|
||||
default build chain.
|
||||
If you wish to run a task that is not part of the default build chain, you can use the
|
||||
<filename>-c</filename> option in BitBake as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop -c devshell
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you wish to rerun a task, use the <filename>-f</filename> force option.
|
||||
For example, the following sequence forces recompilation after changing files in the
|
||||
working directory.
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop
|
||||
.
|
||||
.
|
||||
[make some changes to the source code in the working directory]
|
||||
.
|
||||
.
|
||||
$ bitbake matchbox-desktop -c compile -f
|
||||
$ bitbake matchbox-desktop
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This sequence first builds <filename>matchbox-desktop</filename> and then recompiles it.
|
||||
The last command reruns all tasks (basically the packaging tasks) after the compile.
|
||||
BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
|
||||
understands that the other tasks also need to be run again.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can view a list of tasks in a given package by running the
|
||||
<filename>listtasks</filename> task as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop -c listtasks
|
||||
</literallayout>
|
||||
The results are in the file <filename>${WORKDIR}/temp/log.do_listtasks</filename>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging-dependencies'>
|
||||
<title>Dependency Graphs</title>
|
||||
|
||||
<para>
|
||||
Sometimes it can be hard to see why BitBake wants to build some other packages before a given
|
||||
package you have specified.
|
||||
The <filename>bitbake -g targetname</filename> command creates the
|
||||
<filename>depends.dot</filename>, <filename>package-depends.dot</filename>,
|
||||
and <filename>task-depends.dot</filename> files in the current directory.
|
||||
These files show the package and task dependencies and are useful for debugging problems.
|
||||
You can use the <filename>bitbake -g -u depexp targetname</filename> command to
|
||||
display the results in a more human-readable form.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging-bitbake'>
|
||||
<title>General BitBake Problems</title>
|
||||
|
||||
<para>
|
||||
You can see debug output from BitBake by using the <filename>-D</filename> option.
|
||||
The debug output gives more information about what BitBake
|
||||
is doing and the reason behind it.
|
||||
Each <filename>-D</filename> option you use increases the logging level.
|
||||
The most common usage is <filename>-DDD</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
|
||||
BitBake chose a certain version of a package or why BitBake
|
||||
picked a certain provider.
|
||||
This command could also help you in a situation where you think BitBake did something
|
||||
unexpected.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging-buildfile'>
|
||||
<title>Building with No Dependencies</title>
|
||||
<para>
|
||||
If you really want to build a specific <filename>.bb</filename> file, you can use
|
||||
the command form <filename>bitbake -b <somepath/somefile.bb></filename>.
|
||||
This command form does not check for dependencies so you should use it
|
||||
only when you know its dependencies already exist.
|
||||
You can also specify fragments of the filename.
|
||||
In this case, BitBake checks for a unique match.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging-variables'>
|
||||
<title>Variables</title>
|
||||
<para>
|
||||
The <filename>-e</filename> option dumps the resulting environment for
|
||||
either the configuration (no package specified) or for a
|
||||
specific package when specified; or <filename>-b recipename</filename>
|
||||
to show the environment from parsing a single recipe file only.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='recipe-logging-mechanisms'>
|
||||
<title>Recipe Logging Mechanisms</title>
|
||||
<para>
|
||||
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:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Python:</emphasis> For Python functions, BitBake
|
||||
supports several loglevels: <filename>bb.fatal</filename>,
|
||||
<filename>bb.error</filename>, <filename>bb.warn</filename>,
|
||||
<filename>bb.note</filename>, <filename>bb.plain</filename>,
|
||||
and <filename>bb.debug</filename>.</para></listitem>
|
||||
<listitem><para><emphasis>Bash:</emphasis> For Bash functions, the same set
|
||||
of loglevels exist and are accessed with a similar syntax:
|
||||
<filename>bbfatal</filename>, <filename>bberror</filename>,
|
||||
<filename>bbwarn</filename>, <filename>bbnote</filename>,
|
||||
<filename>bbplain</filename>, and <filename>bbdebug</filename>.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For guidance on how logging is handled in both Python and Bash recipes, see the
|
||||
<filename>logging.bbclass</filename> file in the
|
||||
<filename>meta/classes</filename> folder of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
</para>
|
||||
|
||||
<section id='logging-with-python'>
|
||||
<title>Logging With Python</title>
|
||||
<para>
|
||||
When creating recipes using Python and inserting code that handles build logs
|
||||
keep in mind the goal is to have informative logs while keeping the console as
|
||||
"silent" as possible.
|
||||
Also, if you want status messages in the log use the "debug" loglevel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following is an example written in Python.
|
||||
The code handles logging for a function that determines the number of tasks
|
||||
needed to be run:
|
||||
<literallayout class='monospaced'>
|
||||
python do_listtasks() {
|
||||
bb.debug(2, "Starting to figure out the task list")
|
||||
if noteworthy_condition:
|
||||
bb.note("There are 47 tasks to run")
|
||||
bb.debug(2, "Got to point xyz")
|
||||
if warning_trigger:
|
||||
bb.warn("Detected warning_trigger, this might be a problem later.")
|
||||
if recoverable_error:
|
||||
bb.error("Hit recoverable_error, you really need to fix this!")
|
||||
if fatal_error:
|
||||
bb.fatal("fatal_error detected, unable to print the task list")
|
||||
bb.plain("The tasks present are abc")
|
||||
bb.debug(2, "Finished figuring out the tasklist")
|
||||
}
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='logging-with-bash'>
|
||||
<title>Logging With Bash</title>
|
||||
<para>
|
||||
When creating recipes using Bash and inserting code that handles build
|
||||
logs you have the same goals - informative with minimal console output.
|
||||
The syntax you use for recipes written in Bash is similar to that of
|
||||
recipes written in Python described in the previous section.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following is an example written in Bash.
|
||||
The code logs the progress of the <filename>do_my_function</filename> function.
|
||||
<literallayout class='monospaced'>
|
||||
do_my_function() {
|
||||
bbdebug 2 "Running do_my_function"
|
||||
if [ exceptional_condition ]; then
|
||||
bbnote "Hit exceptional_condition"
|
||||
fi
|
||||
bbdebug 2 "Got to point xyz"
|
||||
if [ warning_trigger ]; then
|
||||
bbwarn "Detected warning_trigger, this might cause a problem later."
|
||||
fi
|
||||
if [ recoverable_error ]; then
|
||||
bberror "Hit recoverable_error, correcting"
|
||||
fi
|
||||
if [ fatal_error ]; then
|
||||
bbfatal "fatal_error detected"
|
||||
fi
|
||||
bbdebug 2 "Completed do_my_function"
|
||||
}
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-debugging-others'>
|
||||
<title>Other Tips</title>
|
||||
|
||||
<para>
|
||||
Here are some other tips that you might find useful:
|
||||
<itemizedlist>
|
||||
<listitem><para>When adding new packages, it is worth watching for
|
||||
undesirable items making their way into compiler command lines.
|
||||
For example, you do not want references to local system files like
|
||||
<filename>/usr/lib/</filename> or <filename>/usr/include/</filename>.
|
||||
</para></listitem>
|
||||
<listitem><para>If you want to remove the psplash boot splashscreen,
|
||||
add <filename>psplash=false</filename> to the kernel command line.
|
||||
Doing so prevents psplash from loading and thus allows you to see the console.
|
||||
It is also possible to switch out of the splashscreen by
|
||||
switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='maintaining-build-output-quality'>
|
||||
<title>Maintaining Build Output Quality</title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>buildhistory</filename> class exists to help you maintain
|
||||
the quality of your build output.
|
||||
You can use the class to highlight unexpected and possibly unwanted
|
||||
changes in the build output.
|
||||
When you enable build history it records information about the contents of
|
||||
each package and image and then commits that information to a local Git
|
||||
repository where you can examine the information.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remainder of this section describes the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>How you can enable and disable
|
||||
build history</para></listitem>
|
||||
<listitem><para>How to understand what the build history contains
|
||||
</para></listitem>
|
||||
<listitem><para>How to limit the information used for build history
|
||||
</para></listitem>
|
||||
<listitem><para>How to examine the build history from both a
|
||||
command-line and web interface</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<section id='enabling-and-disabling-build-history'>
|
||||
<title>Enabling and Disabling Build History</title>
|
||||
|
||||
<para>
|
||||
Build history is disabled by default.
|
||||
To enable it, add the following statements to the end of your
|
||||
<filename>conf/local.conf</filename> file found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
INHERIT += "buildhistory"
|
||||
BUILDHISTORY_COMMIT = "1"
|
||||
</literallayout>
|
||||
Enabling build history as previously described
|
||||
causes the build process to collect build
|
||||
output information and commit it to a local
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> repository.
|
||||
<note>
|
||||
Enabling build history increases your build times slightly,
|
||||
particularly for images, and increases the amount of disk
|
||||
space used during the build.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can disable build history by removing the previous statements
|
||||
from your <filename>conf/local.conf</filename> file.
|
||||
However, you should realize that enabling and disabling
|
||||
build history in this manner can change the
|
||||
<filename>do_package</filename> task checksums, which if you
|
||||
are using the OEBasicHash signature generator (the default
|
||||
for many current distro configurations including
|
||||
<filename>DISTRO = "poky"</filename> and
|
||||
<filename>DISTRO = ""</filename>) will result in the packaging
|
||||
tasks being re-run during the subsequent build.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To disable the build history functionality without causing the
|
||||
packaging tasks to be re-run, add just this statement to your
|
||||
<filename>conf/local.conf</filename> file:
|
||||
<literallayout class='monospaced'>
|
||||
BUILDHISTORY_FEATURES = ""
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='understanding-what-the-build-history-contains'>
|
||||
<title>Understanding What the Build History Contains</title>
|
||||
|
||||
<para>
|
||||
Build history information is kept in
|
||||
<link linkend='var-TMPDIR'><filename>$TMPDIR</filename></link><filename>/buildhistory</filename>
|
||||
in the Build Directory.
|
||||
The following is an example abbreviated listing:
|
||||
<imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
|
||||
</para>
|
||||
|
||||
<section id='build-history-package-information'>
|
||||
<title>Build History Package Information</title>
|
||||
|
||||
<para>
|
||||
The history for each package contains a text file that has
|
||||
name-value pairs with information about the package.
|
||||
For example, <filename>buildhistory/packages/core2-poky-linux/busybox/busybox/latest</filename>
|
||||
contains the following:
|
||||
<literallayout class='monospaced'>
|
||||
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
|
||||
</literallayout>
|
||||
Most of these name-value pairs corresponds to variables used
|
||||
to produce the package.
|
||||
The exceptions are <filename>FILELIST</filename>, which is the
|
||||
actual list of files in the package, and
|
||||
<filename>PKGSIZE</filename>, which is the total size of files
|
||||
in the package in bytes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is also a file corresponding to the recipe from which the
|
||||
package came (e.g.
|
||||
<filename>buildhistory/packages/core2-poky-linux/busybox/latest</filename>):
|
||||
<literallayout class='monospaced'>
|
||||
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
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='build-history-image-information'>
|
||||
<title>Build History Image Information</title>
|
||||
|
||||
<para>
|
||||
The files produced for each image are as follows:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>build-id:</emphasis>
|
||||
Human-readable information about the build configuration
|
||||
and metadata source revisions.</para></listitem>
|
||||
<listitem><para><emphasis>*.dot:</emphasis>
|
||||
Dependency graphs for the image that are
|
||||
compatible with <filename>graphviz</filename>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>files-in-image.txt:</emphasis>
|
||||
A list of files in the image with permissions,
|
||||
owner, group, size, and symlink information.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>image-info.txt:</emphasis>
|
||||
A text file containing name-value pairs with information
|
||||
about the image.
|
||||
See the following listing example for more information.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>installed-package-names.txt:</emphasis>
|
||||
A list of installed packages by name only.</para></listitem>
|
||||
<listitem><para><emphasis>installed-package-sizes.txt:</emphasis>
|
||||
A list of installed packages ordered by size.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>installed-packages.txt:</emphasis>
|
||||
A list of installed packages with fuill package
|
||||
filenames.</para></listitem>
|
||||
</itemizedlist>
|
||||
<note>
|
||||
Installed package information is able to be gathered and
|
||||
produced even if package management is disabled for the final
|
||||
image.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is an example of <filename>image-info.txt</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
DISTRO = poky
|
||||
DISTRO_VERSION = 1.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
|
||||
</literallayout>
|
||||
Other than <filename>IMAGESIZE</filename>, which is the
|
||||
total size of the files in the image in Kbytes, the
|
||||
name-value pairs are variables that may have influenced the
|
||||
content of the image.
|
||||
This information is often useful when you are trying to determine
|
||||
why a change in the package or file listings has occurred.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='using-build-history-to-gather-image-information-only'>
|
||||
<title>Using Build History to Gather Image Information Only</title>
|
||||
|
||||
<para>
|
||||
As you can see, build history produces image information,
|
||||
including dependency graphs, so you can see why something
|
||||
was pulled into the image.
|
||||
If you are just interested in this information and not
|
||||
interested in collecting history or any package information,
|
||||
you can enable writing only image information without
|
||||
any history by adding the following
|
||||
to your <filename>conf/local.conf</filename> file found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
INHERIT += "buildhistory"
|
||||
BUILDHISTORY_COMMIT = "0"
|
||||
BUILDHISTORY_FEATURES = "image"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='examining-build-history-information'>
|
||||
<title>Examining Build History Information</title>
|
||||
|
||||
<para>
|
||||
You can examine build history output from the command line or
|
||||
from a web interface.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To see any changes that have occurred (assuming you have
|
||||
<filename>BUILDHISTORY_COMMIT = "1"</filename>), you can simply
|
||||
use any Git command that allows you to view the history of
|
||||
a repository.
|
||||
Here is one method:
|
||||
<literallayout class='monospaced'>
|
||||
$ git log -p
|
||||
</literallayout>
|
||||
You need to realize, however, that this method does show
|
||||
changes that are not significant (e.g. a package's size
|
||||
changing by a few bytes).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A command-line tool called <filename>buildhistory-diff</filename>
|
||||
does exist though that queries the Git repository and prints just
|
||||
the differences that might be significant in human-readable form.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
$ ~/poky/poky/scripts/buildhistory-diff . HEAD^
|
||||
Changes to images/qemux86_64/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"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To see changes to the build history using a web interface, follow
|
||||
the instruction in the <filename>README</filename> file here.
|
||||
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/'></ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is a sample screenshot of the interface:
|
||||
<imagedata fileref="figures/buildhistory-web.png" align="center" scalefit="1" width="130%" contentdepth="130%" />
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
Loading…
Reference in New Issue