<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.
+ Poky supports several methods of software development. You can use the method that is
+ best for you. This chapter describes each development method.
</para>
<section id="platdev-appdev-external-sdk">
- <title>Developing externally using the Poky SDK</title>
-
+ <title>External Development 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
+ the images section</link>) build tarballs that contain toolchains and
+ libraries suitable for application development outside of Poky. These tarballs
+ 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
+ a setup script (e.g.
+ <filename>/opt/poky/environment-setup-i586-poky-linux</filename>, which
+ you can source to initialize a suitable environment. Sourcing these adds 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
+ useful utilities to the PATH variable. 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.
+ results for tests that need target hardware on which 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.
+ Using the toolchain with autotool-enabled packages is straightforward - just pass the
+ appropriate host option to configure as in the following example:
+ <literallayout class='monospaced'>
+ $ ./configure --host=arm-poky-linux-gnueabi
+ </literallayout>
+ For other projects it is usually a case of ensuring the cross tools are used:
+ <literallayout class='monospaced'>
+ CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld
+ </literallayout>
</para>
</section>
</section>
</section>
-
<section id="platdev-appdev-qemu">
<title>Developing externally in QEMU</title>
<para>
also contain an NFS server exporting the guest's root filesystem
allowing that to be made available to the host.
</para>
- </section>
+ </section>
- <section id="platdev-appdev-insitu">
+ <section id="platdev-appdev-insitu">
<title>Developing in Poky directly</title>
<para>
Working directly in Poky is a fast and effective development technique.
linkend="usingpoky-components-bitbake">2.1.1</link> and <link
linkend="usingpoky-debugging-taskrunning">2.4.2</link>.
</para>
+ </section>
- </section>
-
- <section id="platdev-appdev-devshell">
+ <section id="platdev-appdev-devshell">
<title>Developing with 'devshell'</title>
<para>
environmental variables such as CC to assist applications, such as make,
find the correct tools.
</para>
-
</section>
<section id="platdev-appdev-srcrev">
revision updating.
</para>
</section>
-
- </section>
+</section>
<section id="platdev-gdb-remotedebug">
<title>Debugging with GDB Remotely</title>
BBFILES ?= ""
BBLAYERS = " \
/path/to/poky/meta \
- /path/to/poky/meta-moblin \
/path/to/poky/meta-emenlow \
/path/to/poky/meta-extras \
"
<filename class="directory">/opt/poky</filename>) and then enabling the option
in <filename>local.conf</filename>.
</para>
-
</section>
<section id='intro-getit-dev'>
if this is undesireable we recommend using one of the release branches.
</para>
</section>
-
</section>
-
</chapter>
<!--
vim: expandtab tw=80 ts=4
<!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'
+<book id='poky-ref-manual' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
</imageobject>
</mediaobject>
- <title>Poky Handbook</title>
- <subtitle>Hitchhiker's Guide to Poky</subtitle>
+ <title>Poky Reference Manual</title>
+ <subtitle>A Guide and Reference to Poky</subtitle>
<authorgroup>
<author>
<revhistory>
<revision>
<revnumber>3.3+git</revnumber>
- <date>11 June 2010</date>
+ <date>20 Sept 2010</date>
<revremark>Poky Master Documentation</revremark>
</revision>
</revhistory>
<title>Parsing</title>
<para>
- The first thing BitBake does is that work out its configuration by
+ The first thing BitBake does is 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>
</para>
<para>
- It's useful to have some idea on how the tasks defined by this class work
+ It's useful to have some idea of how the tasks defined by this class work
and what they do behind the scenes.
</para>
<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
+ notify the users of potential 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>
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-extended/images/</filename>,
<filename class="directory"> meta/recipes-sato/images/</filename> and
- <filename class="directory"> meta/packages/meta/</filename>. The standard
+ <filename class="directory"> meta/recipes-tbd/meta/</filename>. The standard
images are listed below along with details of what they contain:
</para>
<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
+ and where they're located is one of the keys to using it. This section walks
through the Poky directory structure giving information about the various
files and directories.
</para>
</section>
<section id='handbook'>
- <title><filename class="directory">handbook</filename></title>
+ <title><filename class="directory">documentation</filename></title>
<para>
- This is the location where this handbook is generated
+ This is the location for documentaiton about poky including this handbook.
</para>
</section>
</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>
<literallayout class='monospaced'>
$ bitbake <target>
-$ bitbake qemu-native
</literallayout>
</para>
<para>
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>
<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.
+ listtasks</command>, and the result is in file ${WORKDIR}/temp/log.do_listtasks.
</para>
</section>
