523 lines
26 KiB
XML
523 lines
26 KiB
XML
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||
|
||
<appendix id='dev-manual-bsp-appendix'>
|
||
|
||
<title>BSP Development Example</title>
|
||
|
||
<para>
|
||
This appendix provides a complete BSP example.
|
||
The example assumes the following:
|
||
<itemizedlist>
|
||
<listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
|
||
<listitem><para>Use of the Crown Bay Board Support Package (BSP) as a base BSP from
|
||
which to work from.</para></listitem>
|
||
<listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
|
||
<listitem><para>Example was developed on an Intel-based Core i7 platform running
|
||
Ubuntu 10.04 LTS released in April of 2010.</para></listitem>
|
||
</itemizedlist>
|
||
</para>
|
||
|
||
<section id='getting-local-yocto-project-files-and-bsp-files'>
|
||
<title>Getting Local Yocto Project Files and BSP Files</title>
|
||
|
||
<para>
|
||
You need to have the Yocto Project files available on your host system.
|
||
You can get files through tarball extraction or by cloning the <filename>poky</filename>
|
||
Git repository.
|
||
See the bulleted item
|
||
"<link linkend='local-yp-release'>Yocto Project Release</link>"
|
||
for information on how to get these files.
|
||
</para>
|
||
|
||
<para>
|
||
Once you have the local <filename>poky</filename> Git repository set up,
|
||
you have many development branches from which you can work.
|
||
From inside the repository you can see the branch names and the tag names used
|
||
in the Git repository using either of the following two commands:
|
||
<literallayout class='monospaced'>
|
||
$ git branch -a
|
||
$ git tag -l
|
||
</literallayout>
|
||
For this example we are going to use the Yocto Project 1.1 Release, which is code
|
||
named "edison".
|
||
These commands create a local branch named <filename>edison</filename>
|
||
that tracks the remote branch of the same name.
|
||
<literallayout class='monospaced'>
|
||
$ cd poky
|
||
$ git checkout -b edison origin/edison
|
||
Switched to a new branch 'edison'
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
|
||
<section id='choosing-a-base-bsp-app'>
|
||
<title>Choosing a Base BSP</title>
|
||
|
||
<para>
|
||
For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
|
||
<trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform
|
||
Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
|
||
The BSP layer is <filename>meta-crownbay</filename>.
|
||
</para>
|
||
|
||
<para>
|
||
For information on how to choose a base BSP, see
|
||
"<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
|
||
</para>
|
||
</section>
|
||
|
||
<section id='getting-your-base-bsp-app'>
|
||
<title>Getting Your Base BSP</title>
|
||
|
||
<para>
|
||
You need to have the base BSP layer on your development system.
|
||
Similar to the local Yocto Project files, you can get the BSP
|
||
layer one of two ways:
|
||
download the BSP tarball and extract it, or set up a local Git repository that
|
||
has the Yocto Project BSP layers.
|
||
You should use the same method that you used to get the local Yocto Project files earlier.
|
||
See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get
|
||
the BSP files.
|
||
</para>
|
||
|
||
<para>
|
||
This example assumes the local <filename>meta-intel</filename> Git repository is
|
||
inside the local <filename>poky</filename> Git repository.
|
||
The <filename>meta-intel</filename> Git repository contains all the metadata
|
||
that supports BSP creation.
|
||
</para>
|
||
|
||
<para>
|
||
Because <filename>meta-intel</filename> is its own Git repository, you will want
|
||
to be sure you are in the appropriate branch for your work.
|
||
For this example we are going to use the <filename>edison</filename> branch.
|
||
<literallayout class='monospaced'>
|
||
$ cd meta-intel
|
||
$ git checkout -b edison origin/edison
|
||
Switched to a new branch 'edison'
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
|
||
<section id='making-a-copy-of-the-base bsp-to-create-your-new-bsp-layer-app'>
|
||
<title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
|
||
|
||
<para>
|
||
Now that you have the local Yocto Project files and the base BSP files, you need to create a
|
||
new layer for your BSP.
|
||
To create your BSP layer, you simply copy the <filename>meta-crownbay</filename>
|
||
layer to a new layer.
|
||
</para>
|
||
|
||
<para>
|
||
For this example, the new layer will be named <filename>meta-mymachine</filename>.
|
||
The name must follow the BSP layer naming convention, which is
|
||
<filename>meta-<name></filename>.
|
||
The following example assumes your working directory is <filename>meta-intel</filename>
|
||
inside the local Yocto Project files.
|
||
If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting
|
||
<filename>meta-crownbay</filename> directory structure to a location of your choice.
|
||
Good practice for a Git repository, however, is to just copy the new layer alongside
|
||
the existing
|
||
BSP layers in the <filename>meta-intel</filename> Git repository:
|
||
<literallayout class='monospaced'>
|
||
$ cp -a meta-crownbay/ meta-mymachine
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
|
||
<section id='making-changes-to-your-bsp-app'>
|
||
<title>Making Changes to Your BSP</title>
|
||
|
||
<para>
|
||
Right now you have two identical BSP layers with different names:
|
||
<filename>meta-crownbay</filename> and <filename>meta-mymachine</filename>.
|
||
You need to change your configurations so that they work for your new BSP and
|
||
your particular hardware.
|
||
The following sections look at each of these areas of the BSP.
|
||
</para>
|
||
|
||
<section id='changing-the-bsp-configuration'>
|
||
<title>Changing the BSP Configuration</title>
|
||
|
||
<para>
|
||
We will look first at the configurations, which are all done in the layer’s
|
||
<filename>conf</filename> directory.
|
||
</para>
|
||
|
||
<para>
|
||
First, since in this example the new BSP will not support EMGD, we will get rid of the
|
||
<filename>crownbay.conf</filename> file and then rename the
|
||
<filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.
|
||
Much of what we do in the configuration directory is designed to help the Yocto Project
|
||
build system work with the new layer and to be able to find and use the right software.
|
||
The following two commands result in a single machine configuration file named
|
||
<filename>mymachine.conf</filename>.
|
||
<literallayout class='monospaced'>
|
||
$ rm meta-mymachine/conf/machine/crownbay.conf
|
||
$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf \
|
||
meta-mymachine/conf/machine/mymachine.conf
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
The next step makes changes to <filename>mymachine.conf</filename> itself.
|
||
The only changes needed for this example are changes to the comment lines.
|
||
Here we simply substitute the Crown Bay name with an appropriate name.
|
||
</para>
|
||
|
||
<para>
|
||
Note that inside the <filename>mymachine.conf</filename> is the
|
||
<filename>PREFERRED_PROVIDER_virtual/kernel</filename> statement.
|
||
This statement identifies the kernel that the BSP is going to use.
|
||
In this case, the BSP is using <filename>linux-yocto</filename>, which is the
|
||
current Linux Yocto kernel based on the Linux 3.0 release.
|
||
</para>
|
||
|
||
<para>
|
||
The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>.
|
||
This file identifies build information needed for the new layer.
|
||
You can see the
|
||
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in
|
||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>The Board
|
||
Support Packages (BSP) Development Guide</ulink>
|
||
for more information on this configuration file.
|
||
Basically, we are changing the existing statements to work with our BSP.
|
||
</para>
|
||
|
||
<para>
|
||
The file contains these statements that reference the Crown Bay BSP:
|
||
<literallayout class='monospaced'>
|
||
BBFILE_COLLECTIONS += "crownbay"
|
||
BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
|
||
BBFILE_PRIORITY_crownbay = "6"
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
Simply substitute the machine string name <filename>crownbay</filename>
|
||
with the new machine name <filename>mymachine</filename> to get the following:
|
||
<literallayout class='monospaced'>
|
||
BBFILE_COLLECTIONS += "mymachine"
|
||
BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
|
||
BBFILE_PRIORITY_mymachine = "6"
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
|
||
<section id='changing-the-recipes-in-your-bsp'>
|
||
<title>Changing the Recipes in Your BSP</title>
|
||
|
||
<para>
|
||
Now we will take a look at the recipes in your new layer.
|
||
The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.
|
||
When you create a BSP, you use these areas for appropriate recipes and append files.
|
||
Recipes take the form of <filename>.bb</filename> files.
|
||
If you want to leverage the existing recipes the Yocto Project build system uses
|
||
but change those recipes, you can use <filename>.bbappend</filename> files.
|
||
All new recipes and append files for your layer must go in the layer’s
|
||
<filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>,
|
||
<filename>recipes-core</filename>, and
|
||
<filename>recipes-graphics</filename> directories.
|
||
</para>
|
||
|
||
<section id='changing-recipes-bsp'>
|
||
<title>Changing <filename>recipes-bsp</filename></title>
|
||
|
||
<para>
|
||
First, let's look at <filename>recipes-bsp</filename>.
|
||
For this example we are not adding any new BSP recipes.
|
||
And, we only need to remove the formfactor we do not want and change the name of
|
||
the remaining one that doesn't support EMGD.
|
||
These commands take care of the <filename>recipes-bsp</filename> recipes:
|
||
<literallayout class='monospaced'>
|
||
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd*
|
||
$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
|
||
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
|
||
<section id='changing-recipes-graphics'>
|
||
<title>Changing <filename>recipes-graphics</filename></title>
|
||
|
||
<para>
|
||
Now let's look at <filename>recipes-graphics</filename>.
|
||
For this example we want to remove anything that supports EMGD and
|
||
be sure to rename remaining directories appropriately.
|
||
The following commands clean up the <filename>recipes-graphics</filename> directory:
|
||
<literallayout class='monospaced'>
|
||
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*
|
||
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
|
||
$ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
|
||
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
At this point the <filename>recipes-graphics</filename> directory just has files that
|
||
support Video Electronics Standards Association (VESA) graphics modes and not EMGD.
|
||
</para>
|
||
</section>
|
||
|
||
<section id='changing-recipes-core'>
|
||
<title>Changing <filename>recipes-core</filename></title>
|
||
|
||
<para>
|
||
Now let's look at changes in <filename>recipes-core</filename>.
|
||
The file <filename>task-core-tools.bbappend</filename> in
|
||
<filename>recipes-core/tasks</filename> appends the similarly named recipe
|
||
located in the local Yocto Project files at
|
||
<filename>meta/recipes-core/tasks</filename>.
|
||
The "append" file in our layer right now is Crown Bay-specific and supports
|
||
EMGD and non-EMGD.
|
||
Here are the contents of the file:
|
||
<literallayout class='monospaced'>
|
||
RRECOMMENDS_task-core-tools-profile_append_crownbay = " systemtap"
|
||
RRECOMMENDS_task-core-tools-profile_append_crownbay-noemgd = " systemtap"
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
The <filename>RRECOMMENDS</filename> statements list packages that
|
||
extend usability.
|
||
The first <filename>RRECOMMENDS</filename> statement can be removed, while the
|
||
second one can be changed to reflect <filename>meta-mymachine</filename>:
|
||
<literallayout class='monospaced'>
|
||
RRECOMMENDS_task-core-tools-profile_append_mymachine = " systemtap"
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
|
||
<section id='changing-recipes-kernel'>
|
||
<title>Changing <filename>recipes-kernel</filename></title>
|
||
|
||
<para>
|
||
Finally, let's look at <filename>recipes-kernel</filename> changes.
|
||
Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined
|
||
earlier in the <filename>mymachine.conf</filename>.
|
||
The recipe for that kernel is not located in the
|
||
BSP layer but rather in the local Yocto Project files at
|
||
<filename>meta/recipes-kernel/linux</filename> and is
|
||
named <filename>linux-yocto_3.0.bb</filename>.
|
||
The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
|
||
statements point to the exact commits used by the Yocto Project development team
|
||
in their source repositories that identify the right kernel for our hardware.
|
||
</para>
|
||
|
||
<para>
|
||
However, in the <filename>meta-mymachine</filename> layer in
|
||
<filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
|
||
file named <filename>linux-yocto_3.0.bbappend</filename> that
|
||
is appended to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
|
||
Thus, the <filename>SRCREV</filename> statements in the "append" file override
|
||
the more general statements found in <filename>meta</filename>.
|
||
</para>
|
||
|
||
<para>
|
||
The <filename>SRCREV</filename> statements in the "append" file currently identify
|
||
the kernel that supports the Crown Bay BSP with and without EMGD support.
|
||
Here are the statements:
|
||
<literallayout class='monospaced'>
|
||
SRCREV_machine_pn-linux-yocto_crownbay ?= \
|
||
"2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||
SRCREV_meta_pn-linux-yocto_crownbay ?= \
|
||
"67a46a608f47c19f16995be7de7b272025864b1b"
|
||
|
||
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
|
||
"2247da9131ea7e46ed4766a69bb1353dba22f873"
|
||
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
|
||
"67a46a608f47c19f16995be7de7b272025864b1b"
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
You will notice that there are two pairs of <filename>SRCREV</filename> statements.
|
||
The top pair identifies the kernel that supports
|
||
EMGD, which we don’t care about in this example.
|
||
The bottom pair identifies the kernel that we will use:
|
||
<filename>linux-yocto</filename>.
|
||
At this point though, the unique commit strings all are still associated with
|
||
Crown Bay and not <filename>meta-mymachine</filename>.
|
||
</para>
|
||
|
||
<para>
|
||
To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>
|
||
we delete the two <filename>SRCREV</filename> statements that support
|
||
EMGD (the top pair).
|
||
We also change the remaining pair to specify <filename>mymachine</filename>
|
||
and insert the commit identifiers to identify the kernel in which we
|
||
are interested, which will be based on the <filename>atom-pc-standard</filename>
|
||
kernel.
|
||
Here are the final <filename>SRCREV</filename> statements:
|
||
<literallayout class='monospaced'>
|
||
SRCREV_machine_pn-linux-yocto_mymachine ?= \
|
||
"06c798f25a19281d7fa944b14366dd75820ba009"
|
||
SRCREV_meta_pn-linux-yocto_mymachine ?= \
|
||
"67a46a608f47c19f16995be7de7b272025864b1b"
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
If you are familiar with Git repositories you probably won’t have trouble locating the
|
||
exact commit strings in the Yocto Project source repositories you need to change
|
||
the <filename>SRCREV</filename> statements.
|
||
You can find all the <filename>machine</filename> and <filename>meta</filename>
|
||
branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
|
||
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.
|
||
</para>
|
||
|
||
<para>
|
||
If you need a little more assistance after going to the link then do the following:
|
||
<orderedlist>
|
||
<listitem><para>Expand the list of branches by clicking <filename>[…]</filename></para></listitem>
|
||
<listitem><para>Click on the <filename>yocto/standard/common-pc/atom-pc</filename>
|
||
branch</para></listitem>
|
||
<listitem><para>Click on the commit column header to view the top commit</para></listitem>
|
||
<listitem><para>Copy the commit string for use in the
|
||
<filename>linux-yocto_3.0.bbappend</filename> file</para></listitem>
|
||
</orderedlist>
|
||
</para>
|
||
|
||
<para>
|
||
For the <filename>SRCREV</filename> statement that points to the <filename>meta</filename>
|
||
branch use the same procedure except expand the <filename>meta</filename>
|
||
branch in step 2 above.
|
||
</para>
|
||
|
||
<para>
|
||
Also in the <filename>linux-yocto_3.0.bbappend</filename> file are
|
||
<filename>COMPATIBLE_MACHINE</filename>, <filename>KMACHINE</filename>,
|
||
and <filename>KERNEL_FEATURES</filename> statements.
|
||
Two sets of these exist: one set supports EMGD and one set does not.
|
||
Because we are not interested in supporting EMGD those three can be deleted.
|
||
The remaining three must be changed so that <filename>mymachine</filename> replaces
|
||
<filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
|
||
Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all
|
||
the edits:
|
||
<literallayout class='monospaced'>
|
||
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
||
COMPATIBLE_MACHINE_mymachine = "mymachine"
|
||
KMACHINE_mymachine = "yocto/standard/mymachine"
|
||
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
|
||
|
||
SRCREV_machine_pn-linux-yocto_mymachine ?= \
|
||
"06c798f25a19281d7fa944b14366dd75820ba009"
|
||
SRCREV_meta_pn-linux-yocto_mymachine ?= \
|
||
"67a46a608f47c19f16995be7de7b272025864b1b"
|
||
</literallayout>
|
||
</para>
|
||
</section>
|
||
</section>
|
||
|
||
<section id='bsp-recipe-change-summary'>
|
||
<title>BSP Recipe Change Summary</title>
|
||
|
||
<para>
|
||
In summary, the edits to the layer’s recipe files result in removal of any files and
|
||
statements that do not support your targeted hardware in addition to the inclusion
|
||
of any new recipes you might need.
|
||
In this example, it was simply a matter of ridding the new layer
|
||
<filename>meta-machine</filename> of any code that supported the EMGD features
|
||
and making sure we were identifying the kernel that supports our example, which
|
||
is the <filename>atom-pc-standard</filename> kernel.
|
||
We did not introduce any new recipes to the layer.
|
||
</para>
|
||
|
||
<para>
|
||
Finally, it is also important to update the layer’s <filename>README</filename>
|
||
file so that the information in it reflects your BSP.
|
||
</para>
|
||
</section>
|
||
</section>
|
||
|
||
<section id='preparing-for-the-build-app'>
|
||
<title>Preparing for the Build</title>
|
||
|
||
<para>
|
||
To get ready to build your image that uses the new layer you need to do the following:
|
||
<orderedlist>
|
||
<listitem><para>Get the environment ready for the build by sourcing the environment
|
||
script.
|
||
The environment script is in the top-level of the local Yocto Project files
|
||
directory structure.
|
||
The script has the string
|
||
<filename>init-build-env</filename> in the file’s name.
|
||
For this example, the following command gets the build environment ready:
|
||
<literallayout class='monospaced'>
|
||
$ source oe-init-build-env yocto-build
|
||
</literallayout>
|
||
When you source the script a build directory is created in the current
|
||
working directory.
|
||
In our example we were in the <filename>poky</filename> directory.
|
||
Thus, entering the previous command created the <filename>yocto-build</filename> directory.
|
||
If you do not provide a name for the build directory it defaults to
|
||
<filename>build</filename>.
|
||
The <filename>yocot-build</filename> directory contains a
|
||
<filename>conf</filename> directory that has
|
||
two configuration files you will need to check: <filename>bblayers.conf</filename>
|
||
and <filename>local.conf</filename>.</para></listitem>
|
||
<listitem><para>Check and edit the resulting <filename>local.conf</filename> file.
|
||
This file minimally identifies the machine for which to build the image by
|
||
configuring the <filename>MACHINE</filename> variable.
|
||
For this example you must set the variable to mymachine as follows:
|
||
<literallayout class='monospaced'>
|
||
MACHINE ??= “mymachine”
|
||
</literallayout>
|
||
You should also be sure any other variables in which you are interested are set.
|
||
Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
|
||
and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time
|
||
if you are using a multi-threaded development system (e.g. values of
|
||
<filename>8</filename> and <filename>j 6</filename>, respectively are optimal
|
||
for a development machine that has four available cores).</para></listitem>
|
||
<listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes
|
||
the path to your new BSP layer.
|
||
In this example you need to include the pathname to <filename>meta-mymachine</filename>.
|
||
For this example the
|
||
<filename>BBLAYERS</filename> variable in the file would need to include the following path:
|
||
<literallayout class='monospaced'>
|
||
$HOME/poky/meta-intel/meta-mymachine
|
||
</literallayout></para></listitem>
|
||
</orderedlist>
|
||
</para>
|
||
|
||
<para>
|
||
The appendix
|
||
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
|
||
Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information
|
||
on configuration variables.
|
||
</para>
|
||
</section>
|
||
|
||
<section id='building-the-image-app'>
|
||
<title>Building the Image</title>
|
||
|
||
<para>
|
||
To build the image for our <filename>meta-mymachine</filename> BSP enter the following command
|
||
from the same shell from which you ran the setup script.
|
||
You should run the <filename>bitbake</filename> command without any intervening shell commands.
|
||
For example, moving your working directory around could cause problems.
|
||
Here is the command for this example:
|
||
<literallayout class='monospaced'>
|
||
$ bitbake -k core-image-sato
|
||
</literallayout>
|
||
</para>
|
||
|
||
<para>
|
||
This command specifies an image that has Sato support and that can be run from a USB device or
|
||
from a CD without having to first install anything.
|
||
The build process takes significant time and includes thousands of tasks, which are reported
|
||
at the console.
|
||
If the build results in any type of error you should check for misspellings in the
|
||
files you changed or problems with your host development environment such as missing packages.
|
||
</para>
|
||
</section>
|
||
</appendix>
|
||
|
||
|
||
<!--
|
||
vim: expandtab tw=80 ts=4
|
||
-->
|