documentation/poky-ref-manual: Yocto Project scrub
I have changed as many "Yocto Project" terms as possible so that better reflect reality. (From yocto-docs rev: 5f729e53b0cb653c97621e4e6598d9295d60ada5) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
7064538309
commit
5966b44893
|
@ -10,7 +10,7 @@
|
|||
<para>
|
||||
The Yocto Project supports several methods of application development through which
|
||||
you can create user-space software designed to run on an embedded device that uses
|
||||
a Linux Yocto image developed with the Yocto Project.
|
||||
a Yocto Project image, which was developed with the OpenEmbedded build system.
|
||||
This flexibility allows you to choose the method that works best for you.
|
||||
This chapter describes each development method.
|
||||
</para>
|
||||
|
@ -25,12 +25,12 @@
|
|||
section in that when you invoke <filename>devshell</filename> source files are
|
||||
extracted into your working directory and patches are applied.
|
||||
Then, a new terminal is opened and you are placed in the working directory.
|
||||
In the new terminal all the Yocto Project build-related environment variables are
|
||||
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 Yocto Project build system were executing them.
|
||||
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 Yocto Project build system.
|
||||
software to be used with the OpenEmbedded build system.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -45,7 +45,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
This command opens a terminal with a shell prompt within the Poky
|
||||
This command opens a terminal with a shell prompt within the Yocto Project
|
||||
environment.
|
||||
The following occurs:
|
||||
<itemizedlist>
|
||||
|
@ -58,7 +58,7 @@
|
|||
</itemizedlist>
|
||||
Within this environment, you can run <filename>configure</filename>
|
||||
or <filename>compile</filename> commands as if they were being run by
|
||||
the Yocto Project build system itself.
|
||||
the OpenEmbedded build system itself.
|
||||
As noted earlier, the working directory also automatically changes to the
|
||||
source directory (<filename><link linkend='var-S'>S</link></filename>).
|
||||
</para>
|
||||
|
@ -71,8 +71,8 @@
|
|||
The default shell used by <filename>devshell</filename> is xterm.
|
||||
For examples of available options, see the "UI/Interaction Configuration"
|
||||
section of the
|
||||
<filename>meta/conf/bitbake.conf</filename> configuration file in the Yocto Project
|
||||
files.
|
||||
<filename>meta/conf/bitbake.conf</filename> configuration file in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -99,7 +99,7 @@
|
|||
|
||||
<para>
|
||||
If you're working on a recipe that pulls from an external Source Code Manager (SCM), it
|
||||
is possible to have the Yocto Project build system notice new changes added to the
|
||||
is possible to have the OpenEmbedded build system notice new changes added to the
|
||||
SCM and then build the package that depends on them using the latest version.
|
||||
This only works for SCMs from which it is possible to get a sensible revision number for changes.
|
||||
Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories.
|
||||
|
@ -107,7 +107,8 @@
|
|||
|
||||
<para>
|
||||
To enable this behavior, simply add the following to the <filename>local.conf</filename>
|
||||
configuration file in the build directory of the Yocto Project files:
|
||||
configuration file found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
SRCREV_pn-<PN> = "${AUTOREV}"
|
||||
</literallayout>
|
||||
|
|
|
@ -13,11 +13,17 @@
|
|||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Poky is the Yocto Project build system that was derived from <ulink
|
||||
The term "Poky" is sometimes used to refer to the build system that the
|
||||
Yocto Project uses.
|
||||
The build system used in the Yocto project is referred to as the
|
||||
OpenEmbedded build system because "Poky" was derived from <ulink
|
||||
url='&OE_HOME_URL;'>OpenEmbedded</ulink>.
|
||||
Poky is a stable, smaller subset focused on the mobile environment.
|
||||
Development in the Yocto Project using Poky is closely tied to OpenEmbedded with
|
||||
features being merged regularly between the two for mutual benefit.
|
||||
For a fuller description of the term "Poky", see the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> term in the Yocto Project
|
||||
Development Manual.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
@ -64,7 +70,8 @@
|
|||
<para>
|
||||
There are three areas that help with stability;
|
||||
<itemizedlist>
|
||||
<listitem><para>The Yocto Project team keeps Poky small and focused.
|
||||
<listitem><para>The Yocto Project team keeps
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> small and focused.
|
||||
It contains around 650 packages as compared to over 5000 for full
|
||||
OpenEmbedded.</para></listitem>
|
||||
<listitem><para>The Yocto Project only supports hardware that the
|
||||
|
@ -100,16 +107,17 @@
|
|||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
Are there any products using Poky?
|
||||
Are there any products using the OpenEmbedded build system (poky)?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink> is using
|
||||
the Yocto Project build system Poky.
|
||||
the OpenEmbedded build system.
|
||||
See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
|
||||
for more information.
|
||||
There are a number of pre-production devices using Poky and the Yocto Project team
|
||||
There are a number of pre-production devices using the OpenEmbedded build system
|
||||
and the Yocto Project team
|
||||
announces them as soon as they are released.
|
||||
</para>
|
||||
</answer>
|
||||
|
@ -118,13 +126,13 @@
|
|||
<qandaentry>
|
||||
<question>
|
||||
<para>
|
||||
What does the Yocto Project build system Poky produce as output?
|
||||
What does the OpenEmbedded build system produce as output?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Because the same set of recipes can be used to create output of various formats, the
|
||||
output of a Yocto Project build depends on how it was started.
|
||||
output of an OpenEmbedded build depends on how it was started.
|
||||
Usually, the output is a flashable image ready for the target device.
|
||||
</para>
|
||||
</answer>
|
||||
|
@ -155,7 +163,7 @@
|
|||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The Yocto Project can build packages in various formats such as
|
||||
The OpenEmbedded build system can build packages in various formats such as
|
||||
<filename>ipk</filename> for <filename>ipkg</filename>/<filename>opkg</filename>,
|
||||
Debian package (<filename>.deb</filename>), or RPM.
|
||||
The packages can then be upgraded using the package tools on the device, much like
|
||||
|
@ -223,8 +231,8 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Once these packages are installed, the Yocto Project will be able to build standard
|
||||
images.
|
||||
Once these packages are installed, the OpenEmbedded build system will be able
|
||||
to build standard images.
|
||||
However, there might be a problem with the QEMU emulator segfaulting.
|
||||
You can either disable the generation of binary locales by setting
|
||||
<filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
|
||||
|
@ -244,14 +252,14 @@
|
|||
<answer>
|
||||
<para>
|
||||
Nothing is wrong.
|
||||
The Yocto Project checks any configured source mirrors before downloading
|
||||
The OpenEmbedded build system checks any configured source mirrors before downloading
|
||||
from the upstream sources.
|
||||
The Yocto Project does this searching for both source archives and
|
||||
The build system does this searching for both source archives and
|
||||
pre-checked out versions of SCM managed software.
|
||||
These checks help in large installations because it can reduce load on the SCM servers
|
||||
themselves.
|
||||
The address above is one of the default mirrors configured into the
|
||||
Yocto Project.
|
||||
build system.
|
||||
Consequently, if an upstream source disappears, the team
|
||||
can place sources there so builds continue to work.
|
||||
</para>
|
||||
|
@ -284,7 +292,7 @@
|
|||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Most source fetching by the Yocto Project is done by <filename>wget</filename>
|
||||
Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
|
||||
and you therefore need to specify the proxy settings in a
|
||||
<filename>.wgetrc</filename> file in your home directory.
|
||||
Example settings in that file would be
|
||||
|
@ -350,7 +358,7 @@
|
|||
the most likely explanation is that either the hardware you're running the
|
||||
build on has some problem, or, if you are running the build under virtualisation,
|
||||
the virtualisation probably has bugs.
|
||||
The Yocto Project processes a massive amount of data causing lots of network, disk and
|
||||
The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and
|
||||
CPU activity and is sensitive to even single bit failures in any of these areas.
|
||||
True random failures have always been traced back to hardware or virtualisation issues.
|
||||
</para>
|
||||
|
@ -449,7 +457,7 @@
|
|||
<answer>
|
||||
<para>
|
||||
The Yocto Project team has tried to do this before but too many of the tools
|
||||
the Yocto Project depends on such as <filename>autoconf</filename>
|
||||
the OpenEmbedded build system depends on such as <filename>autoconf</filename>
|
||||
break when they find spaces in pathnames.
|
||||
Until that situation changes, the team will not support spaces in pathnames.
|
||||
</para>
|
||||
|
@ -495,14 +503,14 @@
|
|||
<qandaentry>
|
||||
<question>
|
||||
<para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
|
||||
How does the Yocto Project build system obtain source code and will it work behind my
|
||||
How does the OpenEmbedded build system obtain source code and will it work behind my
|
||||
firewall or proxy server?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
The way the Yocto Project obtains source code is highly configurable.
|
||||
You can setup the Yocto Project to get source code in most environments if
|
||||
The way the build system obtains source code is highly configurable.
|
||||
You can setup the build system to get source code in most environments if
|
||||
HTTP transport is available.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -511,7 +519,8 @@
|
|||
and then MIRRORS in that order.
|
||||
</para>
|
||||
<para>
|
||||
By default, Poky uses the Yocto Project source PREMIRRORS for SCM-based sources,
|
||||
By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS
|
||||
for SCM-based sources,
|
||||
upstreams for normal tarballs, and then falls back to a number of other mirrors
|
||||
including the Yocto Project source mirror if those fail.
|
||||
</para>
|
||||
|
@ -574,7 +583,7 @@
|
|||
any network accesses to anything other than the PREMIRROR would fail.
|
||||
</para>
|
||||
<para>
|
||||
Poky also honors the standard shell environment variables
|
||||
The build system also honors the standard shell environment variables
|
||||
<filename>http_proxy</filename>, <filename>ftp_proxy</filename>,
|
||||
<filename>https_proxy</filename>, and <filename>all_proxy</filename>
|
||||
to redirect requests through proxy servers.
|
||||
|
@ -600,8 +609,8 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Within the Yocto Project Build Directory is the <filename>tmp</filename>
|
||||
directory.
|
||||
Within the <ulink url='&YOCTO_DOCS_DEV_URL;buile-directory'>build directory</ulink>
|
||||
is the <filename>tmp</filename> directory.
|
||||
To remove all the build output yet preserve any source code or downloaded files
|
||||
from previous builds, simply remove the <filename>tmp</filename> directory.
|
||||
</para>
|
||||
|
|
|
@ -12,8 +12,8 @@
|
|||
This manual provides reference information for the current release of the Yocto Project.
|
||||
The Yocto Project is an open-source collaboration project focused on embedded Linux
|
||||
developers.
|
||||
Amongst other things, the Yocto Project uses the Poky build tool to
|
||||
construct complete Linux images.
|
||||
Amongst other things, the Yocto Project uses the OpenEmbedded build system, which
|
||||
is based on the Poky project, to construct complete Linux images.
|
||||
You can find complete introductory and getting started information on the Yocto Project
|
||||
by reading the
|
||||
<ulink url='&YOCTO_DOCS_QS_URL;'>
|
||||
|
@ -51,9 +51,13 @@
|
|||
the Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-structure'>Reference: Directory Structure</link>:</emphasis>
|
||||
This appendix describes the directory structure of the Yocto Project files.
|
||||
The Yocto Project files represent the file structure or Git repository created
|
||||
as a result of setting up the Yocto Project on your host development system.
|
||||
This appendix describes the directory structure of the
|
||||
Yocto Project files, referred to as the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
The source directory represents the local file structure created
|
||||
as a result from either cloning the upstream
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository or unpacking a
|
||||
released Yocto Project tarball on your host development system.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-bitbake'>Reference: BitBake</link>:</emphasis>
|
||||
|
@ -69,7 +73,7 @@
|
|||
<listitem><para><emphasis>
|
||||
<link linkend='ref-features'>Reference: Features</link>:</emphasis>
|
||||
This appendix describes mechanisms for creating distribution, machine, and image
|
||||
features during the build process using the Yocto Project.</para></listitem>
|
||||
features during the build process using the OpenEmbedded build system.</para></listitem>
|
||||
<listitem><para><emphasis>
|
||||
<link linkend='ref-variables-glos'>Reference: Variables Glossary</link>:</emphasis>
|
||||
This appendix presents most Yocto Project variables.
|
||||
|
@ -124,9 +128,11 @@
|
|||
<section id='intro-getit-dev'>
|
||||
<title>Development Checkouts</title>
|
||||
<para>
|
||||
Development using the Yocto Project requires a local copy of the Yocto Project files.
|
||||
You can get these files by downloading a Yocto Project release tarball and unpacking it,
|
||||
or by establishing a Git repository of the files.
|
||||
Development using the Yocto Project requires a local copy of the Yocto Project files
|
||||
referred to as the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
You can set source directory up by downloading a Yocto Project release tarball and unpacking it,
|
||||
or by cloning a copy of the upstream
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
|
||||
For information on both these methods, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>"
|
||||
section in The Yocto Project Development Manual.
|
||||
|
|
|
@ -7,7 +7,8 @@
|
|||
<title>Reference: BitBake</title>
|
||||
|
||||
<para>
|
||||
BitBake is a program written in Python that interprets the metadata that makes up the Yocto Project.
|
||||
BitBake is a program written in Python that interprets the metadata used by the Yocto Project.
|
||||
The OpenEmbedded build system uses BitBake.
|
||||
At some point, developers wonder what actually happens when you enter:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake core-image-sato
|
||||
|
@ -34,20 +35,22 @@
|
|||
|
||||
<para>
|
||||
The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
|
||||
The Yocto Project keeps this file in the Yocto Project file's <filename>meta/conf/</filename>
|
||||
directory.
|
||||
BitBake finds it by examining its <filename>BBPATH</filename> environment
|
||||
This file resides in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
|
||||
within the <filename>meta/conf/</filename> directory.
|
||||
BitBake finds it by examining its
|
||||
<link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
|
||||
variable and looking for the <filename>meta/conf/</filename>
|
||||
directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the Yocto Project, <filename>bitbake.conf</filename> lists other configuration
|
||||
The <filename>bitbake.conf</filename> file lists other configuration
|
||||
files to include from a <filename>conf/</filename>
|
||||
directory below the directories listed in <filename>BBPATH</filename>.
|
||||
In general, the most important configuration file from a user's perspective
|
||||
is <filename>local.conf</filename>, which contains a user's customized
|
||||
settings for the Yocto Project build environment.
|
||||
settings for the OpenEmbedded build environment.
|
||||
Other notable configuration files are the distribution
|
||||
configuration file (set by the
|
||||
<filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable)
|
||||
|
|
|
@ -12,10 +12,11 @@
|
|||
file.
|
||||
Class files are identified by the extension <filename>.bbclass</filename> and are usually placed
|
||||
in a <filename>classes/</filename> directory beneath the
|
||||
<filename>meta*/</filename> directory found in the Yocto Project file's area
|
||||
<filename>meta*/</filename> directory found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
|
||||
<filename>.conf</filename> files in the <filename>conf</filename> directory.
|
||||
Class files are searched for in <filename>BBPATH</filename>
|
||||
Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
|
||||
using the same method by which <filename>.conf</filename> files are searched.
|
||||
</para>
|
||||
|
||||
|
@ -111,7 +112,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Currently, the Yocto Project supports only one binary per package.
|
||||
Currently, the OpenEmbedded build system supports only one binary per package.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -121,7 +122,7 @@
|
|||
<para>
|
||||
This class uses <filename>update-rc.d</filename> to safely install an
|
||||
initialization script on behalf of the package.
|
||||
The Yocto Project takes care of details such as making sure the script is stopped before
|
||||
The OpenEmbedded build system takes care of details such as making sure the script is stopped before
|
||||
a package is removed and started when the package is installed.
|
||||
Three variables control this class:
|
||||
<filename><link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link></filename>,
|
||||
|
@ -254,7 +255,7 @@
|
|||
|
||||
<para>
|
||||
This class adds the <filename>devshell</filename> task.
|
||||
Distribution policy dictates whether to include this class as the Yocto Project does.
|
||||
Distribution policy dictates whether to include this class.
|
||||
See the
|
||||
"<link linkend='platdev-appdev-devshell'>Development Within a Development Shell</link>" section
|
||||
for more information about using devshell.
|
||||
|
@ -277,8 +278,9 @@
|
|||
<para>
|
||||
You can control the list of resulting package formats by using the
|
||||
<filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename>
|
||||
variable defined in the <filename>local.conf</filename> configuration file
|
||||
found in the Yocto Project file's <filename>conf</filename> directory.
|
||||
variable defined in the <filename>local.conf</filename> configuration file,
|
||||
which is located in the <filename>conf</filename> folder of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
When defining the variable, you can specify one or more package types.
|
||||
Since images are generated from packages, a packaging class is
|
||||
needed to enable image generation.
|
||||
|
@ -380,7 +382,7 @@
|
|||
The class also performs basic user configuration checks from
|
||||
the <filename>local.conf</filename> configuration file to
|
||||
prevent common mistakes that cause build failures.
|
||||
Distribution policy usually whether to include this class as the Yocto Project does.
|
||||
Distribution policy usually determines whether to include this class.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -389,10 +391,10 @@
|
|||
|
||||
<para>
|
||||
This class adds a step to the package generation process that sanity checks the
|
||||
packages generated by the Yocto Project.
|
||||
packages generated by the OpenEmbedded build system.
|
||||
A range of checks are performed that check the build's output
|
||||
for common problems that show up during runtime.
|
||||
Distribution policy usually dictates whether to include this class as the Yocto Project does.
|
||||
Distribution policy usually dictates whether to include this class.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -514,7 +516,8 @@
|
|||
you can use this class to specify those packages and associate the users and groups
|
||||
with those packages.
|
||||
The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
|
||||
recipe in the Yocto Project Files provides a simple exmample that shows how to add three
|
||||
recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
|
||||
provides a simple exmample that shows how to add three
|
||||
users and groups to two packages.
|
||||
See the <filename>useradd-example.bb</filename> for more information on how to
|
||||
use this class.
|
||||
|
@ -526,7 +529,7 @@
|
|||
|
||||
<para>
|
||||
You can use this class to build software from source code that is external to the
|
||||
Yocto Project build system.
|
||||
OpenEmbedded build system.
|
||||
In other words, your source code resides in an external tree outside of the Yocto Project.
|
||||
Building software from an external source tree means that the normal fetch, unpack, and
|
||||
patch process is not used.
|
||||
|
@ -541,7 +544,7 @@
|
|||
<para>
|
||||
This class expects the source code to support recipe builds that use the
|
||||
<link linkend='var-B'><filename>B</filename></link> variable to point to the directory in
|
||||
which the Yocto Project build system places the generated objects built from the recipes.
|
||||
which the OpenEmbedded build system places the generated objects built from the recipes.
|
||||
By default, the <filename>B</filename> directory is set to the following, which is separate from the
|
||||
source directory (<filename>S</filename>):
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -570,7 +573,7 @@
|
|||
When you do, the <link linkend='var-B'><filename>B</filename></link> variable must support the
|
||||
recipe's ability to build variants in different working directories.
|
||||
Most autotools-based recipes support separating these directories.
|
||||
The Yocto Project defaults to using separate directories for <filename>gcc</filename>
|
||||
The OpenEmbedded build system defaults to using separate directories for <filename>gcc</filename>
|
||||
and some kernel recipes.
|
||||
Alternatively, you can make sure that separate recipes exist that each
|
||||
use the <filename>BBCLASSEXTEND</filename> variable to build each variant.
|
||||
|
@ -591,7 +594,7 @@
|
|||
Thus far, this appendix has discussed only the most useful and important
|
||||
classes.
|
||||
However, other classes exist within the <filename>meta/classes</filename> directory
|
||||
in the Yocto Project file's directory structure.
|
||||
in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
You can examine the <filename>.bbclass</filename> files directly for more
|
||||
information.
|
||||
</para>
|
||||
|
|
|
@ -115,7 +115,7 @@
|
|||
<title>Reference: Images</title>
|
||||
|
||||
<para>
|
||||
The contents of images generated by the Yocto Project can be controlled by the
|
||||
The contents of images generated by the OpenEmbedded build system can be controlled by the
|
||||
<filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
|
||||
and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename>
|
||||
variables that you typically configure in your image recipes.
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
<title>Reference: Images</title>
|
||||
|
||||
<para>
|
||||
The Yocto Project build process supports several types of images to satisfy different needs.
|
||||
The OpenEmbedded build process supports several types of images to satisfy different needs.
|
||||
When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe
|
||||
that essentially begins the build for the type of image you want.
|
||||
</para>
|
||||
|
@ -32,8 +32,8 @@
|
|||
These recipes reside in the <filename>meta/recipes-core/images</filename>,
|
||||
<filename>meta/recipes-extended/images</filename>,
|
||||
<filename>meta/recipes-graphics/images</filename>, and
|
||||
<filename>meta/recipes-sato/images</filename> directories of your local Yocto Project
|
||||
file structure (Git repository or extracted release tarball).
|
||||
<filename>meta/recipes-sato/images</filename> directories
|
||||
within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
Although the recipe names are somewhat explanatory, here is a list that describes them:
|
||||
</para>
|
||||
|
||||
|
|
|
@ -9,12 +9,12 @@
|
|||
<para>
|
||||
The Yocto Project consists of several components.
|
||||
Understanding them and knowing where they are located is key to using the Yocto Project well.
|
||||
This appendix describes the Yocto Project file's directory structure and gives information about the various
|
||||
files and directories.
|
||||
This appendix describes the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
|
||||
and gives information about the various files and directories.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information on how to establish the Yocto Project files on your local development system, see the
|
||||
For information on how to establish a local source directory on your development system, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
|
@ -49,18 +49,20 @@
|
|||
|
||||
<para>
|
||||
This directory contains user configuration files and the output
|
||||
generated by the Yocto Project in its standard configuration where the source tree is
|
||||
combined with the output.
|
||||
The build directory is created initially when you <filename>source</filename>
|
||||
generated by the OpenEmbedded build system in its standard configuration where
|
||||
the source tree is combined with the output.
|
||||
The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
|
||||
is created initially when you <filename>source</filename>
|
||||
the Yocto Project environment setup script <filename>oe-init-build-env</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is also possible to place output and configuration
|
||||
files in a directory separate from the Yocto Project files
|
||||
files in a directory separate from the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
|
||||
by providing a directory name when you <filename>source</filename>
|
||||
the setup script.
|
||||
For information on separating output from the Yocto Project files, see <link
|
||||
For information on separating output from your local source directory files, see <link
|
||||
linkend='structure-core-script'>oe-init-build-env</link>.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -147,9 +149,11 @@
|
|||
By default, running this script without a build directory argument creates the
|
||||
<filename>build</filename> directory.
|
||||
If you provide a build directory argument when you <filename>source</filename>
|
||||
the script, you direct the Yocto Project to create a build directory of your choice.
|
||||
the script, you direct OpenEmbedded build system to create a
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> of your choice.
|
||||
For example, the following command creates a build directory named
|
||||
<filename>mybuilds</filename> that is outside of the Yocto Project files:
|
||||
<filename>mybuilds</filename> that is outside of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>sourc directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
$ source oe-init-build-env ~/mybuilds
|
||||
</literallayout>
|
||||
|
@ -181,12 +185,12 @@
|
|||
<title><filename>build/conf/local.conf</filename></title>
|
||||
|
||||
<para>
|
||||
This file contains all the local user configuration of the Yocto Project.
|
||||
This file contains all the local user configuration for your build environment.
|
||||
If there is no <filename>local.conf</filename> present, it is created from
|
||||
<filename>local.conf.sample</filename>.
|
||||
The <filename>local.conf</filename> file contains documentation on the various configuration options.
|
||||
Any variable set here overrides any variable set elsewhere within the Yocto Project unless
|
||||
that variable is hard-coded within the Yocto Project (e.g. by using '=' instead of '?=').
|
||||
Any variable set here overrides any variable set elsewhere within the environment unless
|
||||
that variable is hard-coded within a file (e.g. by using '=' instead of '?=').
|
||||
Some variables are hard-coded for various reasons but these variables are
|
||||
relatively rare.
|
||||
</para>
|
||||
|
@ -244,10 +248,11 @@
|
|||
<title><filename>build/tmp/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives all the Yocto Project output.
|
||||
This directory receives all the OpenEmbedded build system's output.
|
||||
BitBake creates this directory if it does not exist.
|
||||
As a last resort, to clean the Yocto Project and start a build from scratch (other than downloads),
|
||||
you can remove everything in this directory or get rid of the directory completely.
|
||||
As a last resort, to clean up a build and start it from scratch (other than the downloads),
|
||||
you can remove everything in the <filename>tmp</filename> directory or get rid of the
|
||||
directory completely.
|
||||
If you do, you should also completely remove the <filename>build/sstate-cache</filename>
|
||||
directory as well.
|
||||
</para>
|
||||
|
@ -275,7 +280,7 @@
|
|||
<title><filename>build/tmp/deploy/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory contains any 'end result' output from the Yocto Project build process.
|
||||
This directory contains any 'end result' output from the OpenEmbedded build process.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -283,7 +288,8 @@
|
|||
<title><filename>build/tmp/deploy/deb/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives any <filename>.deb</filename> packages produced by the Yocto Project.
|
||||
This directory receives any <filename>.deb</filename> packages produced by
|
||||
the build process.
|
||||
The packages are sorted into feeds for different architecture types.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -292,7 +298,8 @@
|
|||
<title><filename>build/tmp/deploy/rpm/</filename></title>
|
||||
|
||||
<para>
|
||||
This directory receives any <filename>.rpm</filename> packages produced by the Yocto Project.
|
||||
This directory receives any <filename>.rpm</filename> packages produced by
|
||||
the build process.
|
||||
The packages are sorted into feeds for different architecture types.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -319,7 +326,9 @@
|
|||
<section id='structure-build-tmp-deploy-ipk'>
|
||||
<title><filename>build/tmp/deploy/ipk/</filename></title>
|
||||
|
||||
<para>This directory receives <filename>.ipk</filename> packages produced by the Yocto Project.</para>
|
||||
<para>
|
||||
This directory receives <filename>.ipk</filename> packages produced by
|
||||
the build process.</para>
|
||||
</section>
|
||||
|
||||
<section id='structure-build-tmp-sysroots'>
|
||||
|
@ -380,7 +389,8 @@
|
|||
|
||||
<para>
|
||||
It is worth considering the structure of a typical work directory.
|
||||
As an example, consider the linux-yocto kernel 3.0 on the machine <filename>qemux86</filename>
|
||||
As an example, consider the <filename>linux-yocto-kernel-3.0</filename>
|
||||
on the machine <filename>qemux86</filename>
|
||||
built within the Yocto Project.
|
||||
For this package, a work directory of
|
||||
<filename>tmp/work/qemux86-poky-linux/linux-yocto-3.0+git1+<.....></filename>,
|
||||
|
@ -455,7 +465,7 @@
|
|||
<para>
|
||||
This directory contains all the machine configuration files.
|
||||
If you set <filename>MACHINE="qemux86"</filename>,
|
||||
Yocto Project looks for a <filename>qemux86.conf</filename> file in this
|
||||
the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this
|
||||
directory.
|
||||
The <filename>include</filename> directory contains various data common to multiple machines.
|
||||
If you want to add support for a new machine to the Yocto Project, look in this directory.
|
||||
|
@ -467,12 +477,11 @@
|
|||
|
||||
<para>
|
||||
Any distribution-specific configuration is controlled from this directory.
|
||||
The Yocto Project only contains the Yocto Project distribution so
|
||||
<filename>defaultsetup.conf</filename> is the main file here.
|
||||
For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here.
|
||||
This directory includes the versions and the
|
||||
<filename>SRCDATE</filename> definitions for applications that are configured here.
|
||||
An example of an alternative configuration is <filename>poky-bleeding.conf</filename>
|
||||
although this file mainly inherits its configuration from the Yocto Project itself.
|
||||
An example of an alternative configuration might be <filename>poky-bleeding.conf</filename>.
|
||||
Although this file mainly inherits its configuration from Poky.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
<title>Reference: Variables Glossary</title>
|
||||
|
||||
<para>
|
||||
This section lists common variables used in the Yocto Project and gives an overview
|
||||
This section lists common variables used in the OpenEmbedded build system and gives an overview
|
||||
of their function and contents.
|
||||
</para>
|
||||
|
||||
|
@ -89,7 +89,7 @@
|
|||
<glossentry id='var-B'><glossterm>B</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
The directory in which the Yocto Project build system places
|
||||
The directory in which the OpenEmbedded build system places
|
||||
generated objects during a recipe's build process.
|
||||
By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
|
||||
directory:
|
||||
|
@ -99,7 +99,7 @@
|
|||
You can separate the source directory (<filename>S</filename>) and the directory pointed to
|
||||
by the <filename>B</filename> variable.
|
||||
Most autotools-based recipes support separating these directories.
|
||||
The Yocto Project defaults to using separate directories for <filename>gcc</filename>
|
||||
The build system defaults to using separate directories for <filename>gcc</filename>
|
||||
and some kernel recipes.
|
||||
</para>
|
||||
</glossdef>
|
||||
|
@ -160,7 +160,7 @@
|
|||
</literallayout></para>
|
||||
<para>Use the <filename>BBMASK</filename> variable from within the
|
||||
<filename>conf/local.conf</filename> file found
|
||||
in the Yocto Project build directory.</para>
|
||||
in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -243,9 +243,9 @@
|
|||
|
||||
<glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
|
||||
<glossdef>
|
||||
<para>Lists the layers to enable during the Yocto Project build.
|
||||
<para>Lists the layers to enable during the build.
|
||||
This variable is defined in the <filename>bblayers.conf</filename> configuration
|
||||
file in the Yocto Project build directory.
|
||||
file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
BBLAYERS = " \
|
||||
|
@ -335,8 +335,8 @@
|
|||
<filename>/etc</filename> or <filename>${bindir}</filename> rather
|
||||
than <filename>/usr/bin</filename>.
|
||||
You can find a list of these variables at the top of the
|
||||
<filename>/meta/conf/bitbake.conf</filename> file in the Yocto Project
|
||||
files directory.
|
||||
<filename>/meta/conf/bitbake.conf</filename> file in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
</note>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
@ -358,7 +358,7 @@
|
|||
Specifies the list of packages to be added to the image.
|
||||
This variable should only be set in the <filename>local.conf</filename>
|
||||
configuration file found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build Directory</ulink>.
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -479,7 +479,7 @@
|
|||
This directory is self-maintaining and you should not have
|
||||
to touch it.
|
||||
By default, the directory is <filename>downloads</filename> in the
|
||||
Yocto Project build directory.
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
|
||||
<literallayout class='monospaced'>
|
||||
#DL_DIR ?= "${TOPDIR}/downloads"
|
||||
</literallayout>
|
||||
|
@ -635,8 +635,8 @@
|
|||
<filename>/etc</filename> or <filename>${bindir}</filename> rather
|
||||
than <filename>/usr/bin</filename>.
|
||||
You can find a list of these variables at the top of the
|
||||
<filename>/meta/conf/bitbake.conf</filename> file in the Yocto Project
|
||||
files directory.
|
||||
<filename>/meta/conf/bitbake.conf</filename> file in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
</note>
|
||||
|
||||
<para>
|
||||
|
@ -655,7 +655,7 @@
|
|||
<glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
Extends the search path the Yocto Project build system uses when
|
||||
Extends the search path the OpenEmbedded build system uses when
|
||||
looking for files and patches as it processes recipes.
|
||||
The directories BitBake uses when it processes recipes is defined by the
|
||||
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable.
|
||||
|
@ -691,7 +691,7 @@
|
|||
<glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
The default set of directories the Yocto Project build system uses
|
||||
The default set of directories the OpenEmbedded build system uses
|
||||
when searching for patches and files.
|
||||
During the build process, BitBake searches each directory in
|
||||
<filename>FILESPATH</filename> in the specified order when looking for
|
||||
|
@ -702,7 +702,7 @@
|
|||
The default value for the <filename>FILESPATH</filename> variable is defined
|
||||
in the <filename>base.bbclass</filename> class found in
|
||||
<filename>meta/classes</filename> in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>:
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
||||
"${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", \
|
||||
|
@ -727,16 +727,17 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
possible.
|
||||
</para>
|
||||
<para>
|
||||
By default, the Yocto Project uses the <filename>fs-perms.txt</filename>, which
|
||||
is located in the <filename>meta/files</filename> directory of the Yocto Project
|
||||
files directory.
|
||||
By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which
|
||||
is located in the <filename>meta/files</filename> folder in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
If you create your own file permissions setting table, you should place it in your
|
||||
layer or the distros layer.
|
||||
</para>
|
||||
<para>
|
||||
You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
|
||||
<filename>conf/local.conf</filename> file, which is found in the Yocto Project's
|
||||
build directory, to point to your custom <filename>fs-perms.txt</filename>.
|
||||
<filename>conf/local.conf</filename> file, which is found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>, to
|
||||
point to your custom <filename>fs-perms.txt</filename>.
|
||||
You can specify more than a single file permissions setting table.
|
||||
The paths you specify to these files must be defined within the
|
||||
<filename>BBPATH</filename> variable.
|
||||
|
@ -785,7 +786,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
Note that you can add extra features to the image by using the
|
||||
<filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
|
||||
See the "<link linkend="ref-features-image">Reference: Images</link>" section for the
|
||||
list of features present in images built by the Yocto Project.</para>
|
||||
list of features present in images built by the OpenEmbedded build system.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
|
@ -908,7 +909,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossdef>
|
||||
<para>
|
||||
Defines the size in Kbytes for the generated image.
|
||||
The Yocto Project build system determines the final size for the generated
|
||||
The OpenEmbedded build system determines the final size for the generated
|
||||
image using an algorithm that takes into account the initial disk space used
|
||||
for the generated image, a requested size for the image, and requested
|
||||
additional free disk space to be added to the image.
|
||||
|
@ -1035,8 +1036,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
|
||||
<glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
|
||||
<glossdef>
|
||||
<para>Includes additional metadata from the Linux Yocto kernel Git repository.
|
||||
In the Yocto Project build system, the default Board Support Packages (BSPs)
|
||||
<para>Includes additional metadata from the Yocto Project kernel Git repository.
|
||||
In the OpenEmbedded build system, the default Board Support Packages (BSPs)
|
||||
metadata is provided through
|
||||
the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables.
|
||||
You can use the <filename>KERNEL_FEATURES</filename> variable to further
|
||||
|
@ -1049,7 +1050,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
In this way, you can provide validated, but optional, sets of kernel
|
||||
configurations and features.</para>
|
||||
<para>For example, the following adds <filename>netfilter</filename> to all
|
||||
the Linux Yocto kernels and adds sound support to the <filename>qemux86</filename>
|
||||
the Yocto Project kernels and adds sound support to the <filename>qemux86</filename>
|
||||
machine:
|
||||
<literallayout class='monospaced'>
|
||||
# Add netfilter to all linux-yocto kernels
|
||||
|
@ -1137,7 +1138,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossentry id='var-LICENSE_DIR'><glossterm>LICENSE_DIR</glossterm>
|
||||
<glossdef>
|
||||
<para>Path to additional licenses used during the build.
|
||||
By default, the Yocto Project uses <filename>COMMON_LICENSE_DIR</filename>
|
||||
By default, the OpenEmbedded build system uses <filename>COMMON_LICENSE_DIR</filename>
|
||||
to define the directory that holds common license text used during the build.
|
||||
The <filename>LICENSE_DIR</filename> variable allows you to extend that
|
||||
location to other areas that have additional licenses:
|
||||
|
@ -1341,7 +1342,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm>
|
||||
<glossdef>
|
||||
<para>This variable, which is set in the <filename>local.conf</filename> configuration
|
||||
file found in the Yocto Project file's <filename>conf</filename> directory,
|
||||
file found in the <filename>conf</filename> folder of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>,
|
||||
specifies the package manager to use when packaging data.
|
||||
You can provide one or more arguments for the variable with the first
|
||||
argument being the package manager used to create images:
|
||||
|
@ -1534,7 +1536,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variable.
|
||||
</para>
|
||||
<para>
|
||||
The Yocto Project build process automatically installs the list of packages
|
||||
The OpenEmbedded build process automatically installs the list of packages
|
||||
as part of the built package.
|
||||
However, you can remove them later if you want.
|
||||
If, during the build, a package from the list cannot be found, the build
|
||||
|
@ -1572,8 +1574,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossentry id='var-S'><glossterm>S</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
|
||||
Yocto Project Build Directory</ulink> where unpacked package source code resides.
|
||||
The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
|
||||
where unpacked package source code resides.
|
||||
This location is within the working directory
|
||||
(<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>), which
|
||||
is not static.
|
||||
|
@ -1585,9 +1587,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
${WORKDIR}/${PN}-${PV}
|
||||
</literallayout>
|
||||
As an example, assume a
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>
|
||||
Yocto Project Files</ulink> top-level directory named <filename>poky</filename>
|
||||
and a default Yocto Project Build Directory of <filename>poky/build</filename>.
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level
|
||||
folder named <filename>poky</filename>
|
||||
and a default <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
|
||||
at <filename>poky/build</filename>.
|
||||
In this case, the working directory the build system uses to build
|
||||
the <filename>db</filename> package is the following:
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -1661,10 +1664,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossdef>
|
||||
<para></para>
|
||||
<para>
|
||||
By default, the Yocto Project automatically detects whether
|
||||
By default, the OpenEmbedded build system automatically detects whether
|
||||
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>
|
||||
contains files that are machine-specific.
|
||||
If so, the Yocto Project automatically changes
|
||||
If so, the build system automatically changes
|
||||
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>.
|
||||
Setting this variable to "0" disables this behavior.
|
||||
</para>
|
||||
|
@ -1728,7 +1731,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
|
||||
<glossdef>
|
||||
<para>The architecture of the device being built.
|
||||
While a number of values are possible, the Yocto Project primarily supports
|
||||
While a number of values are possible, the OpenEmbedded build system primarily supports
|
||||
<filename>arm</filename> and <filename>i586</filename>.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
@ -1790,11 +1793,11 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
</para>
|
||||
<para>
|
||||
The <filename>TCMODE</filename> variable selects the external toolchain
|
||||
built from the Yocto Project or a few supported combinations of
|
||||
built using the OpenEmbedded build system or a few supported combinations of
|
||||
the upstream GCC or CodeSourcery Labs toolchain.
|
||||
The variable determines which of the <filename>tcmode-*</filename> files in
|
||||
the <filename>meta/conf/distro/include</filename> directory, which is found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>,
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>,
|
||||
is used.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -1811,20 +1814,18 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
This variable is the temporary directory the Yocto Project build system
|
||||
This variable is the temporary directory the OpenEmbedded build system
|
||||
uses when it does its work building images.
|
||||
By default, the <filename>TMPDIR</filename> variable is named
|
||||
<filename>tmp</filename> within the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
|
||||
Yocto Project Build Directory</ulink>.
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you want to establish this directory in a location other than the
|
||||
default, you can uncomment the following statement in the
|
||||
<filename>conf/local.conf</filename> file in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>
|
||||
Yocto Project Files</ulink>:
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
#TMPDIR = "${TOPDIR}/tmp"
|
||||
</literallayout>
|
||||
|
@ -1836,10 +1837,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossdef>
|
||||
<para>
|
||||
This variable is the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
|
||||
Yocto Project Build Directory</ulink>.
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
|
||||
BitBake automatically sets this variable.
|
||||
The Yocto Project build system uses the build directory when building images.
|
||||
The OpenEmbedded build system uses the build directory when building images.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
@ -1857,7 +1857,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
|
||||
<glossdef>
|
||||
<para>
|
||||
The pathname of the working directory in which the Yocto Project build system
|
||||
The pathname of the working directory in which the OpenEmbedded build system
|
||||
builds packages.
|
||||
This directory is located within the
|
||||
<link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> directory structure and changes
|
||||
|
@ -1884,11 +1884,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
|
||||
</literallayout>
|
||||
As an example, assume a
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>
|
||||
Yocto Project Files</ulink> top-level directory named <filename>poky</filename>
|
||||
and a default
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
|
||||
Yocto Project Build Directory</ulink> of <filename>poky/build</filename>.
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level
|
||||
folder name <filename>poky</filename> and a default
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
|
||||
at <filename>poky/build</filename>.
|
||||
In this case, the working directory the build system uses to build
|
||||
the <filename>v86d</filename> package is the following:
|
||||
<literallayout class='monospaced'>
|
||||
|
@ -1902,9 +1901,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
|
|||
<literallayout class='monospaced'>
|
||||
${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
|
||||
</literallayout>
|
||||
As an example, again assume a Yocto Project Files top-level directory
|
||||
named <filename>poky</filename> and a default Yocto Project build directory
|
||||
of <filename>poky/build</filename>.
|
||||
As an example, again assume a source directory top-level folder
|
||||
named <filename>poky</filename> and a default build directory
|
||||
at <filename>poky/build</filename>.
|
||||
In this case, the working directory the build system uses to build
|
||||
the <filename>acl</filename> package, which is dependent on a
|
||||
MIPS-based device, is the following:
|
||||
|
|
|
@ -39,8 +39,8 @@
|
|||
Use this list to monitor Yocto Project development discussions, ask questions, and
|
||||
get help.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink></emphasis>:
|
||||
Use this list to monitor discussions about the Yocto Project build system Poky,
|
||||
ask questions, and get help.</para></listitem>
|
||||
Use this list to monitor discussions about the OpenEmbedded build system, which is
|
||||
based on Poky, ask questions, and get help.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -65,15 +65,16 @@
|
|||
<itemizedlist>
|
||||
<listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
|
||||
</emphasis> The home site for the Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
|
||||
<!-- <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
|
||||
The company where the Yocto Project build system Poky was first developed.
|
||||
OpenedHand has since been acquired by Intel Corporation.</para></listitem>
|
||||
OpenedHand has since been acquired by Intel Corporation.</para></listitem> -->
|
||||
<listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
|
||||
The company who acquired OpenedHand in 2008 and continues development on the
|
||||
The company who acquired OpenedHand in 2008 and began development on the
|
||||
Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
|
||||
The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
|
||||
from and to which it contributes.</para></listitem>
|
||||
The upstream, generic, embedded distribution used as the basis for the build system in the
|
||||
Yocto Project.
|
||||
Poky derives from and contributes back to the OpenEmbedded project.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
|
||||
BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
|
||||
<listitem><para><emphasis><ulink url='http://bitbake.berlios.de/manual/'>
|
||||
|
|
|
@ -8,15 +8,15 @@
|
|||
<para>
|
||||
This chapter describes common usage for the Yocto Project.
|
||||
The information is introductory in nature as other manuals in the Yocto Project
|
||||
provide more details on how to use the Yocto Project.
|
||||
documentation set provide more details on how to use the Yocto Project.
|
||||
</para>
|
||||
|
||||
<section id='usingpoky-build'>
|
||||
<title>Running a Build</title>
|
||||
|
||||
<para>
|
||||
You can find general information on how to build an image using the
|
||||
Yocto Project in the
|
||||
You can find general information on how to build an image using the OpenEmbedded build
|
||||
system in the
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
|
||||
section of The Yocto Project Quick Start.
|
||||
This section provides a summary of the build process and provides information
|
||||
|
@ -36,7 +36,7 @@
|
|||
|
||||
<para>
|
||||
The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
|
||||
uses for the build.
|
||||
uses for the build - the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
|
||||
If you do not specify a build directory it defaults to <filename>build</filename>
|
||||
in your current working directory.
|
||||
A common practice is to use a different build directory for different targets.
|
||||
|
@ -56,11 +56,11 @@
|
|||
<para>
|
||||
The <filename>target</filename> is the name of the recipe you want to build.
|
||||
Common targets are the images in <filename>meta/recipes-core/images</filename>,
|
||||
<filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
|
||||
files.
|
||||
<filename>/meta/recipes-sato/images</filename>, etc. all found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
Or, the target can be the name of a recipe for a specific piece of software such as
|
||||
<application>busybox</application>.
|
||||
For more details about the images the Yocto Project supports, see the
|
||||
For more details about the images the OpenEmbedded build system supports, see the
|
||||
"<link linkend="ref-images">Reference: Images</link>" appendix.
|
||||
</para>
|
||||
|
||||
|
@ -89,7 +89,8 @@
|
|||
|
||||
<para>
|
||||
Once an image has been built, it often needs to be installed.
|
||||
The images and kernels built by the Yocto Project are placed in the build directory in
|
||||
The images and kernels built by the OpenEmbedded build system are placed in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> in
|
||||
<filename class="directory">tmp/deploy/images</filename>.
|
||||
For information on how to run pre-built images such as <filename>qemux86</filename>
|
||||
and <filename>qemuarm</filename>, see the
|
||||
|
@ -104,12 +105,12 @@
|
|||
<title>Debugging Build Failures</title>
|
||||
|
||||
<para>
|
||||
The exact method for debugging Yocto Project build failures depends on the nature of the
|
||||
The exact method for debugging build failures depends on the nature of the
|
||||
problem and on the system's area from which the bug originates.
|
||||
Standard debugging practices such as comparison against the last
|
||||
known working version with examination of the changes and the re-application of steps
|
||||
to identify the one causing the problem are
|
||||
valid for Yocto Project just as they are for any other system.
|
||||
valid for the Yocto Project just as they are for any other system.
|
||||
Even though it is impossible to detail every possible potential failure,
|
||||
this section provides some general tips to aid in debugging.
|
||||
</para>
|
||||
|
@ -263,10 +264,10 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
For guidance on how logging is handled
|
||||
in both Python and Bash recipes, see the
|
||||
For guidance on how logging is handled in both Python and Bash recipes, see the
|
||||
<filename>logging.bbclass</filename> file in the
|
||||
<filename>meta/classes</filename> directory of the Yocto Project files.
|
||||
<filename>meta/classes</filename> folder of the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
|
||||
</para>
|
||||
|
||||
<section id='logging-with-python'>
|
||||
|
|
Loading…
Reference in New Issue