mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 12:29:55 +00:00
Code Issues Projects Releases Wiki Activity

handbook: Move into documentation directory

Browse Source 
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This commit is contained in:
Richard Purdie
2010-10-15 11:55:59 +01:00
parent 13a702e9e5
commit 2208328791
46 changed files with 5 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/poky-ref-manual/Makefile
+38
View File
@@ -0,0 +1,38 @@
all: html pdf tarball
pdf:
cd ..; ./tools/poky-docbook-to-pdf ./poky-ref-manual/poky-handbook.xml ./template
cd..; ./tools/poky-docbook-to-pdf ./poky-ref-manual/bsp-guide.xml ./template
XSLTOPTS = --stringparam html.stylesheet style.css \
--stringparam chapter.autolabel 1 \
--stringparam appendix.autolabel 1 \
--stringparam section.autolabel 1 \
--stringparam section.label.includes.component.label 1 \
--xinclude
##
# These URI should be rewritten by your distribution's xml catalog to
# match your localy installed XSL stylesheets.
XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current
XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
html:
# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
xsltproc $(XSLTOPTS) -o poky-handbook.html $(XSL_XHTML_URI) poky-handbook.xml
xsltproc $(XSLTOPTS) -o bsp-guide.html $(XSL_XHTML_URI) bsp-guide.xml
tarball: html
tar -cvzf poky-handbook.tgz poky-handbook.html style.css screenshots/ss-sato.png poky-beaver.png poky-handbook.png
validate:
xmllint --postvalid --xinclude --noout poky-handbook.xml
OUTPUTS = poky-handbook.tgz poky-handbook.html poky-handbook.pdf bsp-guide.pdf
SOURCES = *.png *.xml *.css *.svg
publish:
scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
clean:
rm $(OUTPUTS)
documentation/poky-ref-manual/TODO
+11
View File
@@ -0,0 +1,11 @@
Handbook Todo List:
* Document adding a new IMAGE_FEATURE to the customising images section
* Add instructions about using zaurus/openmoko emulation
* Add component overview/block diagrams
* Software Deevelopment intro should mention its software development for
intended target and could be a different arch etc and thus special case.
* Expand insane.bbclass documentation to cover tests
* Document remaining classes (see list in ref-classes)
* Document formfactor
documentation/poky-ref-manual/bsp-guide.xml
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<book id='poky-handbook' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='template/poky-handbook.png'
format='SVG'
align='center' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>Board Support Package (BSP) Developers Guide</title>
<authorgroup>
<author>
<firstname>Richard</firstname> <surname>Purdie</surname>
<affiliation>
<orgname>Intel Corporation</orgname>
</affiliation>
<email>richard@linux.intel.com</email>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>0.4</revnumber>
<date>26 May 2010</date>
<revremark>Alpha Draft</revremark>
</revision>
</revhistory>
<copyright>
<year>2010</year>
<holder>Intel Corporation</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-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
</para>
</legalnotice>
</bookinfo>
<xi:include href="bsp.xml"/>
<index id='index'>
<title>Index</title>
</index>
</book>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/bsp.xml
+451
View File
@@ -0,0 +1,451 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id='bsp'>
<title>Board Support Packages (BSP) - Developers Guide</title>
<para>
A Board Support Package (BSP) is a collection of information which together
defines how to support a particular hardware device, set of devices, or
hardware platform. It will include information about the hardware features
present on the device and kernel configuration information along with any
additional hardware drivers required. It will also list any additional software
components required in addition to a generic Linux software stack for both
essential and optional platform features.
</para>
<para>
The intent of this document is to define a structure for these components
so that BSPs follow a commonly understood layout, allowing them to be
provided in a common form that everyone understands. It also allows end-users
to become familiar with one common format and encourages standardisation
of software support of hardware.
</para>
<para>
The proposed format does have elements that are specific to the Poky and
OpenEmbedded build systems. It is intended that this information can be
used by other systems besides Poky/OpenEmbedded and that it will be simple
to extract information and convert to other formats if required. The format
described can be directly accepted as a layer by Poky using its standard
layers mechanism, but it is important to recognise that the BSP captures all
the hardware specific details in one place in a standard format, which is
useful for any person wishing to use the hardware platform regardless of
the build system in use.
</para>
<para>
The BSP specification does not include a build system or other tools -
it is concerned with the hardware specific components only. At the end
distribution point the BSP may be shipped combined with a build system
and other tools, but it is important to maintain the distinction that these
are separate components which may just be combined in certain end products.
</para>
<section id='bsp-filelayout'>
<title>Example Filesystem Layout</title>
<para>
The BSP consists of a file structure inside a base directory, meta-bsp in this example, where "bsp" is a placeholder for the machine or platform name. Examples of some files that it could contain are:
</para>
<para>
<programlisting>
meta-bsp/
meta-bsp/binary/zImage
meta-bsp/binary/poky-image-minimal.directdisk
meta-bsp/conf/layer.conf
meta-bsp/conf/machine/*.conf
meta-bsp/conf/machine/include/tune-*.inc
meta-bsp/packages/bootloader/bootloader_0.1.bb
meta-bsp/packages/linux/linux-bsp-2.6.50/*.patch
meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
meta-bsp/packages/linux/linux-bsp_2.6.50.bb
meta-bsp/packages/modem/modem-driver_0.1.bb
meta-bsp/packages/modem/modem-daemon_0.1.bb
meta-bsp/packages/image-creator/image-creator-native_0.1.bb
meta-bsp/prebuilds/
</programlisting>
</para>
<para>
The following sections detail what these files and directories could contain.
</para>
</section>
<section id='bsp-filelayout-binary'>
<title>Prebuilt User Binaries (meta-bsp/binary/*)</title>
<para>
This optional area contains useful prebuilt kernels and userspace filesystem
images appropriate to the target system. Users could use these to get a system
running and quickly get started on development tasks. The exact types of binaries
present will be highly hardware-dependent but a README file should be present
explaining how to use them with the target hardware. If prebuilt binaries are
present, source code to meet licensing requirements must also be provided in
some form.
</para>
</section>
<section id='bsp-filelayout-layer'>
<title>Layer Configuration (meta-bsp/conf/layer.conf)</title>
<para>
This file identifies the structure as a Poky layer. This file identifies the
contents of the layer and contains information about how Poky should use
it. In general it will most likely be a standard boilerplate file consisting of:
</para>
<para>
<programlisting>
# We have a conf directory, add to BBPATH
BBPATH := "${BBPATH}${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb"
BBFILE_COLLECTIONS += "bsp"
BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
BBFILE_PRIORITY_bsp = "5"
</programlisting>
</para>
<para>
which simply makes bitbake aware of the packages and conf directories.
</para>
<para>
This file is required for recognition of the BSP by Poky.
</para>
</section>
<section id='bsp-filelayout-machine'>
<title>Hardware Configuration Options (meta-bsp/conf/machine/*.conf)</title>
<para>
The machine files bind together all the information contained elsewhere
in the BSP into a format that Poky/OpenEmbedded can understand. If
the BSP supports multiple machines, multiple machine configuration files
can be present. These filenames correspond to the values users set the
MACHINE variable to.
</para>
<para>
These files would define things like which kernel package to use
(PREFERRED_PROVIDER of virtual/kernel), which hardware drivers to
include in different types of images, any special software components
that are needed, any bootloader information, and also any special image
format requirements.
</para>
<para>
At least one machine file is required for a Poky BSP layer but more than one may be present.
</para>
</section>
<section id='bsp-filelayout-tune'>
<title>Hardware Optimisation Options (meta-bsp/conf/machine/include/tune-*.inc)</title>
<para>
These are shared hardware "tuning" definitions and are commonly used to
pass specific optimisation flags to the compiler. An example is
tune-atom.inc:
</para>
<para>
<programlisting>
BASE_PACKAGE_ARCH = "core2"
TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse"
</programlisting>
</para>
<para>
which defines a new package architecture called "core2" and uses the
optimization flags specified, which are carefully chosen to give best
performance on atom cpus.
</para>
<para>
The tune file would be included by the machine definition and can be
contained in the BSP or reference one from the standard core set of
files included with Poky itself.
</para>
<para>
These files are optional for a Poky BSP layer.
</para>
</section>
<section id='bsp-filelayout-kernel'>
<title>Linux Kernel Configuration (meta-bsp/packages/linux/*)</title>
<para>
These files make up the definition of a kernel to use with this
hardware. In this case it is a complete self-contained kernel with its own
configuration and patches but kernels can be shared between many
machines as well. Taking some specific example files:
</para>
<para>
<programlisting>
meta-bsp/packages/linux/linux-bsp_2.6.50.bb
</programlisting>
</para>
<para>
which is the core kernel recipe which firstly details where to get the kernel
source from. All standard source code locations are supported so this could
be a release tarball, some git repository, or source included in
the directory within the BSP itself. It then contains information about which
patches to apply and how to configure and build it. It can reuse the main
Poky kernel build class, so the definitions here can remain very simple.
</para>
<para>
<programlisting>
linux-bsp-2.6.50/*.patch
</programlisting>
</para>
<para>
which are patches which may be applied against the base kernel, wherever
they may have been obtained from.
</para>
<para>
<programlisting>
meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
</programlisting>
</para>
<para>
which is the configuration information to use to configure the kernel.
</para>
<para>
Examples of kernel recipes are available in Poky itself. These files are
optional since a kernel from Poky itself could be selected, although it
would be unusual not to have a kernel configuration.
</para>
</section>
<section id='bsp-filelayout-packages'>
<title>Other Software (meta-bsp/packages/*)</title>
<para>
This area includes other pieces of software which the hardware may need for best
operation. These are just examples of the kind of things that may be
encountered. These are standard .bb file recipes in the usual Poky format,
so for examples, see standard Poky recipes. The source can be included directly,
referred to in source control systems or release tarballs of external software projects.
</para>
<para>
<programlisting>
meta-bsp/packages/bootloader/bootloader_0.1.bb
</programlisting>
</para>
<para>
Some kind of bootloader recipe which may be used to generate a new
bootloader binary. Sometimes these are included in the final image
format and needed to reflash hardware.
</para>
<para>
<programlisting>
meta-bsp/packages/modem/modem-driver_0.1.bb
meta-bsp/packages/modem/modem-daemon_0.1.bb
</programlisting>
</para>
<para>
These are examples of a hardware driver and also a hardware daemon which
may need to be included in images to make the hardware useful. "modem"
is one example but there may be other components needed like firmware.
</para>
<para>
<programlisting>
meta-bsp/packages/image-creator/image-creator-native_0.1.bb
</programlisting>
</para>
<para>
Sometimes the device will need an image in a very specific format for
its update mechanism to accept and reflash with it. Recipes to build the
tools needed to do this can be included with the BSP.
</para>
<para>
These files only need be provided if the platform requires them.
</para>
</section>
<section id='bs-filelayout-bbappend'>
<title>Append BSP specific information to existing recipes</title>
<para>
Say you have a recipe like pointercal which has machine-specific information in it,
and then you have your new BSP code in a layer. Before the .bbappend extension was
introduced, you'd have to copy the whole pointercal recipe and files into your layer,
and then add the single file for your machine, which is ugly.
.bbappend makes the above work much easier, to allow BSP-specific information to be merged
with the original recipe easily. When bitbake finds any X.bbappend files, they will be
included after bitbake loads X.bb but before finalise or anonymous methods run.
This allows the BSP layer to poke around and do whatever it might want to customise
the original recipe.
.bbappend is expected to include the below two lines in the head (which may be changed
in the future):
</para>
<programlisting>
THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
</programlisting>
<para>
Then the BSP could add machine-specific config files in layer directory, which will be
added by bitbake. You can look at meta-emenlow/packages/formfactor as an example.
</para>
</section>
<section id='bsp-filelayout-prebuilds'>
<title>Prebuild Data (meta-bsp/prebuilds/*)</title>
<para>
The location can contain a precompiled representation of the source code
contained elsewhere in the BSP layer. It can be processed and used by
Poky to provide much faster build times, assuming a compatible configuration is used.
</para>
<para>
These files are optional.
</para>
</section>
<section id='bsp-click-through-licensing'>
<title>BSP 'Click-through' Licensing Procedure</title>
<note><para> This section is here as a description of how
click-through licensing is expected to work, and is
not yet not impemented.
</para></note>
<para>
In some cases, a BSP may contain separately licensed IP
(Intellectual Property) for a component, which imposes
upon the user a requirement to accept the terms of a
'click-through' license. Once the license is accepted
(in whatever form that may be, see details below) the
Poky build system can then build and include the
corresponding component in the final BSP image. Some
affected components may be essential to the normal
functioning of the system and have no 'free' replacement
i.e. the resulting system would be non-functional
without them. Other components may be simply
'good-to-have' or purely elective, or if essential
nonetheless have a 'free' (possibly less-capable)
version which may substituted for in the BSP recipe.
</para>
<para>
For the latter cases, where it is possible to do so from
a functionality perspective, the Poky website will make
available a 'de-featured' BSP completely free of
encumbered IP, which can be used directly and without
any further licensing requirements. If present, this
fully 'de-featured' BSP will be named meta-bsp (i.e. the
normal default naming convention). This is the simplest
and therefore preferred option if available, assuming
the resulting functionality meets requirements.
</para>
<para>
If however, a non-encumbered version is unavailable or
the 'free' version would provide unsuitable
functionality or quality, an encumbered version can be
used. Encumbered versions of a BSP are given names of
the form meta-bsp-nonfree. There are several ways
within the Poky build system to satisfy the licensing
requirements for an encumbered BSP, in roughly the
following order of preference:
</para>
<itemizedlist>
<listitem>
<para>
Get a license key (or keys) for the encumbered BSP
by
visiting <ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink>
and give the web form there the name of the BSP
and your e-mail address.
</para>
<programlisting>
[screenshot of dialog box]
</programlisting>
<para>
After agreeing to any applicable license terms, the
BSP key(s) will be immediately sent to the address
given and can be used by specifying BSPKEY_&lt;keydomain&gt;
environment variables when building the image:
</para>
<programlisting>
$ BSPKEY_&lt;keydomain&gt;=&lt;key&gt; bitbake poky-image-sato
</programlisting>
<para>
This will allow the encumbered image to be built
with no change at all to the normal build process.
</para>
<para>
Equivalently and probably more conveniently, a line
for each key can instead be put into the user's
local.conf file.
</para>
<para>
The &lt;keydomain&gt; component of the
BSPKEY_&lt;keydomain&gt; is required because there
may be multiple licenses in effect for a give BSP; a
given &lt;keydomain&gt; in such cases corresponds to
a particular license. In order for an encumbered
BSP encompassing multiple key domains to be built
successfully, a &lt;keydomain&gt; entry for each
applicable license must be present in local.conf or
supplied on the command-line.
</para>
</listitem>
<listitem>
<para>
Do nothing - build as you normally would, and follow
any license prompts that originate from the
encumbered BSP (the build will cleanly stop at this
point). These usually take the form of instructions
needed to manually fetch the encumbered package(s)
and md5 sums into e.g. the poky/build/downloads
directory. Once the manual package fetch has been
completed, restarting the build will continue where
it left off, this time without the prompt since the
license requirements will have been satisfied.
</para>
</listitem>
<listitem>
<para>
Get a full-featured BSP recipe rather than a key, by
visiting
<ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
Accepting the license agreement(s) presented will
subsequently allow you to download a tarball
containing a full-featured BSP legally cleared for
your use by the just-given license agreement(s).
This method will also allow the encumbered image to
be built with no change at all to the normal build
process.
</para>
</listitem>
</itemizedlist>
<para>
Note that method 3 is also the only option available
when downloading pre-compiled images generated from
non-free BSPs. Those images are likewise available at
<ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
</para>
</section>
</chapter>
documentation/poky-ref-manual/development.xml
+825
View File
@@ -0,0 +1,825 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id="platdev">
<title>Platform Development with Poky</title>
<section id="platdev-appdev">
<title>Software development</title>
<para>
Poky supports several methods of software development. These different
forms of development are explained below and can be switched
between as needed.
</para>
<section id="platdev-appdev-external-sdk">
<title>Developing externally using the Poky SDK</title>
<para>
The meta-toolchain and meta-toolchain-sdk targets (<link linkend='ref-images'>see
the images section</link>) build tarballs which contain toolchains and
libraries suitable for application development outside Poky. These unpack into the
<filename class="directory">/opt/poky</filename> directory and contain
a setup script, e.g.
<filename>/opt/poky/environment-setup-i586-poky-linux</filename> which
can be sourced to initialise a suitable environment. After sourcing this, the
compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other
useful utilities are added to the PATH. Variables to assist pkgconfig and
autotools are also set so that, for example, configure can find pre-generated test
results for tests which need target hardware to run.
</para>
<para>
Using the toolchain with autotool enabled packages is straightforward, just pass the
appropriate host option to configure e.g. "./configure --host=arm-poky-linux-gnueabi".
For other projects it is usually a case of ensuring the cross tools are used e.g.
CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld.
</para>
</section>
<section id="platdev-appdev-external-anjuta">
<title>Developing externally using the Anjuta plugin</title>
<para>
An Anjuta IDE plugin exists to make developing software within the Poky framework
easier for the application developer. It presents a graphical IDE from which the
developer can cross compile an application then deploy and execute the output in a QEMU
emulation session. It also supports cross debugging and profiling.
</para>
<!-- DISBALED, TOO BIG!
<screenshot>
<mediaobject>
<imageobject>
<imagedata fileref="screenshots/ss-anjuta-poky-1.png" format="PNG"/>
</imageobject>
<caption>
<para>The Anjuta Poky SDK plugin showing an active QEMU session running Sato</para>
</caption>
</mediaobject>
</screenshot>
-->
<para>
To use the plugin, a toolchain and SDK built by Poky is required along with Anjuta it's development
headers and the Anjuta plugin. The Poky Anjuta plugin is available to download as a tarball at the
<ulink url='http://labs.o-hand.com/anjuta-poky-sdk-plugin/'>OpenedHand labs</ulink> page or
directly from the Poky Git repository located at git://git.pokylinux.org/anjuta-poky; a web interface
to the repository can be accessed at <ulink url='http://git.pokylinux.org/?p=anjuta-poky.git;a=summary'/>.
</para>
<para>
See the README file contained in the project for more information on dependencies and building
the plugin. If you want to disable remote gdb debugging, please pass --diable-gdb-integration
switch when doing configure.
</para>
<section id="platdev-appdev-external-anjuta-setup">
<title>Setting up the Anjuta plugin</title>
<para>Extract the tarball for the toolchain into / as root. The
toolchain will be installed into
<filename class="directory">/opt/poky</filename>.</para>
<para>To use the plugin, first open or create an existing
project. If creating a new project the "C GTK+" project type
will allow itself to be cross-compiled. However you should be
aware that this uses glade for the UI.</para>
<para>To activate the plugin go to
<menuchoice><guimenu>Edit</guimenu><guimenuitem>Preferences</guimenuitem></menuchoice>,
then choose <guilabel>General</guilabel> from the left hand side. Choose the
Installed plugins tab, scroll down to <guilabel>Poky
SDK</guilabel> and check the
box. The plugin is now activated but first it must be
configured.</para>
</section>
<section id="platdev-appdev-external-anjuta-configuration">
<title>Configuring the Anjuta plugin</title>
<para>The configuration options for the SDK can be found by choosing
the <guilabel>Poky SDK</guilabel> icon from the left hand side. The following options
need to be set:</para>
<itemizedlist>
<listitem><para><guilabel>SDK root</guilabel>: If we use external toolchain, we need to set SDK root.
this is the root directory of the SDK's sysroot. For an i586 SDK this will be <filename
class="directory">/opt/poky/</filename>.
This directory will contain directories named like "bin",
"include", "var", etc. under your selected target architecture subdirectory<filename class="directory">
/opt/poky/sysroot/i586-poky-linux/</filename>. Needed cross compile tools are under
<filename class ="directory">/opt/poky/sysroot/i586-pokysdk-linux/</filename>
</para></listitem>
<listitem><para><guilabel>Poky root</guilabel>: If we have local poky build tree, we need to set the Poky root.
this is the root directory of the poky build tree, if you build your i586 target architecture
under the subdirectory of build_x86 within your poky tree, the Poky root directory should be
<filename class="directory">${Poky_tree}/build_x86/</filename>.
</para></listitem>
<listitem><para><guilabel>Target Architecture</guilabel>: this is the cross compile
triplet, e.g. "i586-poky-linux". This target triplet is the prefix extracted from
the set up script file name. For examle, "i586-poky-linux" is extracted from set up script file
<filename>/opt/poky/environment-setup-i586-poky-linux</filename>
</para></listitem>
<listitem><para><guilabel>Kernel</guilabel>: use the file chooser to select the kernel
to use with QEMU</para></listitem>
<listitem><para><guilabel>Root filesystem</guilabel>: use the file chooser to select
the root filesystem directory, this is the directory where you use "poky-extract-sdk" command to
extract the poky-image-sdk tarball.</para></listitem>
</itemizedlist>
<!-- DISBALED, TOO BIG!
<screenshot>
<mediaobject>
<imageobject>
<imagedata fileref="screenshots/ss-anjuta-poky-2.png" format="PNG"/>
</imageobject>
<caption>
<para>Anjuta Preferences Dialog</para>
</caption>
</mediaobject>
</screenshot>
-->
</section>
<section id="platdev-appdev-external-anjuta-usage">
<title>Using the Anjuta plugin</title>
<para>As an example, cross-compiling a project, deploying it into
QEMU and running a debugger against it and then doing a system
wide profile.</para>
<para>Choose <menuchoice><guimenu>Build</guimenu><guimenuitem>Run
Configure</guimenuitem></menuchoice> or
<menuchoice><guimenu>Build</guimenu><guimenuitem>Run
Autogenerate</guimenuitem></menuchoice> to run "configure"
(or to run "autogen") for the project. This passes command line
arguments to instruct it to cross-compile.</para>
<para>Next do
<menuchoice><guimenu>Build</guimenu><guimenuitem>Build
Project</guimenuitem></menuchoice> to build and compile the
project. If you have previously built the project in the same
tree without using the cross-compiler you may find that your
project fails to link. Simply do
<menuchoice><guimenu>Build</guimenu><guimenuitem>Clean
Project</guimenuitem></menuchoice> to remove the old
binaries. You may then try building again.</para>
<para>Next start QEMU by using
<menuchoice><guimenu>Tools</guimenu><guimenuitem>Start
QEMU</guimenuitem></menuchoice>, this will start QEMU and
will show any error messages in the message view. Once Poky has
fully booted within QEMU you may now deploy into it.</para>
<para>Once built and QEMU is running, choose
<menuchoice><guimenu>Tools</guimenu><guimenuitem>Deploy</guimenuitem></menuchoice>,
this will install the package into a temporary directory and
then copy using rsync over SSH into the target. Progress and
messages will be shown in the message view.</para>
<para>To debug a program installed into onto the target choose
<menuchoice><guimenu>Tools</guimenu><guimenuitem>Debug
remote</guimenuitem></menuchoice>. This prompts for the
local binary to debug and also the command line to run on the
target. The command line to run should include the full path to
the to binary installed in the target. This will start a
gdbserver over SSH on the target and also an instance of a
cross-gdb in a local terminal. This will be preloaded to connect
to the server and use the <guilabel>SDK root</guilabel> to find
symbols. This gdb will connect to the target and load in
various libraries and the target program. You should setup any
breakpoints or watchpoints now since you might not be able to
interrupt the execution later. You may stop
the debugger on the target using
<menuchoice><guimenu>Tools</guimenu><guimenuitem>Stop
debugger</guimenuitem></menuchoice>.</para>
<para>It is also possible to execute a command in the target over
SSH, the appropriate environment will be be set for the
execution. Choose
<menuchoice><guimenu>Tools</guimenu><guimenuitem>Run
remote</guimenuitem></menuchoice> to do this. This will open
a terminal with the SSH command inside.</para>
<para>To do a system wide profile against the system running in
QEMU choose
<menuchoice><guimenu>Tools</guimenu><guimenuitem>Profile
remote</guimenuitem></menuchoice>. This will start up
OProfileUI with the appropriate parameters to connect to the
server running inside QEMU and will also supply the path to the
debug information necessary to get a useful profile.</para>
</section>
</section>
<section id="platdev-appdev-qemu">
<title>Developing externally in QEMU</title>
<para>
Running Poky QEMU images is covered in the <link
linkend='intro-quickstart-qemu'>Running an Image</link> section.
</para>
<para>
Poky's QEMU images contain a complete native toolchain. This means
that applications can be developed within QEMU in the same was as a
normal system. Using qemux86 on an x86 machine is fast since the
guest and host architectures match, qemuarm is slower but gives
faithful emulation of ARM specific issues. To speed things up these
images support using distcc to call a cross-compiler outside the
emulated system too. If <command>runqemu</command> was used to start
QEMU, and distccd is present on the host system, any bitbake cross
compiling toolchain available from the build system will automatically
be used from within qemu simply by calling distcc
(<command>export CC="distcc"</command> can be set in the enviroment).
Alterntatively, if a suitable SDK/toolchain is present in
<filename class="directory">/opt/poky</filename> it will also
automatically be used.
</para>
<para>
There are several options for connecting into the emulated system.
QEMU provides a framebuffer interface which has standard consoles
available. There is also a serial connection available which has a
console to the system running on it and IP networking as standard.
The images have a dropbear ssh server running with the root password
disabled allowing standard ssh and scp commands to work. The images
also contain an NFS server exporting the guest's root filesystem
allowing that to be made available to the host.
</para>
</section>
<section id="platdev-appdev-insitu">
<title>Developing in Poky directly</title>
<para>
Working directly in Poky is a fast and effective development technique.
The idea is that you can directly edit files in
<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>
or the source directory <glossterm><link linkend='var-S'>S</link></glossterm>
and then force specific tasks to rerun in order to test the changes.
An example session working on the matchbox-desktop package might
look like this:
</para>
<para>
<literallayout class='monospaced'>
$ bitbake matchbox-desktop
$ sh
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
$ cd matchbox-desktop-2
$ vi src/main.c
$ exit
$ bitbake matchbox-desktop -c compile -f
$ bitbake matchbox-desktop
</literallayout>
</para>
<para>
Here, we build the package, change into the work directory for the package,
change a file, then recompile the package. Instead of using sh like this,
you can also use two different terminals. The risk with working like this
is that a command like unpack could wipe out the changes you've made to the
work directory so you need to work carefully.
</para>
<para>
It is useful when making changes directly to the work directory files to do
so using quilt as detailed in the <link linkend='usingpoky-modifying-packages-quilt'>
modifying packages with quilt</link> section. The resulting patches can be copied
into the recipe directory and used directly in the <glossterm><link
linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
</para>
<para>
For a review of the skills used in this section see Sections <link
linkend="usingpoky-components-bitbake">2.1.1</link> and <link
linkend="usingpoky-debugging-taskrunning">2.4.2</link>.
</para>
</section>
<section id="platdev-appdev-devshell">
<title>Developing with 'devshell'</title>
<para>
When debugging certain commands or even to just edit packages, the
'devshell' can be a useful tool. To start it you run a command like:
</para>
<para>
<literallayout class='monospaced'>
$ bitbake matchbox-desktop -c devshell
</literallayout>
</para>
<para>
which will open a terminal with a shell prompt within the Poky
environment. This means PATH is setup to include the cross toolchain,
the pkgconfig variables are setup to find the right .pc files,
configure will be able to find the Poky site files etc. Within this
environment, you can run configure or compile command as if they
were being run by Poky itself. You are also changed into the
source (<glossterm><link linkend='var-S'>S</link></glossterm>)
directory automatically. When finished with the shell just exit it
or close the terminal window.
</para>
<para>
The default shell used by devshell is the gnome-terminal. Other
forms of terminal can also be used by setting the <glossterm>
<link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and <glossterm>
<link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables
in local.conf. For examples of the other options available, see
<filename>meta/conf/bitbake.conf</filename>. An external shell is
launched rather than opening directly into the original terminal
window to make interaction with bitbakes multiple threads easier
and also allow a client/server split of bitbake in the future
(devshell will still work over X11 forwarding or similar).
</para>
<para>
It is worth remembering that inside devshell you need to use the full
compiler name such as <command>arm-poky-linux-gnueabi-gcc</command>
instead of just <command>gcc</command> and the same applies to other
applications from gcc, bintuils, libtool etc. Poky will have setup
environmental variables such as CC to assist applications, such as make,
find the correct tools.
</para>
</section>
<section id="platdev-appdev-srcrev">
<title>Developing within Poky with an external SCM based package</title>
<para>
If you're working on a recipe which pulls from an external SCM it
is possible to have Poky notice new changes added to the
SCM and then build the latest version. This only works for SCMs
where its possible to get a sensible revision number for changes.
Currently it works for svn, git and bzr repositories.
</para>
<para>
To enable this behaviour it is simply a case of adding <glossterm>
<link linkend='var-SRCREV'>SRCREV</link></glossterm>_pn-<glossterm>
<link linkend='var-PN'>PN</link></glossterm> = "${AUTOREV}" to
local.conf where <glossterm><link linkend='var-PN'>PN</link></glossterm>
is the name of the package for which you want to enable automatic source
revision updating.
</para>
</section>
</section>
<section id="platdev-gdb-remotedebug">
<title>Debugging with GDB Remotely</title>
<para>
<ulink url="http://sourceware.org/gdb/">GDB</ulink> (The GNU Project Debugger)
allows you to examine running programs to understand and fix problems and
also to perform postmortem style analsys of program crashes. It is available
as a package within poky and installed by default in sdk images. It works best
when -dbg packages for the application being debugged are installed as the
extra symbols give more meaningful output from GDB.
</para>
<para>
Sometimes, due to memory or disk space constraints, it is not possible
to use GDB directly on the remote target to debug applications. This is
due to the fact that
GDB needs to load the debugging information and the binaries of the
process being debugged. GDB then needs to perform many
computations to locate information such as function names, variable
names and values, stack traces, etc. even before starting the debugging
process. This places load on the target system and can alter the
characteristics of the program being debugged.
</para>
<para>
This is where GDBSERVER comes into play as it runs on the remote target
and does not load any debugging information from the debugged process.
Instead, the debugging information processing is done by a GDB instance
running on a distant computer - the host GDB. The host GDB then sends
control commands to GDBSERVER to make it stop or start the debugged
program, as well as read or write some memory regions of that debugged
program. All the debugging information loading and processing as well
as the heavy debugging duty is done by the host GDB, giving the
GDBSERVER running on the target a chance to remain small and fast.
</para>
<para>
As the host GDB is responsible for loading the debugging information and
doing the necessary processing to make actual debugging happen, the
user has to make sure it can access the unstripped binaries complete
with their debugging information and compiled with no optimisations. The
host GDB must also have local access to all the libraries used by the
debugged program. On the remote target the binaries can remain stripped
as GDBSERVER does not need any debugging information there. However they
must also be compiled without optimisation matching the host's binaries.
</para>
<para>
The binary being debugged on the remote target machine is hence referred
to as the 'inferior' in keeping with GDB documentation and terminology.
Further documentation on GDB, is available on
<ulink url="http://sourceware.org/gdb/documentation/">on their site</ulink>.
</para>
<section id="platdev-gdb-remotedebug-launch-gdbserver">
<title>Launching GDBSERVER on the target</title>
<para>
First, make sure gdbserver is installed on the target. If not,
install the gdbserver package (which needs the libthread-db1
package).
</para>
<para>
To launch GDBSERVER on the target and make it ready to "debug" a
program located at <emphasis>/path/to/inferior</emphasis>, connect
to the target and launch:
<programlisting>$ gdbserver localhost:2345 /path/to/inferior</programlisting>
After that, gdbserver should be listening on port 2345 for debugging
commands coming from a remote GDB process running on the host computer.
Communication between the GDBSERVER and the host GDB will be done using
TCP. To use other communication protocols please refer to the
GDBSERVER documentation.
</para>
</section>
<section id="platdev-gdb-remotedebug-launch-gdb">
<title>Launching GDB on the host computer</title>
<para>
Running GDB on the host computer takes a number of stages, described in the
following sections.
</para>
<section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
<title>Build the cross GDB package</title>
<para>
A suitable gdb cross binary is required which runs on your host computer but
knows about the the ABI of the remote target. This can be obtained from
the the Poky toolchain, e.g.
<filename>/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb</filename>
which "x86_64" is the host architecture, "arm" is the target architecture and "linux-gnueabi" the target ABI.
</para>
<para>
Alternatively this can be built directly by Poky. To do this you would build
the gdb-cross package so for example you would run:
<programlisting>bitbake gdb-cross</programlisting>
Once built, the cross gdb binary can be found at
<programlisting>tmp/sysroots/&lt;host-arch&gt;/usr/bin/\
&lt;target-arch&gt;-poky-&lt;target-abi&gt;/&lt;target-arch&gt;-poky-&lt;target-abi&gt;-gdb </programlisting>
</para>
</section>
<section id="platdev-gdb-remotedebug-launch-gdb-inferiorbins">
<title>Making the inferior binaries available</title>
<para>
The inferior binary needs to be available to GDB complete with all debugging
symbols in order to get the best possible results along with any libraries
the inferior depends on and their debugging symbols. There are a number of
ways this can be done.
</para>
<para>
Perhaps the easiest is to have an 'sdk' image corresponding to the plain
image installed on the device. In the case of 'pky-image-sato',
'poky-image-sdk' would contain suitable symbols. The sdk images already
have the debugging symbols installed so its just a question expanding the
archive to some location and telling GDB where this is.
</para>
<para>
Alternatively, poky can build a custom directory of files for a specific
debugging purpose by reusing its tmp/rootfs directory, on the host computer
in a slightly different way to normal. This directory contains the contents
of the last built image. This process assumes the image running on the
target was the last image to be built by Poky, the package <emphasis>foo</emphasis>
contains the inferior binary to be debugged has been built without without
optimisation and has debugging information available.
</para>
<para>
Firstly you want to install the <emphasis>foo</emphasis> package to tmp/rootfs
by doing:
</para>
<programlisting>tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf -o \
tmp/rootfs/ update</programlisting>
<para>
then,
</para>
<programlisting>tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf \
-o tmp/rootfs install foo
tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
tmp/work/&lt;target-abi&gt;/poky-image-sato-1.0-r0/opkg.conf \
-o tmp/rootfs install foo-dbg</programlisting>
<para>
which installs the debugging information too.
</para>
</section>
<section id="platdev-gdb-remotedebug-launch-gdb-launchhost">
<title>Launch the host GDB</title>
<para>
To launch the host GDB, run the cross gdb binary identified above with
the inferior binary specified on the commandline:
<programlisting>&lt;target-arch&gt;-poky-&lt;target-abi&gt;-gdb rootfs/usr/bin/foo</programlisting>
This loads the binary of program <emphasis>foo</emphasis>
as well as its debugging information. Once the gdb prompt
appears, you must instruct GDB to load all the libraries
of the inferior from tmp/rootfs:
<programlisting>set solib-absolute-prefix /path/to/tmp/rootfs</programlisting>
where <filename>/path/to/tmp/rootfs</filename> must be
the absolute path to <filename>tmp/rootfs</filename> or wherever the
binaries with debugging information are located.
</para>
<para>
Now, tell GDB to connect to the GDBSERVER running on the remote target:
<programlisting>target remote remote-target-ip-address:2345</programlisting>
Where remote-target-ip-address is the IP address of the
remote target where the GDBSERVER is running. 2345 is the
port on which the GDBSERVER is running.
</para>
</section>
<section id="platdev-gdb-remotedebug-launch-gdb-using">
<title>Using the Debugger</title>
<para>
Debugging can now proceed as normal, as if the debugging were being done on the
local machine, for example to tell GDB to break in the <emphasis>main</emphasis>
function, for instance:
<programlisting>break main</programlisting>
and then to tell GDB to "continue" the inferior execution,
<programlisting>continue</programlisting>
</para>
<para>
For more information about using GDB please see the
project's online documentation at <ulink
url="http://sourceware.org/gdb/download/onlinedocs/"/>.
</para>
</section>
</section>
</section>
<section id="platdev-oprofile">
<title>Profiling with OProfile</title>
<para>
<ulink url="http://oprofile.sourceforge.net/">OProfile</ulink> is a
statistical profiler well suited to finding performance
bottlenecks in both userspace software and the kernel. It provides
answers to questions like "Which functions does my application spend
the most time in when doing X?". Poky is well integrated with OProfile
to make profiling applications on target hardware straightforward.
</para>
<para>
To use OProfile you need an image with OProfile installed. The easiest
way to do this is with "tools-profile" in <glossterm><link
linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>. You also
need debugging symbols to be available on the system where the analysis
will take place. This can be achieved with "dbg-pkgs" in <glossterm><link
linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> or by
installing the appropriate -dbg packages. For
successful call graph analysis the binaries must preserve the frame
pointer register and hence should be compiled with the
"-fno-omit-framepointer" flag. In Poky this can be achieved with
<glossterm><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION
</link></glossterm> = "-fexpensive-optimizations -fno-omit-framepointer
-frename-registers -O2" or by setting <glossterm><link
linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></glossterm> = "1" in
local.conf (the latter will also add extra debug information making the
debug packages large).
</para>
<section id="platdev-oprofile-target">
<title>Profiling on the target</title>
<para>
All the profiling work can be performed on the target device. A
simple OProfile session might look like:
</para>
<para>
<literallayout class='monospaced'>
# opcontrol --reset
# opcontrol --start --separate=lib --no-vmlinux -c 5
[do whatever is being profiled]
# opcontrol --stop
$ opreport -cl
</literallayout>
</para>
<para>
Here, the reset command clears any previously profiled data,
OProfile is then started. The options used to start OProfile mean
dynamic library data is kept separately per application, kernel
profiling is disabled and callgraphing is enabled up to 5 levels
deep. To profile the kernel, you would specify the
<parameter>--vmlinux=/path/to/vmlinux</parameter> option (the vmlinux file is usually in
<filename class="directory">/boot/</filename> in Poky and must match the running kernel). The profile is
then stopped and the results viewed with opreport with options
to see the separate library symbols and callgraph information.
</para>
<para>
Callgraphing means OProfile not only logs infomation about which
functions time is being spent in but also which functions
called those functions (their parents) and which functions that
function calls (its children). The higher the callgraphing depth,
the more accurate the results but this also increased the loging
overhead so it should be used with caution. On ARM, binaries need
to have the frame pointer enabled for callgraphing to work (compile
with the gcc option -fno-omit-framepointer).
</para>
<para>
For more information on using OProfile please see the OProfile
online documentation at <ulink
url="http://oprofile.sourceforge.net/docs/"/>.
</para>
</section>
<section id="platdev-oprofile-oprofileui">
<title>Using OProfileUI</title>
<para>
A graphical user interface for OProfile is also available. You can
either use prebuilt Debian packages from the <ulink
url='http://debian.o-hand.com/'>OpenedHand repository</ulink> or
download and build from svn at
http://svn.o-hand.com/repos/oprofileui/trunk/. If the
"tools-profile" image feature is selected, all necessary binaries
are installed onto the target device for OProfileUI interaction.
</para>
<!-- DISBALED, Need a more 'contexual' shot?
<screenshot>
<mediaobject>
<imageobject>
<imagedata fileref="screenshots/ss-oprofile-viewer.png" format="PNG"/>
</imageobject>
<caption>
<para>OProfileUI Viewer showing an application being profiled on a remote device</para>
</caption>
</mediaobject>
</screenshot>
-->
<para>
In order to convert the data in the sample format from the target
to the host the <filename>opimport</filename> program is needed.
This is not included in standard Debian OProfile packages but an
OProfile package with this addition is also available from the <ulink
url='http://debian.o-hand.com/'>OpenedHand repository</ulink>.
We recommend using OProfile 0.9.3 or greater. Other patches to
OProfile may be needed for recent OProfileUI features, but Poky
usually includes all needed patches on the target device. Please
see the <ulink
url='http://svn.o-hand.com/repos/oprofileui/trunk/README'>
OProfileUI README</ulink> for up to date information, and the
<ulink url="http://labs.o-hand.com/oprofileui">OProfileUI website
</ulink> for more information on the OProfileUI project.
</para>
<section id="platdev-oprofile-oprofileui-online">
<title>Online mode</title>
<para>
This assumes a working network connection with the target
hardware. In this case you just need to run <command>
"oprofile-server"</command> on the device. By default it listens
on port 4224. This can be changed with the <parameter>--port</parameter> command line
option.
</para>
<para>
The client program is called <command>oprofile-viewer</command>. The
UI is relatively straightforward, the key functionality is accessed
through the buttons on the toolbar (which are duplicated in the
menus.) These buttons are:
</para>
<itemizedlist>
<listitem>
<para>
Connect - connect to the remote host, the IP address or hostname for the
target can be supplied here.
</para>
</listitem>
<listitem>
<para>
Disconnect - disconnect from the target.
</para>
</listitem>
<listitem>
<para>
Start - start the profiling on the device.
</para>
</listitem>
<listitem>
<para>
Stop - stop the profiling on the device and download the data to the local
host. This will generate the profile and show it in the viewer.
</para>
</listitem>
<listitem>
<para>
Download - download the data from the target, generate the profile and show it
in the viewer.
</para>
</listitem>
<listitem>
<para>
Reset - reset the sample data on the device. This will remove the sample
information that was collected on a previous sampling run. Ensure you do this
if you do not want to include old sample information.
</para>
</listitem>
<listitem>
<para>
Save - save the data downloaded from the target to another directory for later
examination.
</para>
</listitem>
<listitem>
<para>
Open - load data that was previously saved.
</para>
</listitem>
</itemizedlist>
<para>
The behaviour of the client is to download the complete 'profile archive' from
the target to the host for processing. This archive is a directory containing
the sample data, the object files and the debug information for said object
files. This archive is then converted using a script included in this
distribution ('oparchconv') that uses 'opimport' to convert the archive from
the target to something that can be processed on the host.
</para>
<para>
Downloaded archives are kept in /tmp and cleared up when they are no longer in
use.
</para>
<para>
If you wish to profile into the kernel, this is possible, you just need to ensure
a vmlinux file matching the running kernel is available. In Poky this is usually
located in /boot/vmlinux-KERNELVERSION, where KERNEL-version is the version of
the kernel e.g. 2.6.23. Poky generates separate vmlinux packages for each kernel
it builds so it should be a question of just ensuring a matching package is
installed (<command> opkg install kernel-vmlinux</command>. These are automatically
installed into development and profiling images alongside OProfile. There is a
configuration option within the OProfileUI settings page where the location of
the vmlinux file can be entered.
</para>
<para>
Waiting for debug symbols to transfer from the device can be slow and it's not
always necessary to actually have them on device for OProfile use. All that is
needed is a copy of the filesystem with the debug symbols present on the viewer
system. The <link linkend='platdev-gdb-remotedebug-launch-gdb'>GDB remote debug
section</link> covers how to create such a directory with Poky and the location
of this directory can again be specified in the OProfileUI settings dialog. If
specified, it will be used where the file checksums match those on the system
being profiled.
</para>
</section>
<section id="platdev-oprofile-oprofileui-offline">
<title>Offline mode</title>
<para>
If no network access to the target is available an archive for processing in
'oprofile-viewer' can be generated with the following set of command.
</para>
<para>
<literallayout class='monospaced'>
# opcontrol --reset
# opcontrol --start --separate=lib --no-vmlinux -c 5
[do whatever is being profiled]
# opcontrol --stop
# oparchive -o my_archive
</literallayout>
</para>
<para>
Where my_archive is the name of the archive directory where you would like the
profile archive to be kept. The directory will be created for you. This can
then be copied to another host and loaded using 'oprofile-viewer''s open
functionality. The archive will be converted if necessary.
</para>
</section>
</section>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/examples/hello-autotools/hello_2.3.bb
+7
View File
@@ -0,0 +1,7 @@
DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2"
inherit autotools
documentation/poky-ref-manual/examples/hello-single/files/helloworld.c
+8
View File
@@ -0,0 +1,8 @@
#include <stdio.h>
int main(void)
{
printf("Hello world!\n");
return 0;
}
documentation/poky-ref-manual/examples/hello-single/hello.bb
+16
View File
@@ -0,0 +1,16 @@
DESCRIPTION = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
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}
}
documentation/poky-ref-manual/examples/libxpm/libxpm_3.5.6.bb
+13
View File
@@ -0,0 +1,13 @@
require xorg-lib-common.inc
DESCRIPTION = "X11 Pixmap library"
LICENSE = "X-BSD"
DEPENDS += "libxext"
PR = "r2"
PE = "1"
XORG_PN = "libXpm"
PACKAGES =+ "sxpm cxpm"
FILES_cxpm = "${bindir}/cxpm"
FILES_sxpm = "${bindir}/sxpm"
documentation/poky-ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb
+13
View File
@@ -0,0 +1,13 @@
DESCRIPTION = "Tools for managing memory technology devices."
SECTION = "base"
DEPENDS = "zlib"
HOMEPAGE = "http://www.linux-mtd.infradead.org/"
LICENSE = "GPLv2"
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}
}
documentation/poky-ref-manual/extendpoky.xml
+1040
View File
File diff suppressed because it is too large Load Diff
documentation/poky-ref-manual/faq.xml
+314
View File
@@ -0,0 +1,314 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='faq'>
<title>FAQ</title>
<qandaset>
<qandaentry>
<question>
<para>
How does Poky differ from <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>?
</para>
</question>
<answer>
<para>
Poky is a derivative of <ulink
url='http://www.openembedded.org/'>OpenEmbedded</ulink>, a stable,
smaller subset focused on the GNOME Mobile environment. Development
in Poky is closely tied to OpenEmbedded with features being merged
regularly between the two for mutual benefit.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How can you claim Poky is stable?
</para>
</question>
<answer>
<para>
There are three areas that help with stability;
<itemizedlist>
<listitem>
<para>
We keep Poky small and focused - around 650 packages compared to over 5000 for full OE
</para>
</listitem>
<listitem>
<para>
We only support hardware that we have access to for testing
</para>
</listitem>
<listitem>
<para>
We have 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 Poky?
</para>
</question>
<answer>
<para>
There are two main ways to get a board supported in Poky;
<itemizedlist>
<listitem>
<para>
Send us the board if we don't have it yet
</para>
</listitem>
<listitem>
<para>
Send us bitbake recipes if you have them (see the Poky handbook to find out how to create recipes)
</para>
</listitem>
</itemizedlist>
Usually if it's not a completely exotic board then adding support in Poky should be fairly straightforward.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Are there any products running poky ?
</para>
</question>
<answer>
<para>
The <ulink url='http://vernier.com/labquest/'>Vernier Labquest</ulink> is using Poky (for more about the Labquest see the case study at OpenedHand). There are a number of pre-production devices using Poky and we will announce those as soon as they are released.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What is the Poky output ?
</para>
</question>
<answer>
<para>
The output of a Poky build will depend on how it was started, as the same set of recipes can be used to output various formats. 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 Poky?
</para>
</question>
<answer>
<para>
To add a package you need to create a bitbake recipe - see the Poky handbook to find out how to create a recipe.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Do I have to reflash my entire board with a new poky image when recompiling a package?
</para>
</question>
<answer>
<para>
Poky can build packages in various formats, ipk (for ipkg/opkg), Debian package (.deb), or RPM. The packages can then be upgraded using the package tools on the device, much like on a desktop distribution like Ubuntu or Fedora.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What is GNOME Mobile? What's the difference between GNOME Mobile and GNOME?
</para>
</question>
<answer>
<para>
<ulink url='http://www.gnome.org/mobile/'>GNOME Mobile</ulink> is a subset of the GNOME 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 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'. What's wrong?
</para>
</question>
<answer>
<para>
You're probably running the build on an NTFS filesystem. Use a sane one like ext2/3/4 instead!
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I make Poky work in RHEL/CentOS?
</para>
</question>
<answer>
<para>
To get Poky 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>
texi2html
</para>
</listitem>
<listitem>
<para>
compat-gcc-34
</para>
</listitem>
</itemizedlist>
</para>
<para>
On top of those the following external packages are needed:
<itemizedlist>
<listitem>
<para>
python-sqlite2 from <ulink
url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG
repository</ulink>
</para>
</listitem>
<listitem>
<para>
help2man from <ulink
url='http://centos.karan.org/el5/extras/testing/i386/RPMS/help2man-1.33.1-2.noarch.rpm'>Karan
repository</ulink>
</para>
</listitem>
</itemizedlist>
</para>
<para>
Once these packages are installed Poky will be able to build standard images however there
may be a problem with QEMU segfaulting. You can either disable the generation of binary
locales by setting <glossterm><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
</glossterm> to "0" or remove the linux-2.6-execshield.patch from the kernel and rebuild
it since its that patch which causes the problems with QEMU.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
I see lots of 404 responses for files on http://pokylinux.org/sources/*. Is something wrong?
</para>
</question>
<answer>
<para>
Nothing is wrong, Poky will check any configured source mirrors before downloading
from the upstream sources. It does this searching for both source archives and
pre-checked out versions of SCM managed software. This is so in large installations,
it can reduce load on the SCM servers themselves. The address above is one of the
default mirrors configured into standard Poky so if an upstream source disappears,
we can place sources there so builds continue to work.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
I have a 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 stop it?
</para>
</question>
<answer>
<para>
Set <glossterm><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
</glossterm> = "0" in the .bb file but make sure the package is manually marked as
machine specific in the case that needs it. The code which handles <glossterm><link
linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link></glossterm>
is in base.bbclass.
</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 Poky is done by wget and you therefore need to specify the proxy
settings in a .wgetrc file in your home directory. Example settings in that file would be
'http_proxy = http://proxy.yoyodyne.com:18023/' and 'ftp_proxy = http://proxy.yoyodyne.com:18023/'.
Poky also includes a site.conf.sample file which shows how to configure cvs and git proxy servers
if needed.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
I'm using Ubuntu Intrepid and am seeing build failures. Whats wrong?
</para>
</question>
<answer>
<para>
In Intrepid, Ubuntu turned on by default normally optional compile-time security features
and warnings. There are more details at <ulink
url='https://wiki.ubuntu.com/CompilerFlags'>https://wiki.ubuntu.com/CompilerFlags</ulink>.
You can work around this problem by disabling those options by adding " -Wno-format-security -U_FORTIFY_SOURCE"
to the BUILD_CPPFLAGS variable in conf/bitbake.conf.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Whats the difference between foo and foo-native?
</para>
</question>
<answer>
<para>
The *-native targets are designed to run on the system the build is running on. These are usually tools that are needed to assist the build in some way such as quilt-native which is used to apply patches. The non-native version is the one that would run 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 explaination is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is senstive to even single bit failure in any of these areas. Totally 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 licence complience?
</para>
</question>
<answer>
<para>
This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL complience there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built.
</para>
</answer>
</qandaentry>
</qandaset>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/introduction.xml
+352
View File
@@ -0,0 +1,352 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id='intro'>
<title>Introduction</title>
<section id='intro-what-is'>
<title>What is Poky?</title>
<para>
Poky is an open source platform build tool. It is a complete
software development environment for the creation of Linux
devices. It aids the design, development, building, debugging,
simulation and testing of complete modern software stacks
using Linux, the X Window System and GNOME Mobile
based application frameworks. It is based on <ulink
url='http://openembedded.org/'>OpenEmbedded</ulink> but has
been customised with a particular focus.
</para>
<para> Poky was setup to:</para>
<itemizedlist>
<listitem>
<para>Provide an open source Linux, X11, Matchbox, GTK+, Pimlico, Clutter, and other <ulink url='http://gnome.org/mobile'>GNOME Mobile</ulink> technologies based full platform build and development tool.</para>
</listitem>
<listitem>
<para>Create a focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon.</para>
</listitem>
<listitem>
<para>Fully support a wide range of x86, ARM, MIPS, PowerPC hardware and device virtulisation</para>
</listitem>
</itemizedlist>
<para>
Poky is primarily a platform builder which generates filesystem images
based on open source software such as the Kdrive X server, the Matchbox
window manager, the GTK+ toolkit and the D-Bus message bus system. Images
for many kinds of devices can be generated, however the standard example
machines target QEMU full system emulation(x86, ARM, MIPS and PowerPC) and the ARM based
Sharp Zaurus series of devices. Poky's ability to boot inside a QEMU
emulator makes it particularly suitable as a test platform for development
of embedded software.
</para>
<para>
An important component integrated within Poky is Sato, a GNOME Mobile
based user interface environment.
It is designed to work well with screens at very high DPI and restricted
size, such as those often found on smartphones and PDAs. It is coded with
focus on efficiency and speed so that it works smoothly on hand-held and
other embedded hardware. It will sit neatly on top of any device
using the GNOME Mobile stack, providing a well defined user experience.
</para>
<screenshot>
<mediaobject>
<imageobject>
<imagedata fileref="screenshots/ss-sato.png" format="PNG" align='center' scalefit='1' width="100%" contentdepth="100%"/>
</imageobject>
<caption>
<para>The Sato Desktop - A screenshot from a machine running a Poky built image</para>
</caption>
</mediaobject>
</screenshot>
<para>
Poky has a growing open source community and is also backed up by commercial organisations including <ulink url="http://www.intel.com/">Intel Corporation</ulink>.
</para>
</section>
<section id='intro-manualoverview'>
<title>Documentation Overview</title>
<para>
The handbook is split into sections covering different aspects of Poky.
The <link linkend='usingpoky'>'Using Poky' section</link> gives an overview
of the components that make up Poky followed by information about using and
debugging the Poky build system. The <link linkend='extendpoky'>'Extending Poky' section</link>
gives information about how to extend and customise Poky along with advice
on how to manage these changes.
The <link linkend='bsp'>'Board Support Packages (BSP) - Developers Guide' section</link>
gives information about how to develop BSP such as the common layout, the
software hardware configuration options etc.
The <link linkend='platdev'>'Platform Development with Poky'
section</link> gives information about interaction between Poky and target
hardware for common platform development tasks such as software development,
debugging and profiling. The rest of the manual
consists of several reference sections each giving details on a specific
section of Poky functionality.
</para>
<para>
This manual applies to Poky Release 3.3 (Green).
</para>
</section>
<section id='intro-requirements'>
<title>System Requirements</title>
<para>
We recommend Debian-based distributions, in particular a recent Ubuntu
release (10.04 or newer), as the host system for Poky. Nothing in Poky is
distribution specific and
other distributions will most likely work as long as the appropriate
prerequisites are installed - we know of Poky being used successfully on Redhat,
SUSE, Gentoo and Slackware host systems.
</para>
<para>On a Debian-based system, you need the following packages installed:</para>
<itemizedlist>
<listitem>
<para>build-essential</para>
</listitem>
<listitem>
<para>python (version 2.6 or later)</para>
</listitem>
<listitem>
<para>diffstat</para>
</listitem>
<listitem>
<para>texinfo</para>
</listitem>
<listitem>
<para>texi2html</para>
</listitem>
<listitem>
<para>cvs</para>
</listitem>
<listitem>
<para>subversion</para>
</listitem>
<listitem>
<para>wget</para>
</listitem>
<listitem>
<para>gawk</para>
</listitem>
<listitem>
<para>help2man</para>
</listitem>
<listitem>
<para>chrpath</para>
</listitem>
<listitem>
<para>mercurial</para>
</listitem>
</itemizedlist>
<para>Furthermore if you wish to run an emulated Poky image using <ulink url='http://qemu.org'>QEMU</ulink> (as in the quickstart below) you will need the following packages installed:</para>
<itemizedlist>
<listitem>
<para>libgl1-mesa-dev</para>
</listitem>
<listitem>
<para>libglu1-mesa-dev</para>
</listitem>
<listitem>
<para>libsdl1.2-dev</para>
</listitem>
<listitem>
<para>bochsbios (only to run qemux86 images)</para>
</listitem>
</itemizedlist>
<para>
Debian users can add debian.o-hand.com to their APT sources (See
<ulink url='http://debian.o-hand.com'/>
for instructions on doing this) and then run <command>
"apt-get install qemu poky-depends poky-scripts"</command> which will
automatically install all these dependencies. Virtualisation images with
Poky and all dependencies can also easily be built if required.
</para>
<para>
Poky can use a system provided QEMU or build its own depending on how it's
configured. See the options in <filename>local.conf</filename> for more details.
</para>
</section>
<section id='intro-quickstart'>
<title>Quick Start</title>
<section id='intro-quickstart-build'>
<title>Building and Running an Image</title>
<para>
If you want to try Poky, you can do so in a few commands. The example below
checks out the Poky source code, sets up a build environment, builds an
image and then runs that image under the QEMU emulator in x86 system emulation mode:
</para>
<para>
<literallayout class='monospaced'>
$ wget http://pokylinux.org/releases/poky-green-3.3.tar.bz2
$ tar xjvf poky-green-3.3.tar.bz2
$ cd green-3.3/
$ source poky-init-build-env
$ bitbake poky-image-sato
$ bitbake qemu-native
$ runqemu qemux86
</literallayout>
</para>
<note>
<para>
This process will need Internet access, about 20 GB of disk space
available, and you should expect the build to take about 4 - 5 hours since
it is building an entire Linux system from source including the toolchain!
</para>
</note>
<para>
To build for other machines see the <glossterm><link
linkend='var-MACHINE'>MACHINE</link></glossterm> variable in build/conf/local.conf.
This file contains other useful configuration information and the default version
has examples of common setup needs and is worth
reading. To take advantage of multiple processor cores to speed up builds for example, set the
<glossterm><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm>
and <glossterm><link linkend='var-PARALLEL_MAKE'>PARALLEL_MAKE</link></glossterm> variables.
The images/kernels built by Poky are placed in the <filename class="directory">tmp/deploy/images</filename>
directory.
</para>
<para>
You could also run <command>"poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2"
</command> within the images directory if you have the poky-scripts Debian package
installed from debian.o-hand.com. This allows the QEMU images to be used standalone
outside the Poky build environment.
</para>
<para>
To setup networking within QEMU see the <link linkend='usingpoky-install-qemu-networking'>
QEMU/USB networking with IP masquerading</link> section.
</para>
</section>
<section id='intro-quickstart-qemu'>
<title>Downloading and Using Prebuilt Images</title>
<para>
Prebuilt images from Poky are also available if you just want to run the system
under QEMU. To use these you need to:
</para>
<itemizedlist>
<listitem>
<para>
Add debian.o-hand.com to your APT sources (See
<ulink url='http://debian.o-hand.com'/> for instructions on doing this)
</para>
</listitem>
<listitem>
<para>Install patched QEMU and poky-scripts:</para>
<para>
<literallayout class='monospaced'>
$ apt-get install qemu poky-scripts
</literallayout>
</para>
</listitem>
<listitem>
<para>
Download a Poky QEMU release kernel (*zImage*qemu*.bin) and compressed
filesystem image (poky-image-*-qemu*.ext2.bz2) which
you'll need to decompress with 'bzip2 -d'. These are available from the
<ulink url='http://pokylinux.org/releases/green-3.3/'>last release</ulink>
or from the <ulink url='http://autobuilder.pokylinux.org/'>autobuilder</ulink>.
</para>
</listitem>
<listitem>
<para>Start the image:</para>
<para>
<literallayout class='monospaced'>
$ poky-qemu &lt;kernel&gt; &lt;image&gt;
</literallayout>
</para>
</listitem>
</itemizedlist>
<note><para>
A patched version of QEMU is required at present. A suitable version is available from
<ulink url='http://debian.o-hand.com'/>, it can be built
by poky (bitbake qemu-native) or can be downloaded/built as part of the toolchain/SDK tarballs.
</para></note>
</section>
</section>
<section id='intro-getit'>
<title>Obtaining Poky</title>
<section id='intro-getit-releases'>
<title>Releases</title>
<para>Periodically, we make releases of Poky and these are available
at <ulink url='http://pokylinux.org/releases/'/>.
These are more stable and tested than the nightly development images.</para>
</section>
<section id='intro-getit-nightly'>
<title>Nightly Builds</title>
<para>
We make nightly builds of Poky for testing purposes and to make the
latest developments available. The output from these builds is available
at <ulink url='http://autobuilder.pokylinux.org/'/>
where the numbers increase for each subsequent build and can be used to reference it.
</para>
<para>
Automated builds are available for "standard" Poky and for Poky SDKs and toolchains as well
as any testing versions we might have such as poky-bleeding. The toolchains can
be used either as external standalone toolchains or can be combined with Poky as a
prebuilt toolchain to reduce build time. Using the external toolchains is simply a
case of untarring the tarball into the root of your system (it only creates files in
<filename class="directory">/opt/poky</filename>) and then enabling the option
in <filename>local.conf</filename>.
</para>
</section>
<section id='intro-getit-dev'>
<title>Development Checkouts</title>
<para>
Poky is available from our GIT repository located at
git://git.pokylinux.org/poky.git; a web interface to the repository
can be accessed at <ulink url='http://git.pokylinux.org/'/>.
</para>
<para>
The 'master' is where the deveopment work takes place and you should use this if you're
after to work with the latest cutting edge developments. It is possible trunk
can suffer temporary periods of instability while new features are developed and
if this is undesireable we recommend using one of the release branches.
</para>
</section>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/poky-beaver.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

documentation/poky-ref-manual/poky-handbook.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

documentation/poky-ref-manual/poky-handbook.xml
+102
View File
@@ -0,0 +1,102 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<book id='poky-handbook' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='template/poky-handbook.png'
format='SVG'
align='center' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>Poky Handbook</title>
<subtitle>Hitchhiker's Guide to Poky</subtitle>
<authorgroup>
<author>
<firstname>Richard</firstname> <surname>Purdie</surname>
<affiliation>
<orgname>Intel Corporation</orgname>
</affiliation>
<email>richard@linux.intel.com</email>
</author>
<author>
<firstname>Tomas</firstname> <surname>Frydrych</surname>
<affiliation>
<orgname>Intel Corporation</orgname>
</affiliation>
</author>
<author>
<firstname>Marcin</firstname> <surname>Juszkiewicz</surname>
</author>
<author>
<firstname>Dodji</firstname> <surname>Seketeli</surname>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>3.3+git</revnumber>
<date>11 June 2010</date>
<revremark>Poky Master Documentation</revremark>
</revision>
</revhistory>
<copyright>
<year>2007-2010</year>
<holder>Intel Corporation</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-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
</para>
</legalnotice>
</bookinfo>
<xi:include href="introduction.xml"/>
<xi:include href="usingpoky.xml"/>
<xi:include href="extendpoky.xml"/>
<xi:include href="bsp.xml"/>
<xi:include href="development.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
-->
documentation/poky-ref-manual/poky-logo.svg
+117
View File
@@ -0,0 +1,117 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 13.0.0, SVG Export Plug-In -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [
<!ENTITY ns_flows "http://ns.adobe.com/Flows/1.0/">
]>
<svg version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/"
x="0px" y="0px" width="300px" height="300px" viewBox="-40.981 -92.592 300 300" enable-background="new -40.981 -92.592 300 300"
xml:space="preserve">
<defs>
</defs>
<path fill="#6AC7BD" d="M48.96,48.476v0.003h0.001v-0.061C48.962,48.438,48.96,48.457,48.96,48.476z"/>
<g opacity="0.65">
<g>
<path fill="#EF412A" d="M24.482,23.998v-0.003C10.961,23.994,0,34.955,0,48.476l0.001,0.003v0.003
C0.003,62.001,10.962,72.96,24.482,72.96l0,0H0v24.482h0.003c13.52-0.002,24.479-10.962,24.479-24.481h0.003
C38.005,72.959,48.963,62,48.963,48.479v-0.003C48.962,34.957,38.001,23.998,24.482,23.998z M24.482,50.928
c-1.352,0-2.448-1.096-2.448-2.448s1.096-2.448,2.448-2.448s2.448,1.096,2.448,2.448S25.834,50.928,24.482,50.928z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#A9C542" d="M119.96,48.842c0.064-1.294,1.126-2.326,2.437-2.326c1.31,0,2.371,1.032,2.436,2.327
c12.378-1.223,22.046-11.662,22.046-24.36h-24.482C122.396,10.961,111.435,0,97.915,0v24.485
C97.917,37.183,107.584,47.619,119.96,48.842z M124.833,49.084c-0.064,1.295-1.126,2.327-2.436,2.327h-0.001v22.033h24.482v-0.003
C146.876,60.745,137.208,50.308,124.833,49.084z M119.949,48.963H97.915v24.479h0c12.698,0,23.137-9.668,24.36-22.043
C120.981,51.334,119.949,50.274,119.949,48.963z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#F9C759" d="M168.912,48.967c0-1.311,1.033-2.371,2.328-2.436c-1.222-12.379-11.661-22.049-24.361-22.049v24.481
c0,13.521,10.961,24.481,24.482,24.481v-22.03C170.007,51.415,168.912,50.319,168.912,48.967z M195.841,48.978
c0-0.005,0.001-0.009,0.001-0.014V24.482h-0.004c-12.698,0.002-23.136,9.672-24.356,22.049c1.294,0.064,2.326,1.125,2.326,2.436
s-1.032,2.372-2.327,2.436c1.198,12.187,11.333,21.743,23.763,22.042h-23.883v24.482h0.003
c13.515-0.002,24.47-10.954,24.478-24.467h0.002V48.979L195.841,48.978z M195.832,48.964h0.01v0.014L195.832,48.964z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#6AC7BD" d="M70.994,48.479H48.962v0.002h22.033C70.995,48.481,70.994,48.48,70.994,48.479z M73.44,24.001h-0.003
v22.031c0.002,0,0.003,0,0.005,0c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448c-1.351,0-2.446-1.094-2.448-2.445
H48.958v0.003c0.002,13.519,10.961,24.478,24.479,24.478s24.477-10.959,24.479-24.478v-0.003
C97.916,34.963,86.958,24.003,73.44,24.001z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#EF412A" d="M24.482,23.998v-0.003C10.961,23.994,0,34.955,0,48.476h22.034c0.002-1.351,1.097-2.445,2.448-2.445
c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448v22.01C24.469,59.427,13.514,48.479,0,48.479V72.96h24.481l0,0H0
v24.482h0.003c13.52-0.002,24.479-10.962,24.479-24.481h0.003C38.005,72.959,48.963,62,48.963,48.479v-0.003
C48.962,34.957,38.001,23.998,24.482,23.998z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#A9C542" d="M122.397,46.516c1.31,0,2.371,1.032,2.436,2.327c12.378-1.223,22.046-11.662,22.046-24.36h-24.482
L122.397,46.516L122.397,46.516z M97.915,0v24.482h24.481C122.396,10.961,111.435,0,97.915,0z M122.275,46.528
c-1.223-12.377-11.662-22.046-24.361-22.046v24.482h0v24.479h0c12.698,0,23.137-9.668,24.36-22.043
c-1.294-0.065-2.326-1.125-2.326-2.436C119.949,47.653,120.98,46.593,122.275,46.528z M124.833,49.084
c-0.064,1.295-1.126,2.327-2.436,2.327h-0.001v22.033h24.482v-0.003C146.876,60.745,137.208,50.308,124.833,49.084z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#F9C759" d="M173.795,49.1c-0.071,1.289-1.129,2.315-2.435,2.315c-1.354,0-2.449-1.096-2.449-2.448
c0-1.311,1.033-2.371,2.328-2.436c-1.222-12.379-11.661-22.049-24.361-22.049v24.481c0,13.521,10.961,24.481,24.482,24.481v24.482
h0.003c13.515-0.002,24.47-10.954,24.478-24.467h0.001v-0.016h-0.001C195.833,60.753,186.167,50.322,173.795,49.1z
M195.838,24.482c-12.698,0.002-23.136,9.672-24.356,22.049c1.293,0.064,2.324,1.124,2.326,2.433h22.033v0.015
c0-0.005,0.001-0.01,0.001-0.015V24.482H195.838z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#6AC7BD" d="M71.007,48.347c0.068-1.242,1.055-2.23,2.297-2.301c-0.795-8.026-5.454-14.913-12.103-18.762
C57.601,25.2,53.424,24,48.965,24h-0.003c0,4.46,1.199,8.638,3.283,12.24C56.093,42.891,62.98,47.552,71.007,48.347z
M48.962,48.418c0,0.02-0.001,0.038-0.001,0.058v0.003h0.001V48.418z M70.995,48.482c0-0.001,0-0.001,0-0.002H48.962v0.002H70.995
z M73.44,24.001h-0.003v22.031c0.002,0,0.003,0,0.005,0c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448
c-1.351,0-2.446-1.094-2.448-2.445H48.958v0.003c0.002,13.519,10.961,24.478,24.479,24.478s24.477-10.959,24.479-24.478v-0.003
C97.916,34.963,86.958,24.003,73.44,24.001z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#EF412A" d="M24.482,23.998v-0.003C10.961,23.994,0,34.955,0,48.476h22.034c0.002-1.351,1.097-2.445,2.448-2.445
c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448c-1.311,0-2.372-1.033-2.436-2.327
C9.669,49.824,0.001,60.262,0.001,72.96H0v24.482h0.003c13.52-0.002,24.479-10.962,24.479-24.481h0.003
C38.005,72.959,48.963,62,48.963,48.479v-0.003C48.962,34.957,38.001,23.998,24.482,23.998z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#A9C542" d="M119.949,48.963c0-1.352,1.096-2.448,2.448-2.448c1.31,0,2.371,1.032,2.436,2.327
c12.378-1.223,22.046-11.662,22.046-24.36h-24.482C122.396,10.961,111.435,0,97.915,0v24.482h24.479
c-13.52,0.002-24.478,10.962-24.478,24.481h0v24.479h0c12.698,0,23.137-9.668,24.36-22.043
C120.981,51.334,119.949,50.274,119.949,48.963z M124.833,49.084c-0.064,1.295-1.126,2.327-2.436,2.327h-0.001v22.033h24.482
v-0.003C146.876,60.745,137.208,50.308,124.833,49.084z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#F9C759" d="M195.841,48.979l-0.006-0.015h0.006V48.979c0-0.005,0.001-0.01,0.001-0.015V24.482h-0.004
c-12.698,0.002-23.136,9.672-24.356,22.049c1.294,0.064,2.326,1.125,2.326,2.436c0,1.352-1.096,2.448-2.447,2.448
c-1.354,0-2.449-1.096-2.449-2.448c0-1.311,1.033-2.371,2.328-2.436c-1.222-12.379-11.661-22.049-24.361-22.049v24.481
c0,13.521,10.961,24.481,24.482,24.481v24.482h0.003c13.519-0.002,24.479-10.963,24.479-24.482h-23.884
C185.203,73.126,195.841,62.299,195.841,48.979z"/>
</g>
</g>
<g opacity="0.65">
<g>
<path fill="#6AC7BD" d="M73.44,24.001h-0.003C59.919,24.003,48.96,34.959,48.958,48.476v0.003h0.003v0.002l-0.004,0.001v0.003
c0.002,13.519,10.961,24.478,24.479,24.478s24.477-10.959,24.479-24.478v-0.003C97.916,34.963,86.958,24.003,73.44,24.001z
M73.442,50.928c-1.352,0-2.448-1.096-2.448-2.448s1.096-2.448,2.448-2.448s2.448,1.096,2.448,2.448S74.794,50.928,73.442,50.928z
"/>
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 6.9 KiB

documentation/poky-ref-manual/ref-bitbake.xml
+348
View File
@@ -0,0 +1,348 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='ref-bitbake'>
<title>Reference: Bitbake</title>
<para>
Bitbake is a program written in Python that interprets the metadata
that makes up Poky. At some point, people wonder what actually happens
when you type <command>bitbake poky-image-sato</command>. This section
aims to give an overview of what happens behind the scenes from a
BitBake perspective.
</para>
<para>
It is worth noting that bitbake aims to be a generic "task" executor
capable of handling complex dependency relationships. As such it has no
real knowledge of what the tasks it is executing actually do. It just
considers a list of tasks with dependencies and handles metadata
consisting of variables in a certain format which get passed to the
tasks.
</para>
<section id='ref-bitbake-parsing'>
<title>Parsing</title>
<para>
The first thing BitBake does is that work out its configuration by
looking for a file called <filename>bitbake.conf</filename>.
Bitbake searches through the <varname>BBPATH</varname> environment
variable looking for a <filename class="directory">conf/</filename>
directory containing a <filename>bitbake.conf</filename> file and
adds the first <filename>bitbake.conf</filename> file found in
<varname>BBPATH</varname> (similar to the PATH environment variable).
For Poky, <filename>bitbake.conf</filename> is found in <filename
class="directory">meta/conf/</filename>.
</para>
<para>
In Poky, <filename>bitbake.conf</filename> lists other configuration
files to include from a <filename class="directory">conf/</filename>
directory below the directories listed in <varname>BBPATH</varname>.
In general the most important configuration file from a user's perspective
is <filename>local.conf</filename>, which contains a users customized
settings for Poky. Other notable configuration files are the distribution
configuration file (set by the <glossterm><link linkend='var-DISTRO'>
DISTRO</link></glossterm> variable) and the machine configuration file
(set by the <glossterm><link linkend='var-MACHINE'>MACHINE</link>
</glossterm> variable). The <glossterm><link linkend='var-DISTRO'>
DISTRO</link></glossterm> and <glossterm><link linkend='var-MACHINE'>
MACHINE</link></glossterm> environment variables are both usually set in
the <filename>local.conf</filename> file. Valid distribution
configuration files are available in the <filename class="directory">
meta/conf/distro/</filename> directory and valid machine configuration
files in the <filename class="directory">meta/conf/machine/</filename>
directory. Within the <filename class="directory">
meta/conf/machine/include/</filename> directory are various <filename>
tune-*.inc</filename> configuration files which 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. In particular, <filename>base.bbclass</filename> is
always included, as will any other classes
specified in the configuration using the <glossterm><link
linkend='var-INHERIT'>INHERIT</link></glossterm>
variable. Class files are searched for in a classes subdirectory
under the paths in <varname>BBPATH</varname> in the same way as
configuration files.
</para>
<para>
After the parsing of the configuration files is complete, the
variable <glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm>
is set, usually in
<filename>local.conf</filename>, and defines the list of places to search for
<filename class="extension">.bb</filename> files. By
default this specifies the <filename class="directory">meta/packages/
</filename> directory within Poky, but other directories such as
<filename class="directory">meta-extras/</filename> can be included
too. Adding extra content to
<glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm> is best
acheived through the use of Bitbake
<link linkend='usingpoky-changes-layers'>"layers"</link>.
</para>
<para>
Bitbake parses each <filename class="extension">.bb</filename> file in
<glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm> and
stores the values of various variables. In summary, for each
<filename class="extension">.bb</filename>
file the configuration + base class of variables are set, followed
by the data in the <filename class="extension">.bb</filename> file
itself, followed by any inherit commands that
<filename class="extension">.bb</filename> file might contain.
</para>
<para>
Parsing <filename class="extension">.bb</filename> files is a time
consuming process, so a cache is kept to speed up subsequent parsing.
This cache is invalid if the timestamp of the <filename class="extension">.bb</filename>
file itself has changed, or if the timestamps of any of the include,
configuration or class files the <filename class="extension">.bb</filename>
file depends on have changed.
</para>
</section>
<section id='ref-bitbake-providers'>
<title>Preferences and Providers</title>
<para>
Once all the <filename class="extension">.bb</filename> files have been
parsed, BitBake will proceed to build "poky-image-sato" (or whatever was
specified on the commandline) and looks for providers of that target.
Once a provider is selected, BitBake resolves all the dependencies for
the target. In the case of "poky-image-sato", it would lead to
<filename>task-base.bb</filename>
which in turn would lead to packages like <application>Contacts</application>,
<application>Dates</application>, <application>BusyBox</application>
and these in turn depend on glibc and the toolchain.
</para>
<para>
Sometimes a target might have multiple providers and a common example
is "virtual/kernel" that is provided by each kernel package. Each machine
will often elect the best provider of its kernel with a line like the
following in the machine configuration file:
</para>
<programlisting><glossterm><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></glossterm>_virtual/kernel = "linux-rp"</programlisting>
<para>
The default <glossterm><link linkend='var-PREFERRED_PROVIDER'>
PREFERRED_PROVIDER</link></glossterm> is the provider with the same name as
the target.
</para>
<para>
Understanding how providers are chosen is complicated by the fact
multiple versions might be present. Bitbake defaults to the highest
version of a provider by default. Version comparisons are made using
the same method as Debian. The <glossterm><link
linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></glossterm>
variable can be used to specify a particular version
(usually in the distro configuration) but the order can
also be influenced by the <glossterm><link
linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm>
variable. By default files
have a preference of "0". Setting the
<glossterm><link
linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm> to "-1" will
make a package unlikely to be used unless it was explicitly referenced and
"1" makes it likely the package will be used.
<glossterm><link
linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></glossterm> overrides
any <glossterm><link
linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm>. <glossterm><link
linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm>
is often used to mark more
experimental new versions of packages until they've undergone sufficient
testing to be considered stable.
</para>
<para>
The end result is that internally, BitBake has now built a list of
providers for each target it needs in order of priority.
</para>
</section>
<section id='ref-bitbake-dependencies'>
<title>Dependencies</title>
<para>
Each target BitBake builds consists of multiple tasks (e.g. fetch,
unpack, patch, configure, compile etc.). For best performance on
multi-core systems, BitBake considers each task as an independent
entity with a set of dependencies. There are many variables that
are used to signify these dependencies and more information can be found
about these in the <ulink url='http://bitbake.berlios.de/manual/'>
BitBake manual</ulink>. At a basic level it is sufficient to know
that BitBake uses the <glossterm><link
linkend='var-DEPENDS'>DEPENDS</link></glossterm> and
<glossterm><link linkend='var-RDEPENDS'>RDEPENDS</link></glossterm> variables when
calculating dependencies and descriptions of these variables are
available through the links.
</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 which tasks it needs to run and in what
order. The build now starts with BitBake forking off threads up to
the limit set in the <glossterm><link
linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm> variable
as long as there are tasks ready to run, i.e. tasks with all their
dependencies met.
</para>
<para>
As each task completes, a timestamp is written to the directory
specified by the <glossterm><link
linkend='var-STAMPS'>STAMPS</link></glossterm> variable (usually
<filename class="directory">build/tmp/stamps/*/</filename>). On
subsequent runs, BitBake looks at the <glossterm><link
linkend='var-STAMPS'>STAMPS</link></glossterm>
directory and will not rerun
tasks its already completed unless a timestamp is found to be invalid.
Currently, invalid timestamps are only considered on a per <filename
class="extension">.bb</filename> file basis so if for example the configure stamp has a timestamp greater than the
compile timestamp for a given target the compile task would rerun but this
has no effect on other providers depending on that target. This could
change or become configurable in future versions of BitBake. Some tasks
are marked as "nostamp" tasks which means no timestamp file will be written
and the task will always rerun.
</para>
<para>Once all the tasks have been completed BitBake exits.</para>
</section>
<section id='ref-bitbake-runtask'>
<title>Running a Task</title>
<para>
It's worth noting what BitBake does to run a task. A task 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 is
sent 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>
Python functions are executed internally to BitBake itself and
logging goes to the controlling terminal. Future versions of BitBake will
write the functions to files in a similar way to shell functions and
logging will also go to the log files in a similar way.
</para>
</section>
<section id='ref-bitbake-commandline'>
<title>Commandline</title>
<para>
To quote from "bitbake --help":
</para>
<screen>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.
-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 FILE, --read=FILE read the specified file before 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)
-d, --disable-psyco disable using the psyco just-in-time compiler (not
recommended)
-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
--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>
As well as the containing the parsing and task/dependency handling
code, bitbake also contains a set of "fetcher" modules which allow
fetching of source code from various types of sources. Example
sources might be from disk with the metadata, from websites, from
remote shell accounts or from SCM systems like cvs/subversion/git.
</para>
<para>
The fetchers are usually triggered by entries in
<glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. Information about the
options and formats of entries for specific fetchers can be found in the
<ulink url='http://bitbake.berlios.de/manual/'>BitBake manual</ulink>.
</para>
<para>
One useful feature for certain SCM fetchers is the ability to
"auto-update" when the upstream SCM changes version. Since this
requires certain functionality from the SCM only certain systems
support it, currently Subversion, Bazaar and to a limited extent, Git. It
works using the <glossterm><link linkend='var-SRCREV'>SRCREV</link>
</glossterm> variable. See the <link linkend='platdev-appdev-srcrev'>
developing with an external SCM based project</link> section for more
information.
</para>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4 spell spelllang=en_gb
-->
documentation/poky-ref-manual/ref-classes.xml
+455
View File
@@ -0,0 +1,455 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='ref-classes'>
<title>Reference: Classes</title>
<para>
Class files are used to abstract common functionality and share it amongst multiple
<filename class="extension">.bb</filename> files. Any metadata usually found in a
<filename class="extension">.bb</filename> file can also be placed in a class
file. Class files are identified by the extension
<filename class="extension">.bbclass</filename> and are usually placed
in a <filename class="directory">classes/</filename> directory beneath the
<filename class="directory">meta*/</filename> directory or the directory pointed
by BUILDDIR (e.g. <filename class="directory">build/</filename>)in the same way as
<filename class="extension">.conf</filename> files in the <filename
class="directory">conf</filename> directory. Class files are searched for
in BBPATH in the same was as <filename class="extension">.conf</filename> files too.
</para>
<para>
In most cases inheriting the class is enough to enable its features, although
for some classes you may need to set variables and/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 class="extension">.bb</filename>
file inherits it automatically. It contains definitions of standard basic
tasks such as fetching, unpacking, configuring (empty by default), compiling
(runs any Makefile present), installing (empty by default) and packaging
(empty by default). These 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 <function>oe_runmake</function>.
</para>
</section>
<section id='ref-classes-autotools'>
<title>Autotooled Packages - <filename>autotools.bbclass</filename></title>
<para>
Autotools (autoconf, automake, libtool) brings standardisation and this
class aims to define a set of tasks (configure, compile etc.) that will
work for all autotooled packages. It should usualy be enough to define
a few standard variables as documented in the <link
linkend='usingpoky-extend-addpkg-autotools'>simple autotools
example</link> section and then simply "inherit autotools". This class
can also work with software that emulates autotools.
</para>
<para>
It's useful to have some idea on how the tasks defined by this class work
and what they do behind the scenes.
</para>
<itemizedlist>
<listitem>
<para>
'do_configure' regenearates the configure script (using autoreconf) and
then launches it with a standard set of arguments used during
cross-compilation. Additional parameters can be passed to
<command>configure</command> through the <glossterm><link
linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm> variable.
</para>
</listitem>
<listitem>
<para>
'do_compile' runs <command>make</command> with arguments specifying
the compiler and linker. Additional arguments can be passed through
the <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
</glossterm> variable.
</para>
</listitem>
<listitem>
<para>
'do_install' runs <command>make install</command> passing a DESTDIR
option taking its value from the standard <glossterm><link
linkend='var-DESTDIR'>DESTDIR</link></glossterm> variable.
</para>
</listitem>
</itemizedlist>
</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
they can be installed with the same name. For example the <command>ar</command>
command is available from the "busybox", "binutils" and "elfutils" packages.
This class handles the renaming of the binaries so multiple packages
can be installed which would otherwise conflict and yet the
<command>ar</command> command still works regardless of which are installed
or subsequently removed. It renames the conflicting binary in each package
and symlinks the highest priority binary during installation or removal
of packages.
Four variables control this class:
</para>
<variablelist>
<varlistentry>
<term>ALTERNATIVE_NAME</term>
<listitem>
<para>
Name of binary which will be replaced (<command>ar</command> in this example)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ALTERNATIVE_LINK</term>
<listitem>
<para>
Path to resulting binary ("/bin/ar" in this example)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ALTERNATIVE_PATH</term>
<listitem>
<para>
Path to real binary ("/usr/bin/ar.binutils" in this example)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ALTERNATIVE_PRIORITY</term>
<listitem>
<para>
Priority of binary, the version with the most features should have the highest priority
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Currently, only one binary per package is supported.
</para>
</section>
<section id='ref-classes-update-rc.d'>
<title>Initscripts - <filename>update-rc.d.bbclass</filename></title>
<para>
This class uses update-rc.d to safely install an initscript on behalf of
the package. Details such as making sure the initscript is stopped before
a package is removed and started when the package is installed are taken
care of. Three variables control this class,
<link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link>,
<link linkend='var-INITSCRIPT_NAME'>INITSCRIPT_NAME</link> and
<link linkend='var-INITSCRIPT_PARAMS'>INITSCRIPT_PARAMS</link>. See the
links for details.
</para>
</section>
<section id='ref-classes-binconfig'>
<title>Binary config scripts - <filename>binconfig.bbclass</filename></title>
<para>
Before pkg-config had become widespread, libraries shipped shell
scripts to give information about the libraries and include paths needed
to build software (usually named 'LIBNAME-config'). This class assists
any recipe using such scripts.
</para>
<para>
During staging Bitbake installs such scripts into the <filename
class="directory">sysroots/</filename> directory. It also changes all
paths to point into the <filename class="directory">sysroots/</filename>
directory so all builds which 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. 'glibc' becomes 'libc6' and 'glibc-devel' becomes
'libc6-dev'.
</para>
</section>
<section id='ref-classes-pkgconfig'>
<title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
<para>
Pkg-config brought standardisation and this class aims to make its
integration smooth for all libraries which make use of it.
</para>
<para>
During staging Bitbake installs pkg-config data into the <filename
class="directory">sysroots/</filename> directory. By making use of
sysroot functionality within pkgconfig 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 providing the sources for compiled
binaries. To simplify this process two classes were created:
<filename>src_distribute.bbclass</filename> and
<filename>src_distribute_local.bbclass</filename>.
</para>
<para>
Result of their work are <filename class="directory">tmp/deploy/source/</filename>
subdirs with sources sorted by <glossterm><link linkend='var-LICENSE'>LICENSE</link>
</glossterm> field. If recipe lists few licenses (or has entries like "Bitstream Vera") source archive is put in each
license dir.
</para>
<para>
Src_distribute_local class has three modes of operating:
</para>
<itemizedlist>
<listitem><para>copy - copies the files to the distribute dir</para></listitem>
<listitem><para>symlink - symlinks the files to the distribute dir</para></listitem>
<listitem><para>move+symlink - moves the files into distribute dir, and symlinks them back</para></listitem>
</itemizedlist>
</section>
<section id='ref-classes-perl'>
<title>Perl modules - <filename>cpan.bbclass</filename></title>
<para>
Recipes for Perl modules are simple - usually needs only
pointing to source archive and inheriting of proper bbclass.
Building is split into two methods dependly on method used by
module authors.
</para>
<para>
Modules which use old Makefile.PL based build system require
using of <filename>cpan.bbclass</filename> in their recipes.
</para>
<para>
Modules which use Build.PL based build system require
using of <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 - they usually only
require pointing to the source archive and inheriting the proper
bbclasses.
Building is split into two methods depending on the build method
used by the module authors.
</para>
<para>
Extensions which use autotools based build system require use
of autotools and distutils-base bbclasses in their recipes.
</para>
<para>
Extensions which use distutils build system require use
of <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 devshell task. Its usually up to distribution policy
to include this class (Poky does). See the <link
linkend='platdev-appdev-devshell'>developing with 'devshell' section</link>
for more information about using devshell.
</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 builds
output. The core generic functionality is in
<filename>package.bbclass</filename>, 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 and this is controlled by the <glossterm>
<link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm>
variable. The first class listed in this variable will be used for image
generation. Since images are generated from packages a packaging class is
needed to enable image generation.
</para>
</section>
<section id='ref-classes-kernel'>
<title>Building kernels - <filename>kernel.bbclass</filename></title>
<para>
This class handles building of Linux kernels and the class contains code to know how to build both 2.4 and 2.6 kernel trees. All needed headers are
staged into <glossterm><link
linkend='var-STAGING_KERNEL_DIR'>STAGING_KERNEL_DIR</link></glossterm>
directory to allow building of out-of-tree modules using <filename>module.bbclass</filename>.
</para>
<para>
This means that each kernel module built is packaged separately and inter-module dependencies are
created by parsing the <command>modinfo</command> output. If all modules are
required then installing the "kernel-modules" package will install all
packages with modules and various other kernel packages such as "kernel-vmlinux".
</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>
Those classes add support for creating images in many formats. First the
rootfs is created from packages by one of the <filename>rootfs_*.bbclass</filename>
files (depending on package format used) and then image is created.
The <glossterm><link
linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></glossterm>
variable controls which types of image to generate.
The list of packages to install into the image is controlled by the
<glossterm><link
linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm>
variable.
</para>
</section>
<section id='ref-classes-sanity'>
<title>Host System sanity checks - <filename>sanity.bbclass</filename></title>
<para>
This class checks prerequisite software is present to
notify the users problems that will affect their build. It also
performs basic checks of the user configuration from local.conf to
prevent common mistakes resulting in build failures. It's usually up to
distribution policy whether to include this class (Poky does).
</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 package generation which sanity checks the
packages generated by Poky. There are an ever increasing range of checks
it performs, checking for common problems which break builds/packages/images,
see the bbclass file for more information. It's usually up to distribution
policy whether to include this class (Poky does).
</para>
</section>
<section id='ref-classes-siteinfo'>
<title>Autotools configuration data cache - <filename>siteinfo.bbclass</filename></title>
<para>
Autotools can require tests which have to execute on the target hardware.
Since this isn't possible in general when cross compiling, siteinfo is
used to provide cached test results so these tests can be skipped over but
the correct values used. The <link linkend='structure-meta-site'>meta/site directory</link>
contains test results sorted into different categories like architecture, endianess and
the libc used. Siteinfo provides a list of files containing data relevant to
the current build in the <glossterm><link linkend='var-CONFIG_SITE'>CONFIG_SITE
</link></glossterm> variable which autotools will automatically pick up.
</para>
<para>
The class also provides variables like <glossterm><link
linkend='var-SITEINFO_ENDIANESS'>SITEINFO_ENDIANESS</link></glossterm>
and <glossterm><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link>
</glossterm> which can be used elsewhere in the metadata.
</para>
<para>
This class is included from <filename>base.bbclass</filename> and is hence always active.
</para>
</section>
<section id='ref-classes-others'>
<title>Other Classes</title>
<para>
Only the most useful/important classes are covered here but there are
others, see the <filename class="directory">meta/classes</filename> directory for the rest.
</para>
</section>
<!-- Undocumented classes are:
base_srpm.bbclass
bootimg.bbclass
ccache.inc
ccdv.bbclass
cmake.bbclass
cml1.bbclass
cross.bbclass
flow-lossage.bbclass
gconf.bbclass
gettext.bbclass
gnome.bbclass
gtk-icon-cache.bbclass
icecc.bbclass
lib_package.bbclass
mirrors.bbclass
mozilla.bbclass
multimachine.bbclass
native.bbclass
oelint.bbclass
patch.bbclass
patcher.bbclass
pkg_distribute.bbclass
pkg_metainfo.bbclass
poky.bbclass
rm_work.bbclass
rpm_core.bbclass
scons.bbclass
sdk.bbclass
sdl.bbclass
sip.bbclass
sourcepkg.bbclass
srec.bbclass
syslinux.bbclass
tinderclient.bbclass
tmake.bbclass
utils.bbclass
xfce.bbclass
xlibs.bbclass
-->
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/ref-features.xml
+302
View File
@@ -0,0 +1,302 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix 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
<glossterm linkend='var-DISTRO_FEATURES'><link
linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></glossterm>
variable which is set in the distribution configuration file
(poky.conf for Poky). Machine features are set in the
<glossterm linkend='var-MACHINE_FEATURES'><link
linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></glossterm>
variable which is set in the machine configuration file and
specifies which hardware features a given machine has.
</para>
<para>These two variables are combined 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 doesn't support them.
</para>
<section id='ref-features-distro'>
<title>Distro</title>
<para>The items below are valid options for <glossterm linkend='var-DISTRO_FEATURES'><link
linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></glossterm>.
</para>
<itemizedlist>
<listitem>
<para>
alsa - ALSA support will be included (OSS compatibility
kernel modules will be installed if available)
</para>
</listitem>
<listitem>
<para>
bluetooth - Include bluetooth support (integrated BT only)
</para>
</listitem>
<listitem>
<para>
ext2 - Include tools for supporting for devices with internal
HDD/Microdrive for storing files (instead of Flash only devices)
</para>
</listitem>
<listitem>
<para>
irda - Include Irda support
</para>
</listitem>
<listitem>
<para>
keyboard - Include keyboard support (e.g. keymaps will be
loaded during boot).
</para>
</listitem>
<listitem>
<para>
pci - Include PCI bus support
</para>
</listitem>
<listitem>
<para>
pcmcia - Include PCMCIA/CompactFlash support
</para>
</listitem>
<listitem>
<para>
usbgadget - USB Gadget Device support (for USB
networking/serial/storage)
</para>
</listitem>
<listitem>
<para>
usbhost - USB Host support (allows to connect external
keyboard, mouse, storage, network etc)
</para>
</listitem>
<listitem>
<para>
wifi - WiFi support (integrated only)
</para>
</listitem>
<listitem>
<para>
cramfs - CramFS support
</para>
</listitem>
<listitem>
<para>
ipsec - IPSec support
</para>
</listitem>
<listitem>
<para>
ipv6 - IPv6 support
</para>
</listitem>
<listitem>
<para>
nfs - NFS client support (for mounting NFS exports on
device)
</para>
</listitem>
<listitem>
<para>
ppp - PPP dialup support
</para>
</listitem>
<listitem>
<para>
smbfs - SMB networks client support (for mounting
Samba/Microsoft Windows shares on device)
</para>
</listitem>
</itemizedlist>
</section>
<section id='ref-features-machine'>
<title>Machine</title>
<para>The items below are valid options for <glossterm linkend='var-MACHINE_FEATURES'><link
linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></glossterm>.
</para>
<itemizedlist>
<listitem>
<para>
acpi - Hardware has ACPI (x86/x86_64 only)
</para>
</listitem>
<listitem>
<para>
alsa - Hardware has ALSA audio drivers
</para>
</listitem>
<listitem>
<para>
apm - Hardware uses APM (or APM emulation)
</para>
</listitem>
<listitem>
<para>
bluetooth - Hardware has integrated BT
</para>
</listitem>
<listitem>
<para>
ext2 - Hardware HDD or Microdrive
</para>
</listitem>
<listitem>
<para>
irda - Hardware has Irda support
</para>
</listitem>
<listitem>
<para>
keyboard - Hardware has a keyboard
</para>
</listitem>
<listitem>
<para>
pci - Hardware has a PCI bus
</para>
</listitem>
<listitem>
<para>
pcmcia - Hardware has PCMCIA or CompactFlash sockets
</para>
</listitem>
<listitem>
<para>
screen - Hardware has a screen
</para>
</listitem>
<listitem>
<para>
serial - Hardware has serial support (usually RS232)
</para>
</listitem>
<listitem>
<para>
touchscreen - Hardware has a touchscreen
</para>
</listitem>
<listitem>
<para>
usbgadget - Hardware is USB gadget device capable
</para>
</listitem>
<listitem>
<para>
usbhost - Hardware is USB Host capable
</para>
</listitem>
<listitem>
<para>
wifi - Hardware has integrated WiFi
</para>
</listitem>
</itemizedlist>
</section>
<section id='ref-features-image'>
<title>Reference: Images</title>
<para>
The contents of images generated by Poky can be controlled by the <glossterm
linkend='var-IMAGE_FEATURES'><link
linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
variable in local.conf. Through this 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 <glossterm
linkend='var-IMAGE_FEATURES'><link
linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> contains:
</para>
<itemizedlist>
<listitem>
<para>
apps-console-core - Core console applications such as ssh daemon,
avahi daemon, portmap (for mounting NFS shares)
</para>
</listitem>
<listitem>
<para>
x11-base - X11 server + minimal desktop
</para>
</listitem>
<listitem>
<para>
x11-sato - OpenedHand Sato environment
</para>
</listitem>
<listitem>
<para>
apps-x11-core - Core X11 applications such as an X Terminal, file manager, file editor
</para>
</listitem>
<listitem>
<para>
apps-x11-games - A set of X11 games
</para>
</listitem>
<listitem>
<para>
apps-x11-pimlico - OpenedHand Pimlico application suite
</para>
</listitem>
<listitem>
<para>
tools-sdk - A full SDK which runs on device
</para>
</listitem>
<listitem>
<para>
tools-debug - Debugging tools such as strace and gdb
</para>
</listitem>
<listitem>
<para>
tools-profile - Profiling tools such as oprofile, exmap and LTTng
</para>
</listitem>
<listitem>
<para>
tools-testapps - Device testing tools (e.g. touchscreen debugging)
</para>
</listitem>
<listitem>
<para>
nfs-server - NFS server (exports / over NFS to everybody)
</para>
</listitem>
<listitem>
<para>
dev-pkgs - Development packages (headers and extra library links) for all packages
installed in a given image
</para>
</listitem>
<listitem>
<para>
dbg-pkgs - Debug packages for all packages installed in a given image
</para>
</listitem>
</itemizedlist>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4 spell spelllang=en_gb
-->
documentation/poky-ref-manual/ref-images.xml
+72
View File
@@ -0,0 +1,72 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='ref-images'>
<title>Reference: Images</title>
<para>
Poky has several standard images covering most people's standard needs. A full
list of image targets can be found by looking in the directories
<filename class="directory"> meta/recipes-core/images/</filename>,
<filename class="directory"> meta/packages/images/</filename>,
<filename class="directory"> meta/recipes-sato/images/</filename> and
<filename class="directory"> meta/packages/meta/</filename>. The standard
images are listed below along with details of what they contain:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>poky-image-minimal</emphasis> - A small image, just enough
to allow a device to boot
</para>
</listitem>
<listitem>
<para>
<emphasis>poky-image-base</emphasis> - console only image with full
support of target device hardware
</para>
</listitem>
<listitem>
<para>
<emphasis>poky-image-core</emphasis> - X11 image with simple apps like
terminal, editor and file manager
</para>
</listitem>
<listitem>
<para>
<emphasis>poky-image-sato</emphasis> - X11 image with Sato theme and
Pimlico applications. Also contains terminal, editor and file manager.
</para>
</listitem>
<listitem>
<para>
<emphasis>poky-image-sdk</emphasis> - X11 image like poky-image-sato but
also include native toolchain and libraries needed to build applications
on the device itself. Also includes testing and profiling tools and debug
symbols.
</para>
</listitem>
<listitem>
<para>
<emphasis>meta-toolchain</emphasis> - This generates a tarball containing
a standalone toolchain which can be used externally to Poky. It is self
contained and unpacks to the <filename class="directory">/opt/poky</filename>
directory. It also contains a copy of QEMU and the scripts neccessary to run
poky QEMU images.
</para>
</listitem>
<listitem>
<para>
<emphasis>meta-toolchain-sdk</emphasis> - This includes everything in
meta-toolchain but also includes development headers and libraries
forming a complete standalone SDK. See the <link linkend='platdev-appdev-external-sdk'>
Developing using the Poky SDK</link> and <link linkend='platdev-appdev-external-anjuta'>
Developing using the Anjuta Plugin</link> sections for more information.
</para>
</listitem>
</itemizedlist>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/ref-structure.xml
+514
View File
@@ -0,0 +1,514 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='ref-structure'>
<title>Reference: Directory Structure</title>
<para>
Poky consists of several components and understanding what these are
and where they're located is one of the keys to use it. This section walks
through the Poky directory structure giving information about the various
files and directories.
</para>
<section id='structure-core'>
<title>Top level core components</title>
<section id='structure-core-bitbake'>
<title><filename class="directory">bitbake/</filename></title>
<para>
A copy of BitBake is included within Poky for ease of use, and should
usually match the current BitBake stable release from the BitBake project.
Bitbake, a metadata interpreter, reads the Poky metadata and runs the tasks
defined in the Poky metadata. Failures are usually from the metadata, not
BitBake itself, so most users don't need to worry about BitBake. The
<filename class="directory">bitbake/bin/</filename> directory is placed
into the PATH environment variable by the <link
linkend="structure-core-script">poky-init-build-env</link> script.
</para>
<para>
For more information on BitBake please see the BitBake project site at
<ulink url="http://bitbake.berlios.de/"/>
and the BitBake on-line manual at <ulink url="http://bitbake.berlios.de/manual/"/>.
</para>
</section>
<section id='structure-core-build'>
<title><filename class="directory">build/</filename></title>
<para>
This directory contains user configuration files and the output
generated by Poky in its standard configuration where the source tree is
combined with the output. It is also possible to place output and configuration
files in a directory separate from the Poky source, see the section <link
linkend='structure-core-script'>seperate output directory</link>.
</para>
</section>
<section id='structure-core-meta'>
<title><filename class="directory">meta/</filename></title>
<para>
This directory contains the core metadata, a key part of Poky. Within this
directory there are definitions of the machines, the Poky distribution
and the packages that make up a given system.
</para>
</section>
<section id='structure-core-meta-extras'>
<title><filename class="directory">meta-extras/</filename></title>
<para>
This directory is similar to <filename class="directory">meta/</filename>,
and contains some extra metadata not included in standard Poky. These are
disabled by default, and are not supported as part of Poky.
</para>
</section>
<section id='structure-core-meta-***'>
<title><filename class="directory">meta-***/</filename></title>
<para>
These directories are optional layers to be added to core metadata, which
are enabled by adding them to conf/bblayers.conf.
</para>
</section>
<section id='structure-core-scripts'>
<title><filename class="directory">scripts/</filename></title>
<para>
This directory contains various integration scripts which implement
extra functionality in the Poky environment, such as the QEMU
scripts. This directory is appended to the PATH environment variable by the
<link linkend="structure-core-script">poky-init-build-env</link> script.
</para>
</section>
<section id='structure-core-sources'>
<title><filename class="directory">sources/</filename></title>
<para>
While not part of a checkout, Poky will create this directory as
part of any build. Any downloads are placed in this directory (as
specified by the <glossterm><link linkend='var-DL_DIR'>DL_DIR</link>
</glossterm> variable). This directory can be shared between Poky
builds to save downloading files multiple times. SCM checkouts are
also stored here as e.g. <filename class="directory">sources/svn/
</filename>, <filename class="directory">sources/cvs/</filename> or
<filename class="directory">sources/git/</filename> and the
sources directory may contain archives of checkouts for various
revisions or dates.
</para>
<para>
It's worth noting that BitBake creates <filename class="extension">.md5
</filename> stamp files for downloads. It uses these to mark downloads as
complete as well as for checksum and access accounting purposes. If you add
a file manually to the directory, you need to touch the corresponding
<filename class="extension">.md5</filename> file too.
</para>
<para>
This location can be overridden by setting <glossterm><link
linkend='var-DL_DIR'>DL_DIR</link></glossterm> in <filename>local.conf
</filename>. This directory can be shared between builds and even between
machines via NFS, so downloads are only made once, speeding up builds.
</para>
</section>
<section id='handbook'>
<title><filename class="directory">handbook</filename></title>
<para>
This is the location where this handbook is generated
</para>
</section>
<section id='structure-core-script'>
<title><filename>poky-init-build-env</filename></title>
<para>
This script is used to setup the Poky build environment. Sourcing this file in
a shell makes changes to PATH and sets other core BitBake variables based on the
current working directory. You need to use this before running Poky commands.
Internally it uses scripts within the <filename class="directory">scripts/
</filename> directory to do the bulk of the work. This script supports
specifying any directory as the build output:
</para>
<programlisting>
source POKY_SRC/poky-init-build-env [BUILDDIR]
</programlisting>
<para>
The above command can be typed from any directory, as long as POKY_SRC points to
the desired Poky source tree. The optional BUILDDIR could be any directory you'd
like Poky to generate the build output into.
</para>
</section>
</section>
<section id='structure-build'>
<title><filename class="directory">build/</filename> - The Build Directory</title>
<section id='structure-build-conf-local.conf'>
<title><filename>build/conf/local.conf</filename></title>
<para>
This file contains all the local user configuration of Poky. 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 Poky unless
that variable is hardcoded within Poky (e.g. by using '=' instead of '?=').
Some variables are hardcoded for various reasons but these variables are
relatively rare.
</para>
<para>
Edit this file to set the <glossterm><link linkend='var-MACHINE'>MACHINE</link></glossterm> for which you want to build, which package types you
wish to use (PACKAGE_CLASSES) or where downloaded files should go
(<glossterm><link linkend='var-DL_DIR'>DL_DIR</link></glossterm>).
</para>
</section>
<section id='structure-build-conf-bblayers.conf'>
<title><filename>build/conf/bblayers.conf</filename></title>
<para>
This file defines layers walked by bitbake. If there's no <filename>
bblayers.conf</filename> present, it is created from <filename>bblayers.conf.sample
</filename> when the environment setup script is sourced.
</para>
</section>
<section id='structure-build-tmp'>
<title><filename class="directory">build/tmp/</filename></title>
<para>
This is created by BitBake if it doesn't exist and is where all the Poky output
is placed. To clean Poky and start a build from scratch (other than downloads),
you can wipe this directory. The <filename class="directory">tmp/
</filename> directory has some important sub-components detailed below.
</para>
</section>
<section id='structure-build-tmp-cache'>
<title><filename class="directory">build/tmp/cache/</filename></title>
<para>
When BitBake parses the metadata it creates a cache file of the result which can
be used when subsequently running commands. These are stored here on
a per machine basis.
</para>
</section>
<section id='structure-build-tmp-deploy'>
<title><filename class="directory">build/tmp/deploy/</filename></title>
<para>Any 'end result' output from Poky is placed under here.</para>
</section>
<section id='structure-build-tmp-deploy-deb'>
<title><filename class="directory">build/tmp/deploy/deb/</filename></title>
<para>
Any .deb packages emitted by Poky are placed here, sorted into feeds for
different architecture types.
</para>
</section>
<section id='structure-build-tmp-deploy-rpm'>
<title><filename class="directory">build/tmp/deploy/rpm/</filename></title>
<para>
Any .rpm packages emitted by Poky are placed here, sorted into feeds for
different architecture types.
</para>
</section>
<section id='structure-build-tmp-deploy-images'>
<title><filename class="directory">build/tmp/deploy/images/</filename></title>
<para>
Complete filesystem images are placed here. If you want to flash the resulting
image from a build onto a device, look here for them.
</para>
</section>
<section id='structure-build-tmp-deploy-ipk'>
<title><filename class="directory">build/tmp/deploy/ipk/</filename></title>
<para>Any resulting .ipk packages emitted by Poky are placed here.</para>
</section>
<section id='structure-build-tmp-sysroots'>
<title><filename class="directory">build/tmp/sysroots/</filename></title>
<para>
Any package needing to share output with other packages does so within sysroots.
This means it contains any shared header files and any shared libraries amongst
other data. It is subdivided by architecture so multiple builds can run within
the one build directory.
</para>
</section>
<section id='structure-build-tmp-stamps'>
<title><filename class="directory">build/tmp/stamps/</filename></title>
<para>
This is used by BitBake for accounting purposes to keep track of which tasks
have been run and when. It is also subdivided by architecture. The files are
empty and the important information is the filenames and timestamps.
</para>
</section>
<section id='structure-build-tmp-log'>
<title><filename class="directory">build/tmp/log/</filename></title>
<para>
This contains some general logs if not placing in a package's
<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>, such as
the log output from check_pkg or distro_check tasks.
</para>
</section>
<section id='structure-build-tmp-pkgdata'>
<title><filename class="directory">build/tmp/pkgdata/</filename></title>
<para>
This is an intermediate place for saving packaging data, which will be used
in later packaging process. For detail please refer to <link linkend='ref-classes-package'>
package.bbclass</link>.
</para>
</section>
<section id='structure-build-tmp-pstagelogs'>
<title><filename class="directory">build/tmp/pstagelogs/</filename></title>
<para>
This directory contains manifest for task based prebuilt. Each manifest is basically
a file list for installed files from a given task, which would be useful for later
packaging or cleanup process.
</para>
</section>
<section id='structure-build-tmp-work'>
<title><filename class="directory">build/tmp/work/</filename></title>
<para>
This directory contains various subdirectories for each architecture, and each package built by BitBake has its own work directory under the appropriate architecture subdirectory. All tasks are executed from this work directory. As an example, the source for a particular package will be unpacked, patched, configured and compiled all within its own work directory.
</para>
<para>
It is worth considering the structure of a typical work directory. An
example is the linux-rp kernel, version 2.6.20 r7 on the machine spitz
built within Poky. For this package a work directory of <filename
class="directory">tmp/work/spitz-poky-linux-gnueabi/linux-rp-2.6.20-r7/
</filename>, referred to as <glossterm><link linkend='var-WORKDIR'>WORKDIR
</link></glossterm>, is created. Within this directory, the source is
unpacked to linux-2.6.20 and then patched by quilt (see <link
linkend="usingpoky-modifying-packages-quilt">Section 3.5.1</link>).
Within the <filename class="directory">linux-2.6.20</filename> directory,
standard Quilt directories <filename class="directory">linux-2.6.20/patches</filename>
and <filename class="directory">linux-2.6.20/.pc</filename> are created,
and standard quilt commands can be used.
</para>
<para>
There are other directories generated within <glossterm><link
linkend='var-WORKDIR'>WORKDIR</link></glossterm>. The most important
is <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm><filename class="directory">/temp/</filename> which has log files for each
task (<filename>log.do_*.pid</filename>) and the scripts BitBake runs for
each task (<filename>run.do_*.pid</filename>). The <glossterm><link
linkend='var-WORKDIR'>WORKDIR</link></glossterm><filename
class="directory">/image/</filename> directory is where <command>make
install</command> places its output which is then split into subpackages
within <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>
<filename class="directory">/packages-split/</filename>.
</para>
</section>
</section>
<section id='structure-meta'>
<title><filename class="directory">meta/</filename> - The Metadata</title>
<para>
As mentioned previously, this is the core of Poky. It has several
important subdivisions:
</para>
<section id='structure-meta-classes'>
<title><filename class="directory">meta/classes/</filename></title>
<para>
Contains the <filename class="extension">*.bbclass</filename> files. Class
files are used to abstract common code allowing it to be reused by multiple
packages. The <filename>base.bbclass</filename> file is inherited by every
package. Examples of other important classes are
<filename>autotools.bbclass</filename> that in theory allows any
Autotool-enabled package to work with Poky with minimal effort, or
<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 (<filename>image.bbclass
</filename>, <filename>rootfs_*.bbclass</filename> and
<filename>package*.bbclass</filename>).
</para>
</section>
<section id='structure-meta-conf'>
<title><filename class="directory">meta/conf/</filename></title>
<para>
This is the core set of configuration files which start from
<filename>bitbake.conf</filename> and from which all other configuration
files are included (see the includes at the end of the file, even
<filename>local.conf</filename> is loaded from there!). While
<filename>bitbake.conf</filename> sets up the defaults, these can often be
overridden by user (<filename>local.conf</filename>), machine or
distribution configuration files.
</para>
</section>
<section id='structure-meta-conf-machine'>
<title><filename class="directory">meta/conf/machine/</filename></title>
<para>
Contains all the machine configuration files. If you set MACHINE="spitz", the
end result is Poky looking for a <filename>spitz.conf</filename> file in this directory. The includes
directory contains various data common to multiple machines. If you want to add
support for a new machine to Poky, this is the directory to look in.
</para>
</section>
<section id='structure-meta-conf-distro'>
<title><filename class="directory">meta/conf/distro/</filename></title>
<para>
Any distribution specific configuration is controlled from here. OpenEmbedded
supports multiple distributions of which Poky is one. Poky only contains the
Poky distribution so poky.conf is the main file here. This includes the
versions and SRCDATES for applications which are configured here. An example of
an alternative configuration is poky-bleeding.conf although this mainly inherits
its configuration from Poky itself.
</para>
</section>
<section id='structure-meta-recipes-bsp'>
<title><filename class="directory">meta/recipes-bsp/</filename></title>
<para>
Anything linking to specific hardware or hardware configuration information
are placed here, such as uboot, grub, etc.
</para>
</section>
<section id='structure-meta-recipes-connectivity'>
<title><filename class="directory">meta/recipes-connectivity/</filename></title>
<para>
Libraries and applications related to communication with other devices
</para>
</section>
<section id='structure-meta-recipes-core'>
<title><filename class="directory">meta/recipes-core/</filename></title>
<para>
What's needed to build a basic working Linux image including commonly used dependencies
</para>
</section>
<section id='structure-meta-recipes-devtools'>
<title><filename class="directory">meta/recipes-devtools/</filename></title>
<para>
Tools primarily used by the build system (but can also be used on targets)
</para>
</section>
<section id='structure-meta-recipes-extended'>
<title><filename class="directory">meta/recipes-extended/</filename></title>
<para>
Applications which whilst not essential add features compared to the alternatives in
core. May be needed for full tool functionality or LSB compliance.
</para>
</section>
<section id='structure-meta-recipes-gnome'>
<title><filename class="directory">meta/recipes-gnome/</filename></title>
<para>
All things related to the GTK+ application framework
</para>
</section>
<section id='structure-meta-recipes-graphics'>
<title><filename class="directory">meta/recipes-graphics/</filename></title>
<para>
X and other graphically related system libraries
</para>
</section>
<section id='structure-meta-recipes-kernel'>
<title><filename class="directory">meta/recipes-kernel/</filename></title>
<para>
The kernel and generic applications/libraries with strong kernel dependencies
</para>
</section>
<section id='structure-meta-recipes-multimedia'>
<title><filename class="directory">meta/recipes-multimedia/</filename></title>
<para>
Codecs and support utilties for audio, images and video
</para>
</section>
<section id='structure-meta-recipes-qt'>
<title><filename class="directory">meta/recipes-qt/</filename></title>
<para>
All things related to the QT application framework
</para>
</section>
<section id='structure-meta-recipes-sato'>
<title><filename class="directory">meta/recipes-sato/</filename></title>
<para>
The Sato demo/reference UI/UX, its associated apps and configuration
</para>
</section>
<section id='structure-meta-packages'>
<title><filename class="directory">meta/packages/</filename></title>
<para>
this is a catch-all place for the rest which not fits into above
recipes-***. Images and tasks are also placed here.
</para>
</section>
<section id='structure-meta-site'>
<title><filename class="directory">meta/site/</filename></title>
<para>
Certain autoconf test results cannot be determined when cross compiling since it
can't run tests on a live system. This directory therefore contains a list of
cached results for various architectures which is passed to autoconf.
</para>
</section>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/ref-variables.xml
+879
View File
@@ -0,0 +1,879 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- Dummy chapter -->
<appendix id='ref-variables-glos'>
<title>Reference: Variables Glossary</title>
<para>
This section lists common variables used in Poky and gives an overview
of their function and contents.
</para>
<glossary id='ref-variables-glossary'>
<para>
<link linkend='var-glossary-a'>A</link>
<link linkend='var-glossary-b'>B</link>
<link linkend='var-glossary-c'>C</link>
<link linkend='var-glossary-d'>D</link>
<link linkend='var-glossary-e'>E</link>
<link linkend='var-glossary-f'>F</link>
<!-- <link linkend='var-glossary-g'>G</link> -->
<link linkend='var-glossary-h'>H</link>
<link linkend='var-glossary-i'>I</link>
<!-- <link linkend='var-glossary-j'>J</link> -->
<link linkend='var-glossary-k'>K</link>
<link linkend='var-glossary-l'>L</link>
<link linkend='var-glossary-m'>M</link>
<!-- <link linkend='var-glossary-n'>N</link> -->
<!-- <link linkend='var-glossary-o'>O</link> -->
<link linkend='var-glossary-p'>P</link>
<!-- <link linkend='var-glossary-q'>Q</link> -->
<link linkend='var-glossary-r'>R</link>
<link linkend='var-glossary-s'>S</link>
<link linkend='var-glossary-t'>T</link>
<!-- <link linkend='var-glossary-u'>U</link> -->
<!-- <link linkend='var-glossary-v'>V</link> -->
<link linkend='var-glossary-w'>W</link>
<!-- <link linkend='var-glossary-x'>X</link> -->
<!-- <link linkend='var-glossary-y'>Y</link> -->
<!-- <link linkend='var-glossary-z'>Z</link>-->
</para>
<glossdiv id='var-glossary-a'><title>A</title>
<glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
<glossdef>
<para>E-mail address to contact original author(s) - to
send patches, forward bugs...</para>
</glossdef>
</glossentry>
<glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
<glossdef>
<para>Use current (newest) source revision - used with
<glossterm><link linkend='var-SRCREV'>SRCREV</link></glossterm>
variable.</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-b'><title>B</title>
<glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
<glossdef>
<para>The maximum number of tasks BitBake should run in parallel at any one time</para>
</glossdef>
</glossentry>
<glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
<glossdef>
<para>List of recipes used by BitBake to build software</para>
</glossdef>
</glossentry>
<!-- BBPATH is not a usable variable in .bb files and should not be listed here -->
<glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
<glossdef>
<para>Variable which controls how BitBake displays logs on build failure.</para>
</glossdef>
</glossentry>
<glossentry id='var-BPN'><glossterm>BPN</glossterm>
<glossdef>
<para>Bare name of package with any suffixes like -cross -native
removed. </para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-c'><title>C</title>
<glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
<glossdef>
<para>
Flags passed to C compiler for the target system. Evaluates to the same
as <link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
<glossdef>
<para>A regular expression which evalutates to match the machines the recipe
works with. It stops recipes being run on machines they're incompatible with,
which is partciuarly useful with kernels. It also helps to increase parsing
speed as further parsing of the recipe is skipped as if it found the current
machine is not compatible.</para>
</glossdef>
</glossentry>
<glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm>
<glossdef>
<para>
A list of files which contains autoconf test results relevant
to the current build. This variable is used by the autotools utilities
when running configure.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-d'><title>D</title>
<glossentry id='var-D'><glossterm>D</glossterm>
<glossdef>
<para>Destination directory</para>
</glossdef>
</glossentry>
<glossentry id='var-DEBUG_BUILD'><glossterm>DEBUG_BUILD</glossterm>
<glossdef>
<para>
Build packages with debugging information. This influences the value
<link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</link>
takes.
</para>
</glossdef>
</glossentry>
<glossentry id='var-DEBUG_OPTIMIZATION'><glossterm>DEBUG_OPTIMIZATION</glossterm>
<glossdef>
<para>
The options to pass in <link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link>
and <link linkend='var-CFLAGS'>CFLAGS</link> when compiling a system for debugging.
This defaults to "-O -fno-omit-frame-pointer -g".
</para>
</glossdef>
</glossentry>
<glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
<glossdef>
<para>Priority of recipe</para>
</glossdef>
</glossentry>
<glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
<glossdef>
<para>
A list of build time dependencies for a given recipe. These indicate
recipes that must have staged before this recipe can configure.
</para>
</glossdef>
</glossentry>
<glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
<glossdef>
<para>Package description used by package
managers</para>
</glossdef>
</glossentry>
<glossentry id='var-DESTDIR'><glossterm>DESTDIR</glossterm>
<glossdef>
<para>Destination directory</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm>
<glossdef>
<para>Short name of distribution</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO_EXTRA_RDEPENDS'><glossterm>DISTRO_EXTRA_RDEPENDS</glossterm>
<glossdef>
<para>List of packages required by distribution.</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
<glossdef>
<para>List of packages which extend usability of
image. Those packages will be automatically
installed but can be removed by user.</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO_FEATURES'><glossterm>DISTRO_FEATURES</glossterm>
<glossdef>
<para>Features of the distribution.</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO_NAME'><glossterm>DISTRO_NAME</glossterm>
<glossdef>
<para>Long name of distribution</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm>
<glossdef>
<para>Alias names of the recipe in various Linux distributions. </para>
<para>More information in
<link
linkend='usingpoky-configuring-DISTRO_PN_ALIAS'>
Configuring the DISTRO_PN_ALIAS variable section
</link>
</para>
</glossdef>
</glossentry>
<glossentry id='var-DISTRO_VERSION'><glossterm>DISTRO_VERSION</glossterm>
<glossdef>
<para>Version of distribution</para>
</glossdef>
</glossentry>
<glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
<glossdef>
<para>Directory where all fetched sources will be stored</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-e'><title>E</title>
<glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
<glossdef>
<para>Variable which control which locales for glibc are
to be generated during build (useful if target device
has 64M RAM or less)</para>
</glossdef>
</glossentry>
<glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
<glossdef>
<para>Additional cmake options</para>
</glossdef>
</glossentry>
<glossentry id='var-EXTRA_OECONF'><glossterm>EXTRA_OECONF</glossterm>
<glossdef>
<para>Additional 'configure' script options</para>
</glossdef>
</glossentry>
<glossentry id='var-EXTRA_OEMAKE'><glossterm>EXTRA_OEMAKE</glossterm>
<glossdef>
<para>Additional GNU make options</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-f'><title>F</title>
<glossentry id='var-FILES'><glossterm>FILES</glossterm>
<glossdef>
<para>list of directories/files which will be placed
in packages</para>
</glossdef>
</glossentry>
<glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
<glossdef>
<para>
The options to pass in <link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link>
and <link linkend='var-CFLAGS'>CFLAGS</link> when compiling an optimised system.
This defaults to "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2".
</para>
</glossdef>
</glossentry>
</glossdiv>
<!-- <glossdiv id='var-glossary-g'><title>G</title>-->
<!-- </glossdiv>-->
<glossdiv id='var-glossary-h'><title>H</title>
<glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
<glossdef>
<para>Website where more info about package can be found</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-i'><title>I</title>
<glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
<glossdef>
<para><link linkend="ref-features-image">List of
features</link> present in resulting images</para>
</glossdef>
</glossentry>
<glossentry id='var-IMAGE_FSTYPES'><glossterm>IMAGE_FSTYPES</glossterm>
<glossdef>
<para>Formats of rootfs images which we want to have
created</para>
</glossdef>
</glossentry>
<glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm>
<glossdef>
<para>List of packages used to build image</para>
</glossdef>
</glossentry>
<glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
<glossdef>
<para>
This variable causes the build to not strip binaries in
resulting packages.
</para>
</glossdef>
</glossentry>
<glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
<glossdef>
<para>
This variable causes the named class to be inherited at
this point during parsing. Its only valid in configuration
files.
</para>
</glossdef>
</glossentry>
<glossentry id='var-INITSCRIPT_PACKAGES'><glossterm>INITSCRIPT_PACKAGES</glossterm>
<glossdef>
<para>
Scope: Used in recipes when using update-rc.d.bbclass. Optional, defaults to PN.
</para>
<para>
A list of the packages which contain initscripts. If multiple
packages are specified you need to append the package name
to the other INITSCRIPT_* as an override.
</para>
</glossdef>
</glossentry>
<glossentry id='var-INITSCRIPT_NAME'><glossterm>INITSCRIPT_NAME</glossterm>
<glossdef>
<para>
Scope: Used in recipes when using update-rc.d.bbclass. Mandatory.
</para>
<para>
The filename of the initscript (as installed to ${etcdir}/init.d).
</para>
</glossdef>
</glossentry>
<glossentry id='var-INITSCRIPT_PARAMS'><glossterm>INITSCRIPT_PARAMS</glossterm>
<glossdef>
<para>
Scope: Used in recipes when using update-rc.d.bbclass. Mandatory.
</para>
<para>
Specifies the options to pass to update-rc.d. An example is
"start 99 5 2 . stop 20 0 1 6 ." which gives the script a
runlevel of 99, starts the script in initlevels 2 and 5 and
stops it in levels 0, 1 and 6.
</para>
</glossdef>
</glossentry>
</glossdiv>
<!-- <glossdiv id='var-glossary-j'><title>J</title>-->
<!-- </glossdiv>-->
<glossdiv id='var-glossary-k'><title>K</title>
<glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
<glossdef>
<para>The type of kernel to build for a device, usually set by the
machine configuration files and defaults to "zImage". This is used
when building the kernel and is passed to "make" as the target to
build.</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-l'><title>L</title>
<glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
<glossdef>
<para>When used inside a layer.conf gives the path of the
current layer. This variable requires immediate expansion
(see the Bitbake manual) as lazy expansion can result in
the expansion happening in the wrong directory and therefore
giving the wrong value.</para>
</glossdef>
</glossentry>
<glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
<glossdef>
<para>List of package source licenses.</para>
</glossdef>
</glossentry>
<glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm>
<glossdef>
<para>Checksums of the license text in the recipe source code.
</para>
<para>This variable tracks changes in license text of the source
code files. If the license text is changed, it will trigger the build
failure, which gives developer an opportunity to review any
license change</para>
<para> This is an optional variable now, and the plan is to make
it a required variable in the future </para>
<para>See "meta/package/zlib/zlib_${PV}.bb" file for an example</para>
<para>More information in <link
linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
Configuring the LIC_FILES_CHKSUM variable section</link></para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-m'><title>M</title>
<glossentry id='var-MACHINE'><glossterm>MACHINE</glossterm>
<glossdef>
<para>Target device</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_ESSENTIAL_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_RDEPENDS</glossterm>
<glossdef>
<para>List of packages required to boot device</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_ESSENTIAL_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_RRECOMMENDS</glossterm>
<glossdef>
<para>List of packages required to boot device (usually
additional kernel modules)</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
<glossdef>
<para>List of packages required to use device</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMNEDS</glossterm>
<glossdef>
<para>List of packages useful to use device (for example
additional kernel modules)</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
<glossdef>
<para>List of device features - defined in <link
linkend='ref-features-machine'>machine
features section</link></para>
</glossdef>
</glossentry>
<glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
<glossdef>
<para>E-mail of distribution maintainer</para>
</glossdef>
</glossentry>
</glossdiv>
<!-- <glossdiv id='var-glossary-n'><title>N</title>-->
<!-- </glossdiv>-->
<!-- <glossdiv id='var-glossary-o'><title>O</title>-->
<!-- </glossdiv>-->
<glossdiv id='var-glossary-p'><title>P</title>
<glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm>
<glossdef>
<para>Architecture of resulting package</para>
</glossdef>
</glossentry>
<glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm>
<glossdef>
<para>List of resulting packages formats</para>
</glossdef>
</glossentry>
<glossentry id='var-PACKAGE_EXTRA_ARCHS'><glossterm>PACKAGE_EXTRA_ARCHS</glossterm>
<glossdef>
<para>List of architectures compatible with device
CPU. Usable when build is done for few different
devices with misc processors (like XScale and
ARM926-EJS)</para>
</glossdef>
</glossentry>
<glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
<glossdef>
<para>List of packages to be created from recipe.
The default value is "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev"</para>
</glossdef>
</glossentry>
<glossentry id='var-PARALLEL_MAKE'><glossterm>PARALLEL_MAKE</glossterm>
<glossdef>
<para>Extra options that are passed to the make command during the
compile tasks. This is usually of the form '-j 4' where the number
represents the maximum number of parallel threads make can run.</para>
</glossdef>
</glossentry>
<glossentry id='var-PN'><glossterm>PN</glossterm>
<glossdef>
<para>Name of package.
</para>
</glossdef>
</glossentry>
<glossentry id='var-PR'><glossterm>PR</glossterm>
<glossdef>
<para>Revision of package.
</para>
</glossdef>
</glossentry>
<glossentry id='var-PV'><glossterm>PV</glossterm>
<glossdef>
<para>Version of package.
The default value is "1.0"</para>
</glossdef>
</glossentry>
<glossentry id='var-PE'><glossterm>PE</glossterm>
<glossdef>
<para>
Epoch of the package. The default value is "0". The field is used
to make upgrades possible when the versioning scheme changes in
some backwards incompatible way.
</para>
</glossdef>
</glossentry>
<glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
<glossdef>
<para>If multiple recipes provide an item, this variable
determines which one should be given preference. It
should be set to the "$PN" of the recipe to be preferred.</para>
</glossdef>
</glossentry>
<glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
<glossdef>
<para>
If there are multiple versions of recipe available, this
variable determines which one should be given preference. It
should be set to the "$PV" of the recipe to be preferred.
</para>
</glossdef>
</glossentry>
<glossentry id='var-POKY_EXTRA_INSTALL'><glossterm>POKY_EXTRA_INSTALL</glossterm>
<glossdef>
<para>List of packages to be added to the image. This should
only be set in <filename>local.conf</filename>.</para>
</glossdef>
</glossentry>
<glossentry id='var-POKYLIBC'><glossterm>POKYLIBC</glossterm>
<glossdef>
<para>Libc implementation selector - glibc, eglibc, or uclibc can be selected.</para>
</glossdef>
</glossentry>
<glossentry id='var-POKYMODE'><glossterm>POKYMODE</glossterm>
<glossdef>
<para>Toolchain selector. It can be external toolchain
built from Poky or few supported combinations of
upstream GCC or CodeSourcery Labs toolchain.</para>
</glossdef>
</glossentry>
</glossdiv>
<!-- <glossdiv id='var-glossary-q'><title>Q</title>-->
<!-- </glossdiv>-->
<glossdiv id='var-glossary-r'><title>R</title>
<glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
<glossdef>
<para>List of packages which conflict with this
one. Package will not be installed if they are not
removed first.</para>
</glossdef>
</glossentry>
<glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
<glossdef>
<para>
A list of run-time dependencies for a package. These packages
need to be installed alongside the package it applies to so
the package will run correctly, an example is a perl script
which would rdepend on perl. Since this variable applies to
output packages there would usually be an override attached
to this variable like RDEPENDS_${PN}-dev. Names in this field
should be as they are in <link linkend='var-PACKAGES'>PACKAGES
</link> namespace before any renaming of the output package
by classes like debian.bbclass.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ROOT_FLASH_SIZE'><glossterm>ROOT_FLASH_SIZE</glossterm>
<glossdef>
<para>Size of rootfs in megabytes</para>
</glossdef>
</glossentry>
<glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
<glossdef>
<para>List of packages which extend usability of the
package. Those packages will be automatically
installed but can be removed by user.</para>
</glossdef>
</glossentry>
<glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
<glossdef>
<para>List of packages which are replaced with this
one.</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-s'><title>S</title>
<glossentry id='var-S'><glossterm>S</glossterm>
<glossdef>
<para>
Path to unpacked sources (by default:
"${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}")
</para>
</glossdef>
</glossentry>
<glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
<glossdef>
<para>Section where package should be put - used
by package managers</para>
</glossdef>
</glossentry>
<glossentry id='var-SELECTED_OPTIMIZATION'><glossterm>SELECTED_OPTIMIZATION</glossterm>
<glossdef>
<para>
The variable takes the value of <link linkend='var-FULL_OPTIMIZATION'>FULL_OPTIMIZATION</link>
unless <link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link> = "1" in which case
<link linkend='var-DEBUG_OPTIMIZATION'>DEBUG_OPTIMIZATION</link> is used.
</para>
</glossdef>
</glossentry>
<glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm>
<glossdef>
<para>Speed and device for serial port used to attach
serial console. This is given to kernel as "console"
param and after boot getty is started on that port
so remote login is possible.</para>
</glossdef>
</glossentry>
<glossentry id='var-SHELLCMDS'><glossterm>SHELLCMDS</glossterm>
<glossdef>
<para>
A list of commands to run within the a shell, used by <glossterm><link
linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-SITEINFO_ENDIANESS'><glossterm>SITEINFO_ENDIANESS</glossterm>
<glossdef>
<para>
Contains "le" for little-endian or "be" for big-endian depending
on the endian byte order of the target system.
</para>
</glossdef>
</glossentry>
<glossentry id='var-SITEINFO_BITS'><glossterm>SITEINFO_BITS</glossterm>
<glossdef>
<para>
Contains "32" or "64" depending on the number of bits for the
CPU of the target system.
</para>
</glossdef>
</glossentry>
<glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
<glossdef>
<para>List of source files (local or remote ones)</para>
</glossdef>
</glossentry>
<glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
<glossdef>
<para>
By default there is code which automatically detects whether
<glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>
contains files which are machine specific and if this is the case it
automatically changes
<glossterm><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></glossterm>.
Setting this variable to "0" disables that behaviour.
</para>
</glossdef>
</glossentry>
<glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
<glossdef>
<para>
Date of source code used to build package (if it was fetched
from SCM).
</para>
</glossdef>
</glossentry>
<glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
<glossdef>
<para>
Revision of source code used to build package (Subversion,
GIT, Bazaar only).
</para>
</glossdef>
</glossentry>
<glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm>
<glossdef>
<para>
Directory with kernel headers required to build out-of-tree
modules.
</para>
</glossdef>
</glossentry>
<glossentry id='var-STAMPS'><glossterm>STAMPS</glossterm>
<glossdef>
<para>
Directory (usually TMPDIR/stamps) with timestamps of
executed tasks.
</para>
</glossdef>
</glossentry>
<glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
<glossdef>
<para>Short (72 char suggested) Summary of binary package for packaging sytems such as ipkg, rpm or debian, inherits DESCRIPTION by default</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-t'><title>T</title>
<glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
<glossdef>
<para>The architecture of the device we're building for.
A number of values are possible but Poky primarily supports
"arm" and "i586".</para>
</glossdef>
</glossentry>
<glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm>
<glossdef>
<para>
Flags passed to C compiler for the target system. Evaluates to the same
as <link linkend='var-CFLAGS'>CFLAGS</link>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-TARGET_FPU'><glossterm>TARGET_FPU</glossterm>
<glossdef>
<para>Method of handling FPU code. For FPU-less targets
(most of ARM cpus) it has to be set to "soft" otherwise
kernel emulation will get used which will result in
performance penalty.</para>
</glossdef>
</glossentry>
<glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
<glossdef>
<para>Type of target operating system. Can be "linux"
for glibc based system, "linux-uclibc" for uClibc. For
ARM/EABI targets there are also "linux-gnueabi" and
"linux-uclibc-gnueabi" values possible.</para>
</glossdef>
</glossentry>
<glossentry id='var-TERMCMD'><glossterm>TERMCMD</glossterm>
<glossdef>
<para>
This command is used by bitbake to lauch a terminal window with a
shell. The shell is unspecified so the user's default shell is used.
By default it is set to <command>gnome-terminal</command> but it can
be any X11 terminal application or terminal multiplexers like screen.
</para>
</glossdef>
</glossentry>
<glossentry id='var-TERMCMDRUN'><glossterm>TERMCMDRUN</glossterm>
<glossdef>
<para>
This command is similar to <glossterm><link
linkend='var-TERMCMD'>TERMCMD</link></glossterm> however instead of the users shell it runs the command specified by the <glossterm><link
linkend='var-SHELLCMDS'>SHELLCMDS</link></glossterm> variable.
</para>
</glossdef>
</glossentry>
</glossdiv>
<!-- <glossdiv id='var-glossary-u'><title>U</title>-->
<!-- </glossdiv>-->
<!-- <glossdiv id='var-glossary-v'><title>V</title>-->
<!-- </glossdiv>-->
<glossdiv id='var-glossary-w'><title>W</title>
<glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
<glossdef>
<para>Path to directory in tmp/work/ where package
will be built.</para>
</glossdef>
</glossentry>
</glossdiv>
<!-- <glossdiv id='var-glossary-x'><title>X</title>-->
<!-- </glossdiv>-->
<!-- <glossdiv id='var-glossary-y'><title>Y</title>-->
<!-- </glossdiv>-->
<!-- <glossdiv id='var-glossary-z'><title>Z</title>-->
<!-- </glossdiv>-->
</glossary>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/ref-varlocality.xml
+211
View File
@@ -0,0 +1,211 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='ref-varlocality'>
<title>Reference: Variable Locality (Distro, Machine, Recipe etc.)</title>
<para>
Whilst most variables can be used in almost any context (.conf, .bbclass,
.inc or .bb file), variables are often associated with a particular
locality/context. This section describes some common associations.
</para>
<section id='ref-varlocality-config-distro'>
<title>Distro Configuration</title>
<itemizedlist>
<listitem>
<para><glossterm linkend='var-DISTRO'><link linkend='var-DISTRO'>DISTRO</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-DISTRO_NAME'><link linkend='var-DISTRO_NAME'>DISTRO_NAME</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-DISTRO_VERSION'><link linkend='var-DISTRO_VERSION'>DISTRO_VERSION</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MAINTAINER'><link linkend='var-MAINTAINER'>MAINTAINER</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-PACKAGE_CLASSES'><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-TARGET_OS'><link linkend='var-TARGET_OS'>TARGET_OS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-TARGET_FPU'><link linkend='var-TARGET_FPU'>TARGET_FPU</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-POKYMODE'><link linkend='var-POKYMODE'>POKYMODE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-POKYLIBC'><link linkend='var-POKYLIBC'>POKYLIBC</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
<section id='ref-varlocality-config-machine'>
<title>Machine Configuration</title>
<itemizedlist>
<listitem>
<para><glossterm linkend='var-TARGET_ARCH'><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-SERIAL_CONSOLE'><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-PACKAGE_EXTRA_ARCHS'><link linkend='var-PACKAGE_EXTRA_ARCHS'>PACKAGE_EXTRA_ARCHS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-IMAGE_FSTYPES'><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-ROOT_FLASH_SIZE'><link linkend='var-ROOT_FLASH_SIZE'>ROOT_FLASH_SIZE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MACHINE_FEATURES'><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MACHINE_EXTRA_RDEPENDS'><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MACHINE_EXTRA_RRECOMMENDS'><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MACHINE_ESSENTIAL_RDEPENDS'><link linkend='var-MACHINE_ESSENTIAL_RDEPENDS'>MACHINE_ESSENTIAL_RDEPENDS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'><link linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'>MACHINE_ESSENTIAL_RRECOMMENDS</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
<section id='ref-varlocality-config-local'>
<title>Local Configuration (local.conf)</title>
<itemizedlist>
<listitem>
<para><glossterm linkend='var-DISTRO'><link linkend='var-DISTRO'>DISTRO</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-MACHINE'><link linkend='var-MACHINE'>MACHINE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-DL_DIR'><link linkend='var-DL_DIR'>DL_DIR</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-BBFILES'><link linkend='var-BBFILES'>BBFILES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-IMAGE_FEATURES'><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-PACKAGE_CLASSES'><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-BB_NUMBER_THREADS'><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-BBINCLUDELOGS'><link linkend='var-BBINCLUDELOGS'>BBINCLUDELOGS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm linkend='var-ENABLE_BINARY_LOCALE_GENERATION'><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
<section id='ref-varlocality-recipe-required'>
<title>Recipe Variables - Required</title>
<itemizedlist>
<listitem>
<para><glossterm><link linkend='var-DESCRIPTION'>DESCRIPTION</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-LICENSE'>LICENSE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-SECTION'>SECTION</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-HOMEPAGE'>HOMEPAGE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-AUTHOR'>AUTHOR</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
<section id='ref-varlocality-recipe-dependencies'>
<title>Recipe Variables - Dependencies</title>
<itemizedlist>
<listitem>
<para><glossterm><link linkend='var-DEPENDS'>DEPENDS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-RDEPENDS'>RDEPENDS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-RCONFLICTS'>RCONFLICTS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-RREPLACES'>RREPLACES</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
<section id='ref-varlocality-recipe-paths'>
<title>Recipe Variables - Paths</title>
<itemizedlist>
<listitem>
<para><glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-S'>S</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-FILES'>FILES</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
<section id='ref-varlocality-recipe-build'>
<title>Recipe Variables - Extra Build Information</title>
<itemizedlist>
<listitem>
<para><glossterm><link
linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-EXTRA_OECMAKE'>EXTRA_OECMAKE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm></para>
</listitem>
<listitem>
<para><glossterm><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm></para>
</listitem>
</itemizedlist>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4 spell spelllang=en_gb
-->
documentation/poky-ref-manual/resources.xml
+142
View File
@@ -0,0 +1,142 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='resources'>
<title>Contributing to Poky</title>
<section id='resources-intro'>
<title>Introduction</title>
<para>
We're happy for people to experiment with Poky and there are a number of places to
find help if you run into difficulties or find bugs. To find out how to download
source code see the <link linkend='intro-getit'>Obtaining Poky</link> section of
the Introduction.
</para>
</section>
<section id='resources-bugtracker'>
<title>Bugtracker</title>
<para>
Problems with Poky should be reported in the
<ulink url='http://bugzilla.pokylinux.org/'>bug tracker</ulink>.
</para>
</section>
<section id='resources-mailinglist'>
<title>Mailing list</title>
<para>
To subscribe to the mailing list send mail to:
</para>
<para>
<literallayout class='monospaced'>
poky+subscribe &lt;at&gt; openedhand &lt;dot&gt; com
</literallayout>
</para>
<para>
Then follow the simple instructions in subsequent reply. Archives are
available <ulink
url="http://lists.o-hand.com/poky/">here</ulink>.
</para>
</section>
<section id='resources-irc'>
<title>IRC</title>
<para>
Join #poky on freenode.
</para>
</section>
<section id='resources-links'>
<title>Links</title>
<itemizedlist>
<listitem><para>
<ulink url='http://pokylinux.org'>The Poky website</ulink>
</para></listitem>
<listitem><para>
<ulink url='http://www.openedhand.com/'>OpenedHand</ulink> - The
original company behind Poky.
</para></listitem>
<listitem><para>
<ulink url='http://www.intel.com/'>Intel Corporation</ulink> - The
company who acquired OpenedHand in 2008.
</para></listitem>
<listitem><para>
<ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>
- The upstream generic embedded distribution Poky derives
from (and contributes to).
</para></listitem>
<listitem><para>
<ulink url='http://developer.berlios.de/projects/bitbake/'>Bitbake</ulink>
- The tool used to process Poky metadata.
</para></listitem>
<listitem><para>
<ulink url='http://bitbake.berlios.de/manual/'>Bitbake User
Manual</ulink>
</para></listitem>
<listitem><para>
<ulink url='http://pimlico-project.org/'>Pimlico</ulink> - A
suite of lightweight Personal Information Management (PIM)
applications designed primarily for handheld and mobile
devices.
</para></listitem>
<listitem><para>
<ulink url='http://fabrice.bellard.free.fr/qemu/'>QEMU</ulink>
- An open source machine emulator and virtualizer.
</para></listitem>
</itemizedlist>
</section>
<section id='resources-contributions'>
<title>Contributions</title>
<para>
Contributions to Poky are very welcome. Patches should be sent to the Poky mailing list along with a Signed-off-by: line in the same style as the Linux kernel. Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1:
</para>
<programlisting>
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
</programlisting>
<para>
A Poky contributions tree (poky-contrib, git://git.pokylinux.org/poky-contrib.git)
exists for people to stage contributions in, for regular contributors.
If people desire such access, please ask on the mailing list. Usually
access will be given to anyone with a proven track record of good patches.
</para>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/poky-ref-manual/screenshots/ss-anjuta-poky-1.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 94 KiB

documentation/poky-ref-manual/screenshots/ss-anjuta-poky-2.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 75 KiB

documentation/poky-ref-manual/screenshots/ss-oprofile-viewer.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

documentation/poky-ref-manual/screenshots/ss-sato.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

documentation/poky-ref-manual/style.css
+953
View File
@@ -0,0 +1,953 @@
/*
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:#999999;
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: normal;
}
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: normal;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: normal;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110.000%;
border-bottom: 1px solid black;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 80%;
font-weight: normal;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("poky-beaver.png");
background-position: right top;
float: right;
margin-top: -256px;
padding-right: 50px;
margin-left: 50px;
text-align: right;
width: 200px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
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;
}
.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: #aaa;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #aaa;
}
.warning {
background-color: #fea;
}
.caution {
background-color: #fea;
}
.tip {
background-color: #eff;
}
.note {
background-color: #dfc;
}
.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{
}
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title {
background-image: url("images/title-bg.png");
background-position: bottom;
background-repeat: repeat-x;
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-image: url("poky-handbook.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: #91ae35;
color: #fff;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #fff;
}
.tip a,
.note a {
color: #fff;
text-decoration: underline;
}
documentation/poky-ref-manual/usingpoky.xml
+316
View File
@@ -0,0 +1,316 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id='usingpoky'>
<title>Using Poky</title>
<para>
This section gives an overview of the components that make up Poky
following by information about running poky builds and dealing with any
problems that may arise.
</para>
<section id='usingpoky-components'>
<title>Poky Overview</title>
<para>
At the core of Poky is the bitbake task executor together with various types of
configuration files. This section gives an overview of bitbake and the
configuration files, in particular what they are used for, and how they
interact.
</para>
<para>
Bitbake handles the parsing and execution of the data
files. The data itself is of various types; recipes which give
details about particular pieces of software, class data which is an
abstraction of common build information (e.g. how to build a Linux kernel)
and configuration data for machines, policy decisions, etc., which acts as
a glue and binds everything together. Bitbake knows how to combine multiple
data sources together, each data source being referred to as a <link
linkend='usingpoky-changes-layers'>'layer'</link>.
</para>
<para>
The <link linkend='ref-structure'>directory structure walkthrough</link>
section gives details on the meaning of specific directories but some
brief details on the core components follows:
</para>
<section id='usingpoky-components-bitbake'>
<title>Bitbake</title>
<para>
Bitbake is the tool at the heart of Poky and is responsible
for parsing the metadata, generating a list of tasks from it
and then executing them. To see a list of the options it
supports look at <command>bitbake --help</command>.
</para>
<para>
The most common usage is <command>bitbake packagename</command> where
packagename is the name of the package you wish to build
(from now on called the target). This often equates to the first part of a .bb
filename, so to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
might type <command>bitbake matchbox-desktop</command>.
Several different versions of matchbox-desktop might exist and
bitbake will choose the one selected by the distribution configuration
(more details about how bitbake chooses between different versions
and providers is available in the <link linkend='ref-bitbake-providers'>
'Preferences and Providers' section</link>). Bitbake will also try to execute any
dependent tasks first so before building matchbox-desktop it
would build a cross compiler and glibc if not already built.
</para>
</section>
<section id='usingpoky-components-metadata'>
<title>Metadata (Recipes)</title>
<para>
The .bb files are usually referred to as 'recipes'. In general, a
recipe contains information about a single piece of software such
as where to download the source, any patches that are needed,
any special configuration options, how to compile the source files
and how to package the compiled output.
</para>
<para>
'package' can also be used to describe recipes but since the same
word is used for the packaged output from Poky (i.e. .ipk or .deb
files), this document will avoid it.
</para>
</section>
<section id='usingpoky-components-classes'>
<title>Classes</title>
<para>
Class (.bbclass) files contain information which is useful to share
between metadata files. An example is the autotools class which contains
the common settings that any application using autotools would use. The
<link linkend='ref-classes'>classes reference section</link> gives details
on common classes and how to use them.
</para>
</section>
<section id='usingpoky-components-configuration'>
<title>Configuration</title>
<para>
The configuration (.conf) files define various configuration variables
which govern what Poky does. These are split into several areas, such
as machine configuration options, distribution configuration options,
compiler tuning options, general common configuration and user
configuration (local.conf).
</para>
</section>
</section>
<section id='usingpoky-build'>
<title>Running a Build</title>
<para>
First the Poky build environment needs to be set up using the following command:
</para>
<para>
<literallayout class='monospaced'>
$ source poky-init-build-env [build_dir]
</literallayout>
</para>
<para>
The build_dir is the dir containing all the building object files. The default
build dir is poky-dir/build. Multiple build_dir can be used for different targets.
For example, ~/build/x86 for qemux86 target, and ~/build/arm for qemuarm target.
Please refer to <link linkend="structure-core-script">poky-init-build-env</link>
for detail info
</para>
<para>
Once the Poky build environment is set up, a target can now be built using:
</para>
<para>
<literallayout class='monospaced'>
$ bitbake &lt;target&gt;
$ bitbake qemu-native
</literallayout>
</para>
<para>
The target is the name of the recipe you want to build. Common targets are the
images (in <filename class="directory">meta/packages/images/</filename>)
or the name of a recipe for a specific piece of software like
<application>busybox</application>. More details about the standard images
are available in the <link linkend='ref-images'>image reference section</link>.
The qemu-native target will build the poky customized qemu, and will be used
by runqemu script later.
</para>
</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/kernels built
by Poky are placed in the <filename class="directory">tmp/deploy/images</filename>
directory. Running qemux86 and qemuarm images is covered in the <link
linkend='intro-quickstart-qemu'>Running an Image</link> section. See your
board/machine documentation for information about how to install these images.
</para>
</section>
<section id='usingpoky-debugging'>
<title>Debugging Build Failures</title>
<para>
The exact method for debugging Poky depends on the nature of the
bug(s) and which part of the system they might be from. Standard
debugging practises such as comparing to the last
known working version and examining the changes, reapplying the
changes in steps to identify the one causing the problem etc. are
valid for Poky just like any other system. It's impossible to detail
every possible potential failure here but there are some general
tips to aid 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 the compile task of busybox 1.01 on the ARM spitz machine, this
might be <filename>tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234</filename>
for example. To see what bitbake ran to generate that log, look at the <filename>run.do_taskname.pid </filename>
file in the same directory.
</para>
<para>The output from python tasks is sent directly to the console at present.</para>
</section>
<section id='usingpoky-debugging-taskrunning'>
<title>Running specific tasks</title>
<para> Any given package consists of a set of tasks, in most
cases the series is fetch, unpack, patch, configure,
compile, install, package, package_write and build. The
default task is "build" and any tasks this depends on are
built first hence the standard bitbake behaviour. There are
some tasks such as devshell which are not part of the
default build chain. If you wish to run such a task you can
use the "-c" option to bitbake e.g. <command>bitbake
matchbox-desktop -c devshell</command>.
</para>
<para>
If you wish to rerun a task you can use the force option
"-f". A typical usage session might look like: </para>
<para>
<literallayout class='monospaced'>
% bitbake matchbox-desktop
[change some source in the WORKDIR for example]
% bitbake matchbox-desktop -c compile -f
% bitbake matchbox-desktop</literallayout>
</para>
<para>
which would build matchbox-desktop, then recompile it. The
final command reruns all tasks after the compile (basically
the packaging tasks) since bitbake will notice that the
compile has been rerun and hence the other tasks also need
to run again.
</para>
<para>
You can view a list of tasks in a given package by running
the listtasks task e.g. <command>bitbake matchbox-desktop -c
listtasks</command>, and the result is in file ${WORKDIR}/temp/log.do_listtasks.pid.
</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've specified.
<command>bitbake -g targetname</command> will create
<filename>depends.dot</filename> and
<filename>task-depends.dot</filename> files in the current
directory. They show
which packages and tasks depend on which other packages and
tasks and are useful for debugging purposes.
<command>"bitbake -g -u depexp targetname"</command> will show result
in more human-readable GUI style.
</para>
</section>
<section id='usingpoky-debugging-bitbake'>
<title>General Bitbake Problems</title>
<para>
Debug output from bitbake can be seen with the "-D" option.
The debug output gives more information about what bitbake
is doing and/or why. Each -D option increases the logging
level, the most common usage being "-DDD".
</para>
<para>
The output from <command>bitbake -DDD -v targetname</command> can reveal why
a certain version of a package might be chosen, why bitbake
picked a certain provider or help in other situations where
bitbake does something you're not expecting.
</para>
</section>
<section id='usingpoky-debugging-buildfile'>
<title>Building with no dependencies</title>
<para>
If you really want to build a specific .bb file, you can use
the form <command>bitbake -b somepath/somefile.bb</command>. Note that this
will not check the dependencies so this option should only
be used when you know its dependencies already exist. You
can specify fragments of the filename and bitbake will see
if it can find a unique match.
</para>
</section>
<section id='usingpoky-debugging-variables'>
<title>Variables</title>
<para>
The "-e" option will dump the resulting environment for
either the configuration (no package specified) or for a
specific package when specified with the "-b" option.
</para>
</section>
<section id='usingpoky-debugging-others'>
<title>Other Tips</title>
<tip>
<para>When adding new packages it is worth keeping an eye open for bad
things creeping into compiler commandlines such as references to local
system files (<filename>/usr/lib/</filename> or <filename>/usr/include/</filename> etc.).
</para>
</tip>
<tip>
<para>
If you want to remove the psplash boot splashscreen, add "psplash=false"
to the kernel commandline and psplash won't load allowing you to see
the console. It's also possible to switch out of the splashscreen by
switching virtual console (Fn+Left or Fn+Right on a Zaurus).
</para>
</tip>
</section>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->
documentation/template/Vera.ttf
BIN
View File
Binary file not shown.
documentation/template/Vera.xml
+1
View File
File diff suppressed because one or more lines are too long
documentation/template/VeraMoBd.ttf
BIN
View File
Binary file not shown.
documentation/template/VeraMoBd.xml
+1
View File
File diff suppressed because one or more lines are too long
documentation/template/VeraMono.ttf
BIN
View File
Binary file not shown.
documentation/template/VeraMono.xml
+1
View File
File diff suppressed because one or more lines are too long
documentation/template/draft.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

documentation/template/fop-config.xml
+58
View File
@@ -0,0 +1,58 @@
<fop version="1.0">
<!-- Strict user configuration -->
<strict-configuration>true</strict-configuration>
<!-- Strict FO validation -->
<strict-validation>true</strict-validation>
<!--
Set the baseDir so common/openedhand.svg references in plans still
work ok. Note, relative file references to current dir should still work.
-->
<base>template</base>
<font-base>template</font-base>
<!-- Source resolution in dpi (dots/pixels per inch) for determining the
size of pixels in SVG and bitmap images, default: 72dpi -->
<!-- <source-resolution>72</source-resolution> -->
<!-- Target resolution in dpi (dots/pixels per inch) for specifying the
target resolution for generated bitmaps, default: 72dpi -->
<!-- <target-resolution>72</target-resolution> -->
<!-- default page-height and page-width, in case
value is specified as auto -->
<default-page-settings height="11in" width="8.26in"/>
<!-- <use-cache>false</use-cache> -->
<renderers>
<renderer mime="application/pdf">
<fonts>
<font metrics-file="VeraMono.xml"
kerning="yes"
embed-url="VeraMono.ttf">
<font-triplet name="veramono" style="normal" weight="normal"/>
</font>
<font metrics-file="VeraMoBd.xml"
kerning="yes"
embed-url="VeraMoBd.ttf">
<font-triplet name="veramono" style="normal" weight="bold"/>
</font>
<font metrics-file="Vera.xml"
kerning="yes"
embed-url="Vera.ttf">
<font-triplet name="verasans" style="normal" weight="normal"/>
<font-triplet name="verasans" style="normal" weight="bold"/>
<font-triplet name="verasans" style="italic" weight="normal"/>
<font-triplet name="verasans" style="italic" weight="bold"/>
</font>
<auto-detect/>
</fonts>
</renderer>
</renderers>
</fop>
documentation/template/ohand-color.svg
+150
View File
@@ -0,0 +1,150 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://web.resource.org/cc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="141.17999"
height="55.34"
id="svg2207"
sodipodi:version="0.32"
inkscape:version="0.45"
version="1.0"
sodipodi:docname="ohand-color.svg"
inkscape:output_extension="org.inkscape.output.svg.inkscape"
sodipodi:docbase="/home/mallum/Projects/admin/oh-doc-tools/common"
sodipodi:modified="true">
<defs
id="defs3" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.2"
inkscape:cx="160"
inkscape:cy="146.21189"
inkscape:document-units="mm"
inkscape:current-layer="layer1"
height="55.34px"
width="141.18px"
inkscape:window-width="772"
inkscape:window-height="581"
inkscape:window-x="5"
inkscape:window-y="48" />
<metadata
id="metadata2211">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<g
id="g2094"
style="fill:#6d6d70;fill-opacity:1"
inkscape:export-filename="/home/mallum/Desktop/g2126.png"
inkscape:export-xdpi="312.71841"
inkscape:export-ydpi="312.71841"
transform="matrix(0.5954767,0,0,0.5954767,31.793058,-18.471052)">
<g
id="g19"
style="fill:#6d6d70;fill-opacity:1">
<path
style="fill:#6d6d70;fill-opacity:1"
id="path21"
d="M 48.693,50.633 C 40.282,50.633 33.439,57.477 33.439,65.888 L 33.439,81.142 L 41.066,81.142 L 41.066,65.888 C 41.066,61.684 44.486,58.261 48.692,58.261 C 52.897,58.261 56.32,61.684 56.32,65.888 C 56.32,70.093 52.897,73.516 48.692,73.516 C 45.677,73.516 43.065,71.756 41.828,69.211 L 41.828,79.504 C 43.892,80.549 46.224,81.142 48.692,81.142 C 57.103,81.142 63.947,74.3 63.947,65.888 C 63.948,57.477 57.104,50.633 48.693,50.633 z " />
</g>
<path
style="fill:#6d6d70;fill-opacity:1"
id="path23"
d="M 18.486,50.557 C 26.942,50.557 33.819,57.435 33.819,65.888 C 33.819,74.344 26.942,81.223 18.486,81.223 C 10.032,81.223 3.152,74.344 3.152,65.888 C 3.152,57.435 10.032,50.557 18.486,50.557 z M 18.486,73.556 C 22.713,73.556 26.153,70.118 26.153,65.888 C 26.153,61.661 22.713,58.222 18.486,58.222 C 14.258,58.222 10.819,61.661 10.819,65.888 C 10.82,70.117 14.259,73.556 18.486,73.556 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path25"
d="M 94.074,107.465 L 94.074,96.016 C 94.074,87.605 87.233,80.763 78.822,80.763 C 70.41,80.763 63.567,87.605 63.567,96.016 C 63.567,104.427 70.41,111.269 78.822,111.269 C 81.289,111.269 83.621,110.676 85.685,109.631 L 85.685,99.339 C 84.448,101.885 81.836,103.644 78.822,103.644 C 74.615,103.644 71.194,100.221 71.194,96.016 C 71.194,91.81 74.615,88.388 78.822,88.388 C 83.026,88.388 86.448,91.81 86.448,96.016 L 86.448,107.456 C 86.448,109.562 88.156,111.268 90.262,111.268 C 92.364,111.269 94.068,109.566 94.074,107.465 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path27"
d="M 124.197,95.814 C 124.088,87.496 117.293,80.762 108.949,80.762 C 100.59,80.762 93.783,87.52 93.697,95.856 L 93.693,95.856 L 93.695,107.456 C 93.695,109.562 95.402,111.268 97.509,111.268 C 99.611,111.268 101.316,109.566 101.321,107.464 L 101.321,95.994 L 101.321,95.994 C 101.333,91.798 104.747,88.388 108.948,88.388 C 113.147,88.388 116.563,91.798 116.575,95.994 L 116.575,107.456 C 116.575,109.562 118.282,111.268 120.387,111.268 C 122.492,111.268 124.201,109.562 124.201,107.456 L 124.201,95.814 L 124.197,95.814 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path29"
d="M 63.946,96.005 L 63.946,95.854 L 63.943,95.854 L 63.943,95.815 L 63.942,95.815 C 63.833,87.497 57.037,80.761 48.693,80.761 C 48.682,80.761 48.671,80.763 48.658,80.763 C 48.382,80.763 48.107,80.772 47.833,80.786 C 47.75,80.791 47.668,80.799 47.586,80.806 C 47.378,80.822 47.172,80.838 46.968,80.862 C 46.884,80.873 46.801,80.882 46.719,80.893 C 46.508,80.92 46.298,80.952 46.091,80.987 C 46.024,80.999 45.958,81.01 45.891,81.024 C 45.649,81.068 45.406,81.119 45.168,81.175 C 45.14,81.183 45.112,81.189 45.085,81.195 C 43.656,81.542 42.306,82.092 41.065,82.812 L 41.065,80.761 L 33.438,80.761 L 33.438,95.857 L 33.435,95.857 L 33.435,107.457 C 33.435,109.563 35.142,111.269 37.248,111.269 C 39.093,111.269 40.632,109.958 40.984,108.217 C 41.036,107.963 41.065,107.702 41.065,107.435 L 41.065,95.873 C 41.086,94.732 41.357,93.65 41.828,92.685 L 41.828,92.693 C 42.598,91.106 43.905,89.824 45.511,89.085 C 45.519,89.08 45.529,89.076 45.536,89.073 C 45.849,88.928 46.174,88.807 46.508,88.707 C 46.523,88.704 46.536,88.699 46.55,88.696 C 46.699,88.651 46.85,88.614 47.004,88.576 C 47.025,88.575 47.046,88.567 47.069,88.562 C 47.234,88.527 47.402,88.495 47.572,88.469 C 47.586,88.468 47.6,88.466 47.615,88.463 C 47.763,88.443 47.916,88.427 48.067,88.415 C 48.106,88.41 48.145,88.407 48.186,88.404 C 48.352,88.393 48.52,88.386 48.691,88.386 C 52.888,88.387 56.304,91.797 56.316,95.992 L 56.316,107.454 C 56.316,109.56 58.023,111.266 60.13,111.266 C 61.976,111.266 63.516,109.954 63.867,108.211 C 63.919,107.963 63.946,107.706 63.946,107.442 L 63.946,96.024 C 63.946,96.021 63.947,96.018 63.947,96.015 C 63.948,96.011 63.946,96.008 63.946,96.005 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path31"
d="M 180.644,50.633 C 178.539,50.633 176.832,52.341 176.832,54.447 L 176.832,65.887 C 176.832,70.092 173.41,73.513 169.203,73.513 C 164.998,73.513 161.576,70.092 161.576,65.887 C 161.576,61.683 164.998,58.26 169.203,58.26 C 172.219,58.26 174.83,60.019 176.068,62.565 L 176.068,52.271 C 174.004,51.225 171.673,50.632 169.203,50.632 C 160.793,50.632 153.951,57.476 153.951,65.887 C 153.951,74.298 160.793,81.141 169.203,81.141 C 177.615,81.141 184.459,74.298 184.459,65.887 L 184.459,54.447 C 184.458,52.341 182.751,50.633 180.644,50.633 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path33"
d="M 124.203,77.339 L 124.203,65.687 L 124.197,65.687 C 124.088,57.371 117.293,50.633 108.949,50.633 C 100.592,50.633 93.783,57.393 93.697,65.731 L 93.695,65.731 L 93.695,65.877 C 93.695,65.882 93.693,65.885 93.693,65.888 C 93.693,65.891 93.695,65.896 93.695,65.899 L 93.695,77.33 C 93.695,79.435 95.402,81.142 97.509,81.142 C 99.614,81.142 101.321,79.435 101.321,77.33 L 101.321,65.868 C 101.333,61.672 104.747,58.261 108.948,58.261 C 113.147,58.261 116.563,61.672 116.575,65.868 L 116.575,65.868 L 116.575,77.329 C 116.575,79.434 118.282,81.141 120.389,81.141 C 122.492,81.142 124.197,79.44 124.203,77.339 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path35"
d="M 150.517,80.761 C 148.41,80.761 146.703,82.469 146.703,84.575 L 146.703,96.015 C 146.703,100.22 143.283,103.643 139.076,103.643 C 134.871,103.643 131.449,100.22 131.449,96.015 C 131.449,91.808 134.871,88.387 139.076,88.387 C 142.092,88.387 144.703,90.145 145.941,92.692 L 145.941,82.397 C 143.875,81.353 141.545,80.76 139.076,80.76 C 130.666,80.76 123.822,87.604 123.822,96.015 C 123.822,104.426 130.666,111.268 139.076,111.268 C 147.486,111.268 154.33,104.426 154.33,96.015 L 154.33,84.575 C 154.33,82.469 152.623,80.761 150.517,80.761 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path37"
d="M 82.625,77.345 C 82.625,75.247 80.923,73.547 78.826,73.547 L 78.826,81.142 C 80.922,81.142 82.625,79.442 82.625,77.345 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path39"
d="M 90.252,69.685 C 92.35,69.685 94.048,67.987 94.048,65.888 L 86.453,65.888 C 86.453,67.986 88.154,69.685 90.252,69.685 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path41"
d="M 93.832,77.329 C 93.832,75.223 92.125,73.516 90.018,73.516 L 78.825,73.516 C 74.619,73.516 71.199,70.093 71.199,65.888 C 71.199,61.684 74.619,58.261 78.825,58.261 C 83.032,58.261 86.453,61.684 86.453,65.888 C 86.453,68.904 84.694,71.514 82.149,72.752 L 92.442,72.752 C 93.488,70.689 94.08,68.356 94.08,65.888 C 94.08,57.477 87.237,50.633 78.826,50.633 C 70.415,50.633 63.571,57.477 63.571,65.888 C 63.571,74.3 70.415,81.142 78.826,81.142 L 90.018,81.142 C 92.125,81.142 93.832,79.435 93.832,77.329 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path43"
d="M 142.869,77.345 C 142.869,75.247 141.168,73.547 139.07,73.547 L 139.07,81.142 C 141.167,81.142 142.869,79.442 142.869,77.345 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path45"
d="M 150.496,69.685 C 152.594,69.685 154.293,67.987 154.293,65.888 L 146.699,65.888 C 146.699,67.986 148.398,69.685 150.496,69.685 z " />
<path
style="fill:#6d6d70;fill-opacity:1"
id="path47"
d="M 154.076,77.329 C 154.076,75.223 152.367,73.516 150.262,73.516 L 139.07,73.516 C 134.865,73.516 131.443,70.093 131.443,65.888 C 131.443,61.684 134.865,58.261 139.07,58.261 C 143.275,58.261 146.699,61.684 146.699,65.888 C 146.699,68.904 144.939,71.514 142.392,72.752 L 152.687,72.752 C 153.73,70.689 154.324,68.356 154.324,65.888 C 154.324,57.477 147.48,50.633 139.07,50.633 C 130.66,50.633 123.816,57.477 123.816,65.888 C 123.816,74.3 130.66,81.142 139.07,81.142 L 150.261,81.142 C 152.367,81.142 154.076,79.435 154.076,77.329 z " />
</g>
<g
id="g2126"
transform="matrix(0.7679564,0,0,0.7679564,-66.520631,11.42903)"
inkscape:export-xdpi="312.71841"
inkscape:export-ydpi="312.71841"
style="fill:#35992a;fill-opacity:1">
<g
transform="translate(86.33975,4.23985e-2)"
style="fill:#35992a;fill-opacity:1"
id="g2114">
<g
style="fill:#35992a;fill-opacity:1"
id="g2116">
<path
id="path2118"
transform="translate(-86.33975,-4.239934e-2)"
d="M 89.96875,0.03125 C 87.962748,0.031250001 86.34375,1.6815001 86.34375,3.6875 L 86.34375,17.71875 L 86.34375,19.6875 L 86.34375,28.90625 C 86.343752,39.06825 94.61925,47.34375 104.78125,47.34375 L 113.375,47.34375 L 123.1875,47.34375 L 127.15625,47.34375 C 129.16325,47.343749 130.8125,45.72475 130.8125,43.71875 C 130.8125,41.71275 129.16325,40.09375 127.15625,40.09375 L 123.1875,40.09375 L 123.1875,19.6875 L 123.1875,14.65625 L 123.1875,3.6875 C 123.1875,1.6815 121.5675,0.03125 119.5625,0.03125 C 117.5555,0.031250001 115.9375,1.6815001 115.9375,3.6875 L 115.9375,14.28125 C 115.1185,13.65425 114.26275,13.109 113.34375,12.625 L 113.34375,3.6875 C 113.34475,1.6815 111.6925,0.03125 109.6875,0.03125 C 107.6825,0.031250001 106.0625,1.6815001 106.0625,3.6875 L 106.0625,10.5625 C 105.6305,10.5325 105.22025,10.5 104.78125,10.5 C 104.34125,10.5 103.90075,10.5325 103.46875,10.5625 L 103.46875,3.6875 C 103.46975,1.6815 101.84975,0.03125 99.84375,0.03125 C 97.837749,0.031250001 96.21875,1.6815001 96.21875,3.6875 L 96.21875,12.625 C 95.299754,13.109 94.41375,13.65425 93.59375,14.28125 L 93.59375,3.6875 C 93.59475,1.6815 91.97475,0.03125 89.96875,0.03125 z M 104.78125,14.34375 C 112.80825,14.34375 119.3125,20.87925 119.3125,28.90625 C 119.3125,36.93325 112.80825,43.46875 104.78125,43.46875 C 96.754254,43.46875 90.21875,36.93425 90.21875,28.90625 C 90.218752,20.87825 96.753253,14.34375 104.78125,14.34375 z "
style="fill:#35992a;fill-opacity:1" />
</g>
</g>
<path
style="fill:#35992a;fill-opacity:1"
id="path2122"
d="M 112.04875,28.913399 C 112.04875,24.899399 108.78275,21.634399 104.76975,21.634399 C 100.75675,21.634399 97.490753,24.900399 97.490753,28.913399 C 97.490753,32.926399 100.75675,36.192399 104.76975,36.192399 C 108.78275,36.192399 112.04875,32.927399 112.04875,28.913399 z " />
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

documentation/template/poky-db-pdf.xsl
+64
View File
@@ -0,0 +1,64 @@
<?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/fo/docbook.xsl" />
<!-- check project-plan.sh for how this is generated, needed to tweak
the cover page
-->
<xsl:include href="/tmp/titlepage.xsl"/>
<!-- To force a page break in document, i.e per section add a
<?hard-pagebreak?> tag.
-->
<xsl:template match="processing-instruction('hard-pagebreak')">
<fo:block break-before='page' />
</xsl:template>
<!--Fix for defualt indent getting TOC all wierd..
See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html
FIXME: must be a better fix
-->
<xsl:param name="body.start.indent" select="'0'"/>
<!--<xsl:param name="title.margin.left" select="'0'"/>-->
<!-- stop long-ish header titles getting wrapped -->
<xsl:param name="header.column.widths">1 10 1</xsl:param>
<!-- customise headers and footers a little -->
<xsl:template name="head.sep.rule">
<xsl:if test="$header.rule != 0">
<xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute>
<xsl:attribute name="border-bottom-style">solid</xsl:attribute>
<xsl:attribute name="border-bottom-color">#cccccc</xsl:attribute>
</xsl:if>
</xsl:template>
<xsl:template name="foot.sep.rule">
<xsl:if test="$footer.rule != 0">
<xsl:attribute name="border-top-width">0.5pt</xsl:attribute>
<xsl:attribute name="border-top-style">solid</xsl:attribute>
<xsl:attribute name="border-top-color">#cccccc</xsl:attribute>
</xsl:if>
</xsl:template>
<xsl:attribute-set name="header.content.properties">
<xsl:attribute name="color">#cccccc</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="footer.content.properties">
<xsl:attribute name="color">#cccccc</xsl:attribute>
</xsl:attribute-set>
<!-- general settings -->
<xsl:param name="fop1.extensions" select="1"></xsl:param>
<xsl:param name="paper.type" select="'A4'"></xsl:param>
<xsl:param name="section.autolabel" select="1"></xsl:param>
<xsl:param name="body.font.family" select="'verasans'"></xsl:param>
<xsl:param name="title.font.family" select="'verasans'"></xsl:param>
<xsl:param name="monospace.font.family" select="'veramono'"></xsl:param>
</xsl:stylesheet>
documentation/template/poky-handbook.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

documentation/template/poky.svg
+163
View File
@@ -0,0 +1,163 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
version="1.0"
width="158.56076"
height="79.284424"
viewBox="-40.981 -92.592 300 300"
id="svg2"
xml:space="preserve">
<defs
id="defs4">
</defs>
<path
d="M -36.585379,54.412576 L -36.585379,54.421305 L -36.582469,54.421305 L -36.582469,54.243829 C -36.57956,54.302018 -36.585379,54.357297 -36.585379,54.412576 z "
style="fill:#6ac7bd"
id="path6" />
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g8">
<g
id="g10">
<path
d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 0.001,48.479 L 0.001,48.482 C 0.003,62.001 10.962,72.96 24.482,72.96 L 24.482,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z M 24.482,50.928 C 23.13,50.928 22.034,49.832 22.034,48.48 C 22.034,47.128 23.13,46.032 24.482,46.032 C 25.834,46.032 26.93,47.128 26.93,48.48 C 26.93,49.832 25.834,50.928 24.482,50.928 z "
style="fill:#ef412a"
id="path12" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g14">
<g
id="g16">
<path
d="M 119.96,48.842 C 120.024,47.548 121.086,46.516 122.397,46.516 C 123.707,46.516 124.768,47.548 124.833,48.843 C 137.211,47.62 146.879,37.181 146.879,24.483 L 122.397,24.483 C 122.396,10.961 111.435,0 97.915,0 L 97.915,24.485 C 97.917,37.183 107.584,47.619 119.96,48.842 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z M 119.949,48.963 L 97.915,48.963 L 97.915,73.442 L 97.915,73.442 C 110.613,73.442 121.052,63.774 122.275,51.399 C 120.981,51.334 119.949,50.274 119.949,48.963 z "
style="fill:#a9c542"
id="path18" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g20">
<g
id="g22">
<path
d="M 168.912,48.967 C 168.912,47.656 169.945,46.596 171.24,46.531 C 170.018,34.152 159.579,24.482 146.879,24.482 L 146.879,48.963 C 146.879,62.484 157.84,73.444 171.361,73.444 L 171.361,51.414 C 170.007,51.415 168.912,50.319 168.912,48.967 z M 195.841,48.978 C 195.841,48.973 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.776,46.595 173.808,47.656 173.808,48.967 C 173.808,50.278 172.776,51.339 171.481,51.403 C 172.679,63.59 182.814,73.146 195.244,73.445 L 171.361,73.445 L 171.361,97.927 L 171.364,97.927 C 184.879,97.925 195.834,86.973 195.842,73.46 L 195.844,73.46 L 195.844,48.979 L 195.841,48.978 z M 195.832,48.964 L 195.842,48.964 L 195.842,48.978 L 195.832,48.964 z "
style="fill:#f9c759"
id="path24" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g26">
<g
id="g28">
<path
d="M 70.994,48.479 L 48.962,48.479 L 48.962,48.481 L 70.995,48.481 C 70.995,48.481 70.994,48.48 70.994,48.479 z M 73.44,24.001 L 73.437,24.001 L 73.437,46.032 C 73.439,46.032 73.44,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 C 72.091,50.928 70.996,49.834 70.994,48.483 L 48.958,48.483 L 48.958,48.486 C 48.96,62.005 59.919,72.964 73.437,72.964 C 86.955,72.964 97.914,62.005 97.916,48.486 L 97.916,48.483 C 97.916,34.963 86.958,24.003 73.44,24.001 z "
style="fill:#6ac7bd"
id="path30" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g32">
<g
id="g34">
<path
d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 22.034,48.476 C 22.036,47.125 23.131,46.031 24.482,46.031 C 25.834,46.031 26.93,47.127 26.93,48.479 C 26.93,49.831 25.834,50.927 24.482,50.927 L 24.482,72.937 C 24.469,59.427 13.514,48.479 0,48.479 L 0,72.96 L 24.481,72.96 L 24.481,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z "
style="fill:#ef412a"
id="path36" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g38">
<g
id="g40">
<path
d="M 122.397,46.516 C 123.707,46.516 124.768,47.548 124.833,48.843 C 137.211,47.62 146.879,37.181 146.879,24.483 L 122.397,24.483 L 122.397,46.516 L 122.397,46.516 z M 97.915,0 L 97.915,24.482 L 122.396,24.482 C 122.396,10.961 111.435,0 97.915,0 z M 122.275,46.528 C 121.052,34.151 110.613,24.482 97.914,24.482 L 97.914,48.964 L 97.914,48.964 L 97.914,73.443 L 97.914,73.443 C 110.612,73.443 121.051,63.775 122.274,51.4 C 120.98,51.335 119.948,50.275 119.948,48.964 C 119.949,47.653 120.98,46.593 122.275,46.528 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z "
style="fill:#a9c542"
id="path42" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g44">
<g
id="g46">
<path
d="M 173.795,49.1 C 173.724,50.389 172.666,51.415 171.36,51.415 C 170.006,51.415 168.911,50.319 168.911,48.967 C 168.911,47.656 169.944,46.596 171.239,46.531 C 170.017,34.152 159.578,24.482 146.878,24.482 L 146.878,48.963 C 146.878,62.484 157.839,73.444 171.36,73.444 L 171.36,97.926 L 171.363,97.926 C 184.878,97.924 195.833,86.972 195.841,73.459 L 195.842,73.459 L 195.842,73.443 L 195.841,73.443 C 195.833,60.753 186.167,50.322 173.795,49.1 z M 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.775,46.595 173.806,47.655 173.808,48.964 L 195.841,48.964 L 195.841,48.979 C 195.841,48.974 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 z "
style="fill:#f9c759"
id="path48" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g50">
<g
id="g52">
<path
d="M 71.007,48.347 C 71.075,47.105 72.062,46.117 73.304,46.046 C 72.509,38.02 67.85,31.133 61.201,27.284 C 57.601,25.2 53.424,24 48.965,24 L 48.962,24 C 48.962,28.46 50.161,32.638 52.245,36.24 C 56.093,42.891 62.98,47.552 71.007,48.347 z M 48.962,48.418 C 48.962,48.438 48.961,48.456 48.961,48.476 L 48.961,48.479 L 48.962,48.479 L 48.962,48.418 z M 70.995,48.482 C 70.995,48.481 70.995,48.481 70.995,48.48 L 48.962,48.48 L 48.962,48.482 L 70.995,48.482 z M 73.44,24.001 L 73.437,24.001 L 73.437,46.032 C 73.439,46.032 73.44,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 C 72.091,50.928 70.996,49.834 70.994,48.483 L 48.958,48.483 L 48.958,48.486 C 48.96,62.005 59.919,72.964 73.437,72.964 C 86.955,72.964 97.914,62.005 97.916,48.486 L 97.916,48.483 C 97.916,34.963 86.958,24.003 73.44,24.001 z "
style="fill:#6ac7bd"
id="path54" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g56">
<g
id="g58">
<path
d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 22.034,48.476 C 22.036,47.125 23.131,46.031 24.482,46.031 C 25.834,46.031 26.93,47.127 26.93,48.479 C 26.93,49.831 25.834,50.927 24.482,50.927 C 23.171,50.927 22.11,49.894 22.046,48.6 C 9.669,49.824 0.001,60.262 0.001,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z "
style="fill:#ef412a"
id="path60" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g62">
<g
id="g64">
<path
d="M 119.949,48.963 C 119.949,47.611 121.045,46.515 122.397,46.515 C 123.707,46.515 124.768,47.547 124.833,48.842 C 137.211,47.619 146.879,37.18 146.879,24.482 L 122.397,24.482 C 122.396,10.961 111.435,0 97.915,0 L 97.915,24.482 L 122.394,24.482 C 108.874,24.484 97.916,35.444 97.916,48.963 L 97.916,48.963 L 97.916,73.442 L 97.916,73.442 C 110.614,73.442 121.053,63.774 122.276,51.399 C 120.981,51.334 119.949,50.274 119.949,48.963 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z "
style="fill:#a9c542"
id="path66" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g68">
<g
id="g70">
<path
d="M 195.841,48.979 L 195.835,48.964 L 195.841,48.964 L 195.841,48.979 C 195.841,48.974 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.776,46.595 173.808,47.656 173.808,48.967 C 173.808,50.319 172.712,51.415 171.361,51.415 C 170.007,51.415 168.912,50.319 168.912,48.967 C 168.912,47.656 169.945,46.596 171.24,46.531 C 170.018,34.152 159.579,24.482 146.879,24.482 L 146.879,48.963 C 146.879,62.484 157.84,73.444 171.361,73.444 L 171.361,97.926 L 171.364,97.926 C 184.883,97.924 195.843,86.963 195.843,73.444 L 171.959,73.444 C 185.203,73.126 195.841,62.299 195.841,48.979 z "
style="fill:#f9c759"
id="path72" />
</g>
</g>
<g
transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)"
style="opacity:0.65"
id="g74">
<g
id="g76">
<path
d="M 73.44,24.001 L 73.437,24.001 C 59.919,24.003 48.96,34.959 48.958,48.476 L 48.958,48.479 L 48.961,48.479 L 48.961,48.481 L 48.957,48.482 L 48.957,48.485 C 48.959,62.004 59.918,72.963 73.436,72.963 C 86.954,72.963 97.913,62.004 97.915,48.485 L 97.915,48.482 C 97.916,34.963 86.958,24.003 73.44,24.001 z M 73.442,50.928 C 72.09,50.928 70.994,49.832 70.994,48.48 C 70.994,47.128 72.09,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 z "
style="fill:#6ac7bd"
id="path78" />
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

documentation/template/titlepage.templates.xml
+1240
View File
File diff suppressed because it is too large Load Diff
documentation/tools/poky-docbook-to-pdf
Executable
+45
View File
@@ -0,0 +1,45 @@
#!/bin/sh
if [ -z "$1" -o -z "$2" ]; then
echo "usage: [-v] $0 <docbook file> <templatedir>"
echo
echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets"
echo " installed for this to work!"
echo
exit 0
fi
FO=`echo $1 | sed s/.xml/.fo/` || exit 1
PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1
TEMPLATEDIR=$2
##
# These URI should be rewritten by your distribution's xml catalog to
# match your localy installed XSL stylesheets.
XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current"
xsltproc -o /tmp/titlepage.xsl \
--xinclude \
$XSL_BASE_URI/template/titlepage.xsl \
$TEMPLATEDIR/titlepage.templates.xml || exit 1
xsltproc --xinclude \
--stringparam hyphenate false \
--stringparam formal.title.placement "figure after" \
--stringparam ulink.show 1 \
--stringparam body.font.master 9 \
--stringparam title.font.master 11 \
--stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \
--output $FO \
$TEMPLATEDIR/poky-db-pdf.xsl \
$1 || exit 1
echo fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1
fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1
rm -f $FO
rm -f /tmp/titlepage.xsl
echo
echo " #### Success! $PDF ready. ####"
echo