Gitiles
Code Review Sign In
gerrit.openbmc.org / stefanberger / openbmc / f1e5d6968976c2341c6d554bfcc8895f1b33c26b / . / documentation / dev-manual / dev-manual-model.xml
blob: 6e42c7b3915378bafd659ba481319c7643d2487c [file] [log] [blame]
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<chapter id='dev-manual-model'>
<title>Common Development Models</title>
<para>
Many development models exist for which you can use the Yocto Project.
This chapter overviews simple methods that use tools provided by the
Yocto Project:
<itemizedlist>
<listitem><para><emphasis>System Development:</emphasis>
System Development covers Board Support Package (BSP) development
and kernel modification or configuration.
For an example on how to create a BSP, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
section in the Yocto Project Board Support Package (BSP)
Developer's Guide.
For more complete information on how to work with the kernel,
see the
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
</para></listitem>
<listitem><para><emphasis>User Application Development:</emphasis>
User Application Development covers development of applications
that you intend to run on target hardware.
For information on how to set up your host development system for
user-space application development, see the
<ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
For a simple example of user-space application development using
the <trademark class='trade'>Eclipse</trademark> IDE, see the
"<link linkend='application-development-workflow'>Application
Development Workflow</link>" section.
</para></listitem>
<listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
Direct modification of temporary source code is a convenient
development model to quickly iterate and develop towards a
solution.
Once you implement the solution, you should of course take
steps to get the changes upstream and applied in the affected
recipes.
</para></listitem>
<listitem><para><emphasis>Image Development using Toaster:</emphasis>
You can use <ulink url='&YOCTO_HOME_URL;/Tools-resources/projects/toaster'>Toaster</ulink>
to build custom operating system images within the build
environment.
Toaster provides an efficient interface to the OpenEmbedded build
that allows you to start builds and examine build statistics.
</para></listitem>
<listitem><para><emphasis>Image Development using Hob:</emphasis>
You can use the <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>
to build custom operating system images within the build
environment.
Hob provides an efficient interface to the OpenEmbedded build system.
</para></listitem>
<listitem><para><emphasis>Using a Development Shell:</emphasis>
You can use a <filename>devshell</filename> to efficiently debug
commands or simply edit packages.
Working inside a development shell is a quick way to set up the
OpenEmbedded build environment to work on parts of a project.
</para></listitem>
</itemizedlist>
</para>
<section id='system-development-model'>
<title>System Development Workflow</title>
<para>
System development involves modification or creation of an image that you want to run on
a specific hardware target.
Usually, when you want to create an image that runs on embedded hardware, the image does
not require the same number of features that a full-fledged Linux distribution provides.
Thus, you can create a much smaller image that is designed to use only the
features for your particular hardware.
</para>
<para>
To help you understand how system development works in the Yocto Project, this section
covers two types of image development: BSP creation and kernel modification or
configuration.
</para>
<section id='developing-a-board-support-package-bsp'>
<title>Developing a Board Support Package (BSP)</title>
<para>
A BSP is a collection of recipes that, when applied during a build, results in
an image that you can run on a particular board.
Thus, the package when compiled into the new image, supports the operation of the board.
</para>
<note>
For a brief list of terms used when describing the development process in the Yocto Project,
see the "<link linkend='yocto-project-terms'>Yocto Project Terms</link>" section.
</note>
<para>
The remainder of this section presents the basic
steps used to create a BSP using the Yocto Project's
<ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>BSP Tools</ulink>.
Although not required for BSP creation, the
<filename>meta-intel</filename> repository, which contains
many BSPs supported by the Yocto Project, is part of the example.
</para>
<para>
For an example that shows how to create a new layer using the tools, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
section in the Yocto Project Board Support Package (BSP) Developer's Guide.
</para>
<para>
The following illustration and list summarize the BSP creation general workflow.
</para>
<para>
<imagedata fileref="figures/bsp-dev-flow.png" width="6in" depth="7in" align="center" scalefit="1" />
</para>
<para>
<orderedlist>
<listitem><para><emphasis>Set up your host development system to support
development using the Yocto Project</emphasis>: See the
"<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>"
and the
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>" sections both
in the Yocto Project Quick Start for requirements.</para></listitem>
<listitem><para><emphasis>Establish a local copy of the project files on your
system</emphasis>: You need this <link linkend='source-directory'>Source
Directory</link> available on your host system.
Having these files on your system gives you access to the build
process and to the tools you need.
For information on how to set up the Source Directory,
see the
"<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
<listitem><para><emphasis>Establish the <filename>meta-intel</filename>
repository on your system</emphasis>: Having local copies
of these supported BSP layers on your system gives you
access to layers you might be able to build on or modify
to create your BSP.
For information on how to get these files, see the
"<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
<listitem><para><emphasis>Create your own BSP layer using the
<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:
Layers are ideal for
isolating and storing work for a given piece of hardware.
A layer is really just a location or area in which you place
the recipes and configurations for your BSP.
In fact, a BSP is, in itself, a special type of layer.
The simplest way to create a new BSP layer that is compliant with the
Yocto Project is to use the <filename>yocto-bsp</filename> script.
For information about that script, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
section in the Yocto Project Board Support (BSP) Developer's Guide.
</para>
<para>
Another example that illustrates a layer is an application.
Suppose you are creating an application that has library or other dependencies in
order for it to compile and run.
The layer, in this case, would be where all the recipes that define those dependencies
are kept.
The key point for a layer is that it is an isolated area that contains
all the relevant information for the project that the OpenEmbedded build
system knows about.
For more information on layers, see the
"<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
section.
For more information on BSP layers, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the
Yocto Project Board Support Package (BSP) Developer's Guide.</para>
<note>Five BSPs exist that are part of the
Yocto Project release: <filename>genericx86</filename>, <filename>genericx86-64</filename>,
<filename>beaglebone</filename> (ARM),
<filename>mpc8315e</filename> (PowerPC),
and <filename>edgerouter</filename> (MIPS).
The recipes and configurations for these five BSPs are located and dispersed
within the <link linkend='source-directory'>Source Directory</link>.
On the other hand, the <filename>meta-intel</filename> layer
contains BSP layers for many supported BSPs (e.g.
Crystal Forest, Emenlow, Fish River Island 2, Haswell,
Jasper Forest, and so forth).
Aside from the BSPs in the <filename>meta-intel</filename>
layer, the
<ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
contain additional BSP layers such as
<filename>meta-minnow</filename> and
<filename>meta-raspberrypi</filename>.</note>
<para>When you set up a layer for a new BSP, you should follow a standard layout.
This layout is described in the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
section of the Board Support Package (BSP) Development Guide.
In the standard layout, you will notice a suggested structure for recipes and
configuration information.
You can see the standard layout for a BSP by examining
any supported BSP found in the <filename>meta-intel</filename> layer inside
the Source Directory.</para></listitem>
<listitem><para><emphasis>Make configuration changes to your new BSP
layer</emphasis>: The standard BSP layer structure organizes the files you need
to edit in <filename>conf</filename> and several <filename>recipes-*</filename>
directories within the BSP layer.
Configuration changes identify where your new layer is on the local system
and identify which kernel you are going to use.
When you run the <filename>yocto-bsp</filename> script, you are able to interactively
configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
</para></listitem>
<listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>: Recipe
changes include altering recipes (<filename>.bb</filename> files), removing
recipes you do not use, and adding new recipes or append files
(<filename>.bbappend</filename>) that you need to support your hardware.
</para></listitem>
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
changes to your BSP layer, there remains a few things
you need to do for the OpenEmbedded build system in order for it to create your image.
You need to get the build environment ready by sourcing an environment setup script
(i.e. <filename>oe-init-build-env</filename> or
<filename>oe-init-build-env-memres</filename>)
and you need to be sure two key configuration files are configured appropriately:
the <filename>conf/local.conf</filename> and the
<filename>conf/bblayers.conf</filename> file.
You must make the OpenEmbedded build system aware of your new layer.
See the
"<link linkend='enabling-your-layer'>Enabling Your Layer</link>" section
for information on how to let the build system know about your new layer.</para>
<para>The entire process for building an image is overviewed in the section
"<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>" section
of the Yocto Project Quick Start.
You might want to reference this information.</para></listitem>
<listitem><para><emphasis>Build the image</emphasis>: The OpenEmbedded build system
uses the BitBake tool to build images based on the type of image you want to create.
You can find more information about BitBake in the
<ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
</para>
<para>The build process supports several types of images to satisfy different needs.
See the
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter
in the Yocto Project Reference Manual for information on
supported images.</para></listitem>
</orderedlist>
</para>
<para>
You can view a video presentation on "Building Custom Embedded Images with Yocto"
at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.
After going to the page, just search for "Embedded".
You can also find supplemental information in the
<ulink url='&YOCTO_DOCS_BSP_URL;'>
Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
Finally, there is helpful material and links on this
<ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>wiki page</ulink>.
Although a bit dated, you might find the information on the wiki
helpful.
</para>
</section>
<section id='modifying-the-kernel'>
<title><anchor id='kernel-spot' />Modifying the Kernel</title>
<para>
Kernel modification involves changing the Yocto Project kernel, which could involve changing
configuration options as well as adding new kernel recipes.
Configuration changes can be added in the form of configuration fragments, while recipe
modification comes through the kernel's <filename>recipes-kernel</filename> area
in a kernel layer you create.
</para>
<para>
The remainder of this section presents a high-level overview of the Yocto Project
kernel architecture and the steps to modify the kernel.
You can reference the
"<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
for an example that changes the source code of the kernel.
For information on how to configure the kernel, see the
"<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section.
For more information on the kernel and on modifying the kernel, see the
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
</para>
<section id='kernel-overview'>
<title>Kernel Overview</title>
<para>
Traditionally, when one thinks of a patched kernel, they think of a base kernel
source tree and a fixed structure that contains kernel patches.
The Yocto Project, however, employs mechanisms that, in a sense, result in a kernel source
generator.
By the end of this section, this analogy will become clearer.
</para>
<para>
You can find a web interface to the Yocto Project kernel source repositories at
<ulink url='&YOCTO_GIT_URL;'></ulink>.
If you look at the interface, you will see to the left a grouping of
Git repositories titled "Yocto Linux Kernel."
Within this group, you will find several kernels supported by
the Yocto Project:
<itemizedlist>
<listitem><para><emphasis>
<filename>linux-yocto-3.8</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
Project Release 1.4. This kernel is based on the
Linux 3.8 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-3.10</filename></emphasis> - An
additional, unsupported Yocto Project kernel used with
the Yocto Project Release 1.5.
This kernel is based on the Linux 3.10 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-3.14</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
Project Releases 1.6 and 1.7.
This kernel is based on the Linux 3.14 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-3.17</filename></emphasis> - An
additional, unsupported Yocto Project kernel used with
the Yocto Project Release 1.7.
This kernel is based on the Linux 3.17 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-3.19</filename></emphasis> - The
stable Yocto Project kernel to use with the Yocto
Project Release 1.8.
This kernel is based on the Linux 3.19 released kernel.
</para></listitem>
<listitem><para><emphasis>
<filename>linux-yocto-dev</filename></emphasis> - A
development kernel based on the latest upstream release
candidate available.
</para></listitem>
</itemizedlist>
</para>
<para>
The kernels are maintained using the Git revision control system
that structures them using the familiar "tree", "branch", and "leaf" scheme.
Branches represent diversions from general code to more specific code, while leaves
represent the end-points for a complete and unique kernel whose source files,
when gathered from the root of the tree to the leaf, accumulate to create the files
necessary for a specific piece of hardware and its features.
The following figure displays this concept:
<para>
<imagedata fileref="figures/kernel-overview-1.png"
width="6in" depth="6in" align="center" scale="100" />
</para>
<para>
Within the figure, the "Kernel.org Branch Point" represents the point in the tree
where a supported base kernel is modified from the Linux kernel.
For example, this could be the branch point for the <filename>linux-yocto-3.19</filename>
kernel.
Thus, everything further to the right in the structure is based on the
<filename>linux-yocto-3.19</filename> kernel.
Branch points to the right in the figure represent where the
<filename>linux-yocto-3.19</filename> kernel is modified for specific hardware
or types of kernels, such as real-time kernels.
Each leaf thus represents the end-point for a kernel designed to run on a specific
targeted device.
</para>
<para>
The overall result is a Git-maintained repository from which all the supported
kernel types can be derived for all the supported devices.
A big advantage to this scheme is the sharing of common features by keeping them in
"larger" branches within the tree.
This practice eliminates redundant storage of similar features shared among kernels.
</para>
<note>
Keep in mind the figure does not take into account all the supported Yocto
Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
Also keep in mind that this structure represents the Yocto Project source repositories
that are either pulled from during the build or established on the host development system
prior to the build by either cloning a particular kernel's Git repository or by
downloading and unpacking a tarball.
</note>
<para>
Upstream storage of all the available kernel source code is one thing, while
representing and using the code on your host development system is another.
Conceptually, you can think of the kernel source repositories as all the
source files necessary for all the supported kernels.
As a developer, you are just interested in the source files for the kernel on
which you are working.
And, furthermore, you need them available on your host system.
</para>
<para>
Kernel source code is available on your host system a couple of different
ways.
If you are working in the kernel all the time, you probably would want
to set up your own local Git repository of the kernel tree.
If you just need to make some patches to the kernel, you can access
temporary kernel source files that were extracted and used
during a build.
We will just talk about working with the temporary source code.
For more information on how to get kernel source code onto your
host system, see the
"<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
bulleted item earlier in the manual.
</para>
<para>
What happens during the build?
When you build the kernel on your development system, all files needed for the build
are taken from the source repositories pointed to by the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable
and gathered in a temporary work area
where they are subsequently used to create the unique kernel.
Thus, in a sense, the process constructs a local source tree specific to your
kernel to generate the new kernel image - a source generator if you will.
</para>
The following figure shows the temporary file structure
created on your host system when the build occurs.
This
<link linkend='build-directory'>Build Directory</link> contains all the
source files used during the build.
</para>
<para>
<imagedata fileref="figures/kernel-overview-2-generic.png"
width="6in" depth="5in" align="center" scale="100" />
</para>
<para>
Again, for additional information on the Yocto Project kernel's
architecture and its branching strategy, see the
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
You can also reference the
"<link linkend='patching-the-kernel'>Patching the Kernel</link>"
section for a detailed example that modifies the kernel.
</para>
</section>
<section id='kernel-modification-workflow'>
<title>Kernel Modification Workflow</title>
<para>
This illustration and the following list summarizes the kernel modification general workflow.
</para>
<para>
<imagedata fileref="figures/kernel-dev-flow.png"
width="6in" depth="5in" align="center" scalefit="1" />
</para>
<para>
<orderedlist>
<listitem><para><emphasis>Set up your host development system to support
development using the Yocto Project</emphasis>: See
"<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>" sections both
in the Yocto Project Quick Start for requirements.</para></listitem>
<listitem><para><emphasis>Establish a local copy of project files on your
system</emphasis>: Having the <link linkend='source-directory'>Source
Directory</link> on your system gives you access to the build process and tools
you need.
For information on how to get these files, see the bulleted item
"<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
</para></listitem>
<listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:
Temporary kernel source files are kept in the
<link linkend='build-directory'>Build Directory</link>
created by the
OpenEmbedded build system when you run BitBake.
If you have never built the kernel in which you are
interested, you need to run an initial build to
establish local kernel source files.</para>
<para>If you are building an image for the first time, you need to get the build
environment ready by sourcing an environment setup script
(i.e. <filename>oe-init-build-env</filename> or
<filename>oe-init-build-env-memres</filename>).
You also need to be sure two key configuration files
(<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
are configured appropriately.</para>
<para>The entire process for building an image is overviewed in the
"<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
section of the Yocto Project Quick Start.
You might want to reference this information.
You can find more information on BitBake in the
<ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
</para>
<para>The build process supports several types of images to satisfy different needs.
See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
the Yocto Project Reference Manual for information on supported images.
</para></listitem>
<listitem><para><emphasis>Make changes to the kernel source code if
applicable</emphasis>: Modifying the kernel does not always mean directly
changing source files.
However, if you have to do this, you make the changes to the files in the
Build Directory.</para></listitem>
<listitem><para><emphasis>Make kernel configuration changes if applicable</emphasis>:
If your situation calls for changing the kernel's
configuration, you can use
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#generating-configuration-files'><filename>menuconfig</filename></ulink>,
which allows you to interactively develop and test the
configuration changes you are making to the kernel.
Saving changes you make with
<filename>menuconfig</filename> updates
the kernel's <filename>.config</filename> file.
<note><title>Warning</title>
Try to resist the temptation to directly edit an
existing <filename>.config</filename> file, which is
found in the Build Directory at
<filename>tmp/sysroots/<replaceable>machine-name</replaceable>/kernel</filename>.
Doing so, can produce unexpected results when the
OpenEmbedded build system regenerates the configuration
file.
</note>
Once you are satisfied with the configuration
changes made using <filename>menuconfig</filename>
and you have saved them, you can directly compare the
resulting <filename>.config</filename> file against an
existing original and gather those changes into a
<link linkend='creating-config-fragments'>configuration fragment file</link>
to be referenced from within the kernel's
<filename>.bbappend</filename> file.</para>
<para>Additionally, if you are working in a BSP layer
and need to modify the BSP's kernel's configuration,
you can use the
<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'><filename>yocto-kernel</filename></ulink>
script as well as <filename>menuconfig</filename>.
The <filename>yocto-kernel</filename> script lets
you interactively set up kernel configurations.
</para></listitem>
<listitem><para><emphasis>Rebuild the kernel image with your changes</emphasis>:
Rebuilding the kernel image applies your changes.
</para></listitem>
</orderedlist>
</para>
</section>
</section>
</section>
<section id='application-development-workflow'>
<title>Application Development Workflow</title>
<para>
Application development involves creating an application that you want
to run on your target hardware, which is running a kernel image created using the
OpenEmbedded build system.
The Yocto Project provides an
<ulink url='&YOCTO_DOCS_ADT_URL;#adt-intro'>Application Development Toolkit (ADT)</ulink>
and stand-alone
<ulink url='&YOCTO_DOCS_ADT_URL;#the-cross-development-toolchain'>cross-development toolchains</ulink>
that facilitate quick development and integration of your application into its runtime environment.
Using the ADT and toolchains, you can compile and link your application.
You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE,
you can use an Eclipse Yocto Plug-in to
allow you to develop, deploy, and test your application all from within Eclipse.
</para>
<para>
While we strongly suggest using the ADT to develop your application, this option might not
be best for you.
If this is the case, you can still use pieces of the Yocto Project for your development process.
However, because the process can vary greatly, this manual does not provide detail on the process.
</para>
<section id='workflow-using-the-adt-and-eclipse'>
<title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
<para>
To help you understand how application development works using the ADT, this section
provides an overview of the general development process and a detailed example of the process
as it is used from within the Eclipse IDE.
</para>
<para>
The following illustration and list summarize the application development general workflow.
</para>
<para>
<imagedata fileref="figures/app-dev-flow.png"
width="7in" depth="8in" align="center" scale="100" />
</para>
<para>
<orderedlist>
<listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
See
"<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
and
"<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" sections both
in the Yocto Project Reference Manual for requirements.
In particular, be sure your host system has the
<filename>xterm</filename> package installed.
</para></listitem>
<listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
You must have a target kernel image that has been built using the OpenEmbedded
build system.</para>
<para>Depending on whether the Yocto Project has a pre-built image that matches your target
architecture and where you are going to run the image while you develop your application
(QEMU or real hardware), the area from which you get the image differs.
<itemizedlist>
<listitem><para>Download the image from
<ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
if your target architecture is supported and you are going to develop
and test your application on actual hardware.</para></listitem>
<listitem><para>Download the image from
<ulink url='&YOCTO_QEMU_DL_URL;'>
<filename>machines/qemu</filename></ulink> if your target architecture is supported
and you are going to develop and test your application using the QEMU
emulator.</para></listitem>
<listitem><para>Build your image if you cannot find a pre-built image that matches
your target architecture.
If your target architecture is similar to a supported architecture, you can
modify the kernel image before you build it.
See the
"<link linkend='patching-the-kernel'>Patching the Kernel</link>"
section for an example.</para></listitem>
</itemizedlist></para>
<para>For information on pre-built kernel image naming schemes for images
that can run on the QEMU emulator, see the
"<ulink url='&YOCTO_DOCS_QS_URL;#downloading-the-pre-built-linux-kernel'>Downloading the Pre-Built Linux Kernel</ulink>"
section in the Yocto Project Application Developer's Guide.</para></listitem>
<listitem><para><emphasis>Install the ADT</emphasis>:
The ADT provides a target-specific cross-development toolchain, the root filesystem,
the QEMU emulator, and other tools that can help you develop your application.
While it is possible to get these pieces separately, the ADT Installer provides an
easy, inclusive method.
You can get these pieces by running an ADT installer script, which is configurable.
For information on how to install the ADT, see the
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
section
in the Yocto Project Application Developer's Guide.</para></listitem>
<listitem><para><emphasis>If applicable, secure the target root filesystem
and the Cross-development toolchain</emphasis>:
If you choose not to install the ADT using the ADT Installer,
you need to find and download the appropriate root filesystem and
the cross-development toolchain.</para>
<para>You can find the tarballs for the root filesystem in the same area used
for the kernel image.
Depending on the type of image you are running, the root filesystem you need differs.
For example, if you are developing an application that runs on an image that
supports Sato, you need to get a root filesystem that supports Sato.</para>
<para>You can find the cross-development toolchains at
<ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
Be sure to get the correct toolchain for your development host and your
target architecture.
See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
section in the Yocto Project Application Developer's Guide for information
and the
"<ulink url='&YOCTO_DOCS_QS_URL;#installing-the-toolchain'>Installing the Toolchain</ulink>"
in the Yocto Project Application Developer's Guide for information on finding and installing
the correct toolchain based on your host development system and your target
architecture.
</para></listitem>
<listitem><para><emphasis>Create and build your application</emphasis>:
At this point, you need to have source files for your application.
Once you have the files, you can use the Eclipse IDE to import them and build the
project.
If you are not using Eclipse, you need to use the cross-development tools you have
installed to create the image.</para></listitem>
<listitem><para><emphasis>Deploy the image with the application</emphasis>:
If you are using the Eclipse IDE, you can deploy your image to the hardware or to
QEMU through the project's preferences.
If you are not using the Eclipse IDE, then you need to deploy the application
to the hardware using other methods.
Or, if you are using QEMU, you need to use that tool and
load your image in for testing.
See the
"<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
chapter for information on using QEMU.
</para></listitem>
<listitem><para><emphasis>Test and debug the application</emphasis>:
Once your application is deployed, you need to test it.
Within the Eclipse IDE, you can use the debugging environment along with the
set of user-space tools installed along with the ADT to debug your application.
Of course, the same user-space tools are available separately if you choose
not to use the Eclipse IDE.</para></listitem>
</orderedlist>
</para>
</section>
<section id='adt-eclipse'>
<title>Working Within Eclipse</title>
<para>
The Eclipse IDE is a popular development environment and it fully
supports development using the Yocto Project.
<note>
This release of the Yocto Project supports both the Luna
and Kepler versions of the Eclipse IDE.
Thus, the following information provides setup information for
both versions.
</note>
</para>
<para>
When you install and configure the Eclipse Yocto Project Plug-in
into the Eclipse IDE, you maximize your Yocto Project experience.
Installing and configuring the Plug-in results in an environment
that has extensions specifically designed to let you more easily
develop software.
These extensions allow for cross-compilation, deployment, and
execution of your output into a QEMU emulation session as well as
actual target hardware.
You can also perform cross-debugging and profiling.
The environment also supports a suite of tools that allows you
to perform remote profiling, tracing, collection of power data,
collection of latency data, and collection of performance data.
</para>
<para>
This section describes how to install and configure the Eclipse IDE
Yocto Plug-in and how to use it to develop your application.
</para>
<section id='setting-up-the-eclipse-ide'>
<title>Setting Up the Eclipse IDE</title>
<para>
To develop within the Eclipse IDE, you need to do the following:
<orderedlist>
<listitem><para>Install the optimal version of the Eclipse
IDE.</para></listitem>
<listitem><para>Configure the Eclipse IDE.
</para></listitem>
<listitem><para>Install the Eclipse Yocto Plug-in.
</para></listitem>
<listitem><para>Configure the Eclipse Yocto Plug-in.
</para></listitem>
</orderedlist>
<note>
Do not install Eclipse from your distribution's package
repository.
Be sure to install Eclipse from the official Eclipse
download site as directed in the next section.
</note>
</para>
<section id='installing-eclipse-ide'>
<title>Installing the Eclipse IDE</title>
<para>
It is recommended that you have the Luna SR2 (4.4.2)
version of the Eclipse IDE installed on your development
system.
However, if you currently have the Kepler 4.3.2 version
installed and you do not want to upgrade the IDE, you can
configure Kepler to work with the Yocto Project.
</para>
<para>
If you do not have the Luna SR2 (4.4.2) Eclipse IDE
installed, you can find the tarball at
<ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
From that site, choose the appropriate download from the
"Eclipse IDE for C/C++ Developers".
This version contains the Eclipse Platform, the Java
Development Tools (JDT), and the Plug-in Development
Environment.
</para>
<para>
Once you have downloaded the tarball, extract it into a
clean directory.
For example, the following commands unpack and install the
downloaded Eclipse IDE tarball into a clean directory
using the default name <filename>eclipse</filename>:
<literallayout class='monospaced'>
$ cd ~
$ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz
</literallayout>
</para>
</section>
<section id='configuring-the-eclipse-ide'>
<title>Configuring the Eclipse IDE</title>
<para>
This section presents the steps needed to configure the
Eclipse IDE.
</para>
<para>
Before installing and configuring the Eclipse Yocto Plug-in,
you need to configure the Eclipse IDE.
Follow these general steps:
<orderedlist>
<listitem><para>Start the Eclipse IDE.</para></listitem>
<listitem><para>Make sure you are in your Workbench and
select "Install New Software" from the "Help"
pull-down menu.</para></listitem>
<listitem><para>Select
<filename>Luna - &ECLIPSE_LUNA_URL;</filename>
from the "Work with:" pull-down menu.
<note>
For Kepler, select
<filename>Kepler - &ECLIPSE_KEPLER_URL;</filename>
</note>
</para></listitem>
<listitem><para>Expand the box next to "Linux Tools"
and select the
<filename>Linux Tools LTTng Tracer Control</filename>,
<filename>Linux Tools LTTng Userspace Analysis</filename>,
and
<filename>LTTng Kernel Analysis</filename> boxes.
If these selections do not appear in the list,
that means the items are already installed.
<note>
For Kepler, select
<filename>LTTng - Linux Tracing Toolkit</filename>
box.
</note>
</para></listitem>
<listitem><para>Expand the box next to "Mobile and
Device Development" and select the following boxes.
Again, if any of the following items are not
available for selection, that means the items are
already installed:
<itemizedlist>
<listitem><para><filename>C/C++ Remote Launch (Requires RSE Remote System Explorer)</filename></para></listitem>
<listitem><para><filename>Remote System Explorer End-user Runtime</filename></para></listitem>
<listitem><para><filename>Remote System Explorer User Actions</filename></para></listitem>
<listitem><para><filename>Target Management Terminal (Core SDK)</filename></para></listitem>
<listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
<listitem><para><filename>TCF Target Explorer</filename></para></listitem>
</itemizedlist></para></listitem>
<listitem><para>Expand the box next to "Programming
Languages" and select the
<filename>C/C++ Autotools Support</filename>
and <filename>C/C++ Development Tools</filename>
boxes.
For Luna, these items do not appear on the list
as they are already installed.
</para></listitem>
<listitem><para>Complete the installation and restart
the Eclipse IDE.</para></listitem>
</orderedlist>
</para>
</section>
<section id='installing-the-eclipse-yocto-plug-in'>
<title>Installing or Accessing the Eclipse Yocto Plug-in</title>
<para>
You can install the Eclipse Yocto Plug-in into the Eclipse
IDE one of two ways: use the Yocto Project's Eclipse
Update site to install the pre-built plug-in or build and
install the plug-in from the latest source code.
</para>
<section id='new-software'>
<title>Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site</title>
<para>
To install the Eclipse Yocto Plug-in from the update
site, follow these steps:
<orderedlist>
<listitem><para>Start up the Eclipse IDE.
</para></listitem>
<listitem><para>In Eclipse, select "Install New
Software" from the "Help" menu.
</para></listitem>
<listitem><para>Click "Add..." in the "Work with:"
area.</para></listitem>
<listitem><para>Enter
<filename>&ECLIPSE_DL_PLUGIN_URL;/luna</filename>
in the URL field and provide a meaningful name
in the "Name" field.
<note>
If you are using Kepler, use
<filename>&ECLIPSE_DL_PLUGIN_URL;/kepler</filename>
in the URL field.
</note></para></listitem>
<listitem><para>Click "OK" to have the entry added
to the "Work with:" drop-down list.
</para></listitem>
<listitem><para>Select the entry for the plug-in
from the "Work with:" drop-down list.
</para></listitem>
<listitem><para>Check the boxes next to
<filename>Yocto Project ADT Plug-in</filename>,
<filename>Yocto Project Bitbake Commander Plug-in</filename>,
and
<filename>Yocto Project Documentation plug-in</filename>.
</para></listitem>
<listitem><para>Complete the remaining software
installation steps and then restart the Eclipse
IDE to finish the installation of the plug-in.
<note>
You can click "OK" when prompted about
installing software that contains unsigned
content.
</note>
</para></listitem>
</orderedlist>
</para>
</section>
<section id='zip-file-method'>
<title>Installing the Plug-in Using the Latest Source Code</title>
<para>
To install the Eclipse Yocto Plug-in from the latest
source code, follow these steps:
<orderedlist>
<listitem><para>Be sure your development system
is not using OpenJDK to build the plug-in
by doing the following:
<orderedlist>
<listitem><para>Use the Oracle JDK.
If you don't have that, go to
<ulink url='http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html'></ulink>
and download the latest appropriate
Java SE Development Kit tarball for
your development system and
extract it into your home directory.
</para></listitem>
<listitem><para>In the shell you are going
to do your work, export the location of
the Oracle Java.
The previous step creates a new folder
for the extracted software.
You need to use the following
<filename>export</filename> command
and provide the specific location:
<literallayout class='monospaced'>
export PATH=~/<replaceable>extracted_jdk_location</replaceable>/bin:$PATH
</literallayout>
</para></listitem>
</orderedlist>
</para></listitem>
<listitem><para>In the same shell, create a Git
repository with:
<literallayout class='monospaced'>
$ cd ~
$ git clone git://git.yoctoproject.org/eclipse-poky
</literallayout>
</para></listitem>
<listitem><para>Be sure to checkout the correct
tag.
For example, if you are using Luna, do the
following:
<literallayout class='monospaced'>
$ git checkout luna/yocto-&DISTRO;
</literallayout>
This puts you in a detached HEAD state, which
is fine since you are only going to be building
and not developing.
<note>
If you are building kepler, checkout the
<filename>kepler/yocto-&DISTRO;</filename>
branch.
</note>
</para></listitem>
<listitem><para>Change to the
<filename>scripts</filename>
directory within the Git repository:
<literallayout class='monospaced'>
$ cd scripts
</literallayout>
</para></listitem>
<listitem><para>Set up the local build environment
by running the setup script:
<literallayout class='monospaced'>
$ ./setup.sh
</literallayout>
</para></listitem>
<listitem><para>When the script finishes execution,
it prompts you with instructions on how to run
the <filename>build.sh</filename> script, which
is also in the <filename>scripts</filename>
directory of the Git repository created
earlier.
</para></listitem>
<listitem><para>Run the <filename>build.sh</filename>
script as directed.
Be sure to provide the tag name, documentation
branch, and a release name.
Here is an example that uses the
<filename>luna/yocto-&DISTRO;</filename> tag, the
<filename>master</filename> documentation
branch, and
<filename>&DISTRO_NAME;</filename> for the
release name:
<literallayout class='monospaced'>
$ ECLIPSE_HOME=/home/scottrif/eclipse-poky/scripts/eclipse ./build.sh luna/yocto-&DISTRO; master &DISTRO_NAME; 2>&amp;1 | tee -a build.log
</literallayout>
After running the script, the file
<filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename>
is in the current directory.
</para></listitem>
<listitem><para>If necessary, start the Eclipse IDE
and be sure you are in the Workbench.
</para></listitem>
<listitem><para>Select "Install New Software" from
the "Help" pull-down menu.
</para></listitem>
<listitem><para>Click "Add".</para></listitem>
<listitem><para>Provide anything you want in the
"Name" field.
</para></listitem>
<listitem><para>Click "Archive" and browse to the
ZIP file you built in step eight.
This ZIP file should not be "unzipped", and must
be the <filename>*archive.zip</filename> file
created by running the
<filename>build.sh</filename> script.
</para></listitem>
<listitem><para>Click the "OK" button.
</para></listitem>
<listitem><para>Check the boxes that appear in
the installation window to install the
<filename>Yocto Project ADT Plug-in</filename>,
<filename>Yocto Project Bitbake Commander Plug-in</filename>,
and the
<filename>Yocto Project Documentation plug-in</filename>.
</para></listitem>
<listitem><para>Finish the installation by clicking
through the appropriate buttons.
You can click "OK" when prompted about
installing software that contains unsigned
content.
</para></listitem>
<listitem><para>Restart the Eclipse IDE if
necessary.
</para></listitem>
</orderedlist>
</para>
<para>
At this point you should be able to configure the
Eclipse Yocto Plug-in as described in the
"<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
section.</para>
</section>
</section>
<section id='configuring-the-eclipse-yocto-plug-in'>
<title>Configuring the Eclipse Yocto Plug-in</title>
<para>
Configuring the Eclipse Yocto Plug-in involves setting the
Cross Compiler options and the Target options.
The configurations you choose become the default settings
for all projects.
You do have opportunities to change them later when
you configure the project (see the following section).
</para>
<para>
To start, you need to do the following from within the
Eclipse IDE:
<itemizedlist>
<listitem><para>Choose "Preferences" from the
"Window" menu to display the Preferences Dialog.
</para></listitem>
<listitem><para>Click "Yocto Project ADT" to display
the configuration screen.
</para></listitem>
</itemizedlist>
</para>
<section id='configuring-the-cross-compiler-options'>
<title>Configuring the Cross-Compiler Options</title>
<para>
To configure the Cross Compiler Options, you must select
the type of toolchain, point to the toolchain, specify
the sysroot location, and select the target
architecture.
<itemizedlist>
<listitem><para><emphasis>Selecting the Toolchain Type:</emphasis>
Choose between
<filename>Standalone pre-built toolchain</filename>
and
<filename>Build system derived toolchain</filename>
for Cross Compiler Options.
<itemizedlist>
<listitem><para><emphasis>
<filename>Standalone Pre-built Toolchain:</filename></emphasis>
Select this mode when you are using
a stand-alone cross-toolchain.
For example, suppose you are an
application developer and do not
need to build a target image.
Instead, you just want to use an
architecture-specific toolchain on
an existing kernel and target root
filesystem.</para></listitem>
<listitem><para><emphasis>
<filename>Build System Derived Toolchain:</filename></emphasis>
Select this mode if the
cross-toolchain has been installed
and built as part of the
<link linkend='build-directory'>Build Directory</link>.
When you select
<filename>Build system derived toolchain</filename>,
you are using the toolchain bundled
inside the Build Directory.
</para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para><emphasis>Point to the Toolchain:</emphasis>
If you are using a stand-alone pre-built
toolchain, you should be pointing to where it is
installed.
If you used the ADT Installer script and
accepted the default installation directory, the
toolchain will be installed in the
<filename>&YOCTO_ADTPATH_DIR;</filename>
directory.
Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring and Running the ADT Installer Script</ulink>"
and
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
in the Yocto Project Application Developer's
Guide describe how to install a stand-alone
cross-toolchain.</para>
<para>If you are using a system-derived
toolchain, the path you provide for the
<filename>Toolchain Root Location</filename>
field is the
<link linkend='build-directory'>Build Directory</link>.
See the
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Build Directory</ulink>"
section in the Yocto Project Application
Developer's Guide for information on how to
install the toolchain into the Build
Directory.</para></listitem>
<listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
This location is where the root filesystem for
the target hardware resides.
If you used the ADT Installer script and
accepted the default installation directory,
then the location in your home directory
in a folder named
<filename>test-yocto/</filename><replaceable>target_arch</replaceable>.
Additionally, when you use the ADT Installer
script, the
<filename>/opt/poky/&DISTRO;/sysroots</filename>
location is used for the QEMU
user-space tools and the NFS boot process.
</para>
<para>If you used either of the other two
methods to install the toolchain or did not
accept the ADT Installer script's default
installation directory, then the location of
the sysroot filesystem depends on where you
separately extracted and installed the
filesystem.</para>
<para>For information on how to install the
toolchain and on how to extract and install the
sysroot filesystem, see the
"<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
section in the Yocto Project Application
Developer's Guide.
</para></listitem>
<listitem><para><emphasis>Select the Target Architecture:</emphasis>
The target architecture is the type of hardware
you are going to use or emulate.
Use the pull-down
<filename>Target Architecture</filename> menu
to make your selection.
The pull-down menu should have the supported
architectures.
If the architecture you need is not listed in
the menu, you will need to build the image.
See the
"<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
section of the Yocto Project Quick Start for
more information.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='configuring-the-target-options'>
<title>Configuring the Target Options</title>
<para>
You can choose to emulate hardware using the QEMU
emulator, or you can choose to run your image on actual
hardware.
<itemizedlist>
<listitem><para><emphasis>QEMU:</emphasis>
Select this option if you will be using the
QEMU emulator.
If you are using the emulator, you also need to
locate the kernel and specify any custom
options.</para>
<para>If you selected
<filename>Build system derived toolchain</filename>,
the target kernel you built will be located in
the Build Directory in
<filename>tmp/deploy/images/<replaceable>machine</replaceable></filename>
directory.
If you selected
<filename>Standalone pre-built toolchain</filename>,
the pre-built image you downloaded is located
in the directory you specified when you
downloaded the image.</para>
<para>Most custom options are for advanced QEMU
users to further customize their QEMU instance.
These options are specified between paired
angled brackets.
Some options must be specified outside the
brackets.
In particular, the options
<filename>serial</filename>,
<filename>nographic</filename>, and
<filename>kvm</filename> must all be outside the
brackets.
Use the <filename>man qemu</filename> command
to get help on all the options and their use.
The following is an example:
<literallayout class='monospaced'>
serial ‘&lt;-m 256 -full-screen&gt;’
</literallayout></para>
<para>
Regardless of the mode, Sysroot is already
defined as part of the Cross-Compiler Options
configuration in the
<filename>Sysroot Location:</filename> field.
</para></listitem>
<listitem><para><emphasis>External HW:</emphasis>
Select this option if you will be using actual
hardware.</para></listitem>
</itemizedlist>
</para>
<para>
Click the "OK" to save your plug-in configurations.
</para>
</section>
</section>
</section>
<section id='creating-the-project'>
<title>Creating the Project</title>
<para>
You can create two types of projects: Autotools-based, or
Makefile-based.
This section describes how to create Autotools-based projects
from within the Eclipse IDE.
For information on creating Makefile-based projects in a
terminal window, see the section
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-command-line'>Using the Command Line</ulink>"
in the Yocto Project Application Developer's Guide.
<note>
Do not use special characters in project names
(e.g. spaces, underscores, etc.). Doing so can
cause configuration to fail.
</note>
</para>
<para>
To create a project based on a Yocto template and then display
the source code, follow these steps:
<orderedlist>
<listitem><para>Select "Project" from the "File -> New" menu.
</para></listitem>
<listitem><para>Double click <filename>CC++</filename>.
</para></listitem>
<listitem><para>Double click <filename>C Project</filename>
to create the project.</para></listitem>
<listitem><para>Expand <filename>Yocto Project ADT Autotools Project</filename>.
</para></listitem>
<listitem><para>Select <filename>Hello World ANSI C Autotools Project</filename>.
This is an Autotools-based project based on a Yocto
template.</para></listitem>
<listitem><para>Put a name in the <filename>Project name:</filename>
field.
Do not use hyphens as part of the name.
</para></listitem>
<listitem><para>Click "Next".</para></listitem>
<listitem><para>Add information in the
<filename>Author</filename> and
<filename>Copyright notice</filename> fields.
</para></listitem>
<listitem><para>Be sure the <filename>License</filename>
field is correct.</para></listitem>
<listitem><para>Click "Finish".</para></listitem>
<listitem><para>If the "open perspective" prompt appears,
click "Yes" so that you in the C/C++ perspective.
</para></listitem>
<listitem><para>The left-hand navigation pane shows your
project.
You can display your source by double clicking the
project's source file.</para></listitem>
</orderedlist>
</para>
</section>
<section id='configuring-the-cross-toolchains'>
<title>Configuring the Cross-Toolchains</title>
<para>
The earlier section,
"<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>",
sets up the default project configurations.
You can override these settings for a given project by following
these steps:
<orderedlist>
<listitem><para>Select "Change Yocto Project Settings" from
the "Project" menu.
This selection brings up the Yocto Project Settings
Dialog and allows you to make changes specific to an
individual project.</para>
<para>By default, the Cross Compiler Options and Target
Options for a project are inherited from settings you
provided using the Preferences Dialog as described
earlier in the
"<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>" section.
The Yocto Project Settings Dialog allows you to override
those default settings for a given project.
</para></listitem>
<listitem><para>Make your configurations for the project
and click "OK".
</para></listitem>
<listitem><para>Right-click in the navigation pane and
select "Reconfigure Project" from the pop-up menu.
This selection reconfigures the project by running
<filename>autogen.sh</filename> in the workspace for
your project.
The script also runs <filename>libtoolize</filename>,
<filename>aclocal</filename>,
<filename>autoconf</filename>,
<filename>autoheader</filename>,
<filename>automake --a</filename>, and
<filename>./configure</filename>.
Click on the "Console" tab beneath your source code to
see the results of reconfiguring your project.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='building-the-project'>
<title>Building the Project</title>
<para>
To build the project select "Build Project" from the
"Project" menu.
The console should update and you can note the cross-compiler
you are using.
<note>
When building "Yocto Project ADT Autotools" projects, the Eclipse
IDE might display error messages for Functions/Symbols/Types
that cannot be "resolved", even when the related include file
is listed at the project navigator and when the project is
able to build.
For these cases only, it is recommended to add a new linked
folder to the appropriate sysroot.
Use these steps to add the linked folder:
<orderedlist>
<listitem><para>
Select the project.
</para></listitem>
<listitem><para>
Select "Folder" from the
<filename>File > New</filename> menu.
</para></listitem>
<listitem><para>
In the "New Folder" Dialog, select "Link to alternate
location (linked folder)".
</para></listitem>
<listitem><para>
Click "Browse" to navigate to the include folder inside
the same sysroot location selected in the Yocto Project
configuration preferences.
</para></listitem>
<listitem><para>
Click "OK".
</para></listitem>
<listitem><para>
Click "Finish" to save the linked folder.
</para></listitem>
</orderedlist>
</note>
</para>
</section>
<section id='starting-qemu-in-user-space-nfs-mode'>
<title>Starting QEMU in User-Space NFS Mode</title>
<para>
To start the QEMU emulator from within Eclipse, follow these
steps:
<note>
See the
"<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
chapter for more information on using QEMU.
</note>
<orderedlist>
<listitem><para>Expose and select "External Tools" from
the "Run" menu.
Your image should appear as a selectable menu item.
</para></listitem>
<listitem><para>Select your image from the menu to launch
the emulator in a new window.
</para></listitem>
<listitem><para>If needed, enter your host root password in
the shell window at the prompt.
This sets up a <filename>Tap 0</filename> connection
needed for running in user-space NFS mode.
</para></listitem>
<listitem><para>Wait for QEMU to launch.</para></listitem>
<listitem><para>Once QEMU launches, you can begin operating
within that environment.
One useful task at this point would be to determine the
IP Address for the user-space NFS by using the
<filename>ifconfig</filename> command.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='deploying-and-debugging-the-application'>
<title>Deploying and Debugging the Application</title>
<para>
Once the QEMU emulator is running the image, you can deploy
your application using the Eclipse IDE and then use
the emulator to perform debugging.
Follow these steps to deploy the application.
<orderedlist>
<listitem><para>Select "Debug Configurations..." from the
"Run" menu.</para></listitem>
<listitem><para>In the left area, expand
<filename>C/C++Remote Application</filename>.
</para></listitem>
<listitem><para>Locate your project and select it to bring
up a new tabbed view in the Debug Configurations Dialog.
</para></listitem>
<listitem><para>Enter the absolute path into which you want
to deploy the application.
Use the "Remote Absolute File Path for
C/C++Application:" field.
For example, enter
<filename>/usr/bin/<replaceable>programname</replaceable></filename>.
</para></listitem>
<listitem><para>Click on the "Debugger" tab to see the
cross-tool debugger you are using.</para></listitem>
<listitem><para>Click on the "Main" tab.</para></listitem>
<listitem><para>Create a new connection to the QEMU instance
by clicking on "new".</para></listitem>
<listitem><para>Select <filename>TCF</filename>, which means
Target Communication Framework.</para></listitem>
<listitem><para>Click "Next".</para></listitem>
<listitem><para>Clear out the "host name" field and enter
the IP Address determined earlier.</para></listitem>
<listitem><para>Click "Finish" to close the
New Connections Dialog.</para></listitem>
<listitem><para>Use the drop-down menu now in the
"Connection" field and pick the IP Address you entered.
</para></listitem>
<listitem><para>Click "Debug" to bring up a login screen
and login.</para></listitem>
<listitem><para>Accept the debug perspective.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='running-user-space-tools'>
<title>Running User-Space Tools</title>
<para>
As mentioned earlier in the manual, several tools exist that
enhance your development experience.
These tools are aids in developing and debugging applications
and images.
You can run these user-space tools from within the Eclipse
IDE through the "YoctoProjectTools" 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><emphasis><filename>OProfile</filename>:</emphasis>
Selecting this tool causes the
<filename>oprofile-server</filename> on the remote
target to launch on the local host machine.
The <filename>oprofile-viewer</filename> must be
installed on the local host machine and the
<filename>oprofile-server</filename> must be installed
on the remote target, respectively, in order to use.
You must compile and install the
<filename>oprofile-viewer</filename> from the source
code on your local host machine.
Furthermore, in order to convert the target's sample
format data into a form that the host can use, you must
have OProfile version 0.9.4 or greater installed on the
host.</para>
<para>You can locate both the viewer and server from
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
You can also find more information on setting up and
using this tool in the
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>oprofile</ulink>"
section of the Yocto Project Profiling and Tracing
Manual.
<note>The <filename>oprofile-server</filename> is
installed by default on the
<filename>core-image-sato-sdk</filename> image.</note>
</para></listitem>
<listitem><para><emphasis><filename>Lttng2.0 trace import</filename>:</emphasis>
Selecting this tool transfers the remote target's
<filename>Lttng</filename> tracing data back to the
local host machine and uses the Lttng Eclipse plug-in
to graphically display the output.
For information on how to use Lttng to trace an
application,
see <ulink url='http://lttng.org/documentation'></ulink>
and the
"<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>"
section, which is in the Yocto Project Profiling and
Tracing Manual.
<note>Do not use
<filename>Lttng-user space (legacy)</filename> tool.
This tool no longer has any upstream support.</note>
</para>
<para>Before you use the
<filename>Lttng2.0 trace import</filename> tool,
you need to setup the Lttng Eclipse plug-in and create a
Tracing project.
Do the following:
<orderedlist>
<listitem><para>Select "Open Perspective" from the
"Window" menu and then select "Other..." to
bring up a menu of other perspectives.
Choose "Tracing".
</para></listitem>
<listitem><para>Click "OK" to change the Eclipse
perspective into the Tracing perspective.
</para></listitem>
<listitem><para>Create a new Tracing project by
selecting "Project" from the "File -> New" menu.
</para></listitem>
<listitem><para>Choose "Tracing Project" from the
"Tracing" menu and click "Next".
</para></listitem>
<listitem><para>Provide a name for your tracing
project and click "Finish".
</para></listitem>
<listitem><para>Generate your tracing data on the
remote target.</para></listitem>
<listitem><para>Select "Lttng2.0 trace import"
from the "Yocto Project Tools" menu to
start the data import process.</para></listitem>
<listitem><para>Specify your remote connection name.
</para></listitem>
<listitem><para>For the Ust directory path, specify
the location of your remote tracing data.
Make sure the location ends with
<filename>ust</filename> (e.g.
<filename>/usr/mysession/ust</filename>).
</para></listitem>
<listitem><para>Click "OK" to complete the import
process.
The data is now in the local tracing project
you created.</para></listitem>
<listitem><para>Right click on the data and then use
the menu to Select "Generic CTF Trace" from the
"Trace Type... -> Common Trace Format" menu to
map the tracing type.</para></listitem>
<listitem><para>Right click the mouse and select
"Open" to bring up the Eclipse Lttng Trace
Viewer so you view the tracing data.
</para></listitem>
</orderedlist></para></listitem>
<listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis>
Selecting this tool runs PowerTOP on the remote target
machine and displays the results in a new view called
PowerTOP.</para>
<para>The "Time to gather data(sec):" field is the time
passed in seconds before data is gathered from the
remote target for analysis.</para>
<para>The "show pids in wakeups list:" field corresponds
to the <filename>-p</filename> argument passed to
<filename>PowerTOP</filename>.</para></listitem>
<listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
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.
For more information on setting up and using
<filename>perf</filename>, see the
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
section in the Yocto Project Profiling and Tracing
Manual.
</para></listitem>
<listitem><para><emphasis><filename>SystemTap</filename>:</emphasis>
Systemtap is a tool that lets you create and reuse
scripts to examine the activities of a live Linux
system.
You can easily extract, filter, and summarize data
that helps you diagnose complex performance or
functional problems.
For more information on setting up and using
<filename>SystemTap</filename>, see the
<ulink url='https://sourceware.org/systemtap/documentation.html'>SystemTap Documentation</ulink>.
</para></listitem>
<listitem><para><emphasis><filename>yocto-bsp</filename>:</emphasis>
The <filename>yocto-bsp</filename> tool lets you
quickly set up a Board Support Package (BSP) layer.
The tool requires a Metadata location, build location,
BSP name, BSP output location, and a kernel
architecture.
For more information on the
<filename>yocto-bsp</filename> tool outside of Eclipse,
see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a new BSP Layer Using the yocto-bsp Script</ulink>"
section in the Yocto Project Board Support Package
(BSP) Developer's Guide.
</para></listitem>
</itemizedlist>
</para>
</section>
</section>
<section id='workflow-using-stand-alone-cross-development-toolchains'>
<title>Workflow Using Stand-Alone Cross-Development Toolchains</title>
<para>
If you want to develop an application without prior installation
of the ADT, you still can employ the
<link linkend='cross-development-toolchain'>Cross Development Toolchain</link>,
the QEMU emulator, and a number of supported target image files.
You just need to follow these general steps:
<orderedlist>
<listitem><para><emphasis>Install the cross-development
toolchain for your target hardware:</emphasis>
For information on how to install the toolchain, see the
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
section in the Yocto Project Application Developer's
Guide.</para></listitem>
<listitem><para><emphasis>Download the Target Image:</emphasis>
The Yocto Project supports several target architectures
and has many pre-built kernel images and root filesystem
images.</para>
<para>If you are going to develop your application on
hardware, go to the
<ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
download area and choose a target machine area
from which to download the kernel image and root filesystem.
This download area could have several files in it that
support development using actual hardware.
For example, the area might contain
<filename>.hddimg</filename> files that combine the
kernel image with the filesystem, boot loaders, and
so forth.
Be sure to get the files you need for your particular
development process.</para>
<para>If you are going to develop your application and
then run and test it using the QEMU emulator, go to the
<ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink>
download area.
From this area, go down into the directory for your
target architecture (e.g. <filename>qemux86_64</filename>
for an <trademark class='registered'>Intel</trademark>-based
64-bit architecture).
Download kernel, root filesystem, and any other files you
need for your process.
<note>In order to use the root filesystem in QEMU, you
need to extract it.
See the
"<ulink url='&YOCTO_DOCS_ADT_URL;#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>"
section for information on how to extract the root
filesystem.</note></para></listitem>
<listitem><para><emphasis>Develop and Test your
Application:</emphasis> At this point, you have the tools
to develop your application.
If you need to separately install and use the QEMU
emulator, you can go to
<ulink url='http://wiki.qemu.org/Main_Page'>QEMU Home Page</ulink>
to download and learn about the emulator.
You can see the
"<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
chapter for information on using QEMU within the Yocto
Project.</para></listitem>
</orderedlist>
</para>
</section>
</section>
<section id="dev-modifying-source-code">
<title>Modifying Source Code</title>
<para>
A common development workflow consists of modifying project source
files that are external to the Yocto Project and then integrating
that project's build output into an image built using the
OpenEmbedded build system.
Given this scenario, development engineers typically want to stick
to their familiar project development tools and methods, which allows
them to just focus on the project.
</para>
<para>
Several workflows exist that allow you to develop, build, and test
code that is going to be integrated into an image built using the
OpenEmbedded build system.
This section describes two:
<itemizedlist>
<listitem><para><emphasis><filename>devtool</filename>:</emphasis>
A set of tools to aid in working on the source code built by
the OpenEmbedded build system.
Section
"<link linkend='using-devtool-in-your-workflow'>Using <filename>devtool</filename> in Your Workflow</link>"
describes this workflow.
If you want more information that showcases the workflow, click
<ulink url='https://drive.google.com/a/linaro.org/file/d/0B3KGzY5fW7laTDVxUXo3UDRvd2s/view'>here</ulink>
for an excellent presentation by Trevor Woerner that
provides detailed background information and a complete
working tutorial.
</para></listitem>
<listitem><para><emphasis><ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>:</emphasis>
A powerful tool that allows you to capture source
code changes without having a clean source tree.
While Quilt is not the preferred workflow of the two, this
section includes it for users that are committed to using
the tool.
See the
"<link linkend='using-a-quilt-workflow'>Using Quilt in Your Workflow</link>"
section for more information.
</para></listitem>
</itemizedlist>
</para>
<section id='using-devtool-in-your-workflow'>
<title>Using <filename>devtool</filename> in Your Workflow</title>
<para>
As mentioned earlier, <filename>devtool</filename> helps
you easily develop projects whose build output must be part of
an image built using the OpenEmbedded build system.
The remainder of this section presents the workflow you would
use that includes <filename>devtool</filename>.
<footnote>
<para>
Kudos and thanks to
<ulink url='mailto:twoerner@gmail.com'>Trevor Woerner</ulink>
whose
"<ulink url='https://drive.google.com/file/d/0B3KGzY5fW7laTDVxUXo3UDRvd2s/view'>Yocto Project Developer Workflow Tutorial</ulink>"
paper contributed nicely towards the development of this
section.
</para>
</footnote>
</para>
<para>
The steps in this section assume you have a previously built
image that is already either running in QEMU or running on actual
hardware.
Also, it is assumed that for deployment of the image to the
target, SSH is installed in the image and if the image is running
on real hardware that you have network access to and from your
development machine.
</para>
<section id='update-your-external-source'>
<title>Update Your External Source</title>
<para>
Part of the development flow using
<filename>devtool</filename> of course involves updating
your source files.
Several opportunities exist in the workflow to extract and
work on the files.
For now, just realize that you need to be able to have
access to and edit files.
One obvious solution is to initially extract the code into an
isolated area in preparation for modification.
</para>
<para>
Another option is to use the
<filename>devtool modify</filename> command.
This command makes use of a "workspace" layer where much of
the transitional work occurs, which is needed for setting up
Metadata used by the OpenEmbedded build system that lets you
build your software.
Options (i.e. "-x") exist using <filename>devtool</filename>
that enable you to use the tool to extract source code.
</para>
</section>
<section id='use-devtool-to-integrate-your-code-with-the-image'>
<title>Use <filename>devtool add</filename> to Integrate Your Code with the Image</title>
<para>
The <filename>devtool add</filename> command automatically
generates the needed Metadata that allows the OpenEmbedded
build system to build your code into the image.
<note>
If a package or packages produced by the recipe on which
you are working are not already in
<ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
for the image, you must add them.
The <filename>devtool add</filename> command does not
add them for you.
</note>
Use the following command form:
<literallayout class='monospaced'>
$ devtool add <replaceable>your-project-name</replaceable>&nbsp;<replaceable>path-to-source</replaceable>
</literallayout>
</para>
<para>
Running <filename>devtool</filename> for the first time
creates a workspace layer through the
<filename>bblayers.conf</filename> file that
is based on your project's location:
<literallayout class='monospaced'>
<replaceable>path-to-source</replaceable>/<replaceable>build-directory</replaceable>/<replaceable>workspace-layer</replaceable>
</literallayout>
By default, the name of the workspace layer is "workspace".
</para>
<para>
For details on the workspace layer created in the
<replaceable>build-directory</replaceable>,
see the
"<link linkend='devtool-adding-a-new-recipe-to-the-workspace'>Adding a New Recipe to the Workspace Layer</link>"
section.
</para>
<!--
<para>
Of course, each layer must have a
<filename>layer.conf</filename> configuration file.
<filename>devtool</filename> also creates this configuration
file:
<literallayout class='monospaced'>
$ cat workspace/conf/layer.conf
# ### workspace layer auto­generated by devtool ###
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes/*/*.bb \
${LAYERDIR}/appends/*.bbappend"
BBFILE_COLLECTIONS += "workspacelayer"
BBFILE_PATTERN_workspacelayer = "^${LAYERDIR}/"
BBFILE_PATTERN_IGNORE_EMPTY_workspacelayer = "1"
BBFILE_PRIORITY_workspacelayer = "99"
</literallayout>
</para>
-->
<para>
Running <filename>devtool add</filename> automatically
generates your recipe:
<literallayout class='monospaced'>
$ cat workspace/recipes/<replaceable>your-project-name</replaceable>/<replaceable>your-project-name</replaceable>.bb
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be fully functional.
# (Feel free to remove these comments when editing.)
#
# Unable to find any files that looked like license statements. Check the accompanying
# documentation and source headers and set LICENSE and LIC_FILES_CHKSUM accordingly.
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""
# No information for SRC_URI yet (only an external source tree was
# specified)
SRC_URI = ""
DEPENDS = "libx11"
# NOTE: if this software is not capable of being built in a separate build directory
# from the source, you should replace autotools with autotools­-brokensep in the
# inherit line
inherit autotools
# Specify any options you want to pass to the configure script using EXTRA_OECONF:
EXTRA_OECONF = ""
</literallayout>
</para>
<para>
Lastly, the <filename>devtool add</filename> command creates the
<filename>.bbappend</filename> file:
<literallayout class='monospaced'>
$ cat workspace/appends/<replaceable>your-project-name</replaceable>.bbappend
inherit externalsrc
EXTERNALSRC = "/<replaceable>path-to-source</replaceable>/<replaceable>your-project-name</replaceable>"
# initial_rev: <replaceable>commit-ID</replaceable>
</literallayout>
</para>
</section>
<section id='build-your-project'>
<title>Build Your Project</title>
<para>
You can use BitBake or <filename>devtool build</filename> to
build your modified project.
</para>
<para>
To use BitBake, use the following:
<literallayout class='monospaced'>
$ bitbake <replaceable>your-project-name</replaceable>
</literallayout>
Alternatively, you can use
<filename>devtool build</filename>, which is equivalent to
<filename>bitbake -c populate_sysroot</filename>.
For example:
<literallayout class='monospaced'>
$ devtool build <replaceable>your-project-name</replaceable>
</literallayout>
</para>
</section>
<!--
<section id='dev-build-the-image'>
<title>Build the Image</title>
<para>
The final step before testing is to rebuild the base image
with your project changes as part of the image.
Simply run BitBake again on your image.
Here is an example:
<literallayout class='monospaced'>
$ bitbake <replaceable>image</replaceable>
</literallayout>
</para>
</section>
<section id='dev-testing-the-image'>
<title>Testing the Image</title>
<para>
Once you have the image, you can test it using QEMU.
Here is an example assuming "qemux86":
<literallayout class='monospaced'>
$ runqemu qemux86 <replaceable>image</replaceable>
</literallayout>
For information on how to test an image using QEMU, see the
"<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
section.
</para>
</section>
-->
</section>
<section id='devtool-quick-reference'>
<title><filename>devtool</filename> Quick Reference</title>
<para>
<filename>devtool</filename> has more functionality than simply
adding a new recipe and the supporting Metadata to a temporary
workspace layer.
This section provides a short reference on
<filename>devtool</filename> for most of the commands.
</para>
<section id='devtool-getting-help'>
<title>Getting Help</title>
<para>
The easiest way to get help with the
<filename>devtool</filename> command is using the
<filename>--help</filename> option:
<literallayout class='monospaced'>
$ devtool --help
usage: devtool [-h] [--basepath BASEPATH] [-d] [-q] [--color COLOR]
&lt;subcommand&gt; ...
OpenEmbedded development tool
optional arguments:
-h, --help show this help message and exit
--basepath BASEPATH Base directory of SDK / build directory
-d, --debug Enable debug output
-q, --quiet Print only errors
--color COLOR Colorize output (where COLOR is auto, always, never)
subcommands:
&lt;subcommand&gt;
create-workspace Set up a workspace
deploy-target Deploy recipe output files to live target machine
undeploy-target Undeploy recipe output files in live target machine
add Add a new recipe
modify Modify the source for an existing recipe
extract Extract the source for an existing recipe
update-recipe Apply changes from external source tree to recipe
status Show workspace status
build Build a recipe
reset Remove a recipe from your workspace
Use devtool &lt;subcommand&gt; --help to get help on a specific command
</literallayout>
</para>
<para>
As directed in the general help output, you can get more
syntax on a specific command by providing the command
name and using <filename>--help</filename>:
<literallayout class='monospaced'>
$ devtool add --help
usage: devtool add [-h] [--same-dir] [--fetch URI] [--version VERSION]
recipename srctree
Adds a new recipe
positional arguments:
recipename Name for new recipe to add
srctree Path to external source tree
optional arguments:
-h, --help show this help message and exit
--same-dir, -s Build in same directory as source
--fetch URI, -f URI Fetch the specified URI and extract it to create the
source tree
--version VERSION, -V VERSION
Version to use within recipe (PV)
</literallayout>
</para>
</section>
<section id='devtool-adding-a-new-recipe-to-the-workspace'>
<title>Adding a New Recipe to the Workspace Layer</title>
<para>
Use the <filename>devtool add</filename> command to add a new recipe
to the workspace layer.
The recipe you add should not exist -
<filename>devtool</filename> creates it for you.
The source files the recipe uses should exist in an external
area.
</para>
<para>
The following example creates and adds a new recipe named
<filename>jackson</filename> to the workspace layer.
The source code built by the recipes resides in
<filename>/home/scottrif/sources/jackson</filename>:
<literallayout class='monospaced'>
$ devtool add jackson /home/scottrif/sources/jackson
</literallayout>
<note>
For complete syntax, use the
<filename>devtool add --help</filename> command.
</note>
</para>
<para>
If you add a recipe and the workspace layer does not exist,
the command creates the layer and populates it as follows:
</para>
<para>
<imagedata fileref="figures/build-workspace-directory.png"
width="6in" depth="4in" align="center" scale="100" />
</para>
<para>
<literallayout class='monospaced'>
README - Provides information on what is in workspace layer and how to
manage it.
appends - A directory that contains *.bbappend files, which point to
external source.
conf - A configuration directory that contains the layer.conf file.
recipes - A directory containing recipes. This directory contains a
folder for each directory added whose name matches that of the
added recipe. devtool places the <replaceable>recipe</replaceable>.bb file
within that sub-directory.
</literallayout>
</para>
<para>
Running <filename>devtool add</filename> when the
workspace layer exists causes the tool to add the recipe
and append files into the existing workspace layer.
The <filename>.bbappend</filename> file is created to point
to the external source tree.
</para>
</section>
<section id='devtool-modifying-a-recipe'>
<title>Modifying an Existing Recipe</title>
<para>
Use the <filename>devtool modify</filename> command to begin
modifying the source of an existing recipe.
This command is very similar to the
<link linkend='devtool-adding-a-new-recipe-to-the-workspace'><filename>add</filename></link>
command except that it does not physically create the
recipe in the workspace layer because the recipe already
exists in an another layer.
</para>
<para>
The <filename>devtool modify</filename> command extracts the
source for a recipe, sets it up as a Git repository if the
source had not already been fetched from Git, checks out a
branch for development, and applies any patches from the recipe
as commits on top.
You can use the following command to checkout the source
files:
<literallayout class='monospaced'>
$ devtool modify -x <replaceable>recipe</replaceable>&nbsp;<replaceable>path-to-source</replaceable>
</literallayout>
Using the above command form, the default development branch
would be "devtool".
<note>
For complete syntax, use the
<filename>devtool modify --help</filename> command.
</note>
</para>
</section>
<section id='devtool-updating-a-recipe'>
<title>Updating a Recipe</title>
<para>
Use the <filename>devtool update-recipe</filename> command to
update your recipe with patches that reflect changes you make
to the source files.
For example, if you know you are going to work on some
code, you could first use the
<link linkend='devtool-modifying-a-recipe'><filename>devtool modify</filename></link>
command to extract the code and set up the workspace.
After which, you could modify, compile, and test the code.
</para>
<para>
When you are satisfied with the results and you have committed
your changes to the Git repository, you can then
run the <filename>devtool update-recipe</filename> to create the
patches and update the recipe:
<literallayout class='monospaced'>
$ devtool update-recipe <replaceable>recipe</replaceable>
</literallayout>
If you run the <filename>devtool update-recipe</filename>
without committing your changes, the command ignores the
changes.
</para>
<para>
Often, you might want to apply customizations made to your
software in your own layer rather than apply them to the
original recipe.
If so, you can use the
<filename>-a</filename> or <filename>--append</filename>
option with the <filename>devtool update-recipe</filename>
command.
These options allow you to specify the layer into which to
write an append file:
<literallayout class='monospaced'>
$ devtool update-recipe <replaceable>recipe</replaceable> -a <replaceable>base-layer-directory</replaceable>
</literallayout>
The <filename>*.bbappend</filename> file is created at the
appropriate path within the specified layer directory, which
may or may not be in your <filename>bblayers.conf</filename>
file.
If an append file already exists, the command updates it
appropriately.
<note>
For complete syntax, use the
<filename>devtool update-recipe --help</filename> command.
</note>
</para>
</section>
<section id='devtool-resetting-a-recipe'>
<title>Resetting a Recipe</title>
<para>
Use the <filename>devtool reset</filename> command to remove a
recipe and its configuration (e.g. the corresponding
<filename>.bbappend</filename> file) from the workspace layer.
Realize that this command deletes the recipe and the
append file.
The command does not physically move them for you.
Consequently, you must be sure to physically relocate your
updated recipe and the append file outside of the workspace
layer before running the <filename>devtool reset</filename>
command.
</para>
<para>
If the <filename>devtool reset</filename> command detects that
the recipe or the append files have been modified, the
command preserves the modified files in a separate "attic"
subdirectory under the workspace layer.
<note>
For complete syntax, use the
<filename>devtool reset --help</filename> command.
</note>
</para>
</section>
<section id='devtool-building-your-software'>
<title>Building Your Software</title>
<para>
Use the <filename>devtool build</filename> command to cause the
OpenEmbedded build system to build your software based
on the recipe file.
The <filename>devtool build</filename> command is equivalent to
<filename>bitbake -c populate_sysroot</filename>.
Here is an example:
<literallayout class='monospaced'>
$ devtool build <replaceable>recipe</replaceable>
</literallayout>
<note>
For complete syntax, use the
<filename>devtool build --help</filename> command.
</note>
Building your software using <filename>devtool build</filename>
is identical to using BitBake to build the software.
</para>
</section>
<section id='devtool-deploying-your-software-on-the-target-machine'>
<title>Deploying Your Software on the Target Machine</title>
<para>
Use the <filename>devtool deploy-target</filename> command to
deploy the recipe's build output to the live target machine:
<literallayout class='monospaced'>
$ devtool deploy-target <replaceable>recipe</replaceable>&nbsp;<replaceable>target</replaceable>
</literallayout>
The <replaceable>target</replaceable> is the address of the
target machine, which must be running an SSH server (i.e.
<filename>user@hostname[:destdir]</filename>).
</para>
<para>
This command deploys all files installed during the
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
task.
Furthermore, you do not need to have package management enabled
within the target machine.
If you do, the package manager is bypassed.
<note><title>Notes</title>
<para>
The <filename>deploy-target</filename>
functionality is for development only.
You should never use it to update an image that will be
used in production.
</para>
<para>
For complete syntax, use the
<filename>devtool deploy-target --help</filename>
command.
</para>
</note>
</para>
</section>
<section id='devtool-removing-your-software-from-the-target-machine'>
<title>Removing Your Software from the Target Machine</title>
<para>
Use the <filename>devtool undeploy-target</filename> command to
remove deployed build output from the target machine.
For the <filename>devtool undeploy-target</filename> command to
work, you must have previously used the
<link linkend='devtool-deploying-your-software-on-the-target-machine'><filename>devtool deploy-target</filename></link>
command.
<literallayout class='monospaced'>
$ devtool undeploy-target <replaceable>recipe</replaceable>&nbsp;<replaceable>target</replaceable>
</literallayout>
The <replaceable>target</replaceable> is the address of the
target machine, which must be running an SSH server (i.e.
<filename>user@hostname</filename>).
<note>
For complete syntax, use the
<filename>devtool undeploy-target --help</filename> command.
</note>
</para>
</section>
<section id='devtool-creating-the-workspace'>
<title>Creating the Workspace Layer in an Alternative Location</title>
<para>
Use the <filename>devtool create-workspace</filename> command to
create a new workspace layer in your
<link linkend='build-directory'>Build Directory</link>.
When you create a new workspace layer, it is populated with the
<filename>README</filename> file and the
<filename>conf</filename> directory only.
</para>
<para>
The following example creates a new workspace layer in your
current working and by default names the workspace layer
"workspace":
<literallayout class='monospaced'>
$ devtool create-workspace
</literallayout>
<note>
For complete syntax, use the
<filename>devtool create-workspace --help</filename> command.
</note>
</para>
<para>
You can create a workspace layer anywhere by supplying
a pathname with the command.
The following command creates a new workspace layer named
"new-workspace":
<literallayout class='monospaced'>
$ devtool create-workspace /home/scottrif/new-workspace
</literallayout>
</para>
</section>
</section>
<section id="using-a-quilt-workflow">
<title>Using Quilt in Your Workflow</title>
<para>
<ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
is a powerful tool that allows you to capture source code changes
without having a clean source tree.
This section outlines the typical workflow you can use to modify
source code, test changes, and then preserve the changes in the
form of a patch all using Quilt.
<note><title>Tip</title>
With regard to preserving changes to source files if you
clean a recipe or have <filename>rm_work</filename> enabled,
the workflow described in the
"<link linkend='using-devtool-in-your-workflow'>Using <filename>devtool</filename> in Your Workflow</link>"
section is a safer development flow than than the flow that
uses Quilt.
</note>
</para>
<para>
Follow these general steps:
<orderedlist>
<listitem><para><emphasis>Find the Source Code:</emphasis>
Temporary source code used by the OpenEmbedded build system
is kept in the
<link linkend='build-directory'>Build Directory</link>.
See the
"<link linkend='finding-the-temporary-source-code'>Finding Temporary Source Code</link>"
section to learn how to locate the directory that has the
temporary source code for a particular package.
</para></listitem>
<listitem><para><emphasis>Change Your Working Directory:</emphasis>
You need to be in the directory that has the temporary source code.
That directory is defined by the
<ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>
variable.</para></listitem>
<listitem><para><emphasis>Create a New Patch:</emphasis>
Before modifying source code, you need to create a new patch.
To create a new patch file, use <filename>quilt new</filename> as below:
<literallayout class='monospaced'>
$ quilt new my_changes.patch
</literallayout></para></listitem>
<listitem><para><emphasis>Notify Quilt and Add Files:</emphasis>
After creating the patch, you need to notify Quilt about the files
you plan to edit.
You notify Quilt by adding the files to the patch you just created:
<literallayout class='monospaced'>
$ quilt add file1.c file2.c file3.c
</literallayout>
</para></listitem>
<listitem><para><emphasis>Edit the Files:</emphasis>
Make your changes in the source code to the files you added
to the patch.
</para></listitem>
<listitem><para><emphasis>Test Your Changes:</emphasis>
Once you have modified the source code, the easiest way to
your changes is by calling the
<filename>do_compile</filename> task as shown in the
following example:
<literallayout class='monospaced'>
$ bitbake -c compile -f <replaceable>package</replaceable>
</literallayout>
The <filename>-f</filename> or <filename>--force</filename>
option forces the specified task to execute.
If you find problems with your code, you can just keep editing and
re-testing iteratively until things work as expected.
<note>All the modifications you make to the temporary source code
disappear once you run the
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-clean'><filename>do_clean</filename></ulink>
or
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-cleanall'><filename>do_cleanall</filename></ulink>
tasks using BitBake (i.e.
<filename>bitbake -c clean <replaceable>package</replaceable></filename>
and
<filename>bitbake -c cleanall <replaceable>package</replaceable></filename>).
Modifications will also disappear if you use the <filename>rm_work</filename>
feature as described in the
"<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
section of the Yocto Project Quick Start.
</note></para></listitem>
<listitem><para><emphasis>Generate the Patch:</emphasis>
Once your changes work as expected, you need to use Quilt to generate the final patch that
contains all your modifications.
<literallayout class='monospaced'>
$ quilt refresh
</literallayout>
At this point, the <filename>my_changes.patch</filename> file has all your edits made
to the <filename>file1.c</filename>, <filename>file2.c</filename>, and
<filename>file3.c</filename> files.</para>
<para>You can find the resulting patch file in the <filename>patches/</filename>
subdirectory of the source (<filename>S</filename>) directory.</para></listitem>
<listitem><para><emphasis>Copy the Patch File:</emphasis>
For simplicity, copy the patch file into a directory named <filename>files</filename>,
which you can create in the same directory that holds the recipe
(<filename>.bb</filename>) file or the
append (<filename>.bbappend</filename>) file.
Placing the patch here guarantees that the OpenEmbedded build system will find
the patch.
Next, add the patch into the
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename>
of the recipe.
Here is an example:
<literallayout class='monospaced'>
SRC_URI += "file://my_changes.patch"
</literallayout></para></listitem>
</orderedlist>
</para>
</section>
<section id='finding-the-temporary-source-code'>
<title>Finding Temporary Source Code</title>
<para>
You might find it helpful during development to modify the
temporary source code used by recipes to build packages.
For example, suppose you are developing a patch and you need to
experiment a bit to figure out your solution.
After you have initially built the package, you can iteratively
tweak the source code, which is located in the
<link linkend='build-directory'>Build Directory</link>, and then
you can force a re-compile and quickly test your altered code.
Once you settle on a solution, you can then preserve your changes
in the form of patches.
If you are using Quilt for development, see the
"<link linkend='using-a-quilt-workflow'>Using Quilt in Your Workflow</link>"
section for more information.
</para>
<para>
During a build, the unpacked temporary source code used by recipes
to build packages is available in the Build Directory as
defined by the
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable.
Below is the default value for the <filename>S</filename> variable as defined in the
<filename>meta/conf/bitbake.conf</filename> configuration file in the
<link linkend='source-directory'>Source Directory</link>:
<literallayout class='monospaced'>
S = "${WORKDIR}/${BP}"
</literallayout>
You should be aware that many recipes override the <filename>S</filename> variable.
For example, recipes that fetch their source from Git usually set
<filename>S</filename> to <filename>${WORKDIR}/git</filename>.
<note>
The
<ulink url='&YOCTO_DOCS_REF_URL;#var-BP'><filename>BP</filename></ulink>
represents the base recipe name, which consists of the name and version:
<literallayout class='monospaced'>
BP = "${BPN}-${PV}"
</literallayout>
</note>
</para>
<para>
The path to the work directory for the recipe
(<ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>)
is defined as follows:
<literallayout class='monospaced'>
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
</literallayout>
The actual directory depends on several things:
<itemizedlist>
<listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>:
The top-level build output directory</listitem>
<listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></ulink>:
The target system identifier</listitem>
<listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>:
The recipe name</listitem>
<listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTENDPE'><filename>EXTENDPE</filename></ulink>:
The epoch - (if
<ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>
is not specified, which is usually the case for most
recipes, then <filename>EXTENDPE</filename> is blank)</listitem>
<listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>:
The recipe version</listitem>
<listitem><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>:
The recipe revision</listitem>
</itemizedlist>
</para>
<para>
As an example, assume a Source Directory top-level folder
named <filename>poky</filename>, a default Build Directory at
<filename>poky/build</filename>, and a
<filename>qemux86-poky-linux</filename> machine target
system.
Furthermore, suppose your recipe is named
<filename>foo_1.3.0.bb</filename>.
In this case, the work directory the build system uses to
build the package would be as follows:
<literallayout class='monospaced'>
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
</literallayout>
</para>
<para>
Now that you know where to locate the directory that has the
temporary source code, you can use a Quilt as described in section
"<link linkend='using-a-quilt-workflow'>Using Quilt in Your Workflow</link>"
to make your edits, test the changes, and preserve the changes in
the form of patches.
</para>
</section>
</section>
<section id='image-development-using-toaster'>
<title>Image Development Using Toaster</title>
<para>
Toaster is a web interface to the Yocto Project's OpenEmbedded build
system.
You can initiate builds using Toaster as well as examine the results
and statistics of builds.
See the
<ulink url='&YOCTO_DOCS_TOAST_URL;#toaster-manual-intro'>Toaster User Manual</ulink>
for information on how to set up and use Toaster to build images.
</para>
</section>
<section id='image-development-using-hob'>
<title>Image Development Using Hob</title>
<para>
The <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> is a graphical user interface for the
OpenEmbedded build system, which is based on BitBake.
You can use the Hob to build custom operating system images within the Yocto Project build environment.
Hob simply provides a friendly interface over the build system used during development.
In other words, building images with the Hob lets you take care of common build tasks more easily.
</para>
<para>
For a better understanding of Hob, see the project page at
<ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink>
on the Yocto Project website.
If you follow the "Documentation" link from the Hob page, you will
find a short introductory training video on Hob.
The following lists some features of Hob:
<itemizedlist>
<listitem><para>You can setup and run Hob using these commands:
<literallayout class='monospaced'>
$ source oe-init-build-env
$ hob
</literallayout></para></listitem>
<listitem><para>You can set the
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
for which you are building the image.</para></listitem>
<listitem><para>You can modify various policy settings such as the
package format with which to build,
the parallelism BitBake uses, whether or not to build an
external toolchain, and which host to build against.
</para></listitem>
<listitem><para>You can manage
<link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
<listitem><para>You can select a base image and then add extra packages for your custom build.
</para></listitem>
<listitem><para>You can launch and monitor the build from within Hob.</para></listitem>
</itemizedlist>
</para>
</section>
<section id="platdev-appdev-devshell">
<title>Using a Development Shell</title>
<para>
When debugging certain commands or even when just editing packages,
<filename>devshell</filename> can be a useful tool.
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 OpenEmbedded 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 OpenEmbedded build system were executing them.
Consequently, working this way can be helpful when debugging a build or preparing
software to be used with the OpenEmbedded build system.
</para>
<para>
Following is an example that uses <filename>devshell</filename> on a target named
<filename>matchbox-desktop</filename>:
<literallayout class='monospaced'>
$ bitbake matchbox-desktop -c devshell
</literallayout>
</para>
<para>
This command spawns a terminal with a shell prompt within the OpenEmbedded build environment.
The <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL'><filename>OE_TERMINAL</filename></ulink>
variable controls what type of shell is opened.
</para>
<para>
For spawned terminals, the following occurs:
<itemizedlist>
<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>
</para>
<para>
Within this environment, you can run configure or compile
commands as if they were being run by
the OpenEmbedded build system itself.
As noted earlier, the working directory also automatically changes to the
Source Directory (<ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>).
</para>
<para>
When you are finished, you just exit the shell or close the terminal window.
</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>binutils</filename>,
<filename>libtool</filename> and so forth.
BitBake sets up 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>
</chapter>