documentation/poky-ref-manual/development.xml: re-write of software dev section

This is a comprehensive pass through this entire section that incorporates
understanding given to me by Scott Garman.  I have added more detail and
text that helps the non-developer understand what is fundamentally going
on.

(From yocto-docs rev: 124c722ccf0316f6e62790ca77c88d0444559378)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2011-08-17 14:38:22 -07:00 committed by Richard Purdie
parent 34de499685
commit 96f0c57a0a
1 changed files with 184 additions and 472 deletions

View File

@ -15,40 +15,56 @@
</para>
<section id="platdev-appdev-external-sdk">
<title>External Development Using the Application Development Toolkit (ADT)</title>
<title>External Development Using the Meta-Toolchain</title>
<para>
The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and
libraries suitable for application development outside of Poky.
For information on these targets see the <ulink linkend='ref-images'>Reference: Images</ulink>
appendix.
The Yocto Project provides toolchains that allow you to develop your application
outside of the Yocto Project build system for specific hardware.
These toolchains (called meta-toolchains) contain cross-development tools like compilers,
linkers, and debuggers that build your application for your target.
The Yocto Project also provides images that have toolchains set up for supported
architectures.
See
<xref linkend='ref-images'>Reference: Images</xref> for a listing of the image
types that Yocto Project supports.
</para>
<para>
Using the BitBake tool you can build a meta-toolchain or meta-toolchain-sdk target,
which is in the form of a tarball.
Unpacking this tarball into the <filename class="directory">/opt/poky</filename> directory
on your host produces a setup script
(e.g. <filename>/opt/poky/environment-setup-i586-poky-linux</filename>) that
you can source to initialize your build environment.
Sourcing this script adds the compiler, QEMU scripts, QEMU binary, a special version of
<filename>pkgconfig</filename> and other
useful utilities to the <filename>PATH</filename> variable used by the Yocto Project
build environment.
Variables to assist <filename>pkgconfig</filename> and
Autotools are also defined so that, for example, <filename>configure</filename>
can find pre-generated test results for tests that need target hardware on which to run.
</para>
<para>
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>), from which
you can source to initialize a suitable environment. Sourcing these files adds the
compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other
useful utilities to the PATH variable. Variables to assist pkgconfig and
autotools are also defined so that, for example, configure can find pre-generated test
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.
Using the toolchain with Autotool-enabled packages is straightforward - just pass the
appropriate <filename>host</filename> option to <filename>configure</filename>.
Following is an 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:
For projects that are not Autotool-enabled, it is usually just a case of ensuring
you point to and use the cross-toolchain.
For example, the following two lines of code in a <filename>Makefile</filename>
that builds your application
specify to use the cross-compiler <filename>arm-poky-linux-gnueabi-gcc</filename>
and linker <filename>arm-poky-linux-gnueabi-ld</filename>, which are part of the
meta-toolchain you have previously established:
<literallayout class='monospaced'>
CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld
CC=arm-poky-linux-gnueabi-gcc;
LD=arm-poky-linux-gnueabi-ld;
</literallayout>
</para>
</section>
<section id="using-the-eclipse-and-anjuta-plug-ins">
<title>Using the Eclipse Plug-in</title>
<title>External Development Using the Eclipse Plug-in</title>
<para>
The current release of the Yocto Project supports the Eclipse IDE plug-in
to make developing software easier for the application developer.
@ -79,420 +95,74 @@
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
"Application Development Toolkit (ADT) User's Guide."</ulink>
</para>
<!--
<section id="the-eclipse-plug-in">
<title>The Eclipse Plug-in</title>
<para>
To use the Eclipse plug-in, a toolchain and SDK built by Poky is required along with
the Eclipse Framework (Helios 3.6.1).
To install the plug-in you need to be in the Eclipse IDE and select
the following menu:
<literallayout class='monospaced'>
Help -> Install New Software
</literallayout>
Specify the target URL as
<ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>.
</para>
<para>
If you want to download the source code for the plug-in you can find it in the Poky
git repository, which has a web interface, and is located at
<ulink url="http://git.yoctoproject.org"></ulink> under IDE Plugins.
</para>
<section id="installing-and-setting-up-the-eclipse-ide">
<title>Installing and Setting up the Eclipse IDE</title>
<para>
If you don't have the Eclipse IDE (Helios 3.6.1) on your system you need to
download and install it from <ulink url="http://www.eclipse.org/downloads"></ulink>.
Choose the Eclipse Classic, which contains the Eclipse Platform, Java Development
Tools (JDT), and the Plug-in Development Environment.
</para>
<note>
<para>
Due to the Java Virtual Machine's garbage collection (GC) process the
permanent generation space (PermGen) is not cleaned up. This space stores
meta-data descriptions of classes. The default value is set too small
and it could trigger an out-of-memory error like the following:
<literallayout class='monospaced'>
Java.lang.OutOfMemoryError: PermGen space
</literallayout>
This error causes the applications to hang.
</para>
</note>
<para>
To fix this issue you can use the <filename>-vmargs</filename>
option when you start Eclipse to increase the size of the permanent generation space:
<literallayout class='monospaced'>
Eclipse -vmargs -XX:PermSize=256M
</literallayout>
</para>
</section>
<section id="installing-the-yocto-plug-in">
<title>Installing the Yocto Plug-in</title>
<para>
Once you have the Eclipse IDE installed and configured you need to install the
Yocto plug-in. You do this similar to installing the Eclipse plug-ins in the
previous section.
</para>
<para>
Do the following to install the Yocto plug-in into the Eclipse IDE:
<orderedlist>
<listitem><para>Select the "Help -> Install New Software" item.</para></listitem>
<listitem><para>In the "Work with:" area click "Add..." and enter the URL for
the Yocto plug-in, which is
<ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink></para></listitem>
<listitem><para>Finish out the installation of the update similar to any other
Eclipse plug-in.</para></listitem>
</orderedlist>
</para>
</section>
<section id="configuring-yocto-eclipse-plug-in">
<title>Configuring Yocto Eclipse plug-in</title>
<para>
To configure the Yocto Eclipse plug-in you need to select the mode and the
architecture with which you will be working. Start by selecting "Preferences"
from the "Window" menu and then select "Yocto SDK".
</para>
<para>
If you normally will use an installed Yocto
SDK (under <filename>/opt/poky</filename>) select “SDK Root Mode”. Otherwise, if your crosstool chain
and sysroot are within your poky tree, select “Poky Tree Mode”.
If you are in SDK Root Mode you need to provide your poky tree path, for
example, <filename>$&lt;Poky_tree&gt;/build/</filename>.
</para>
<para>
Next, you need to select the architecture.
Use the drop down list and select the architecture that youll be primarily
working against.
For target option, select your typical target QEMU vs External hardware. If you
choose QEMU, youll need to specify your QEMU kernel file with full path and the
rootfs mount point. Yocto QEMU boots off user mode NFS.
See the <link linkend='platdev-appdev-qemu'>Developing Externally in QEMU</link> section for
how to set it up.
</para>
<para>
To make your settings the defaults for every new Yocto project created using
the Eclipse IDE, simply save the settings.
</para>
</section>
<section id="using-the-yocto-eclipse-plug-in">
<title>Using the Yocto Eclipse Plug-in</title>
<para>
As an example, this section shows you how to cross-compile a Yocto C project that
is autotools-based, deploy the project into QEMU, and then run the debugger against it.
You need to configure the project, trigger the <filename> autogen.sh</filename>, build
the image, start QEMU, and then debug.
</para>
<para>
The following steps show how to create a Yocto autotools-based project using a given template:
</para>
<orderedlist>
<listitem><para>Select "File -> New -> Project" to start the wizard.</para></listitem>
<listitem><para>Expand "C/C++" and select "C Project".</para></listitem>
<listitem><para>Click "Next" and select a template (e.g. "Hello World ANSI C Project").</para></listitem>
<listitem><para>Complete the steps to create the new Yocto autotools-based project using
your chosen template.</para></listitem>
</orderedlist>
<para>
By default, the project uses the Yocto preferences settings as defined using the procedure in
<link linkend="configuring-yocto-eclipse-plug-in">the previous section</link>.
If there are any specific setup requirements for the newly created project
you need to reconfigure the Yocto plug-in through the menu selection by doing the following:
</para>
<orderedlist>
<listitem><para>Select the "Project -> Invoke Yocto Tools -> Reconfigure Yocto" menu item.</para></listitem>
<listitem><para>Complete the dialogue to specify the specific toolchain and QEMU setup information.</para></listitem>
</orderedlist>
<para>
To build the project follow these steps:
</para>
<orderedlist>
<listitem><para>Select "Project -> Reconfigure Project" to trigger the
<filename>autogen.sh</filename> command.</para></listitem>
<listitem><para>Select "Project -> Build" to build the project.</para></listitem>
</orderedlist>
<para>
To start QEMU follow these steps:
</para>
<orderedlist>
<listitem><para>Select "Run -> External Tools" and see if there is
a QEMU instance for the desired target.
If one exists, click on the instance to start QEMU.
If your target does not exist, click "External Tools Configuration" and
you should find an instance of QEMU for your architecture
under the entry under "Program".</para></listitem>
<listitem><para>Wait for the boot to complete.</para></listitem>
</orderedlist>
<para>
To deploy your project and start debugging follow these steps:
</para>
<orderedlist>
<listitem><para>Highlight your project in the project explorer.</para></listitem>
<listitem><para>Select "Run -> Debug Configurations" to bring up your remote debugging configuration
in the right-hand window.</para></listitem>
<listitem><para>Expand “C/C++ Remote Application”.</para></listitem>
<listitem><para>Select "projectname_ gdb_target-poky-linux".
You need to be sure there is an entry for the remote target.
If no entry exists, click "New..." to bring up the wizard.
Use the wizard to select TCF and enter the IP address of you remote target in the
“Host name:” field.
Back in the Remote Debug Configure window, specify in the
“Remote Absolute File Path for C/C++ Application” field the absolute path for the program on
the remote target.
By default, the program deploys into the remote target.
If you don't want this behavior then check “Skip download to target path”.</para></listitem>
<listitem><para>Click "Debug” to start the remote debugging session.</para></listitem>
</orderedlist>
</section>
<section id="using-yocto-eclipse-plug-in-remote-tools-suite">
<title>Using Yocto Eclipse plug-in Remote Tools Suite</title>
<para>
Remote tools allow you to perform system profiling, kernel tracing,
examine power consumption, and so forth. To see and access the remote tools use the
"Window -> YoctoTools" menu.
</para>
<para>
Once you pick a tool you need to configure it for the remote target. Every tool
needs to have the connection configured. You must select an existing TCF-based
RSE connection to the remote target. If one does not exist, click "New" to create one.
</para>
<para>
Here are some specifics about the remote tools:
<itemizedlist>
<listitem><para>OProfile: Selecting this tool causes the oprofile-server on the remote
target to launch on the local host machine. The oprofile-viewer
must be installed on the local host machine and the oprofile-server must be
installed on the remote target, respectively, in order to use .</para></listitem>
<listitem><para>lttng: Selecting this tool runs "usttrace" on the remote target, transfers
the output data back to the local host machine and uses "lttv-gui" to graphically
display the output. The "lttv-gui" must be installed on the
local host machine to use this tool.
For information on how to use "lttng" to trace an
application, see <ulink url="http://lttng.org/files/ust/manual/ust.html"></ulink>.
<para>
For "Application" you must supply the absolute path name of the application to
be traced by user mode lttng. For example, typing <filename>/path/to/foo"
</filename> triggers "usttrace /path/to/foo" on the
remote target to trace the program <filename>/path/to/foo</filename>.
</para>
<para>
"Argument" is passed to "usttrace" running on the remote target.
</para></para>
</listitem>
<listitem><para>powertop: Selecting this tool runs "powertop" on the
remote target machine and displays the results in a new view called "powertop".
<para>
"Time to gather data(sec):" is the time passed in seconds before data is
gathered from the remote target for analysis.
</para>
<para>
"show pids in wakeups list:" corresponds to the <filename>-p</filename>
argument passed to "powertop".
</para></para>
</listitem>
<listitem><para>latencytop and perf: "latencytop" identifies
system latency, while "perf" monitors the system's performance
counter registers. Selecting either of these tools causes an RSE
terminal view to appear from which you can run the tools. Both tools refresh the
entire screen to display results while they run.</para></listitem>
</itemizedlist>
</para>
</section>
</section>
<section id="the-anjuta-plug-in">
<title>The Anjuta Plug-in</title>
<note>
<para>
Support for the Anjuta plug-in ends after Yocto project 0.9 Release.
However, the source code can be downloaded from the git repository listed later in
this section.
The community is free to continue supporting it post 0.9 Release.
</para>
</note>
<para>
An Anjuta IDE plug-in exists to make developing software within the Poky framework
easier for the application developer familiar with that environment.
The plug-in presents a graphical IDE that allows you to cross-compile, cross-debug,
profile, deploy, and execute an application.
</para>
<para>
To use the plug-in, a toolchain and SDK built by Poky, Anjuta, its development headers and the Anjuta
Plug-in are all required.
The Poky Anjuta Plug-in is available to download as a tarball at the OpenedHand
labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or
directly from the Poky Git repository located at git://git.yoctoproject.org/anjuta-poky.
You can access the source code from a web interface to the repository at
<ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
</para>
<para>
See the README file contained in the project for more information on
Anjuta dependencies and building the plug-in.
If you want to disable remote gdb debugging, pass the "&dash;&dash;disable-gdb-integration" switch when
you configure the plug-in.
</para>
<section id="setting-up-the-anjuta-plugin">
<title>Setting Up the Anjuta Plug-in</title>
<para>
Follow these steps to set up the plug-in:
<orderedlist>
<listitem><para>Extract the tarball for the toolchain into / as root.
The toolchain will be installed into <filename>/opt/poky</filename>.</para></listitem>
<listitem><para>To use the plug-in, first open or create an existing project.
If you are creating a new project, the "C GTK+"
project type will allow itself to be cross-compiled.
However, you should be aware that this type uses "glade" for the UI.</para></listitem>
<listitem><para>To activate the plug-in, select "Edit -> Preferences" and then choose
"General" from the left hand side.
Choose the "Installed plug-ins" tab, scroll down to "Poky SDK" and
check the box.</para></listitem>
</orderedlist>
The plug-in is now activated but not configured.
</para>
</section>
<section id="configuring-the-anjuta-plugin">
<title>Configuring the Anjuta Plug-in</title>
<para>
You can find the configuration options for the SDK by choosing the Poky
SDK icon from the left hand side.
You need to define the following options:
<itemizedlist>
<listitem><para>SDK root: If you use an external toolchain you need to set
SDK root, which is the root directory of the SDK's sysroot.
For an i586 SDK directory is <filename>/opt/poky/</filename>.
This directory will contain "bin", "include", "var" and so forth under your
selected target architecture subdirectory
<filename>/opt/poky/sysroot/i586-poky-linux/</filename>.
The cross-compile tools you need are in
<filename>/opt/poky/sysroot/i586-pokysdk-linux/</filename>.</para></listitem>
<listitem><para>Poky root: If you have a local Poky build tree, you need to
set the Poky root, which is the root directory of the poky build tree.
If you build your i586 target architecture under the subdirectory of
<filename>build_x86</filename> within your Poky tree, the Poky root directory
should be <filename>$&lt;poky_tree&gt;/build_x86/</filename>.</para></listitem>
<listitem><para>Target Architecture: This is the cross compile triplet,
for example, "i586-poky-linux".
This target triplet is the prefix extracted from the set up script file's name.
For example, if the script file name is
<filename>/opt/poky/environment-setup-i586-poky-linux</filename> then the extracted target
triplet is "i586-poky-linux".</para></listitem>
<listitem><para>Kernel: Use the file chooser to select the kernel used with QEMU.</para></listitem>
<listitem><para>Root filesystem: Use the file chooser to select the root
filesystem directory. This directory is where you use "runqemu-extract-sdk" to extract the
core-image-sdk tarball.</para></listitem>
</itemizedlist>
</para>
</section>
<section id="using-the-anjuta-plug-in">
<title>Using the Anjuta Plug-in</title>
<para>
The steps in this section show how to cross-compile a project, deploy it into
QEMU, run a debugger against it and then perform a system-wide profile.
<orderedlist>
<listitem><para>Choose "Build -> Run Configure" or "Build -> Run Autogenerate" to run
"configure" or "autogen", respectively for the project.
Either command passes command-line arguments to instruct the
cross-compile.</para></listitem>
<listitem><para>Choose "Build -> Build Project" to build and compile the project.
If you have previously built the project in the same tree without using
the cross-compiler you might find that your project fails to link.
If this is the case, simply select "Build -> Clean Project" to remove the
old binaries.
After you clean the project you can then try building it again.</para></listitem>
<listitem><para>Choose "Tools -> Start QEMU" to start QEMU.
After QEMU starts any error messages will appear in the message view.
Once Poky has fully booted within QEMU you can deploy the project
into it.</para></listitem>
<listitem><para>Once the project is built and you have QEMU running choose
"Tools -> Deploy" to install the package into a temporary
directory and then copy it using "rsync" over SSH into the target.
A progress bar and appropriate messages appear in the message view.</para></listitem>
<listitem><para>To debug a program installed onto the target choose
"Tools -> Debug remote".
Choosing this menu item causes prompts to appear to define the local binary
for debugging and also for the command line used to run on the target.
When you provide the command line be sure to include the full path to the to binary
installed in the target.
When the command line runs a "gdbserver" over SSH is started on the target and
an instance of "cross-gdb" starts in a local terminal.
The instance of "cross-gdb" will be preloaded to connect to the server and use the SDK root to
find symbols.
It also connects to the target and loads in various libraries as well as the
target program.
You should define any breakpoints or watchpoints at this point in the process since you might not
be able to interrupt the execution later.
To stop the debugger on the target choose "Tools -> Stop debugger".</para></listitem>
<listitem><para>It is also possible to execute a command in the target over SSH.
Doing so causes the appropriate environment to be established for execution.
To execute a command choose "Choose Tools -> Run remote".
This selection opens a terminal with the SSH command inside.</para></listitem>
<listitem><para>To perform a system-wide profile against the system running in QEMU choose
"Tools -> Profile remote".
This choice starts up "OProfileUI" with the appropriate parameters to
connect to the server running inside QEMU and also supplies the path
for debug information necessary to get a useful profile.</para></listitem>
</orderedlist>
</para>
</section>
</section>
-->
</section>
</section>
<section id="platdev-appdev-qemu">
<title>Developing Externally in QEMU</title>
<title>External Development Using the QEMU Emulator</title>
<para>
Running Poky QEMU images is covered in the
<ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
</para>
<para>
Poky's QEMU images contain a complete native toolchain. This means
you can develop applications within QEMU similar to the way you would in a normal system.
Using qemux86 on an x86 machine is fast since the
guest and host architectures match.
On the other hand, using qemuarm can be 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. If "runqemu" was used to start
QEMU, and "distccd" is present on the host system, any Bitbake cross-compiling
toolchain available from the build system is automatically
used from within QEMU simply by calling "distcc". You can accomplish this by defining the
cross-compiler variable (e.g. <filename>export CC="distcc"</filename>).
Alternatively, if a suitable SDK/toolchain is present in
<filename>/opt/poky</filename> it is also
automatically be used.
The QEMU images shipped with the Yocto Project contain complete toolchains
native to specific target architectures.
This support allows you to develop applications within QEMU similar to the way
you would using a normal host development system.
</para>
<para>
Speed can be an issue depending on the target and host architecture mix.
For example, using the <filename>qemux86</filename> image in the emulator
on an Intel-based 32-bit (x86) host machine is fast because the target and
host architectures match.
On the other hand, using the <filename>qemuarm</filename> image on the same Intel-based
host can be slower.
But, you still achieve faithful emulation of ARM-specific issues.
</para>
<para>
There are several options for connecting into the emulated system.
QEMU provides a framebuffer interface that has standard consoles
available. There is also a serial connection available that has a
console to the system running on it and uses standard IP networking.
The images have a dropbear ssh server running with the root password
disabled to allow standard ssh and scp commands to work. The images
also contain an NFS server that exports the guest's root filesystem, which
allows it to be made available to the host.
To speed things up, the QEMU images support using <filename>distcc</filename>
to call a cross-compiler outside the emulated system.
If you used <filename>runqemu</filename> to start QEMU, and
<filename>distccd</filename> is present on the host system, any BitBake cross-compiling
toolchain available from the build system is automatically
used from within QEMU simply by calling <filename>distcc</filename>.
You can accomplish this by defining the cross-compiler variable
(e.g. <filename>export CC="distcc"</filename>).
Alternatively, if a suitable SDK/toolchain is present in
<filename>/opt/poky</filename> the toolchain is also automatically used.
</para>
<para>
Several mechanisms exist that let you connect into the system running on the
QEMU emulator:
<itemizedlist>
<listitem><para>QEMU provides a framebuffer interface that makes standard
consoles available.</para></listitem>
<listitem><para>Generally, headless embedded devices have a serial port.
If so, you can configure the operating system of the running image
to use that port to run a console.
The connection uses standard IP networking.</para></listitem>
<listitem><para>The QEMU images have a Dropbear secure shell (ssh) server
that runs with the root password disabled.
This allows you to use standard <filename>ssh</filename> and
<filename>scp</filename> commands.</para></listitem>
<listitem><para>The QEMU images also contain an embedded Network Files
System (NFS) server that exports the image's root filesystem.
This allows you to make the filesystem available to the
host.</para></listitem>
</itemizedlist>
</para>
</section>
<section id="platdev-appdev-insitu">
<title>Developing in Poky Directly</title>
<title>Development Using Yocto Project 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>
Working directly with the Yocto Project is a fast and effective development technique.
The idea is that you can directly edit files in a working directory
(<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:
@ -505,6 +175,11 @@
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
$ cd matchbox-desktop-2
$ vi src/main.c
.
.
[Make your changes]
.
.
$ exit
$ bitbake matchbox-desktop -c compile -f
$ bitbake matchbox-desktop
@ -512,34 +187,56 @@
</para>
<para>
This example builds the package, changes into the work directory for the package,
changes a file, then recompiles the package. Instead of using "sh" as it is in the example,
you can also use two different terminals. However, the risk of using two terminals
is that a command like "unpack" could destroy the changes you've made to the
work directory. Consequently, you need to work carefully.
This example builds the <filename>matchbox-desktop</filename> package,
creates a new terminal, changes into the work directory for the package,
changes a file, exits out of the terminal, and then recompiles the
package.
Instead of using <filename>sh</filename>,
you can also use two different terminals.
However, the risk of using two terminals is that a command like
<filename>unpack</filename> could destroy your changes in the
work directory.
Consequently, 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. You can copy the resulting patches
into the recipe directory and use them directly in the <glossterm><link
linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
so using the Quilt tool as detailed in the
<link linkend='usingpoky-modifying-packages-quilt'>
Modifying Package Source Code with Quilt</link> section.
Using Quilt, you can copy patches into the recipe directory and use the patches directly
through use of the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable.
</para>
<para>
For a review of the skills used in this section see the <link
linkend="usingpoky-components-bitbake">Bitbake</link> and <link
linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> Sections.
For a review of the skills used in this section, see the
<link linkend="usingpoky-components-bitbake">BitBake</link> and
<link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> sections
in this manual.
</para>
</section>
<section id="platdev-appdev-devshell">
<title>Developing with 'devshell'</title>
<title>Development Within a Development Shell</title>
<para>
When debugging certain commands or even when just editing packages, the
'devshell' can be a useful tool.
Use a command like the following to start this tool.
When debugging certain commands or even when just editing packages,
<filename>devshell</filename> can be a useful tool.
Using <filename>devshell</filename> differs from the example shown in the previous
section in that when you invoke <filename>devshell</filename> source files are
extracted into your working directory and patches are applied.
Then, a new terminal is opened and you are placed in the working directory.
In the new terminal all the Yocto Project build-related environment variables are
still defined so you can use commands such as <filename>configure</filename> and
<filename>make</filename>.
The commands execute just as if the Yocto Project build system were executing them.
Consequently, workng this way can be helpful when debugging a build or preparing
software to be used with the Yocto Project build system.
</para>
<para>
Following is an example that uses <filename>devshell</filename> on a target named
<filename>matchbox-desktop</filename>:
</para>
<para>
@ -550,62 +247,77 @@
<para>
This command opens a terminal with a shell prompt within the Poky
environment. Consequently, the following occurs:
environment.
The following occurs:
<itemizedlist>
<listitem><para>The PATH variable includes the cross toolchain.</para></listitem>
<listitem><para>The pkgconfig variables find the correct <filename>.pc</filename> files.</para></listitem>
<listitem><para>"configure" finds the Poky site files as well as any other necessary files.</para></listitem>
<listitem><para>The <filename>PATH</filename> variable includes the
cross-toolchain.</para></listitem>
<listitem><para>The <filename>pkgconfig</filename> variables find the correct
<filename>.pc</filename> files.</para></listitem>
<listitem><para>The <filename>configure</filename> command finds the
Yocto Project site files as well as any other necessary files.</para></listitem>
</itemizedlist>
Within this environment, you can run "configure" or "compile" commands as if they
were being run by Poky itself.
The working directory also automatically changes to the (<glossterm><link linkend='var-S'>S</link></glossterm>)
directory.
Within this environment, you can run <filename>configure</filename>
or <filename>compile</filename> commands as if they were being run by
the Yocto Project build system itself.
As noted earlier, the working directory also automatically changes to the
source directory (<glossterm><link linkend='var-S'>S</link></glossterm>).
</para>
<para>
When you are finished, you just exit the shell or close the terminal window.
</para>
<para>
The default shell used by "devshell" is the gnome-terminal.
You can use other forms of terminal can by setting the <glossterm>
<link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and <glossterm>
<link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables
in <filename>local.conf</filename>.
For examples of the other options available, see
<filename>meta/conf/bitbake.conf</filename>.
</para>
<para>
An external shell is launched rather than opening directly into the original terminal
window.
This allows easier interaction with Bitbake's multiple threads as well as
for a future client/server split.
Note that "devshell" will still work over X11 forwarding or similar situations.
The default shell used by <filename>devshell</filename> is the GNOME Terminal.
You can use other terminal forms by setting the
<glossterm><link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and
<glossterm><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables
in the Yocto Project's <filename>local.conf</filename> file found in the build
directory.
For examples of the other options available, see the "UI/Interaction Configuration"
section of the
<filename>meta/conf/bitbake.conf</filename> configuration file in the Yocto Project
files.
</para>
<para>
It is worth remembering that inside "devshell" you need to use the full
compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
instead of just <filename>gcc</filename>.
The same applies to other applications such as gcc, bintuils, libtool and so forth.
Poky will have setup environmental variables such as CC to assist applications, such as make,
find the correct tools.
Because an external shell is launched rather than opening directly into the
original terminal window, it allows easier interaction with Bitbake's multiple
threads as well as accomodates a future client/server split.
</para>
<note>
<para>It is worth remembering that when using <filename>devshell</filename>
you need to use the full compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
instead of just using <filename>gcc</filename>.
The same applies to other applications such as <filename>bintuils</filename>,
<filename>libtool</filename> and so forth.
The Yocto Project has setup environment variables such as <filename>CC</filename>
to assist applications, such as <filename>make</filename> to find the correct tools.</para>
<para>It is also worth noting that <filename>devshell</filename> still works over
X11 forwarding and similar situations</para>
</note>
</section>
<section id="platdev-appdev-srcrev">
<title>Developing within Poky with an External SCM-based Package</title>
<title>Development Within Yocto Project for a Package that Uses an External SCM</title>
<para>
If you're working on a recipe that pulls from an external SCM it
is possible to have Poky notice new changes added to the
SCM and then build the latest version using them.
If you're working on a recipe that pulls from an external Source Code Manager (SCM), it
is possible to have the Yocto Project build system notice new changes added to the
SCM and then build the package that depends on them using the latest version.
This only works for SCMs from which it is possible to get a sensible revision number for changes.
Currently it works for svn, git and bzr repositories.
Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories.
</para>
<para>
To enable this behavior simply add <glossterm>
<link linkend='var-SRCREV'>SRCREV</link></glossterm>_pn-<glossterm>
<link linkend='var-PN'>PN</link></glossterm> = "${AUTOREV}" to
<filename>local.conf</filename>, where <glossterm><link linkend='var-PN'>PN</link></glossterm>
To enable this behavior, simply add the following to the <filename>local.conf</filename>
configuration file in the build directory of the Yocto Project files:
<literallayout class='monospaced'>
SRCREV_pn-&lt;PN&gt; = "${AUTOREV}"
</literallayout>
where <filename>PN</filename>
is the name of the package for which you want to enable automatic source
revision updating.
</para>