6704 lines
322 KiB
XML
6704 lines
322 KiB
XML
<!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; ] >
|
|
|
|
<!-- Dummy chapter -->
|
|
<chapter id='ref-variables-glos'>
|
|
|
|
<title>Variables Glossary</title>
|
|
|
|
<para>
|
|
This chapter lists common variables used in the OpenEmbedded build system and gives an overview
|
|
of their function and contents.
|
|
</para>
|
|
|
|
<glossary id='ref-variables-glossary'>
|
|
|
|
|
|
<para>
|
|
<link linkend='var-ALLOW_EMPTY'>A</link>
|
|
<link linkend='var-B'>B</link>
|
|
<link linkend='var-CFLAGS'>C</link>
|
|
<link linkend='var-D'>D</link>
|
|
<link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>E</link>
|
|
<link linkend='var-FEED_DEPLOYDIR_BASE_URI'>F</link>
|
|
<link linkend='var-GROUPADD_PARAM'>G</link>
|
|
<link linkend='var-HOMEPAGE'>H</link>
|
|
<link linkend='var-ICECC_CC'>I</link>
|
|
<!-- <link linkend='var-glossary-j'>J</link> -->
|
|
<link linkend='var-KARCH'>K</link>
|
|
<link linkend='var-LABELS'>L</link>
|
|
<link linkend='var-MACHINE'>M</link>
|
|
<!-- <link linkend='var-glossary-n'>N</link> -->
|
|
<link linkend='var-OE_BINCONFIG_EXTRA_MANGLE'>O</link>
|
|
<link linkend='var-P'>P</link>
|
|
<!-- <link linkend='var-glossary-q'>Q</link> -->
|
|
<link linkend='var-RCONFLICTS'>R</link>
|
|
<link linkend='var-S'>S</link>
|
|
<link linkend='var-T'>T</link>
|
|
<link linkend='var-UBOOT_CONFIG'>U</link>
|
|
<!-- <link linkend='var-glossary-v'>V</link> -->
|
|
<link linkend='var-WARN_QA'>W</link>
|
|
<!-- <link linkend='var-glossary-x'>X</link> -->
|
|
<!-- <link linkend='var-glossary-y'>Y</link> -->
|
|
<!-- <link linkend='var-glossary-z'>Z</link>-->
|
|
</para>
|
|
|
|
<glossdiv id='var-glossary-a'><title>A</title>
|
|
|
|
<glossentry id='var-ALLOW_EMPTY'><glossterm>ALLOW_EMPTY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies if an output package should still be produced if it is empty.
|
|
By default, BitBake does not produce empty packages.
|
|
This default behavior can cause issues when there is an
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> or
|
|
some other hard runtime requirement on the existence of the package.
|
|
</para>
|
|
|
|
<para>
|
|
Like all package-controlling variables, you must always use them in
|
|
conjunction with a package name override, as in:
|
|
<literallayout class='monospaced'>
|
|
ALLOW_EMPTY_${PN} = "1"
|
|
ALLOW_EMPTY_${PN}-dev = "1"
|
|
ALLOW_EMPTY_${PN}-staticdev = "1"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ALTERNATIVE'><glossterm>ALTERNATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists commands in a package that need an alternative
|
|
binary naming scheme.
|
|
Sometimes the same command is provided in multiple packages.
|
|
When this occurs, the OpenEmbedded build system needs to
|
|
use the alternatives system to create a different binary
|
|
naming scheme so the commands can co-exist.
|
|
</para>
|
|
|
|
<para>
|
|
To use the variable, list out the package's commands
|
|
that also exist as part of another package.
|
|
For example, if the <filename>busybox</filename> package
|
|
has four commands that also exist as part of another
|
|
package, you identify them as follows:
|
|
<literallayout class='monospaced'>
|
|
ALTERNATIVE_busybox = "sh sed test bracket"
|
|
</literallayout>
|
|
For more information on the alternatives system, see the
|
|
"<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ALTERNATIVE_LINK_NAME'><glossterm>ALTERNATIVE_LINK_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Used by the alternatives system to map duplicated commands
|
|
to actual locations.
|
|
For example, if the <filename>bracket</filename> command
|
|
provided by the <filename>busybox</filename> package is
|
|
duplicated through another package, you must use the
|
|
<filename>ALTERNATIVE_LINK_NAME</filename> variable to
|
|
specify the actual location:
|
|
<literallayout class='monospaced'>
|
|
ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
|
|
</literallayout>
|
|
In this example, the binary for the
|
|
<filename>bracket</filename> command (i.e.
|
|
<filename>[</filename>) from the
|
|
<filename>busybox</filename> package resides in
|
|
<filename>/usr/bin/</filename>.
|
|
<note>
|
|
If <filename>ALTERNATIVE_LINK_NAME</filename> is not
|
|
defined, it defaults to
|
|
<filename>${bindir}/<name></filename>.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
For more information on the alternatives system, see the
|
|
"<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ALTERNATIVE_PRIORITY'><glossterm>ALTERNATIVE_PRIORITY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Used by the alternatives system to create default
|
|
priorities for duplicated commands.
|
|
You can use the variable to create a single default
|
|
regardless of the command name or package, a default for
|
|
specific duplicated commands regardless of the package, or
|
|
a default for specific commands tied to particular packages.
|
|
Here are the available syntax forms:
|
|
<literallayout class='monospaced'>
|
|
ALTERNATIVE_PRIORITY = "<priority>"
|
|
ALTERNATIVE_PRIORITY[<name>] = "<priority>"
|
|
ALTERNATIVE_PRIORITY_<pkg>[<name>] = "<priority>"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For more information on the alternatives system, see the
|
|
"<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ALTERNATIVE_TARGET'><glossterm>ALTERNATIVE_TARGET</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Used by the alternatives system to create default link
|
|
locations for duplicated commands.
|
|
You can use the variable to create a single default
|
|
location for all duplicated commands regardless of the
|
|
command name or package, a default for
|
|
specific duplicated commands regardless of the package, or
|
|
a default for specific commands tied to particular packages.
|
|
Here are the available syntax forms:
|
|
<literallayout class='monospaced'>
|
|
ALTERNATIVE_TARGET = "<target>"
|
|
ALTERNATIVE_TARGET[<name>] = "<target>"
|
|
ALTERNATIVE_TARGET_<pkg>[<name>] = "<target>"
|
|
</literallayout>
|
|
<note>
|
|
<para>
|
|
If <filename>ALTERNATIVE_TARGET</filename> is not
|
|
defined, it inherits the value from the
|
|
<link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
If <filename>ALTERNATIVE_LINK_NAME</filename> and
|
|
<filename>ALTERNATIVE_TARGET</filename> are the
|
|
same, the target for
|
|
<filename>ALTERNATIVE_TARGET</filename>
|
|
has "<filename>.{BPN}</filename>" appended to it.
|
|
</para>
|
|
|
|
<para>
|
|
Finally, if the file referenced has not been
|
|
renamed, the alternatives system will rename it to
|
|
avoid the need to rename alternative files in the
|
|
<filename>do_install</filename> task while
|
|
retaining support for the command if necessary.
|
|
</para>
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
For more information on the alternatives system, see the
|
|
"<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-APPEND'><glossterm>APPEND</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An override list of append strings for each
|
|
<link linkend='var-LABELS'><filename>LABEL</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
|
|
class for more information on how this variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
|
|
<glossdef>
|
|
<para>The email address used to contact the original author
|
|
or authors in order to send patches and forward bugs.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
|
|
<glossdef>
|
|
<para>When <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
|
|
is set to the value of this variable, it specifies to use the latest
|
|
source revision in the repository.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
SRCREV = "${AUTOREV}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-b'><title>B</title>
|
|
|
|
<glossentry id='var-B'><glossterm>B</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The directory within the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
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, which is defined as:
|
|
<literallayout class='monospaced'>
|
|
S = "${WORKDIR}/${BP}/"
|
|
</literallayout>
|
|
You can separate the (<filename>S</filename>) directory
|
|
and the directory pointed to by the <filename>B</filename>
|
|
variable.
|
|
Most Autotools-based recipes support separating these
|
|
directories.
|
|
The build system defaults to using separate directories for
|
|
<filename>gcc</filename> and some kernel recipes.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists "recommended-only" packages to not install.
|
|
Recommended-only packages are packages installed only
|
|
through the
|
|
<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
|
|
variable.
|
|
You can prevent any of these "recommended" packages from
|
|
being installed by listing them with the
|
|
<filename>BAD_RECOMMENDATIONS</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
BAD_RECOMMENDATIONS = "<package_name> <package_name> <package_name> ..."
|
|
</literallayout>
|
|
You can set this variable globally in your
|
|
<filename>local.conf</filename> file or you can attach it to
|
|
a specific image recipe by using the recipe name override:
|
|
<literallayout class='monospaced'>
|
|
BAD_RECOMMENDATIONS_pn-<target_image> = "<package_name>"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
It is important to realize that if you choose to not install
|
|
packages using this variable and some other packages are
|
|
dependent on them (i.e. listed in a recipe's
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
|
|
variable), the OpenEmbedded build system ignores your
|
|
request and will install the packages to avoid dependency
|
|
errors.
|
|
</para>
|
|
|
|
<para>
|
|
Support for this variable exists only when using the
|
|
IPK and RPM packaging backend.
|
|
Support does not exist for DEB.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
|
|
and the
|
|
<link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
|
|
variables for related information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines how BitBake handles situations where an append
|
|
file (<filename>.bbappend</filename>) has no
|
|
corresponding recipe file (<filename>.bb</filename>).
|
|
This condition often occurs when layers get out of sync
|
|
(e.g. <filename>oe-core</filename> bumps a
|
|
recipe version and the old recipe no longer exists and the
|
|
other layer has not been updated to the new version
|
|
of the recipe yet).
|
|
</para>
|
|
|
|
<para>
|
|
The default fatal behavior is safest because it is
|
|
the sane reaction given something is out of sync.
|
|
It is important to realize when your changes are no longer
|
|
being applied.
|
|
</para>
|
|
|
|
<para>
|
|
You can change the default behavior by setting this
|
|
variable to "1", "yes", or "true"
|
|
in your <filename>local.conf</filename> file, which is
|
|
located in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
BB_DANGLINGAPPENDS_WARNONLY = "1"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Monitors disk space and available inodes during the build
|
|
and allows you to control the build based on these
|
|
parameters.
|
|
</para>
|
|
|
|
<para>
|
|
Disk space monitoring is disabled by default.
|
|
To enable monitoring, add the <filename>BB_DISKMON_DIRS</filename>
|
|
variable to your <filename>conf/local.conf</filename> file found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
Use the following form:
|
|
<literallayout class='monospaced'>
|
|
BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]"
|
|
|
|
where:
|
|
|
|
<action> is:
|
|
ABORT: Immediately abort the build when
|
|
a threshold is broken.
|
|
STOPTASKS: Stop the build after the currently
|
|
executing tasks have finished when
|
|
a threshold is broken.
|
|
WARN: Issue a warning but continue the
|
|
build when a threshold is broken.
|
|
Subsequent warnings are issued as
|
|
defined by the
|
|
<link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
|
|
which must be defined in the
|
|
conf/local.conf file.
|
|
|
|
<dir> is:
|
|
Any directory you choose. You can specify one or
|
|
more directories to monitor by separating the
|
|
groupings with a space. If two directories are
|
|
on the same device, only the first directory
|
|
is monitored.
|
|
|
|
<threshold> is:
|
|
Either the minimum available disk space,
|
|
the minimum number of free inodes, or
|
|
both. You must specify at least one. To
|
|
omit one or the other, simply omit the value.
|
|
Specify the threshold using G, M, K for Gbytes,
|
|
Mbytes, and Kbytes, respectively. If you do
|
|
not specify G, M, or K, Kbytes is assumed by
|
|
default. Do not use GB, MB, or KB.
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
Here are some examples:
|
|
<literallayout class='monospaced'>
|
|
BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
|
|
BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
|
|
BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
|
|
</literallayout>
|
|
The first example works only if you also provide
|
|
the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable
|
|
in the <filename>conf/local.conf</filename>.
|
|
This example causes the build system to immediately
|
|
abort when either the disk space in <filename>${TMPDIR}</filename> drops
|
|
below 1 Gbyte or the available free inodes drops below
|
|
100 Kbytes.
|
|
Because two directories are provided with the variable, the
|
|
build system also issue a
|
|
warning when the disk space in the
|
|
<filename>${SSTATE_DIR}</filename> directory drops
|
|
below 1 Gbyte or the number of free inodes drops
|
|
below 100 Kbytes.
|
|
Subsequent warnings are issued during intervals as
|
|
defined by the <filename>BB_DISKMON_WARNINTERVAL</filename>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
The second example stops the build after all currently
|
|
executing tasks complete when the minimum disk space
|
|
in the <filename>${<link linkend='var-TMPDIR'>TMPDIR</link>}</filename>
|
|
directory drops below 1 Gbyte.
|
|
No disk monitoring occurs for the free inodes in this case.
|
|
</para>
|
|
|
|
<para>
|
|
The final example immediately aborts the build when the
|
|
number of free inodes in the <filename>${TMPDIR}</filename> directory
|
|
drops below 100 Kbytes.
|
|
No disk space monitoring for the directory itself occurs
|
|
in this case.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the disk space and free inode warning intervals.
|
|
To set these intervals, define the variable in your
|
|
<filename>conf/local.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
If you are going to use the
|
|
<filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
|
|
also use the
|
|
<link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable
|
|
and define its action as "WARN".
|
|
During the build, subsequent warnings are issued each time
|
|
disk space or number of free inodes further reduces by
|
|
the respective interval.
|
|
</para>
|
|
|
|
<para>
|
|
If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
|
|
variable and you do use <filename>BB_DISKMON_DIRS</filename> with
|
|
the "WARN" action, the disk monitoring interval defaults to
|
|
the following:
|
|
<literallayout class='monospaced'>
|
|
BB_DISKMON_WARNINTERVAL = "50M,5K"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
When specifying the variable in your configuration file,
|
|
use the following form:
|
|
<literallayout class='monospaced'>
|
|
BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>"
|
|
|
|
where:
|
|
|
|
<disk_space_interval> is:
|
|
An interval of memory expressed in either
|
|
G, M, or K for Gbytes, Mbytes, or Kbytes,
|
|
respectively. You cannot use GB, MB, or KB.
|
|
|
|
<disk_inode_interval> is:
|
|
An interval of free inodes expressed in either
|
|
G, M, or K for Gbytes, Mbytes, or Kbytes,
|
|
respectively. You cannot use GB, MB, or KB.
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
|
|
BB_DISKMON_WARNINTERVAL = "50M,5K"
|
|
</literallayout>
|
|
These variables cause the OpenEmbedded build system to
|
|
issue subsequent warnings each time the available
|
|
disk space further reduces by 50 Mbytes or the number
|
|
of free inodes further reduces by 5 Kbytes in the
|
|
<filename>${SSTATE_DIR}</filename> directory.
|
|
Subsequent warnings based on the interval occur each time
|
|
a respective interval is reached beyond the initial warning
|
|
(i.e. 1 Gbytes and 100 Kbytes).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Causes tarballs of the Git repositories to be placed in the
|
|
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
|
|
directory.
|
|
For performance reasons, creating and placing tarballs of
|
|
the Git repositories is not the default action by the
|
|
OpenEmbedded build system.
|
|
<literallayout class='monospaced'>
|
|
BB_GENERATE_MIRROR_TARBALLS = "1"
|
|
</literallayout>
|
|
Set this variable in your <filename>local.conf</filename>
|
|
file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
|
|
<glossdef>
|
|
<para>The maximum number of tasks BitBake should run in parallel at any one time.
|
|
If your host development system supports multiple cores, a good rule of thumb
|
|
is to set this variable to twice the number of cores.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Allows you to extend a recipe so that it builds variants of the software.
|
|
Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
|
|
which is a copy of Quilt built to run on the build system;
|
|
"crosses" such as <filename>gcc-cross</filename>,
|
|
which is a compiler built to run on the build machine but produces binaries
|
|
that run on the target <link linkend='var-MACHINE'><filename>MACHINE</filename></link>;
|
|
"nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
|
|
and "mulitlibs" in the form "<filename>multilib:<multilib_name></filename>".
|
|
</para>
|
|
|
|
<para>
|
|
To build a different variant of the recipe with a minimal amount of code, it usually
|
|
is as simple as adding the following to your recipe:
|
|
<literallayout class='monospaced'>
|
|
BBCLASSEXTEND =+ "native nativesdk"
|
|
BBCLASSEXTEND =+ "multilib:<multilib_name>"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
|
|
<glossdef>
|
|
<para>Lists the names of configured layers.
|
|
These names are used to find the other <filename>BBFILE_*</filename>
|
|
variables.
|
|
Typically, each layer will append its name to this variable in its
|
|
<filename>conf/layer.conf</filename> file.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
|
|
<glossdef>
|
|
<para>Variable that expands to match files from
|
|
<link linkend='var-BBFILES'><filename>BBFILES</filename></link>
|
|
in a particular layer.
|
|
This variable is used in the <filename>conf/layer.conf</filename> file and must
|
|
be suffixed with the name of the specific layer (e.g.
|
|
<filename>BBFILE_PATTERN_emenlow</filename>).</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
|
|
<glossdef>
|
|
<para>Assigns the priority for recipe files in each layer.</para>
|
|
<para>This variable is useful in situations where the same recipe appears in
|
|
more than one layer.
|
|
Setting this variable allows you to prioritize a
|
|
layer against other layers that contain the same recipe - effectively
|
|
letting you control the precedence for the multiple layers.
|
|
The precedence established through this variable stands regardless of a
|
|
recipe's version
|
|
(<link linkend='var-PV'><filename>PV</filename></link> variable).
|
|
For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
|
|
which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
|
|
lower precedence.</para>
|
|
<para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
|
|
precedence.
|
|
For example, the value 6 has a higher precedence than the value 5.
|
|
If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
|
|
dependencies (see the
|
|
<filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for
|
|
more information.
|
|
The default priority, if unspecified
|
|
for a layer with no dependencies, is the lowest defined priority + 1
|
|
(or 1 if no priorities are defined).</para>
|
|
<tip>
|
|
You can use the command <filename>bitbake-layers show-layers</filename> to list
|
|
all configured layers along with their priorities.
|
|
</tip>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
|
|
<glossdef>
|
|
<para>List of recipe files used by BitBake to build software.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
|
|
<glossdef>
|
|
<para>Variable that controls how BitBake displays logs on build failure.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
|
|
<glossdef>
|
|
<para>Lists the layers to enable during the build.
|
|
This variable is defined in the <filename>bblayers.conf</filename> configuration
|
|
file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
BBLAYERS = " \
|
|
/home/scottrif/poky/meta \
|
|
/home/scottrif/poky/meta-yocto \
|
|
/home/scottrif/poky/meta-yocto-bsp \
|
|
/home/scottrif/poky/meta-mykernel \
|
|
"
|
|
|
|
BBLAYERS_NON_REMOVABLE ?= " \
|
|
/home/scottrif/poky/meta \
|
|
/home/scottrif/poky/meta-yocto \
|
|
"
|
|
</literallayout>
|
|
This example enables four layers, one of which is a custom, user-defined layer
|
|
named <filename>meta-mykernel</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBLAYERS_NON_REMOVABLE'><glossterm>BBLAYERS_NON_REMOVABLE</glossterm>
|
|
<glossdef>
|
|
<para>Lists core layers that cannot be removed from the
|
|
<filename>bblayers.conf</filename> file during a build
|
|
using the
|
|
<ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
|
|
<note>
|
|
When building an image outside of Hob, this variable
|
|
is ignored.
|
|
</note>
|
|
In order for BitBake to build your image using Hob, your
|
|
<filename>bblayers.conf</filename> file must include the
|
|
<filename>meta</filename> and <filename>meta-yocto</filename>
|
|
core layers.
|
|
Here is an example that shows these two layers listed in
|
|
the <filename>BBLAYERS_NON_REMOVABLE</filename> statement:
|
|
<literallayout class='monospaced'>
|
|
BBLAYERS = " \
|
|
/home/scottrif/poky/meta \
|
|
/home/scottrif/poky/meta-yocto \
|
|
/home/scottrif/poky/meta-yocto-bsp \
|
|
/home/scottrif/poky/meta-mykernel \
|
|
"
|
|
|
|
BBLAYERS_NON_REMOVABLE ?= " \
|
|
/home/scottrif/poky/meta \
|
|
/home/scottrif/poky/meta-yocto \
|
|
"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Prevents BitBake from processing recipes and recipe
|
|
append files.
|
|
Use the <filename>BBMASK</filename> variable from within the
|
|
<filename>conf/local.conf</filename> file found
|
|
in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
You can use the <filename>BBMASK</filename> variable
|
|
to "hide" these <filename>.bb</filename> and
|
|
<filename>.bbappend</filename> files.
|
|
BitBake ignores any recipe or recipe append files that
|
|
match the expression.
|
|
It is as if BitBake does not see them at all.
|
|
Consequently, matching files are not parsed or otherwise
|
|
used by BitBake.</para>
|
|
<para>
|
|
The value you provide is passed to Python's regular
|
|
expression compiler.
|
|
The expression is compared against the full paths to
|
|
the files.
|
|
For complete syntax information, see Python's
|
|
documentation at
|
|
<ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
The following example uses a complete regular expression
|
|
to tell BitBake to ignore all recipe and recipe append
|
|
files in the <filename>meta-ti/recipes-misc/</filename>
|
|
directory:
|
|
<literallayout class='monospaced'>
|
|
BBMASK = "meta-ti/recipes-misc/"
|
|
</literallayout>
|
|
If you want to mask out multiple directories or recipes,
|
|
use the vertical bar to separate the regular expression
|
|
fragments.
|
|
This next example masks out multiple directories and
|
|
individual recipes:
|
|
<literallayout class='monospaced'>
|
|
BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
|
|
BBMASK .= "|.*meta-oe/recipes-support/"
|
|
BBMASK .= "|.*openldap"
|
|
BBMASK .= "|.*opencv"
|
|
BBMASK .= "|.*lzma"
|
|
</literallayout>
|
|
Notice how the vertical bar is used to append the fragments.
|
|
<note>
|
|
When specifying a directory name, use the trailing
|
|
slash character to ensure you match just that directory
|
|
name.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Used by BitBake to locate
|
|
<filename>.bbclass</filename> and configuration files.
|
|
This variable is analogous to the
|
|
<filename>PATH</filename> variable.
|
|
<note>
|
|
If you run BitBake from a directory outside of the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;build-directory'>Build Directory</ulink>,
|
|
you must be sure to set
|
|
<filename>BBPATH</filename> to point to the
|
|
Build Directory.
|
|
Set the variable as you would any environment variable
|
|
and then run BitBake:
|
|
<literallayout class='monospaced'>
|
|
$ BBPATH = "<build_directory>"
|
|
$ export BBPATH
|
|
$ bitbake <target>
|
|
</literallayout>
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the server that runs memory-resident BitBake.
|
|
This variable is set by the
|
|
<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
|
|
setup script and should not be hand-edited.
|
|
The variable is only used when you employ memory-resident
|
|
BitBake.
|
|
The setup script exports the value as follows:
|
|
<literallayout class='monospaced'>
|
|
export BBSERVER=localhost:$port
|
|
</literallayout>
|
|
For more information on how the
|
|
<filename>BBSERVER</filename> is used, see the
|
|
<filename>oe-init-build-env-memres</filename> script, which
|
|
is located in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BINCONFIG_GLOB'><glossterm>BINCONFIG_GLOB</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting <filename>binconfig.bbclass</filename>
|
|
from a recipe, this variable specifies a wildcard for
|
|
configuration scripts that need editing.
|
|
The scripts are edited to correct any paths that have been
|
|
set up during compilation so that they are correct for
|
|
use when installed into the sysroot and called by the
|
|
build processes of other recipes.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on how this variable works, see
|
|
<filename>meta/classes/binconfig.bbclass</filename> in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
You can also find general information on the class in the
|
|
"<link linkend='ref-classes-binconfig'><filename>binconfig.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BP'><glossterm>BP</glossterm>
|
|
<glossdef>
|
|
<para>The base recipe name and version but without any special
|
|
recipe name suffix (i.e. <filename>-native</filename>, <filename>lib64-</filename>,
|
|
and so forth).
|
|
<filename>BP</filename> is comprised of the following:
|
|
<literallayout class="monospaced">
|
|
${BPN}-${PV}
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BPN'><glossterm>BPN</glossterm>
|
|
<glossdef>
|
|
<para>The bare name of the recipe.
|
|
This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable
|
|
but removes common suffixes such as "-native" and "-cross" as well
|
|
as removes common prefixes such as multilib's "lib64-" and "lib32-".
|
|
The exact list of suffixes removed is specified by the
|
|
<link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
|
|
The exact list of prefixes removed is specified by the
|
|
<link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
|
|
Prefixes are removed for <filename>multilib</filename>
|
|
and <filename>nativesdk</filename> cases.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUGTRACKER'><glossterm>BUGTRACKER</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a URL for an upstream bug tracking website for
|
|
a recipe.
|
|
The OpenEmbedded build system does not use this variable.
|
|
Rather, the variable is a useful pointer in case a bug
|
|
in the software being built needs to be manually reported.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDDIR'><glossterm>BUILDDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the location of the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
You can define this directory indirectly through the
|
|
<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
|
|
and
|
|
<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
|
|
scripts by passing in a Build Directory path when you run
|
|
the scripts.
|
|
If you run the scripts and do not provide a Build Directory
|
|
path, the <filename>BUILDDIR</filename> defaults to
|
|
<filename>build</filename> in the current directory.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDSTATS_BASE'><glossterm>BUILDSTATS_BASE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the location of the directory that holds build
|
|
statistics when you use and enable the
|
|
<link linkend='ref-classes-buildstats'><filename>buildstats</filename></link>
|
|
class.
|
|
The <filename>BUILDSTATS_BASE</filename> directory defaults
|
|
to
|
|
<filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/buildstats/</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUSYBOX_SPLIT_SUID'><glossterm>BUSYBOX_SPLIT_SUID</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
For the BusyBox recipe, specifies whether to split the
|
|
output executable file into two parts: one for features
|
|
that require <filename>setuid root</filename>, and one for
|
|
the remaining features (i.e. those that do not require
|
|
<filename>setuid root</filename>).
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>BUSYBOX_SPLIT_SUID</filename> variable
|
|
defaults to "1", which results in a single output
|
|
executable file.
|
|
Set the variable to "0" to split the output file.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-c'><title>C</title>
|
|
|
|
<glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Flags passed to the C compiler for the target system.
|
|
This variable evaluates to the same as
|
|
<filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CLASSOVERRIDE'><glossterm>CLASSOVERRIDE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An internal variable specifying the special class override
|
|
that should currently apply (e.g. "class-target",
|
|
"class-native", and so forth).
|
|
The classes that use this variable set it to
|
|
appropriate values.
|
|
</para>
|
|
|
|
<para>
|
|
You do not normally directly interact with this variable.
|
|
The value for the <filename>CLASSOVERRIDE</filename>
|
|
variable goes into
|
|
<link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
|
|
and then can be used as an override.
|
|
Here is an example where "python-native" is added to
|
|
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
|
|
only when building for the native case:
|
|
<literallayout class='monospaced'>
|
|
DEPENDS_append_class-native = " python-native"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMBINED_FEATURES'><glossterm>COMBINED_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Provides a list of hardware features that are enabled in
|
|
both
|
|
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
|
|
and
|
|
<link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
|
|
This select list of features contains features that make
|
|
sense to be controlled both at the machine and distribution
|
|
configuration level.
|
|
For example, the "bluetooth" feature requires hardware
|
|
support but should also be optional at the distribution
|
|
level, in case the hardware supports Bluetooth but you
|
|
do not ever intend to use it.
|
|
</para>
|
|
|
|
<para>
|
|
For more information, see the
|
|
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
|
|
and <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
|
|
variables.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMMON_LICENSE_DIR'><glossterm>COMMON_LICENSE_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to <filename>meta/files/common-licenses</filename>
|
|
in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
|
|
which is where generic license files reside.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
|
|
<glossdef>
|
|
<para>A regular expression that resolves to one or more hosts
|
|
(when the recipe is native) or one or more targets (when
|
|
the recipe is non-native) with which a recipe is compatible.
|
|
The regular expression is matched against
|
|
<link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
|
|
You can use the variable to stop recipes from being built
|
|
for classes of systems with which the recipes are not
|
|
compatible.
|
|
Stopping these builds is particularly useful with kernels.
|
|
The variable also helps to increase parsing speed
|
|
since the build system skips parsing recipes not
|
|
compatible with the current system.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
|
|
<glossdef>
|
|
<para>A regular expression that resolves to one or more
|
|
target machines with which a recipe is compatible.
|
|
The regular expression is matched against
|
|
<link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
|
|
You can use the variable to stop recipes from being built
|
|
for machines with which the recipes are not compatible.
|
|
Stopping these builds is particularly useful with kernels.
|
|
The variable also helps to increase parsing speed
|
|
since the build system skips parsing recipes not
|
|
compatible with the current machine.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMPLEMENTARY_GLOB'><glossterm>COMPLEMENTARY_GLOB</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines wildcards to match when installing a list of
|
|
complementary packages for all the packages explicitly
|
|
(or implicitly) installed in an image.
|
|
The resulting list of complementary packages is associated
|
|
with an item that can be added to
|
|
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
|
|
An example usage of this is the "dev-pkgs" item that when
|
|
added to <filename>IMAGE_FEATURES</filename> will
|
|
install -dev packages (containing headers and other
|
|
development files) for every package in the image.
|
|
</para>
|
|
|
|
<para>
|
|
To add a new feature item pointing to a wildcard, use a
|
|
variable flag to specify the feature item name and
|
|
use the value to specify the wildcard.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CONFFILES'><glossterm>CONFFILES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Identifies editable or configurable files that are part of a package.
|
|
If the Package Management System (PMS) is being used to update
|
|
packages on the target system, it is possible that
|
|
configuration files you have changed after the original installation
|
|
and that you now want to remain unchanged are overwritten.
|
|
In other words, editable files might exist in the package that you do not
|
|
want reset as part of the package update process.
|
|
You can use the <filename>CONFFILES</filename> variable to list the files in the
|
|
package that you wish to prevent the PMS from overwriting during this update process.
|
|
</para>
|
|
|
|
<para>
|
|
To use the <filename>CONFFILES</filename> variable, provide a package name
|
|
override that identifies the resulting package.
|
|
Then, provide a space-separated list of files.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
CONFFILES_${PN} += "${sysconfdir}/file1 \
|
|
${sysconfdir}/file2 ${sysconfdir}/file3"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
A relationship exists between the <filename>CONFFILES</filename> and
|
|
<filename><link linkend='var-FILES'>FILES</link></filename> variables.
|
|
The files listed within <filename>CONFFILES</filename> must be a subset of
|
|
the files listed within <filename>FILES</filename>.
|
|
Because the configuration files you provide with <filename>CONFFILES</filename>
|
|
are simply being identified so that the PMS will not overwrite them,
|
|
it makes sense that
|
|
the files must already be included as part of the package through the
|
|
<filename>FILES</filename> variable.
|
|
</para>
|
|
|
|
<note>
|
|
When specifying paths as part of the <filename>CONFFILES</filename> variable,
|
|
it is good practice to use appropriate path variables.
|
|
For example, <filename>${sysconfdir}</filename> rather than
|
|
<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
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of files that contains <filename>autoconf</filename> test results relevant
|
|
to the current build.
|
|
This variable is used by the Autotools utilities when running
|
|
<filename>configure</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CONFLICT_DISTRO_FEATURES'><glossterm>CONFLICT_DISTRO_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>distro_features_check</filename> class, this
|
|
variable identifies distribution features that would
|
|
be in conflict should the recipe
|
|
be built.
|
|
In other words, if the
|
|
<filename>CONFLICT_DISTRO_FEATURES</filename> variable
|
|
lists a feature that also appears in
|
|
<filename>DISTRO_FEATURES</filename> within the
|
|
current configuration, an error occurs and the
|
|
build stops.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CORE_IMAGE_EXTRA_INSTALL'><glossterm>CORE_IMAGE_EXTRA_INSTALL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the list of packages to be added to the image.
|
|
You should only set this variable in the
|
|
<filename>local.conf</filename> configuration file found
|
|
in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
This variable replaces <filename>POKY_EXTRA_INSTALL</filename>, which is no longer supported.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COREBASE'><glossterm>COREBASE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the parent directory of the OpenEmbedded
|
|
Core Metadata layer (i.e. <filename>meta</filename>).
|
|
</para>
|
|
|
|
<para>
|
|
It is an important distinction that
|
|
<filename>COREBASE</filename> points to the parent of this
|
|
layer and not the layer itself.
|
|
Consider an example where you have cloned the Poky Git
|
|
repository and retained the <filename>poky</filename>
|
|
name for your local copy of the repository.
|
|
In this case, <filename>COREBASE</filename> points to
|
|
the <filename>poky</filename> folder because it is the
|
|
parent directory of the <filename>poky/meta</filename>
|
|
layer.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-d'><title>D</title>
|
|
|
|
<glossentry id='var-D'><glossterm>D</glossterm>
|
|
<glossdef>
|
|
<para>The destination directory.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DATETIME'><glossterm>DATETIME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The date and time on which the current build started.
|
|
The format is suitable for timestamps.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEBUG_BUILD'><glossterm>DEBUG_BUILD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies to build packages with debugging information.
|
|
This influences the value of the
|
|
<filename><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</link></filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEBUG_OPTIMIZATION'><glossterm>DEBUG_OPTIMIZATION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The options to pass in
|
|
<filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
|
|
and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename> when compiling
|
|
a system for debugging.
|
|
This variable defaults to "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a weak bias for recipe selection priority.
|
|
</para>
|
|
<para>
|
|
The most common usage of this is variable is to set
|
|
it to "-1" within a recipe for a development version of a
|
|
piece of software.
|
|
Using the variable in this way causes the stable version
|
|
of the recipe to build by default in the absence of
|
|
<filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
|
|
being used to build the development version.
|
|
</para>
|
|
<note>
|
|
The bias provided by <filename>DEFAULT_PREFERENCE</filename>
|
|
is weak and is overridden by
|
|
<filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
|
|
if that variable is different between two layers
|
|
that contain different versions of the same recipe.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists a recipe's build-time dependencies
|
|
(i.e. other recipe files).
|
|
The system ensures that all the dependencies listed
|
|
have been built and have their contents in the appropriate
|
|
sysroots before the recipe's configure task is executed.
|
|
</para>
|
|
|
|
<para>
|
|
Consider this simple example for two recipes named "a" and
|
|
"b" that produce similarly named packages.
|
|
In this example, the <filename>DEPENDS</filename>
|
|
statement appears in the "a" recipe:
|
|
<literallayout class='monospaced'>
|
|
DEPENDS = "b"
|
|
</literallayout>
|
|
Here, the dependency is such that the
|
|
<filename>do_configure</filename> task for recipe "a"
|
|
depends on the <filename>do_populate_sysroot</filename>
|
|
task of recipe "b".
|
|
This means anything that recipe "b" puts into sysroot
|
|
is available when recipe "a" is configuring itself.
|
|
</para>
|
|
|
|
<para>
|
|
For information on runtime dependencies, see the
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEPLOY_DIR'><glossterm>DEPLOY_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the general area that the OpenEmbedded build
|
|
system uses to place images, packages, SDKs and other output
|
|
files that are ready to be used outside of the build system.
|
|
By default, this directory resides within the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
as <filename>${TMPDIR}/deploy</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on the structure of the Build
|
|
Directory, see
|
|
"<link linkend='structure-build'>The Build Directory - <filename>build/</filename></link>"
|
|
section.
|
|
For more detail on the contents of the
|
|
<filename>deploy</filename> directory, see the
|
|
"<link linkend='images-dev-environment'>Images</link>" and
|
|
"<link linkend='sdk-dev-environment'>Application Development SDK</link>"
|
|
sections.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEPLOY_DIR_IMAGE'><glossterm>DEPLOY_DIR_IMAGE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the area that the OpenEmbedded build system uses
|
|
to place images and other associated output files that are
|
|
ready to be deployed onto the target machine.
|
|
The directory is machine-specific as it contains the
|
|
<filename>${MACHINE}</filename> name.
|
|
By default, this directory resides within the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
as <filename>${DEPLOY_DIR}/images/${MACHINE}/</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on the structure of the Build
|
|
Directory, see
|
|
"<link linkend='structure-build'>The Build Directory - <filename>build/</filename></link>"
|
|
section.
|
|
For more detail on the contents of the
|
|
<filename>deploy</filename> directory, see the
|
|
"<link linkend='images-dev-environment'>Images</link>" and
|
|
"<link linkend='sdk-dev-environment'>Application Development SDK</link>"
|
|
sections.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
|
|
<glossdef>
|
|
<para>The package description used by package managers.
|
|
If not set, <filename>DESCRIPTION</filename> takes
|
|
the value of the
|
|
<link linkend='var-SUMMARY'><filename>SUMMARY</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The short name of the distribution.
|
|
This variable corresponds to a distribution
|
|
configuration file whose root name is the same as the
|
|
variable's argument and whose filename extension is
|
|
<filename>.conf</filename>.
|
|
For example, the distribution configuration file for the
|
|
Poky distribution is named <filename>poky.conf</filename>
|
|
and resides in the
|
|
<filename>meta-yocto/conf/distro</filename> directory of
|
|
the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
Within that <filename>poky.conf</filename> file, the
|
|
<filename>DISTRO</filename> variable is set as follows:
|
|
<literallayout class='monospaced'>
|
|
DISTRO = "poky"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
Distribution configuration files are located in a
|
|
<filename>conf/distro</filename> directory within the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
|
|
that contains the distribution configuration.
|
|
The value for <filename>DISTRO</filename> must not contain
|
|
spaces, and is typically all lower-case.
|
|
<note>
|
|
If the <filename>DISTRO</filename> variable is blank, a set
|
|
of default configurations are used, which are specified
|
|
within
|
|
<filename>meta/conf/distro/defaultsetup.conf</filename>
|
|
also in the Source Directory.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_EXTRA_RDEPENDS'><glossterm>DISTRO_EXTRA_RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a list of distro-specific packages to add to all images.
|
|
This variable takes affect through
|
|
<filename>packagegroup-base</filename> so the
|
|
variable only really applies to the more full-featured
|
|
images that include <filename>packagegroup-base</filename>.
|
|
You can use this variable to keep distro policy out of
|
|
generic images.
|
|
As with all other distro variables, you set this variable
|
|
in the distro <filename>.conf</filename> file.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a list of distro-specific packages to add to all images
|
|
if the packages exist.
|
|
The packages might not exist or be empty (e.g. kernel modules).
|
|
The list of packages are automatically installed but you can
|
|
remove them.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_FEATURES'><glossterm>DISTRO_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The software support you want in your distribution for
|
|
various features.
|
|
You define your distribution features in the distribution
|
|
configuration file.
|
|
</para>
|
|
|
|
<para>
|
|
In most cases, the presence or absence of a feature in
|
|
<filename>DISTRO_FEATURES</filename> is translated to the
|
|
appropriate option supplied to the configure script
|
|
during <filename>do_configure</filename> for recipes that
|
|
optionally support the feature.
|
|
For example, specifying "x11" in
|
|
<filename>DISTRO_FEATURES</filename>, causes
|
|
every piece of software built for the target that can
|
|
optionally support X11 to have its X11 support enabled.
|
|
</para>
|
|
|
|
<para>
|
|
Two more examples are Bluetooth and NFS support.
|
|
For a more complete list of features that ships with the
|
|
Yocto Project and that you can provide with this variable,
|
|
see the
|
|
"<link linkend='ref-features-distro'>Distro Features</link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_FEATURES_BACKFILL'><glossterm>DISTRO_FEATURES_BACKFILL</glossterm>
|
|
<glossdef>
|
|
<para>Features to be added to
|
|
<filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>
|
|
if not also present in
|
|
<filename><link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'>DISTRO_FEATURES_BACKFILL_CONSIDERED</link></filename>.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is set in the <filename>meta/conf/bitbake.conf</filename> file.
|
|
It is not intended to be user-configurable.
|
|
It is best to just reference the variable to see which distro features are
|
|
being backfilled for all distro configurations.
|
|
See the <link linkend='ref-features-backfill'>Feature backfilling</link> section for
|
|
more information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><glossterm>DISTRO_FEATURES_BACKFILL_CONSIDERED</glossterm>
|
|
<glossdef>
|
|
<para>Features from
|
|
<filename><link linkend='var-DISTRO_FEATURES_BACKFILL'>DISTRO_FEATURES_BACKFILL</link></filename>
|
|
that should not be backfilled (i.e. added to
|
|
<filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>)
|
|
during the build.
|
|
See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
|
|
more information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_NAME'><glossterm>DISTRO_NAME</glossterm>
|
|
<glossdef>
|
|
<para>The long name of the distribution.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm>
|
|
<glossdef>
|
|
<para>Alias names used for the recipe in various Linux distributions.</para>
|
|
<para>See the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-DISTRO_PN_ALIAS'>Handling
|
|
a Package Name Alias</ulink>" section in the Yocto Project Development
|
|
Manual for more information.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO_VERSION'><glossterm>DISTRO_VERSION</glossterm>
|
|
<glossdef>
|
|
<para>The version of the distribution.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTROOVERRIDES'><glossterm>DISTROOVERRIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable lists overrides specific to the current
|
|
distribution.
|
|
By default, the variable list includes the value of the
|
|
<filename><link linkend='var-DISTRO'>DISTRO</link></filename>
|
|
variable.
|
|
You can extend the variable to apply any variable overrides
|
|
you want as part of the distribution and are not
|
|
already in <filename>OVERRIDES</filename> through
|
|
some other means.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The central download directory used by the build process to
|
|
store downloads.
|
|
By default, <filename>DL_DIR</filename> gets files
|
|
suitable for mirroring for everything except Git
|
|
repositories.
|
|
If you want tarballs of Git repositories, use the
|
|
<link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
You can set this directory by defining the
|
|
<filename>DL_DIR</filename> variable in the
|
|
<filename>conf/local.conf</filename> file.
|
|
This directory is self-maintaining and you should not have
|
|
to touch it.
|
|
By default, the directory is <filename>downloads</filename>
|
|
in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
<literallayout class='monospaced'>
|
|
#DL_DIR ?= "${TOPDIR}/downloads"
|
|
</literallayout>
|
|
To specify a different download directory, simply remove
|
|
the comment from the line and provide your directory.
|
|
</para>
|
|
|
|
<para>
|
|
During a first build, the system downloads many different
|
|
source code tarballs from various upstream projects.
|
|
Downloading can take a while, particularly if your network
|
|
connection is slow.
|
|
Tarballs are all stored in the directory defined by
|
|
<filename>DL_DIR</filename> and the build system looks there
|
|
first to find source tarballs.
|
|
<note>
|
|
When wiping and rebuilding, you can preserve this
|
|
directory to speed up this part of subsequent
|
|
builds.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
You can safely share this directory between multiple builds
|
|
on the same development machine.
|
|
For additional information on how the build process gets
|
|
source files when working behind a firewall or proxy server,
|
|
see this specific question in the
|
|
"<link linkend='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</link>"
|
|
chapter.
|
|
</para>
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-e'><title>E</title>
|
|
|
|
<glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>Variable that controls which locales for
|
|
<filename>eglibc</filename> are generated during the
|
|
build (useful if the target device has 64Mbytes
|
|
of RAM or less).</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ERROR_QA'><glossterm>ERROR_QA</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the quality assurance checks whose failures are
|
|
reported as errors by the OpenEmbedded build system.
|
|
You set this variable in your distribution configuration
|
|
file.
|
|
For a list of the checks you can control with this variable,
|
|
see the
|
|
"<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Directs BitBake to exclude a recipe from world builds (i.e.
|
|
<filename>bitbake world</filename>).
|
|
During world builds, BitBake locates, parses and builds all
|
|
recipes found in every layer exposed in the
|
|
<filename>bblayers.conf</filename> configuration file.
|
|
</para>
|
|
|
|
<para>
|
|
To exclude a recipe from a world build using this variable,
|
|
set the variable to "1" in the recipe.
|
|
</para>
|
|
|
|
<note>
|
|
Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
|
|
may still be built during a world build in order to satisfy
|
|
dependencies of other recipes.
|
|
Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
|
|
only ensures that the recipe is not explicitly added
|
|
to the list of build targets in a world build.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTENDPE'><glossterm>EXTENDPE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Used with file and pathnames to create a prefix for a recipe's
|
|
version based on the recipe's
|
|
<link linkend='var-PE'><filename>PE</filename></link> value.
|
|
If <filename>PE</filename> is set and greater than zero for a recipe,
|
|
<filename>EXTENDPE</filename> becomes that value (e.g if
|
|
<filename>PE</filename> is equal to "1" then <filename>EXTENDPE</filename>
|
|
becomes "1_").
|
|
If a recipe's <filename>PE</filename> is not set (the default) or is equal to
|
|
zero, <filename>EXTENDPE</filename> becomes "".</para>
|
|
<para>See the <link linkend='var-STAMP'><filename>STAMP</filename></link>
|
|
variable for an example.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTENDPKGV'><glossterm>EXTENDPKGV</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The full package version specification as it appears on the
|
|
final packages produced by a recipe.
|
|
The variable's value is normally used to fix a runtime
|
|
dependency to the exact same version of another package
|
|
in the same recipe:
|
|
<literallayout class='monospaced'>
|
|
RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
The dependency relationships are intended to force the
|
|
package manager to upgrade these types of packages in
|
|
lock-step.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTERNALSRC'><glossterm>EXTERNALSRC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If <filename>externalsrc.bbclass</filename> is inherited,
|
|
this variable points to the source tree, which is
|
|
outside of the OpenEmbedded build system.
|
|
When set, this variable sets the
|
|
<link linkend='var-S'><filename>S</filename></link>
|
|
variable, which is what the OpenEmbedded build system uses
|
|
to locate unpacked recipe source code.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on
|
|
<filename>externalsrc.bbclass</filename>, see the
|
|
"<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
|
|
section.
|
|
You can also find information on how to use this variable
|
|
in the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTERNALSRC_BUILD'><glossterm>EXTERNALSRC_BUILD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If <filename>externalsrc.bbclass</filename> is inherited,
|
|
this variable points to the directory in which the recipe's
|
|
source code is built,
|
|
which is outside of the OpenEmbedded build system.
|
|
When set, this variable sets the
|
|
<link linkend='var-B'><filename>B</filename></link>
|
|
variable, which is what the OpenEmbedded build system uses
|
|
to locate the Build Directory.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on
|
|
<filename>externalsrc.bbclass</filename>, see the
|
|
"<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
|
|
section.
|
|
You can also find information on how to use this variable
|
|
in the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_IMAGE_FEATURES'><glossterm>EXTRA_IMAGE_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of additional features to include in an image.
|
|
Typically, you configure this variable in your
|
|
<filename>local.conf</filename> file, which is found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
Although you can use this variable from within a recipe,
|
|
best practices dictate that you do not.
|
|
<note>
|
|
To enable primary features from within the image
|
|
recipe, use the
|
|
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
|
|
variable.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
Here are some examples of features you can add:
|
|
<literallayout class='monospaced'>
|
|
"dbg-pkgs" - Adds -dbg packages for all installed packages
|
|
including symbol information for debugging and
|
|
profiling.
|
|
|
|
"debug-tweaks" - Makes an image suitable for development.
|
|
For example, ssh root access has a blank
|
|
password. You should remove this feature
|
|
before you produce a production image.
|
|
|
|
"dev-pkgs" - Adds -dev packages for all installed packages.
|
|
This is useful if you want to develop against
|
|
the libraries in the image.
|
|
|
|
"read-only-rootfs" - Creates an image whose root
|
|
filesystem is read-only. See the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
|
|
section in the Yocto Project
|
|
Development Manual for more
|
|
information
|
|
|
|
"tools-debug" - Adds debugging tools such as gdb and
|
|
strace.
|
|
|
|
"tools-profile" - Adds profiling tools such as oprofile,
|
|
exmap, lttng and valgrind (x86 only).
|
|
|
|
"tools-sdk" - Adds development tools such as gcc, make,
|
|
pkgconfig and so forth.
|
|
|
|
"tools-testapps" - Adds useful testing tools such as
|
|
ts_print, aplay, arecord and so
|
|
forth.
|
|
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For a complete list of image features that ships with the
|
|
Yocto Project, see the
|
|
"<link linkend="ref-features-image">Image Features</link>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
For an example that shows how to customize your image by
|
|
using this variable, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_IMAGEDEPENDS'><glossterm>EXTRA_IMAGEDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>A list of recipes to build that do not provide packages
|
|
for installing into the root filesystem.
|
|
</para>
|
|
<para>Sometimes a recipe is required to build the final image but is not
|
|
needed in the root filesystem.
|
|
You can use the <filename>EXTRA_IMAGEDEPENDS</filename> variable to
|
|
list these recipes and thus specify the dependencies.
|
|
A typical example is a required bootloader in a machine configuration.
|
|
</para>
|
|
<note>
|
|
To add packages to the root filesystem, see the various
|
|
<filename>*<link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
|
|
and <filename>*<link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></filename>
|
|
variables.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
|
|
<glossdef>
|
|
<para>Additional <filename>cmake</filename> options.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_OECONF'><glossterm>EXTRA_OECONF</glossterm>
|
|
<glossdef>
|
|
<para>Additional <filename>configure</filename> script options.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_OEMAKE'><glossterm>EXTRA_OEMAKE</glossterm>
|
|
<glossdef>
|
|
<para>Additional GNU <filename>make</filename> options.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_USERS_PARAMS'><glossterm>EXTRA_USERS_PARAMS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<link linkend='ref-classes-extrausers'><filename>extrausers</filename></link>
|
|
class, this variable provides image level user and group
|
|
operations.
|
|
This is a more global method of providing user and group
|
|
configuration as compared to using the
|
|
<link linkend='ref-classes-useradd'><filename>useradd</filename></link>
|
|
class, which ties user and group configurations to a
|
|
specific recipe.
|
|
</para>
|
|
|
|
<para>
|
|
The set list of commands you can configure using the
|
|
<filename>EXTRA_USERS_PARAMS</filename> is shown in the
|
|
<filename>extrausers</filename> class.
|
|
These commands map to the normal Unix commands of the same
|
|
names:
|
|
<literallayout class='monospaced'>
|
|
# EXTRA_USERS_PARAMS = "\
|
|
# useradd -p '' tester; \
|
|
# groupadd developers; \
|
|
# userdel nobody; \
|
|
# groupdel -g video; \
|
|
# groupmod -g 1020 developers; \
|
|
# usermod -s /bin/sh tester; \
|
|
# "
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-f'><title>F</title>
|
|
|
|
<glossentry id='var-FEED_DEPLOYDIR_BASE_URI'><glossterm>FEED_DEPLOYDIR_BASE_URI</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the base URL of the server and location within
|
|
the document-root that provides the metadata and
|
|
packages required by OPKG to support runtime package
|
|
management of IPK packages.
|
|
You set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
Consider the following example:
|
|
<literallayout class='monospaced'>
|
|
FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir"
|
|
</literallayout>
|
|
This example assumes you are serving your packages over
|
|
HTTP and your databases are located in a directory
|
|
named <filename>BOARD-dir</filename>, which is underneath
|
|
your HTTP server's document-root.
|
|
In this case, the OpenEmbedded build system generates a set
|
|
of configuration files for you in your target that work
|
|
with the feed.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FILES'><glossterm>FILES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of directories or files that are placed in packages.
|
|
</para>
|
|
|
|
<para>
|
|
To use the <filename>FILES</filename> variable, provide a package name
|
|
override that identifies the resulting package.
|
|
Then, provide a space-separated list of files or paths that identifies the
|
|
files you want included as part of the resulting package.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<note>
|
|
When specifying paths as part of the <filename>FILES</filename> variable,
|
|
it is good practice to use appropriate path variables.
|
|
For example, use <filename>${sysconfdir}</filename> rather than
|
|
<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
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</note>
|
|
|
|
<para>
|
|
If some of the files you provide with the <filename>FILES</filename> variable
|
|
are editable and you know they should not be
|
|
overwritten during the package update process by the Package Management
|
|
System (PMS), you can identify these files so that the PMS will not
|
|
overwrite them.
|
|
See the <filename><link linkend='var-CONFFILES'>CONFFILES</link></filename>
|
|
variable for information on how to identify these files to the PMS.
|
|
</para>
|
|
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Extends the search path the OpenEmbedded build system uses
|
|
when looking for files and patches as it processes recipes
|
|
and append files.
|
|
The default directories BitBake uses when it processes
|
|
recipes are initially defined by the
|
|
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
|
|
variable.
|
|
You can extend <filename>FILESPATH</filename> variable
|
|
by using <filename>FILESEXTRAPATHS</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
Best practices dictate that you accomplish this by using
|
|
<filename>FILESEXTRAPATHS</filename> from within a
|
|
<filename>.bbappend</filename> file and that you prepend
|
|
paths as follows:
|
|
<literallayout class='monospaced'>
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
|
</literallayout>
|
|
In the above example, the build system first looks for files
|
|
in a directory that has the same name as the corresponding
|
|
append file.
|
|
<note>
|
|
<para>When extending <filename>FILESEXTRAPATHS</filename>,
|
|
be sure to use the immediate expansion
|
|
(<filename>:=</filename>) operator.
|
|
Immediate expansion makes sure that BitBake evaluates
|
|
<link linkend='var-THISDIR'><filename>THISDIR</filename></link>
|
|
at the time the directive is encountered rather than at
|
|
some later time when expansion might result in a
|
|
directory that does not contain the files you need.
|
|
</para>
|
|
<para>Also, include the trailing separating colon
|
|
character if you are prepending.
|
|
The trailing colon character is necessary because you
|
|
are directing BitBake to extend the path by prepending
|
|
directories to the search path.</para>
|
|
</note>
|
|
Here is another common use:
|
|
<literallayout class='monospaced'>
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
|
|
</literallayout>
|
|
In this example, the build system extends the
|
|
<filename>FILESPATH</filename> variable to include a
|
|
directory named <filename>files</filename> that is in the
|
|
same directory as the corresponding append file.
|
|
</para>
|
|
|
|
<para>
|
|
Here is a final example that specifically adds three paths:
|
|
<literallayout class='monospaced'>
|
|
FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
By prepending paths in <filename>.bbappend</filename>
|
|
files, you allow multiple append files that reside in
|
|
different layers but are used for the same recipe to
|
|
correctly extend the path.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FILESOVERRIDES'><glossterm>FILESOVERRIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A subset of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
|
|
used by the OpenEmbedded build system for creating
|
|
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
|
|
You can find more information on how overrides are handled
|
|
in the BitBake Manual that is located at
|
|
<filename>bitbake/doc/manual</filename> in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>FILESOVERRIDES</filename>
|
|
variable is defined as:
|
|
<literallayout class='monospaced'>
|
|
FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
|
|
</literallayout>
|
|
|
|
<note>
|
|
Do not hand-edit the <filename>FILESOVERRIDES</filename>
|
|
variable.
|
|
The values match up with expected overrides and are
|
|
used in an expected manner by the build system.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
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 files and patches specified by each
|
|
<filename>file://</filename> URI in a recipe.
|
|
</para>
|
|
|
|
<para>
|
|
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;#source-directory'>Source Directory</ulink>:
|
|
<literallayout class='monospaced'>
|
|
FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
|
|
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
|
|
</literallayout>
|
|
<note>
|
|
Do not hand-edit the <filename>FILESPATH</filename>
|
|
variable.
|
|
If you want the build system to look in directories
|
|
other than the defaults, extend the
|
|
<filename>FILESPATH</filename> variable by using the
|
|
<link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
|
|
variable.
|
|
</note>
|
|
Be aware that the default <filename>FILESPATH</filename>
|
|
directories do not map to directories in custom layers
|
|
where append files (<filename>.bbappend</filename>)
|
|
are used.
|
|
If you want the build system to find patches or files
|
|
that reside with your append files, you need to extend
|
|
the <filename>FILESPATH</filename> variable by using
|
|
the
|
|
<link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FILESYSTEM_PERMS_TABLES'><glossterm>FILESYSTEM_PERMS_TABLES</glossterm>
|
|
<glossdef>
|
|
<para>Allows you to define your own file permissions settings table as part of
|
|
your configuration for the packaging process.
|
|
For example, suppose you need a consistent set of custom permissions for
|
|
a set of groups and users across an entire work project.
|
|
It is best to do this in the packages themselves but this is not always
|
|
possible.
|
|
</para>
|
|
<para>
|
|
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 distro's 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
|
|
<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
|
|
<link linkend='var-BBPATH'><filename>BBPATH</filename></link> variable.
|
|
</para>
|
|
<para>
|
|
For guidance on how to create your own file permissions settings table file,
|
|
examine the existing <filename>fs-perms.txt</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FONT_PACKAGES'><glossterm>FONT_PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<link linkend='ref-classes-fontcache'><filename>fontcache</filename></link>
|
|
class, this variable identifies packages that contain fonts
|
|
the OpenEmbedded build system installs.
|
|
By default, installed fonts appear in the main package
|
|
(i.e. <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
|
|
Use this variable if fonts you need appear in a package
|
|
other than that main package.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The options to pass in
|
|
<filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
|
|
and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>
|
|
when compiling an optimized system.
|
|
This variable defaults to
|
|
"-O2 -pipe ${DEBUG_FLAGS}".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-g'><title>G</title>
|
|
|
|
<glossentry id='var-GROUPADD_PARAM'><glossterm>GROUPADD_PARAM</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>useradd</filename> class, this variable
|
|
specifies for a package what parameters should be passed
|
|
to the <filename>groupadd</filename> command
|
|
if you wish to add a group to the system when the package
|
|
is installed.
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example from the <filename>dbus</filename>
|
|
recipe:
|
|
<literallayout class='monospaced'>
|
|
GROUPADD_PARAM_${PN} = "-r netdev"
|
|
</literallayout>
|
|
For information on the standard Linux shell command
|
|
<filename>groupadd</filename>, see
|
|
<ulink url='http://linux.die.net/man/8/groupadd'></ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-GROUPMEMS_PARAM'><glossterm>GROUPMEMS_PARAM</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>useradd</filename> class, this variable
|
|
specifies for a package what parameters should be passed
|
|
to the <filename>groupmems</filename> command
|
|
if you wish to modify the members of a group when the
|
|
package is installed.
|
|
</para>
|
|
|
|
<para>
|
|
For information on the standard Linux shell command
|
|
<filename>groupmems</filename>, see
|
|
<ulink url='http://linux.die.net/man/8/groupmems'></ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-GRUB_GFXSERIAL'><glossterm>GRUB_GFXSERIAL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Configures the GNU GRand Unified Bootloader (GRUB) to have
|
|
graphics and serial in the boot menu.
|
|
Set this variable to "1" in your
|
|
<filename>local.conf</filename> or distribution
|
|
configuration file to enable graphics and serial
|
|
in the menu.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
|
|
class for more information on how this variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-GRUB_OPTS'><glossterm>GRUB_OPTS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Additional options to add to the GNU GRand Unified
|
|
Bootloader (GRUB) configuration.
|
|
Use a semi-colon character (<filename>;</filename>) to
|
|
separate multiple options.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>GRUB_OPTS</filename> variable is optional.
|
|
See the
|
|
<link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
|
|
class for more information on how this variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-GRUB_TIMEOUT'><glossterm>GRUB_TIMEOUT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the timeout before executing the default
|
|
<filename>LABEL</filename> in the GNU GRand Unified
|
|
Bootloader (GRUB).
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>GRUB_TIMEOUT</filename> variable is optional.
|
|
See the
|
|
<link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
|
|
class for more information on how this variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-GTKIMMODULES_PACKAGES'><glossterm>GTKIMMODULES_PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Includes the packages that contain the GIMP Toolkit input
|
|
method modules being installed when the modules are in
|
|
packages other than the main package.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-gtk-immodules-cache'><filename>gtk-immodules-cache</filename></link>
|
|
class for more information on how this variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-h'><title>H</title>
|
|
|
|
<glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
|
|
<glossdef>
|
|
<para>Website where more information about the software the recipe is building
|
|
can be found.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the system, including the architecture and the
|
|
operating system, for with the build is occurring
|
|
in the context of the current
|
|
recipe.
|
|
The OpenEmbedded build system automatically sets this
|
|
variable.
|
|
You do not need to set the variable yourself.
|
|
</para>
|
|
|
|
<para>
|
|
Here are two examples:
|
|
<itemizedlist>
|
|
<listitem><para>Given a native recipe on a 32-bit
|
|
x86 machine running Linux, the value is
|
|
"i686-linux".
|
|
</para></listitem>
|
|
<listitem><para>Given a recipe being built for a
|
|
little-endian MIPS target running Linux,
|
|
the value might be "mipsel-linux".
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-i'><title>I</title>
|
|
|
|
<glossentry id='var-ICECC_CC'><glossterm>ICECC_CC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The path to the GNU C compiler <filename>gcc</filename>.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You do not set this variable by hand.
|
|
</para>
|
|
|
|
<para>
|
|
When the location for the GNU C compiler is not a
|
|
symbolic link, the class sets the variable to the location
|
|
of the compiler.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_CXX'><glossterm>ICECC_CXX</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The path to the GNU C++ compiler <filename>g++</filename>.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You do not set this variable by hand.
|
|
</para>
|
|
|
|
<para>
|
|
When the location for the GNU C++ compiler is not a
|
|
symbolic link, the class sets the variable to the location
|
|
of the compiler.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_ENV_EXEC'><glossterm>ICECC_ENV_EXEC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the <filename>icecc-create-env</filename> script
|
|
that you provide.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
If you do not point to a script that you provide, the
|
|
OpenEmbedded build system uses the default script provided
|
|
by the <filename>icecc-create-env.bb</filename> recipe,
|
|
which is a modified version and not the one that comes with
|
|
<filename>icecc</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_PATH'><glossterm>ICECC_PATH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location of the <filename>icecc</filename> binary.
|
|
You can set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
If your <filename>local.conf</filename> file does not define
|
|
this variable, the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class attempts to define it by locating
|
|
<filename>icecc</filename> using <filename>which</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_USER_CLASS_BL'><glossterm>ICECC_USER_CLASS_BL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Identifies user classes that you do not want the
|
|
Icecream distributed compile support to consider.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
When you list classes using this variable, you are
|
|
"blacklisting" them from distributed compilation across
|
|
remote hosts.
|
|
Any classes you list will be distributed and compiled
|
|
locally.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_USER_PACKAGE_BL'><glossterm>ICECC_USER_PACKAGE_BL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Identifies user packages that you do not want the
|
|
Icecream distributed compile support to consider.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
When you list packages using this variable, you are
|
|
"blacklisting" them from distributed compilation across
|
|
remote hosts.
|
|
Any packages you list will be distributed and compiled
|
|
locally.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_USER_PACKAGE_WL'><glossterm>ICECC_USER_PACKAGE_WL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Identifies user packages that use an empty
|
|
<link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
|
|
variable that you want to force remote distributed
|
|
compilation on using the Icecream distributed compile
|
|
support.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ICECC_VERSION'><glossterm>ICECC_VERSION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The version of the cross-compiler used in the
|
|
cross-development toolchain.
|
|
This variable is used by the
|
|
<link linkend='ref-classes-icecc'><filename>icecc</filename></link>
|
|
class.
|
|
You do not set this variable by hand.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_BASENAME'><glossterm>IMAGE_BASENAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The base name of image output files.
|
|
This variable defaults to the recipe name
|
|
(<filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_CLASSES'><glossterm>IMAGE_CLASSES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of classes that all images should inherit.
|
|
You typically use this variable to specify the list of
|
|
classes that register the different types of images
|
|
the OpenEmbedded build system creates.
|
|
</para>
|
|
|
|
<para>
|
|
The default value for <filename>IMAGE_CLASSES</filename> is
|
|
<filename>image_types</filename>.
|
|
You can set this variable in your
|
|
<filename>local.conf</filename> or in a distribution
|
|
configuration file.
|
|
</para>
|
|
|
|
<para>
|
|
For more information, see
|
|
<filename>meta/classes/image_types.bbclass</filename> in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The primary list of features to include in an image.
|
|
Typically, you configure this variable in an image recipe.
|
|
Although you can use this variable from your
|
|
<filename>local.conf</filename> file, which is found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
|
|
best practices dictate that you do not.
|
|
<note>
|
|
To enable extra features from outside the image recipe,
|
|
use the
|
|
<filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
|
|
</note>
|
|
For a list of image features that ships with the Yocto
|
|
Project, see the
|
|
"<link linkend="ref-features-image">Image Features</link>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
For an example that shows how to customize your image by
|
|
using this variable, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_FSTYPES'><glossterm>IMAGE_FSTYPES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the formats the OpenEmbedded build system uses
|
|
during the build when creating the root filesystem.
|
|
For example, setting <filename>IMAGE_FSTYPES</filename>
|
|
as follows causes the build system to create root
|
|
filesystems using two formats: <filename>.ext3</filename>
|
|
and <filename>.tar.bz2</filename>:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_FSTYPES = "ext3 tar.bz2"
|
|
</literallayout>
|
|
For the complete list of supported image formats from which
|
|
you can choose, see
|
|
<link linkend='var-IMAGE_TYPES'><filename>IMAGE_TYPES</filename></link>.
|
|
</para>
|
|
|
|
<note>
|
|
If you add "live" to <filename>IMAGE_FSTYPES</filename>
|
|
inside an image recipe, be sure that you do so prior to the
|
|
"inherit image" line of the recipe or the live image will
|
|
not build.
|
|
</note>
|
|
|
|
<note>
|
|
Due to the way this variable is processed, it is not
|
|
possible to update its contents using
|
|
<filename>_append</filename> or
|
|
<filename>_prepend</filename>. To add one or more
|
|
additional options to this variable the
|
|
<filename>+=</filename> operator must be used.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the packages to install into an image.
|
|
The <filename>IMAGE_INSTALL</filename> variable is a mechanism for an image
|
|
recipe and you should use it with care to avoid ordering issues.
|
|
</para>
|
|
|
|
<para>
|
|
Image recipes set <filename>IMAGE_INSTALL</filename> to specify the
|
|
packages to install into an image through <filename>image.bbclass</filename>.
|
|
Additionally, "helper" classes exist, such as <filename>core-image.bbclass</filename>,
|
|
that can take
|
|
<filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename> lists
|
|
and turn these into auto-generated entries in
|
|
<filename>IMAGE_INSTALL</filename> in addition to its default contents.
|
|
</para>
|
|
|
|
<para>
|
|
Using <filename>IMAGE_INSTALL</filename> with the <filename>+=</filename>
|
|
operator from the <filename>/conf/local.conf</filename> file or from within
|
|
an image recipe is not recommended as it can cause ordering issues.
|
|
Since <filename>core-image.bbclass</filename> sets <filename>IMAGE_INSTALL</filename>
|
|
to a default value using the <filename>?=</filename> operator, using a
|
|
<filename>+=</filename> operation against <filename>IMAGE_INSTALL</filename>
|
|
will result in unexpected behavior when used in
|
|
<filename>conf/local.conf</filename>.
|
|
Furthermore, the same operation from within an image recipe may or may not
|
|
succeed depending on the specific situation.
|
|
In both these cases, the behavior is contrary to how most users expect
|
|
the <filename>+=</filename> operator to work.
|
|
</para>
|
|
|
|
<para>
|
|
When you use this variable, it is best to use it as follows:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_INSTALL_append = " package-name"
|
|
</literallayout>
|
|
Be sure to include the space between the quotation character and the start of the
|
|
package name or names.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_LINGUAS'><glossterm>IMAGE_LINGUAS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the list of locales to install into the image
|
|
during the root filesystem construction process.
|
|
The OpenEmbedded build system automatically splits locale
|
|
files, which are used for localization, into separate
|
|
packages.
|
|
Setting the <filename>IMAGE_LINGUAS</filename> variable
|
|
ensures that any locale packages that correspond to packages
|
|
already selected for installation into the image are also
|
|
installed.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_LINGUAS = "pt-br de-de"
|
|
</literallayout>
|
|
In this example, the build system ensures any Brazilian
|
|
Portuguese and German locale files that correspond to
|
|
packages in the image are installed (i.e.
|
|
<filename>*-locale-pt-br</filename>
|
|
and <filename>*-locale-de-de</filename> as well as
|
|
<filename>*-locale-pt</filename>
|
|
and <filename>*-locale-de</filename>, since some software
|
|
packages only provide locale files by language and not by
|
|
country-specific language).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_NAME'><glossterm>IMAGE_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The name of the output image files minus the extension.
|
|
This variable is derived using the
|
|
<link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>,
|
|
<link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
|
|
and
|
|
<link linkend='var-DATETIME'><filename>DATETIME</filename></link>
|
|
variables:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines a multiplier that the build system applies to the initial image
|
|
size for cases when the multiplier times the returned disk usage value
|
|
for the image is greater than the sum of
|
|
<filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
|
|
and
|
|
<filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>.
|
|
The result of the multiplier applied to the initial image size creates
|
|
free disk space in the image as overhead.
|
|
By default, the build process uses a multiplier of 1.3 for this variable.
|
|
This default value results in 30% free disk space added to the image when this
|
|
method is used to determine the final generated image size.
|
|
You should be aware that post install scripts and the package management
|
|
system uses disk space inside this overhead area.
|
|
Consequently, the multiplier does not produce an image with
|
|
all the theoretical free disk space.
|
|
See <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
|
|
for information on how the build system determines the overall image size.
|
|
</para>
|
|
|
|
<para>
|
|
The default 30% free disk space typically gives the image enough room to boot
|
|
and allows for basic post installs while still leaving a small amount of
|
|
free disk space.
|
|
If 30% free space is inadequate, you can increase the default value.
|
|
For example, the following setting gives you 50% free space added to the image:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_OVERHEAD_FACTOR = "1.5"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
Alternatively, you can ensure a specific amount of free disk space is added
|
|
to the image by using the
|
|
<filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_POSTPROCESS_COMMAND'><glossterm>IMAGE_POSTPROCESS_COMMAND</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Added by classes to run post processing commands once the
|
|
OpenEmbedded build system has created the image.
|
|
You can specify shell commands separated by semicolons:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_POSTPROCESS_COMMAND += "<shell_command>; ... "
|
|
</literallayout>
|
|
If you need to pass the path to the root filesystem within
|
|
the command, you can use
|
|
<filename>${IMAGE_ROOTFS}</filename>, which points to
|
|
the root filesystem image.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_ROOTFS'><glossterm>IMAGE_ROOTFS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location of the root filesystem while it is under
|
|
construction (i.e. during <filename>do_rootfs</filename>).
|
|
This variable is not configurable.
|
|
Do not change it.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_ROOTFS_EXTRA_SPACE'><glossterm>IMAGE_ROOTFS_EXTRA_SPACE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines additional free disk space created in the image in Kbytes.
|
|
By default, this variable is set to "0".
|
|
This free disk space is added to the image after the build system determines
|
|
the image size as described in
|
|
<filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is particularly useful when you want to ensure that a
|
|
specific amount of free disk space is available on a device after an image
|
|
is installed and running.
|
|
For example, to be sure 5 Gbytes of free disk space is available, set the
|
|
variable as follows:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For example, the Yocto Project Build Appliance specifically requests 40 Gbytes
|
|
of extra space with the line:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_ROOTFS_SIZE'><glossterm>IMAGE_ROOTFS_SIZE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the size in Kbytes for the generated image.
|
|
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.
|
|
Programatically, the build system determines the final size of the
|
|
generated image as follows:
|
|
<literallayout class='monospaced'>
|
|
if (image-du * overhead) < rootfs-size:
|
|
internal-rootfs-size = rootfs-size + xspace
|
|
else:
|
|
internal-rootfs-size = (image-du * overhead) + xspace
|
|
|
|
where:
|
|
|
|
image-du = Returned value of the du command on
|
|
the image.
|
|
|
|
overhead = IMAGE_OVERHEAD_FACTOR
|
|
|
|
rootfs-size = IMAGE_ROOTFS_SIZE
|
|
|
|
internal-rootfs-size = Initial root filesystem
|
|
size before any modifications.
|
|
|
|
xspace = IMAGE_ROOTFS_EXTRA_SPACE
|
|
</literallayout>
|
|
See the <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
|
|
and <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
|
|
variables for related information.
|
|
<!-- In the above example, <filename>overhead</filename> is defined by the
|
|
<filename><link linkend='var-IMAGE_OVERHEAD_FACTOR'>IMAGE_OVERHEAD_FACTOR</link></filename>
|
|
variable, <filename>xspace</filename> is defined by the
|
|
<filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
|
|
variable, and <filename>du</filename> is the results of the disk usage command
|
|
on the initially generated image. -->
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_TYPES'><glossterm>IMAGE_TYPES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the complete list of supported image types
|
|
by default:
|
|
<literallayout class='monospaced'>
|
|
jffs2
|
|
sum.jffs2
|
|
cramfs
|
|
ext2
|
|
ext2.gz
|
|
ext2.bz2
|
|
ext3
|
|
ext3.gz
|
|
ext2.lzma
|
|
btrfs
|
|
live
|
|
squashfs
|
|
squashfs-xz
|
|
ubi
|
|
ubifs
|
|
tar
|
|
tar.gz
|
|
tar.bz2
|
|
tar.xz
|
|
cpio
|
|
cpio.gz
|
|
cpio.xz
|
|
cpio.lzma
|
|
vmdk
|
|
elf
|
|
</literallayout>
|
|
For more information on how these types of images, see
|
|
<filename>meta/classes/image_types*.bbclass</filename>
|
|
in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INC_PR'><glossterm>INC_PR</glossterm>
|
|
<glossdef>
|
|
<para>Helps define the recipe revision for recipes that share
|
|
a common <filename>include</filename> file.
|
|
You can think of this variable as part of the recipe revision
|
|
as set from within an include file.</para>
|
|
<para>Suppose, for example, you have a set of recipes that
|
|
are used across several projects.
|
|
And, within each of those recipes the revision
|
|
(its <link linkend='var-PR'><filename>PR</filename></link>
|
|
value) is set accordingly.
|
|
In this case, when the revision of those recipes changes,
|
|
the burden is on you to find all those recipes and
|
|
be sure that they get changed to reflect the updated
|
|
version of the recipe.
|
|
In this scenario, it can get complicated when recipes
|
|
that are used in many places and provide common functionality
|
|
are upgraded to a new revision.</para>
|
|
<para>A more efficient way of dealing with this situation is
|
|
to set the <filename>INC_PR</filename> variable inside
|
|
the <filename>include</filename> files that the recipes
|
|
share and then expand the <filename>INC_PR</filename>
|
|
variable within the recipes to help
|
|
define the recipe revision.
|
|
</para>
|
|
<para>
|
|
The following provides an example that shows how to use
|
|
the <filename>INC_PR</filename> variable
|
|
given a common <filename>include</filename> file that
|
|
defines the variable.
|
|
Once the variable is defined in the
|
|
<filename>include</filename> file, you can use the
|
|
variable to set the <filename>PR</filename> values in
|
|
each recipe.
|
|
You will notice that when you set a recipe's
|
|
<filename>PR</filename> you can provide more granular
|
|
revisioning by appending values to the
|
|
<filename>INC_PR</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
|
|
recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
|
|
recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
|
|
recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
|
|
</literallayout>
|
|
The first line of the example establishes the baseline
|
|
revision to be used for all recipes that use the
|
|
<filename>include</filename> file.
|
|
The remaining lines in the example are from individual
|
|
recipes and show how the <filename>PR</filename> value
|
|
is set.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INCOMPATIBLE_LICENSE'><glossterm>INCOMPATIBLE_LICENSE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a space-separated list of license names
|
|
(as they would appear in
|
|
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>)
|
|
that should be excluded from the build.
|
|
Recipes that provide no alternatives to listed incompatible
|
|
licenses are not built.
|
|
Packages that are individually licensed with the specified
|
|
incompatible licenses will be deleted.
|
|
</para>
|
|
|
|
<note>
|
|
This functionality is only regularly tested using
|
|
the following setting:
|
|
<literallayout class='monospaced'>
|
|
INCOMPATIBLE_LICENSE = "GPLv3"
|
|
</literallayout>
|
|
Although you can use other settings, you might be required
|
|
to remove dependencies on or provide alternatives to
|
|
components that are required to produce a functional system
|
|
image.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INHIBIT_DEFAULT_DEPS'><glossterm>INHIBIT_DEFAULT_DEPS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Prevents the default dependencies, namely the C compiler
|
|
and standard C library (libc), from being added to
|
|
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>.
|
|
This variable is usually used within recipes that do not
|
|
require any compilation using the C compiler.
|
|
</para>
|
|
|
|
<para>
|
|
Set the variable to "1" to prevent the default dependencies
|
|
from being added.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If set to "1", causes the build to not strip binaries in resulting packages.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Causes the named class to be inherited at
|
|
this point during parsing.
|
|
The variable is only valid in configuration files.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INHERIT_DISTRO'><glossterm>INHERIT_DISTRO</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists classes that are inherited by default at the
|
|
distribution level.
|
|
It is unlikely that you want to edit this variable.
|
|
</para>
|
|
|
|
<para>
|
|
The variable is set as follows in the
|
|
<filename>meta/conf/distro/defaultsetup.conf</filename>
|
|
file:
|
|
<literallayout class='monospaced'>
|
|
INHERIT_DISTRO ?= "debian devshell sstate license"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITRAMFS_FSTYPES'><glossterm>INITRAMFS_FSTYPES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the format for the output image of an initial
|
|
RAM disk (initramfs), which is used during boot.
|
|
Supported formats are the same as those supported by the
|
|
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITRD'><glossterm>INITRD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Indicates a filesystem image to use as an initial RAM
|
|
disk (<filename>initrd</filename>).
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>INITRD</filename> variable is an optional
|
|
variable used with the
|
|
<link linkend='ref-classes-bootimg'><filename>buildimg</filename></link>
|
|
class.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITSCRIPT_NAME'><glossterm>INITSCRIPT_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The filename of the initialization script as installed to
|
|
<filename>${sysconfdir}/init.d</filename>.
|
|
</para>
|
|
<para>
|
|
This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
|
|
The variable is mandatory.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITSCRIPT_PACKAGES'><glossterm>INITSCRIPT_PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of the packages that contain initscripts.
|
|
If multiple packages are specified, you need to append the package name
|
|
to the other <filename>INITSCRIPT_*</filename> as an override.</para>
|
|
<para>
|
|
This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
|
|
The variable is optional and defaults to the
|
|
<link linkend='var-PN'><filename>PN</filename></link> variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITSCRIPT_PARAMS'><glossterm>INITSCRIPT_PARAMS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the options to pass to <filename>update-rc.d</filename>.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
|
|
</literallayout>
|
|
In this example, the script has a runlevel of 99,
|
|
starts the script in initlevels 2 and 5, and
|
|
stops the script in levels 0, 1 and 6.
|
|
</para>
|
|
<para>
|
|
The variable is mandatory and is used in recipes when using
|
|
<filename>update-rc.d.bbclass</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the QA checks to skip for a specific package
|
|
within a recipe.
|
|
For example, to skip the check for symbolic link
|
|
<filename>.so</filename> files in the main package of a
|
|
recipe, add the following to the recipe.
|
|
The package name override must be used, which in this
|
|
example is <filename>${PN}</filename>:
|
|
<literallayout class='monospaced'>
|
|
INSANE_SKIP_${PN} += "dev-so"
|
|
</literallayout>
|
|
</para>
|
|
<para>
|
|
See the "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
|
|
section for a list of the valid QA checks you can
|
|
specify using this variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IPK_FEED_URIS'><glossterm>IPK_FEED_URIS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When the IPK backend is in use and package management
|
|
is enabled on the target, you can use this variable to
|
|
set up <filename>opkg</filename> in the target image
|
|
to point to package feeds on a nominated server.
|
|
Once the feed is established, you can perform
|
|
installations or upgrades using the package manager
|
|
at runtime.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<!--
|
|
<glossentry id='var-INTERCEPT_DIR'><glossterm>INTERCEPT_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An environment variable that defines the directory where
|
|
post installation hooks are installed for the
|
|
post install environment.
|
|
This variable is fixed as follows:
|
|
<literallayout class='monospaced'>
|
|
${WORKDIR}/intercept_scripts
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
After installation of a target's root filesystem,
|
|
post installation scripts, which are essentially bash scripts,
|
|
are all executed just a single time.
|
|
Limiting execution of these scripts minimizes installation
|
|
time that would be lengthened due to certain packages
|
|
triggering redundant operations.
|
|
For example, consider the installation of font packages
|
|
as a common example.
|
|
Without limiting the execution of post installation scripts,
|
|
all font directories would be rescanned to create the
|
|
cache after each individual font package was installed.
|
|
</para>
|
|
|
|
<para>
|
|
Do not edit the <filename>INTERCEPT_DIR</filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
-->
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-j'><title>J</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<glossdiv id='var-glossary-k'><title>K</title>
|
|
|
|
<glossentry id='var-KARCH'><glossterm>KARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the kernel architecture used when assembling
|
|
the configuration.
|
|
Architectures supported for this release are:
|
|
<literallayout class='monospaced'>
|
|
powerpc
|
|
i386
|
|
x86_64
|
|
arm
|
|
qemu
|
|
mips
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
You define the <filename>KARCH</filename> variable in the
|
|
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KBRANCH'><glossterm>KBRANCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A regular expression used by the build process to explicitly identify the kernel
|
|
branch that is validated, patched and configured during a build.
|
|
The <filename>KBRANCH</filename> variable is optional.
|
|
You can use it to trigger checks to ensure the exact kernel branch you want is
|
|
being used by the build process.
|
|
</para>
|
|
|
|
<para>
|
|
Values for this variable are set in the kernel's recipe file and the kernel's
|
|
append file.
|
|
For example, if you are using the Yocto Project kernel that is based on the
|
|
Linux 3.4 kernel, the kernel recipe file is the
|
|
<filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename> file.
|
|
Following is the default value for <filename>KBRANCH</filename> and the default
|
|
override for the architectures the Yocto Project supports:
|
|
<literallayout class='monospaced'>
|
|
KBRANCH_DEFAULT = "standard/base"
|
|
KBRANCH = "${KBRANCH_DEFAULT}"
|
|
</literallayout>
|
|
This branch exists in the <filename>linux-yocto-3.4</filename> kernel Git
|
|
repository <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is also used from the kernel's append file to identify the kernel
|
|
branch specific to a particular machine or target hardware.
|
|
The kernel's append file is located in the BSP layer for a given machine.
|
|
For example, the kernel append file for the Crown Bay BSP is in the
|
|
<filename>meta-intel</filename> Git repository and is named
|
|
<filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend</filename>.
|
|
Here are the related statements from the append file:
|
|
<literallayout class='monospaced'>
|
|
COMPATIBLE_MACHINE_crownbay = "crownbay"
|
|
KMACHINE_crownbay = "crownbay"
|
|
KBRANCH_crownbay = "standard/crownbay"
|
|
|
|
COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
|
|
KMACHINE_crownbay-noemgd = "crownbay"
|
|
KBRANCH_crownbay-noemgd = "standard/crownbay"
|
|
</literallayout>
|
|
The <filename>KBRANCH_*</filename> statements identify the kernel branch to
|
|
use when building for the Crown Bay BSP.
|
|
In this case there are two identical statements: one for each type of
|
|
Crown Bay machine.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KBRANCH_DEFAULT'><glossterm>KBRANCH_DEFAULT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the Linux kernel source repository's default
|
|
branch used to build the Linux kernel.
|
|
The <filename>KBRANCH_DEFAULT</filename> value is
|
|
the default value for
|
|
<link linkend='var-KBRANCH'><filename>KBRANCH</filename></link>.
|
|
Unless you specify otherwise,
|
|
<filename>KBRANCH_DEFAULT</filename> initializes to
|
|
"master".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies additional <filename>make</filename>
|
|
command-line arguments the OpenEmbedded build system
|
|
passes on when compiling the kernel.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>Includes additional metadata from the Yocto Project kernel Git repository.
|
|
In the OpenEmbedded build system, the default Board Support Packages (BSPs)
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
|
|
is provided through
|
|
the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
|
|
and <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link> variables.
|
|
You can use the <filename>KERNEL_FEATURES</filename> variable to further
|
|
add metadata for all BSPs.</para>
|
|
<para>The metadata you add through this variable includes config fragments and
|
|
features descriptions,
|
|
which usually includes patches as well as config fragments.
|
|
You typically override the <filename>KERNEL_FEATURES</filename> variable
|
|
for a specific machine.
|
|
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 Yocto Project kernels and adds sound support to the <filename>qemux86</filename>
|
|
machine:
|
|
<literallayout class='monospaced'>
|
|
# Add netfilter to all linux-yocto kernels
|
|
KERNEL_FEATURES="features/netfilter"
|
|
|
|
# Add sound support to the qemux86 machine
|
|
KERNEL_FEATURES_append_qemux86=" cfg/sound"
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
|
|
<glossdef>
|
|
<para>The type of kernel to build for a device, usually set by the
|
|
machine configuration files and defaults to "zImage".
|
|
This variable is used
|
|
when building the kernel and is passed to <filename>make</filename> as the target to
|
|
build.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_PATH'><glossterm>KERNEL_PATH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location of the kernel sources.
|
|
This variable is set to the value of the
|
|
<link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
|
|
within the <filename>module.bbclass</filename> class.
|
|
For information on how this variable is used, see the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
The <link linkend='var-KERNEL_SRC'><filename>KERNEL_SRC</filename></link>
|
|
variable is identical to the <filename>KERNEL_PATH</filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_SRC'><glossterm>KERNEL_SRC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location of the kernel sources.
|
|
This variable is set to the value of the
|
|
<link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
|
|
within the <filename>module.bbclass</filename> class.
|
|
For information on how this variable is used, see the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
The <link linkend='var-KERNEL_PATH'><filename>KERNEL_PATH</filename></link>
|
|
variable is identical to the <filename>KERNEL_SRC</filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KFEATURE_DESCRIPTION'><glossterm>KFEATURE_DESCRIPTION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Provides a short description of a configuration fragment.
|
|
You use this variable in the <filename>.scc</filename>
|
|
file that describes a configuration fragment file.
|
|
Here is the variable used in a file named
|
|
<filename>smp.scc</filename> to describe SMP being
|
|
enabled:
|
|
<literallayout class='monospaced'>
|
|
define KFEATURE_DESCRIPTION "Enable SMP"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KMACHINE'><glossterm>KMACHINE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The machine as known by the kernel.
|
|
Sometimes the machine name used by the kernel does not match the machine name
|
|
used by the OpenEmbedded build system.
|
|
For example, the machine name that the OpenEmbedded build system understands as
|
|
<filename>qemuarm</filename> goes by a different name in the Linux Yocto kernel.
|
|
The kernel understands that machine as <filename>arm_versatile926ejs</filename>.
|
|
For cases like these, the <filename>KMACHINE</filename> variable maps the
|
|
kernel machine name to the OpenEmbedded build system machine name.
|
|
</para>
|
|
|
|
<para>
|
|
Kernel machine names are initially defined in the
|
|
Yocto Linux Kernel's <filename>meta</filename> branch.
|
|
From the <filename>meta</filename> branch, look in
|
|
the <filename>meta/cfg/kernel-cache/bsp/<bsp_name>/<bsp-name>-<kernel-type>.scc</filename> file.
|
|
For example, from the <filename>meta</filename> branch in the
|
|
<filename>linux-yocto-3.0</filename> kernel, the
|
|
<filename>meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</filename> file
|
|
has the following:
|
|
<literallayout class='monospaced'>
|
|
define KMACHINE cedartrail
|
|
define KTYPE standard
|
|
define KARCH i386
|
|
|
|
include ktypes/standard
|
|
branch cedartrail
|
|
|
|
include cedartrail.scc
|
|
</literallayout>
|
|
You can see that the kernel understands the machine name for
|
|
the Cedar Trail Board Support Package (BSP) as
|
|
<filename>cedartrail</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
If you look in the Cedar Trail BSP layer in the
|
|
<filename>meta-intel</filename>
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
|
|
at <filename>meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>,
|
|
you will find the following statements among others:
|
|
<literallayout class='monospaced'>
|
|
COMPATIBLE_MACHINE_cedartrail = "cedartrail"
|
|
KMACHINE_cedartrail = "cedartrail"
|
|
KBRANCH_cedartrail = "yocto/standard/cedartrail"
|
|
KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc"
|
|
KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc"
|
|
|
|
COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
|
|
KMACHINE_cedartrail-nopvr = "cedartrail"
|
|
KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
|
|
KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
|
|
</literallayout>
|
|
The <filename>KMACHINE</filename> statements in the kernel's append file make sure that
|
|
the OpenEmbedded build system and the Yocto Linux kernel understand the same machine
|
|
names.
|
|
</para>
|
|
|
|
<para>
|
|
This append file uses two <filename>KMACHINE</filename> statements.
|
|
The first is not really necessary but does ensure that the machine known to the
|
|
OpenEmbedded build system as <filename>cedartrail</filename> maps to the machine
|
|
in the kernel also known as <filename>cedartrail</filename>:
|
|
<literallayout class='monospaced'>
|
|
KMACHINE_cedartrail = "cedartrail"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
The second statement is a good example of why the <filename>KMACHINE</filename> variable
|
|
is needed.
|
|
In this example, the OpenEmbedded build system uses the <filename>cedartrail-nopvr</filename>
|
|
machine name to refer to the Cedar Trail BSP that does not support the proprietary
|
|
PowerVR driver.
|
|
The kernel, however, uses the machine name <filename>cedartrail</filename>.
|
|
Thus, the append file must map the <filename>cedartrail-nopvr</filename> machine name to
|
|
the kernel's <filename>cedartrail</filename> name:
|
|
<literallayout class='monospaced'>
|
|
KMACHINE_cedartrail-nopvr = "cedartrail"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
BSPs that ship with the Yocto Project release provide all mappings between the Yocto
|
|
Project kernel machine names and the OpenEmbedded machine names.
|
|
Be sure to use the <filename>KMACHINE</filename> if you create a BSP and the machine
|
|
name you use is different than that used in the kernel.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KTYPE'><glossterm>KTYPE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the kernel type to be used in assembling the
|
|
configuration.
|
|
The linux-yocto recipes define "standard", "tiny",
|
|
and "preempt-rt" kernel types.
|
|
See the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
|
|
section in the Yocto Project Linux Kernel Development
|
|
Manual for more information on kernel types.
|
|
</para>
|
|
|
|
<para>
|
|
You define the <filename>KTYPE</filename> variable in the
|
|
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
|
|
The value you use must match the value used for the
|
|
<link linkend='var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></link>
|
|
value used by the kernel recipe.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-l'><title>L</title>
|
|
|
|
<glossentry id='var-LABELS'><glossterm>LABELS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Provides a list of targets for automatic configuration.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
|
|
class for more information on how this variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>Lists the layers that this recipe depends upon, separated by spaces.
|
|
Optionally, you can specify a specific layer version for a dependency
|
|
by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
|
|
to be compared against
|
|
<link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
|
|
in this case).
|
|
An error will be produced if any dependency is missing or
|
|
the version numbers do not match exactly (if specified).
|
|
This variable is used in the <filename>conf/layer.conf</filename> file
|
|
and must be suffixed with the name of the specific layer (e.g.
|
|
<filename>LAYERDEPENDS_mylayer</filename>).</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
|
|
<glossdef>
|
|
<para>When used inside the <filename>layer.conf</filename> configuration
|
|
file, this variable provides the path of the current layer.
|
|
This variable is not available outside of <filename>layer.conf</filename>
|
|
and references are expanded immediately when parsing of the file completes.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
|
|
<glossdef>
|
|
<para>Optionally specifies the version of a layer as a single number.
|
|
You can use this within
|
|
<link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
|
|
for another layer in order to depend on a specific version
|
|
of the layer.
|
|
This variable is used in the <filename>conf/layer.conf</filename> file
|
|
and must be suffixed with the name of the specific layer (e.g.
|
|
<filename>LAYERVERSION_mylayer</filename>).</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm>
|
|
<glossdef>
|
|
<para>Checksums of the license text in the recipe source code.</para>
|
|
<para>This variable tracks changes in license text of the source
|
|
code files.
|
|
If the license text is changed, it will trigger a build
|
|
failure, which gives the developer an opportunity to review any
|
|
license change.</para>
|
|
<para>
|
|
This variable must be defined for all recipes (unless
|
|
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
|
|
is set to "CLOSED")</para>
|
|
<para>For more information, see the
|
|
<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
|
|
Tracking License Changes</link> section</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of source licenses for the recipe.
|
|
Follow these rules:
|
|
<itemizedlist>
|
|
<listitem><para>Do not use spaces within individual
|
|
license names.</para></listitem>
|
|
<listitem><para>Separate license names using
|
|
| (pipe) when there is a choice between licenses.
|
|
</para></listitem>
|
|
<listitem><para>Separate license names using
|
|
& (ampersand) when multiple licenses exist
|
|
that cover different parts of the source.
|
|
</para></listitem>
|
|
<listitem><para>You can use spaces between license
|
|
names.</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
Here are some examples:
|
|
<literallayout class='monospaced'>
|
|
LICENSE = "LGPLv2.1 | GPLv3"
|
|
LICENSE = "MPL-1 & LGPLv2.1"
|
|
LICENSE = "GPLv2+"
|
|
</literallayout>
|
|
The first example is from the recipes for Qt, which the user
|
|
may choose to distribute under either the LGPL version
|
|
2.1 or GPL version 3.
|
|
The second example is from Cairo where two licenses cover
|
|
different parts of the source code.
|
|
The final example is from <filename>sysstat</filename>,
|
|
which presents a single license.
|
|
</para>
|
|
|
|
<para>
|
|
You can also specify licenses on a per-package basis to
|
|
handle situations where components of the output have
|
|
different licenses.
|
|
For example, a piece of software whose code is
|
|
licensed under GPLv2 but has accompanying documentation
|
|
licensed under the GNU Free Documentation License 1.2 could
|
|
be specified as follows:
|
|
<literallayout class='monospaced'>
|
|
LICENSE = "GFDL-1.2 & GPLv2"
|
|
LICENSE_${PN} = "GPLv2"
|
|
LICENSE_${PN}-doc = "GFDL-1.2"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LICENSE_PATH'><glossterm>LICENSE_PATH</glossterm>
|
|
<glossdef>
|
|
<para>Path to additional licenses used during the build.
|
|
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_PATH</filename> variable allows you to extend that
|
|
location to other areas that have additional licenses:
|
|
<literallayout class='monospaced'>
|
|
LICENSE_PATH += "/path/to/additional/common/licenses"
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LINUX_KERNEL_TYPE'><glossterm>LINUX_KERNEL_TYPE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the kernel type to be used in assembling the
|
|
configuration.
|
|
The linux-yocto recipes define "standard", "tiny", and
|
|
"preempt-rt" kernel types.
|
|
See the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
|
|
section in the Yocto Project Linux Kernel Development
|
|
Manual for more information on kernel types.
|
|
</para>
|
|
|
|
<para>
|
|
If you do not specify a
|
|
<filename>LINUX_KERNEL_TYPE</filename>, it defaults to
|
|
"standard".
|
|
Together with
|
|
<link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>,
|
|
the <filename>LINUX_KERNEL_TYPE</filename> variable
|
|
defines the search
|
|
arguments used by the kernel tools to find the appropriate
|
|
description within the kernel
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
|
|
with which to build out the sources and configuration.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LINUX_VERSION'><glossterm>LINUX_VERSION</glossterm>
|
|
<glossdef>
|
|
<para>The Linux version from <filename>kernel.org</filename>
|
|
on which the Linux kernel image being built using the
|
|
OpenEmbedded build system is based.
|
|
You define this variable in the kernel recipe.
|
|
For example, the <filename>linux-yocto-3.4.bb</filename>
|
|
kernel recipe found in
|
|
<filename>meta/recipes-kernel/linux</filename>
|
|
defines the variables as follows:
|
|
<literallayout class='monospaced'>
|
|
LINUX_VERSION ?= "3.4.24"
|
|
</literallayout>
|
|
The <filename>LINUX_VERSION</filename> variable is used to
|
|
define <link linkend='var-PV'><filename>PV</filename></link>
|
|
for the recipe:
|
|
<literallayout class='monospaced'>
|
|
PV = "${LINUX_VERSION}+git${SRCPV}"
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LINUX_VERSION_EXTENSION'><glossterm>LINUX_VERSION_EXTENSION</glossterm>
|
|
<glossdef>
|
|
<para>A string extension compiled into the version
|
|
string of the Linux kernel built with the OpenEmbedded
|
|
build system.
|
|
You define this variable in the kernel recipe.
|
|
For example, the linux-yocto kernel recipes all define
|
|
the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
LINUX_VERSION_EXTENSION ?= "-yocto-${<link linkend='var-LINUX_KERNEL_TYPE'>LINUX_KERNEL_TYPE</link>}"
|
|
</literallayout>
|
|
Defining this variable essentially sets the
|
|
Linux kernel configuration item
|
|
<filename>CONFIG_LOCALVERSION</filename>, which is visible
|
|
through the <filename>uname</filename> command.
|
|
Here is an example that shows the extension assuming it
|
|
was set as previously shown:
|
|
<literallayout class='monospaced'>
|
|
$ uname -r
|
|
3.7.0-rc8-custom
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the directory to which the OpenEmbedded build
|
|
system writes overall log files.
|
|
The default directory is <filename>${TMPDIR}/log</filename>.
|
|
</para>
|
|
<para>
|
|
For the directory containing logs specific to each task,
|
|
see the <link linkend='var-T'><filename>T</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-m'><title>M</title>
|
|
|
|
<glossentry id='var-MACHINE'><glossterm>MACHINE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the target device for which the image is built.
|
|
You define <filename>MACHINE</filename> in the
|
|
<filename>local.conf</filename> file found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
By default, <filename>MACHINE</filename> is set to
|
|
"qemux86", which is an x86-based architecture machine to
|
|
be emulated using QEMU:
|
|
<literallayout class='monospaced'>
|
|
MACHINE ?= "qemux86"
|
|
</literallayout>
|
|
The variable corresponds to a machine configuration file of the
|
|
same name, through which machine-specific configurations are set.
|
|
Thus, when <filename>MACHINE</filename> is set to "qemux86" there
|
|
exists the corresponding <filename>qemux86.conf</filename> machine
|
|
configuration file, which can be found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
in <filename>meta/conf/machine</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
The list of machines supported by the Yocto Project as
|
|
shipped include the following:
|
|
<literallayout class='monospaced'>
|
|
MACHINE ?= "qemuarm"
|
|
MACHINE ?= "qemumips"
|
|
MACHINE ?= "qemuppc"
|
|
MACHINE ?= "qemux86"
|
|
MACHINE ?= "qemux86-64"
|
|
MACHINE ?= "genericx86"
|
|
MACHINE ?= "genericx86-64"
|
|
MACHINE ?= "beagleboard"
|
|
MACHINE ?= "mpc8315e-rdb"
|
|
MACHINE ?= "routerstationpro"
|
|
</literallayout>
|
|
The last five are Yocto Project reference hardware boards, which
|
|
are provided in the <filename>meta-yocto-bsp</filename> layer.
|
|
<note>Adding additional Board Support Package (BSP) layers
|
|
to your configuration adds new possible settings for
|
|
<filename>MACHINE</filename>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
A list of required machine-specific packages to install as part of
|
|
the image being built.
|
|
The build process depends on these packages being present.
|
|
Furthermore, because this is a "machine essential" variable, the list of
|
|
packages are essential for the machine to boot.
|
|
The impact of this variable affects images based on
|
|
<filename>packagegroup-core-boot</filename>,
|
|
including the <filename>core-image-minimal</filename> image.
|
|
</para>
|
|
<para>
|
|
This variable is similar to the
|
|
<filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename>
|
|
variable with the exception that the image being built has a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will not build if a file in this list is not found.
|
|
</para>
|
|
<para>
|
|
As an example, suppose the machine for which you are building requires
|
|
<filename>example-init</filename> to be run during boot to initialize the hardware.
|
|
In this case, you would use the following in the machine's
|
|
<filename>.conf</filename> configuration file:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
A list of recommended machine-specific packages to install as part of
|
|
the image being built.
|
|
The build process does not depend on these packages being present.
|
|
However, because this is a "machine essential" variable, the list of
|
|
packages are essential for the machine to boot.
|
|
The impact of this variable affects images based on
|
|
<filename>packagegroup-core-boot</filename>,
|
|
including the <filename>core-image-minimal</filename> image.
|
|
</para>
|
|
<para>
|
|
This variable is similar to the
|
|
<filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename>
|
|
variable with the exception that the image being built does not have a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will still build if a package in this list is not found.
|
|
Typically, this variable is used to handle essential kernel modules, whose
|
|
functionality may be selected to be built into the kernel rather than as a module,
|
|
in which case a package will not be produced.
|
|
</para>
|
|
<para>
|
|
Consider an example where you have a custom kernel where a specific touchscreen
|
|
driver is required for the machine to be usable.
|
|
However, the driver can be built as a module or
|
|
into the kernel depending on the kernel configuration.
|
|
If the driver is built as a module, you want it to be installed.
|
|
But, when the driver is built into the kernel, you still want the
|
|
build to succeed.
|
|
This variable sets up a "recommends" relationship so that in the latter case,
|
|
the build will not fail due to the missing package.
|
|
To accomplish this, assuming the package for the module was called
|
|
<filename>kernel-module-ab123</filename>, you would use the
|
|
following in the machine's <filename>.conf</filename> configuration
|
|
file:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
|
|
</literallayout>
|
|
</para>
|
|
<para>
|
|
Some examples of these machine essentials are flash, screen, keyboard, mouse,
|
|
or touchscreen drivers (depending on the machine).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of machine-specific packages to install as part of the
|
|
image being built that are not essential for the machine to boot.
|
|
However, the build process for more fully-featured images
|
|
depends on the packages being present.
|
|
</para>
|
|
<para>
|
|
This variable affects all images based on
|
|
<filename>packagegroup-base</filename>, which does not include the
|
|
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
|
|
images.
|
|
</para>
|
|
<para>
|
|
The variable is similar to the
|
|
<filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename>
|
|
variable with the exception that the image being built has a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will not build if a file in this list is not found.
|
|
</para>
|
|
<para>
|
|
An example is a machine that has WiFi capability but is not
|
|
essential for the machine to boot the image.
|
|
However, if you are building a more fully-featured image, you want to enable
|
|
the WiFi.
|
|
The package containing the firmware for the WiFi hardware is always
|
|
expected to exist, so it is acceptable for the build process to depend upon
|
|
finding the package.
|
|
In this case, assuming the package for the firmware was called
|
|
<filename>wifidriver-firmware</filename>, you would use the following in the
|
|
<filename>.conf</filename> file for the machine:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
A list of machine-specific packages to install as part of the
|
|
image being built that are not essential for booting the machine.
|
|
The image being built has no build dependency on this list of packages.
|
|
</para>
|
|
<para>
|
|
This variable affects only images based on
|
|
<filename>packagegroup-base</filename>, which does not include the
|
|
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
|
|
images.
|
|
</para>
|
|
<para>
|
|
This variable is similar to the
|
|
<filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename>
|
|
variable with the exception that the image being built does not have a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will build if a file in this list is not found.
|
|
</para>
|
|
<para>
|
|
An example is a machine that has WiFi capability but is not essential
|
|
For the machine to boot the image.
|
|
However, if you are building a more fully-featured image, you want to enable
|
|
WiFi.
|
|
In this case, the package containing the WiFi kernel module will not be produced
|
|
if the WiFi driver is built into the kernel, in which case you still want the
|
|
build to succeed instead of failing as a result of the package not being found.
|
|
To accomplish this, assuming the package for the module was called
|
|
<filename>kernel-module-examplewifi</filename>, you would use the
|
|
following in the <filename>.conf</filename> file for the machine:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the list of hardware features the
|
|
<link linkend='var-MACHINE'><filename>MACHINE</filename></link> is capable
|
|
of supporting.
|
|
For related information on enabling features, see the
|
|
<link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>,
|
|
<link linkend='var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></link>,
|
|
and
|
|
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
|
|
variables.
|
|
</para>
|
|
|
|
<para>
|
|
For a list of hardware features supported by the Yocto
|
|
Project as shipped, see the
|
|
"<link linkend='ref-features-machine'>Machine Features</link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_FEATURES_BACKFILL'><glossterm>MACHINE_FEATURES_BACKFILL</glossterm>
|
|
<glossdef>
|
|
<para>Features to be added to
|
|
<filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>
|
|
if not also present in
|
|
<filename><link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'>MACHINE_FEATURES_BACKFILL_CONSIDERED</link></filename>.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is set in the <filename>meta/conf/bitbake.conf</filename> file.
|
|
It is not intended to be user-configurable.
|
|
It is best to just reference the variable to see which machine features are
|
|
being backfilled for all machine configurations.
|
|
See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
|
|
more information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><glossterm>MACHINE_FEATURES_BACKFILL_CONSIDERED</glossterm>
|
|
<glossdef>
|
|
<para>Features from
|
|
<filename><link linkend='var-MACHINE_FEATURES_BACKFILL'>MACHINE_FEATURES_BACKFILL</link></filename>
|
|
that should not be backfilled (i.e. added to
|
|
<filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>)
|
|
during the build.
|
|
See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
|
|
more information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists overrides specific to the current machine.
|
|
By default, this list includes the value
|
|
of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>.
|
|
You can extend the list to apply variable overrides for
|
|
classes of machines.
|
|
For example, all QEMU emulated machines (e.g. qemuarm,
|
|
qemux86, and so forth) include a common file named
|
|
<filename>meta/conf/machine/include/qemu.inc</filename>
|
|
that prepends <filename>MACHINEOVERRIDES</filename> with
|
|
the following variable override:
|
|
<literallayout class='monospaced'>
|
|
MACHINEOVERRIDES =. "qemuall:"
|
|
</literallayout>
|
|
Applying an override like <filename>qemuall</filename>
|
|
affects all QEMU emulated machines elsewhere.
|
|
Here is an example from the
|
|
<filename>connman-conf</filename> recipe:
|
|
<literallayout class='monospaced'>
|
|
SRC_URI_append_qemuall = "file://wired.config \
|
|
file://wired-setup \
|
|
"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
|
|
<glossdef>
|
|
<para>The email address of the distribution maintainer.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies additional paths from which the OpenEmbedded
|
|
build system gets source code.
|
|
When the build system searches for source code, it first
|
|
tries the local download directory.
|
|
If that location fails, the build system tries locations
|
|
defined by
|
|
<link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
|
|
the upstream source, and then locations specified by
|
|
<filename>MIRRORS</filename> in that order.
|
|
</para>
|
|
|
|
<para>
|
|
Assuming your distribution
|
|
(<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
|
|
is "poky", the default value for
|
|
<filename>MIRRORS</filename> is defined in the
|
|
<filename>conf/distro/poky.conf</filename> file in the
|
|
<filename>meta-yocto</filename> Git repository.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MLPREFIX'><glossterm>MLPREFIX</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a prefix has been added to
|
|
<link linkend='var-PN'><filename>PN</filename></link> to create a special version
|
|
of a recipe or package, such as a Multilib version.
|
|
The variable is used in places where the prefix needs to be
|
|
added to or removed from a the name (e.g. the
|
|
<link linkend='var-BPN'><filename>BPN</filename></link> variable).
|
|
<filename>MLPREFIX</filename> gets set when a prefix has been
|
|
added to <filename>PN</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Controls creation of the <filename>modules-*.tgz</filename>
|
|
file.
|
|
Set this variable to "0" to disable creation of this
|
|
file, which contains all of the kernel modules resulting
|
|
from a kernel build.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Separates files for different machines such that you can build
|
|
for multiple target machines using the same output directories.
|
|
See the <link linkend='var-STAMP'><filename>STAMP</filename></link> variable
|
|
for an example.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-n'><title>N</title>
|
|
|
|
<glossentry id='var-NATIVELSBSTRING'><glossterm>NATIVELSBSTRING</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A string identifying the host distribution.
|
|
Strings consist of the host distributor ID
|
|
followed by the release, as reported by the
|
|
<filename>lsb_release</filename> tool
|
|
or as read from <filename>/etc/lsb-release</filename>.
|
|
For example, when running a build on Ubuntu 12.10, the value
|
|
is "Ubuntu-12.10".
|
|
If this information is unable to be determined, the value
|
|
resolves to "Unknown".
|
|
</para>
|
|
<para>
|
|
This variable is used by default to isolate native shared
|
|
state packages for different distributions (e.g. to avoid
|
|
problems with <filename>glibc</filename> version
|
|
incompatibilities).
|
|
Additionally, the variable is checked against
|
|
<link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
|
|
if that variable is set.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-NO_RECOMMENDATIONS'><glossterm>NO_RECOMMENDATIONS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Prevents installation of all "recommended-only" packages.
|
|
Recommended-only packages are packages installed only
|
|
through the
|
|
<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
|
|
variable).
|
|
Setting the <filename>NO_RECOMMENDATIONS</filename> variable
|
|
to "1" turns this feature on:
|
|
<literallayout class='monospaced'>
|
|
NO_RECOMMENDATIONS = "1"
|
|
</literallayout>
|
|
You can set this variable globally in your
|
|
<filename>local.conf</filename> file or you can attach it to
|
|
a specific image recipe by using the recipe name override:
|
|
<literallayout class='monospaced'>
|
|
NO_RECOMMENDATIONS_pn-<target_image> = "<package_name>"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
It is important to realize that if you choose to not install
|
|
packages using this variable and some other packages are
|
|
dependent on them (i.e. listed in a recipe's
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
|
|
variable), the OpenEmbedded build system ignores your
|
|
request and will install the packages to avoid dependency
|
|
errors.
|
|
<note>
|
|
Some recommended packages might be required for certain
|
|
system functionality, such as kernel modules.
|
|
It is up to you to add packages with the
|
|
<link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
|
|
variable.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
Support for this variable exists only when using the
|
|
IPK and RPM packaging backend.
|
|
Support does not exist for DEB.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
|
|
and the
|
|
<link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
|
|
variables for related information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-NOHDD'><glossterm>NOHDD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Causes the OpenEmbedded build system to skip building the
|
|
<filename>.hddimg</filename> image.
|
|
The <filename>NOHDD</filename> variable is used with the
|
|
<link linkend='ref-classes-bootimg'><filename>buildimg</filename></link>
|
|
class.
|
|
Set the variable to "1" to prevent the
|
|
<filename>.hddimg</filename> image from being built.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-NOISO'><glossterm>NOISO</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Causes the OpenEmbedded build system to skip building the
|
|
ISO image.
|
|
The <filename>NOISO</filename> variable is used with the
|
|
<link linkend='ref-classes-bootimg'><filename>buildimg</filename></link>
|
|
class.
|
|
Set the variable to "1" to prevent the ISO image from
|
|
being built.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-o'><title>O</title>
|
|
|
|
<glossentry id='var-OE_BINCONFIG_EXTRA_MANGLE'><glossterm>OE_BINCONFIG_EXTRA_MANGLE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>binconfig.bbclass</filename> class, this variable
|
|
specifies additional arguments passed to the "sed" command.
|
|
The sed command alters any paths in configuration scripts
|
|
that have been set up during compilation.
|
|
Inheriting this class results in all paths in these scripts
|
|
being changed to point into the
|
|
<filename>sysroots/</filename> directory so that all builds
|
|
that use the script will use the correct directories
|
|
for the cross compiling layout.
|
|
</para>
|
|
|
|
<para>
|
|
See the <filename>meta/classes/binconfig.bbclass</filename>
|
|
in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
for details on how this class applies these additional
|
|
sed command arguments.
|
|
For general information on the
|
|
<filename>binconfig.bbclass</filename> class, see the
|
|
"<link linkend='ref-classes-binconfig'>Binary Configuration Scripts - <filename>binconfig.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-OE_IMPORTS'><glossterm>OE_IMPORTS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An internal variable used to tell the OpenEmbedded build
|
|
system what Python modules to import for every Python
|
|
function run by the system.
|
|
</para>
|
|
|
|
<note>
|
|
Do not set this variable.
|
|
It is for internal use only.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-OE_TERMINAL'><glossterm>OE_TERMINAL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Controls how the OpenEmbedded build system spawns
|
|
interactive terminals on the host development system
|
|
(e.g. using the BitBake command with the
|
|
<filename>-c devshell</filename> command-line option).
|
|
For more information, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
|
|
in the Yocto Project Development Manual.
|
|
</para>
|
|
|
|
<para>
|
|
You can use the following values for the
|
|
<filename>OE_TERMINAL</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
auto
|
|
gnome
|
|
xfce
|
|
rxvt
|
|
screen
|
|
konsole
|
|
none
|
|
</literallayout>
|
|
<note>Konsole support only works for KDE 3.x.
|
|
Also, "auto" is the default behavior for
|
|
<filename>OE_TERMINAL</filename></note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-OEROOT'><glossterm>OEROOT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The directory from which the top-level build environment
|
|
setup script is sourced.
|
|
The Yocto Project makes two top-level build environment
|
|
setup scripts available:
|
|
<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
|
|
and
|
|
<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>.
|
|
When you run one of these scripts, the
|
|
<filename>OEROOT</filename> variable resolves to the
|
|
directory that holds the script.
|
|
</para>
|
|
|
|
<para>
|
|
For additional information on how this variable is used,
|
|
see the initialization scripts.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-OLDEST_KERNEL'><glossterm>OLDEST_KERNEL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Declares the oldest version of the Linux kernel that the
|
|
produced binaries must support.
|
|
This variable is passed into the build of the Embedded
|
|
GNU C Library (<filename>eglibc</filename>).
|
|
</para>
|
|
|
|
<para>
|
|
The default for this variable comes from the
|
|
<filename>meta/conf/bitbake.conf</filename> configuration
|
|
file.
|
|
You can override this default by setting the variable
|
|
in a custom distribution configuration file.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
BitBake uses <filename>OVERRIDES</filename> to control
|
|
what variables are overridden after BitBake parses
|
|
recipes and configuration files.
|
|
You can find more information on how overrides are handled
|
|
in the BitBake Manual that is located at
|
|
<filename>bitbake/doc/manual</filename> in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-p'><title>P</title>
|
|
|
|
<glossentry id='var-P'><glossterm>P</glossterm>
|
|
<glossdef>
|
|
<para>The recipe name and version.
|
|
<filename>P</filename> is comprised of the following:
|
|
<literallayout class='monospaced'>
|
|
${PN}-${PV}
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>The architecture of the resulting package or packages.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_BEFORE_PN'><glossterm>PACKAGE_BEFORE_PN</glossterm>
|
|
<glossdef>
|
|
<para>Enables easily adding packages to
|
|
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
|
|
before <filename>${<link linkend='var-PN'>PN</link>}</filename>
|
|
so that those added packages can pick up files that would normally be
|
|
included in the default package.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<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 <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:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
|
|
</literallayout>
|
|
For information on build performance effects as a result of the
|
|
package manager use, see
|
|
<link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>
|
|
in this manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_EXCLUDE'><glossterm>PACKAGE_EXCLUDE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists packages that should not be installed into an image.
|
|
For example:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_EXCLUDE = "<package_name> <package_name> <package_name> ..."
|
|
</literallayout>
|
|
You can set this variable globally in your
|
|
<filename>local.conf</filename> file or you can attach it to
|
|
a specific image recipe by using the recipe name override:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_EXCLUDE_pn-<target_image> = "<package_name>"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
If you choose to not install
|
|
a package using this variable and some other package is
|
|
dependent on it (i.e. listed in a recipe's
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
|
|
variable), the OpenEmbedded build system generates a fatal
|
|
installation error.
|
|
Because the build system halts the process with a fatal
|
|
error, you can use the variable with an iterative
|
|
development process to remove specific components from a
|
|
system.
|
|
</para>
|
|
|
|
<para>
|
|
Support for this variable exists only when using the
|
|
IPK and RPM packaging backend.
|
|
Support does not exist for DEB.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
|
|
and the
|
|
<link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
|
|
variables for related information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_EXTRA_ARCHS'><glossterm>PACKAGE_EXTRA_ARCHS</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the list of architectures compatible with the device CPU.
|
|
This variable is useful when you build for several different devices that use
|
|
miscellaneous processors such as XScale and ARM926-EJS).</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_GROUP'><glossterm>PACKAGE_GROUP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines one or more packages to include in an image when
|
|
a specific item is included in
|
|
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
|
|
When setting the value, <filename>PACKAGE_GROUP</filename>
|
|
should have the name of the feature item as an override.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_GROUP_widget = "package1 package2"
|
|
</literallayout>
|
|
In this example, if "widget" were added to
|
|
<filename>IMAGE_FEATURES</filename>, "package1" and
|
|
"package2" would be included in the image.
|
|
<note>
|
|
Packages installed by features defined through
|
|
<filename>PACKAGE_GROUP</filename> are often package
|
|
groups.
|
|
While similarly named, you should not confuse the
|
|
<filename>PACKAGE_GROUP</filename> variable with
|
|
package groups, which are discussed elsewhere in the
|
|
documentation.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_INSTALL'><glossterm>PACKAGE_INSTALL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The final list of packages passed to the package manager
|
|
for installation into the image.
|
|
Because the package manager controls actual installation
|
|
of all packages, the list of packages passed using
|
|
<filename>PACKAGE_INSTALL</filename> is not the final list
|
|
of packages that are actually installed.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is internal to the image construction
|
|
code.
|
|
Use the
|
|
<link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
|
|
variable to specify packages for installation.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGECONFIG'><glossterm>PACKAGECONFIG</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable provides a means of enabling or disabling
|
|
features of a recipe on a per-recipe basis.
|
|
<filename>PACKAGECONFIG</filename> blocks are defined
|
|
in recipes when you specify features and then arguments
|
|
that define feature behaviors.
|
|
Here is the basic block structure:
|
|
<literallayout class='monospaced'>
|
|
PACKAGECONFIG ??= "f1 f2 f3 ..."
|
|
PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
|
|
PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
|
|
PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
|
|
</literallayout>
|
|
The <filename>PACKAGECONFIG</filename>
|
|
variable itself specifies a space-separated list of the
|
|
features to enable.
|
|
Following the features, you can determine the behavior of
|
|
each feature by providing up to four order-dependent
|
|
arguments, which are separated by commas.
|
|
You can omit any argument you like but must retain the
|
|
separating commas.
|
|
The order is important and specifies the following:
|
|
<orderedlist>
|
|
<listitem><para>Extra arguments
|
|
that should be added to the configure script
|
|
argument list
|
|
(<link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>)
|
|
if the feature is enabled.</para></listitem>
|
|
<listitem><para>Extra arguments
|
|
that should be added to <filename>EXTRA_OECONF</filename>
|
|
if the feature is disabled.
|
|
</para></listitem>
|
|
<listitem><para>Additional build dependencies
|
|
(<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>)
|
|
that should be added if the feature is enabled.
|
|
</para></listitem>
|
|
<listitem><para>Additional runtime dependencies
|
|
(<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
|
|
that should be added if the feature is enabled.
|
|
</para></listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<para>
|
|
Consider the following
|
|
<filename>PACKAGECONFIG</filename> block taken from the
|
|
<filename>librsvg</filename> recipe.
|
|
In this example the feature is <filename>croco</filename>,
|
|
which has three arguments that determine the feature's
|
|
behavior.
|
|
<literallayout class='monospaced'>
|
|
PACKAGECONFIG ??= "croco"
|
|
PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
|
|
</literallayout>
|
|
The <filename>--with-croco</filename> and
|
|
<filename>libcroco</filename> arguments apply only if
|
|
the feature is enabled.
|
|
In this case, <filename>--with-croco</filename> is
|
|
added to the configure script argument list and
|
|
<filename>libcroco</filename> is added to
|
|
<filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
|
|
On the other hand, if the feature is disabled say through
|
|
a <filename>.bbappend</filename> file in another layer, then
|
|
the second argument <filename>--without-croco</filename> is
|
|
added to the configure script rather than
|
|
<filename>--with-croco</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
The basic <filename>PACKAGECONFIG</filename> structure
|
|
previously described holds true regardless of whether you
|
|
are creating a block or changing a block.
|
|
When creating a block, use the structure inside your
|
|
recipe.
|
|
</para>
|
|
|
|
<para>
|
|
If you want to change an existing
|
|
<filename>PACKAGECONFIG</filename> block, you can do so
|
|
one of two ways:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis>Append file:</emphasis>
|
|
Create an append file named
|
|
<filename><recipename>.bbappend</filename> in your
|
|
layer and override the value of
|
|
<filename>PACKAGECONFIG</filename>.
|
|
You can either completely override the variable:
|
|
<literallayout class='monospaced'>
|
|
PACKAGECONFIG="f4 f5"
|
|
</literallayout>
|
|
Or, you can just append the variable:
|
|
<literallayout class='monospaced'>
|
|
PACKAGECONFIG_append = " f4"
|
|
</literallayout></para></listitem>
|
|
<listitem><para><emphasis>Configuration file:</emphasis>
|
|
This method is identical to changing the block
|
|
through an append file except you edit your
|
|
<filename>local.conf</filename> or
|
|
<filename><mydistro>.conf</filename> file.
|
|
As with append files previously described,
|
|
you can either completely override the variable:
|
|
<literallayout class='monospaced'>
|
|
PACKAGECONFIG_pn-<recipename>="f4 f5"
|
|
</literallayout>
|
|
Or, you can just amend the variable:
|
|
<literallayout class='monospaced'>
|
|
PACKAGECONFIG_append_pn-<recipename> = " f4"
|
|
</literallayout></para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>The list of packages to be created from the recipe.
|
|
The default value is the following:
|
|
<literallayout class='monospaced'>
|
|
${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A promise that your recipe satisfies runtime dependencies
|
|
for optional modules that are found in other recipes.
|
|
<filename>PACKAGES_DYNAMIC</filename>
|
|
does not actually satisfy the dependencies, it only states that
|
|
they should be satisfied.
|
|
For example, if a hard, runtime dependency
|
|
(<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
|
|
of another package is satisfied
|
|
at build time through the <filename>PACKAGES_DYNAMIC</filename>
|
|
variable, but a package with the module name is never actually
|
|
produced, then the other package will be broken.
|
|
Thus, if you attempt to include that package in an image,
|
|
you will get a dependency failure from the packaging system
|
|
during <filename>do_rootfs</filename>.
|
|
</para>
|
|
<para>
|
|
Typically, if there is a chance that such a situation can
|
|
occur and the package that is not created is valid
|
|
without the dependency being satisfied, then you should use
|
|
<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
|
|
(a soft runtime dependency) instead of
|
|
<filename>RDEPENDS</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
For an example of how to use the <filename>PACKAGES_DYNAMIC</filename>
|
|
variable when you are splitting packages, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging'>Handling Optional Module Packaging</ulink>" section
|
|
in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PARALLEL_MAKE'><glossterm>PARALLEL_MAKE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Extra options that are passed to the
|
|
<filename>make</filename> command during the
|
|
<filename>do_compile</filename> task in order to specify
|
|
parallel compilation.
|
|
This variable is usually in the form
|
|
<filename>-j 4</filename>, where the number
|
|
represents the maximum number of parallel threads make can
|
|
run.
|
|
If you development host supports multiple cores a good
|
|
rule of thumb is to set this variable to twice the number
|
|
of cores on the host.
|
|
<note>
|
|
Individual recipes might clear out this variable if
|
|
the software being built has problems running its
|
|
<filename>make</filename> process in parallel.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PARALLEL_MAKEINST'><glossterm>PARALLEL_MAKEINST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Extra options passed to the
|
|
<filename>make install</filename> command during the
|
|
<filename>do_install</filename> task in order to specify
|
|
parallel installation.
|
|
This variable defaults to the value of
|
|
<link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>.
|
|
<note>
|
|
Individual recipes might clear out this variable if
|
|
the software being built has problems running its
|
|
<filename>make install</filename> process in parallel.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PATCHRESOLVE'><glossterm>PATCHRESOLVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Determines the action to take when a patch fails.
|
|
You can set this variable to one of two values: "noop" and
|
|
"user".
|
|
</para>
|
|
|
|
<para>
|
|
The default value of "noop" causes the build to simply fail
|
|
when the OpenEmbedded build system cannot successfully
|
|
apply a patch.
|
|
Setting the value to "user" causes the build system to
|
|
launch a shell and places you in the right location so that
|
|
you can manually resolve the conflicts.
|
|
</para>
|
|
|
|
<para>
|
|
Set this variable in your
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PATCHTOOL'><glossterm>PATCHTOOL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the utility used to apply patches for a recipe
|
|
during <filename>do_patch</filename>.
|
|
You can specify one of three utilities: "patch", "quilt", or
|
|
"git".
|
|
The default utility used is "quilt" except for the
|
|
quilt-native recipe itself.
|
|
Because the quilt tool is not available at the
|
|
time quilt-native is being patched, it uses "patch".
|
|
</para>
|
|
|
|
<para>
|
|
If you wish to use an alternative patching tool, set the
|
|
variable in the recipe using one of the following:
|
|
<literallayout class='monospaced'>
|
|
PATCHTOOL = "patch"
|
|
PATCHTOOL = "quilt"
|
|
PATCHTOOL = "git"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PE'><glossterm>PE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
the epoch of the recipe.
|
|
By default, this variable is unset.
|
|
The field is used to make upgrades possible when the
|
|
versioning scheme changes in some backwards incompatible
|
|
way.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PF'><glossterm>PF</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the recipe or package name and includes all version and revision
|
|
numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
|
|
<filename>bash-4.2-r1/</filename>).
|
|
This variable is comprised of the following:
|
|
<literallayout class='monospaced'>
|
|
${<link linkend='var-PN'>PN</link>}-${<link linkend='var-EXTENDPE'>EXTENDPE</link>}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKGD'><glossterm>PKGD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the destination directory for files to be
|
|
packaged before they are split into individual packages.
|
|
This directory defaults to the following:
|
|
<literallayout class='monospaced'>
|
|
${WORKDIR}/package
|
|
</literallayout>
|
|
Do not change this default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKGDATA_DIR'><glossterm>PKGDATA_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to a shared, global-state directory that holds data
|
|
generated during the packaging process.
|
|
During the packaging process, the
|
|
<filename>do_packagedata</filename> task packages
|
|
data for each recipe and installs it into this temporary,
|
|
shared area.
|
|
This directory defaults to the following:
|
|
<literallayout class='monospaced'>
|
|
${STAGING_DIR_HOST}/pkgdata
|
|
</literallayout>
|
|
Do not change this default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKGDEST'><glossterm>PKGDEST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the parent directory for files to be packaged
|
|
after they have been split into individual packages.
|
|
This directory defaults to the following:
|
|
<literallayout class='monospaced'>
|
|
${WORKDIR}/packages-split
|
|
</literallayout>
|
|
Under this directory, the build system creates
|
|
directories for each package specified in
|
|
<link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
|
|
Do not change this default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKGDESTWORK'><glossterm>PKGDESTWORK</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to a temporary work area used by the
|
|
<filename>do_package</filename> task to write output
|
|
from the <filename>do_packagedata</filename> task.
|
|
The <filename>PKGDESTWORK</filename> location defaults to
|
|
the following:
|
|
<literallayout class='monospaced'>
|
|
${WORKDIR}/pkgdata
|
|
</literallayout>
|
|
The <filename>do_packagedata</filename> task then packages
|
|
the data in the temporary work area and installs it into a
|
|
shared directory pointed to by
|
|
<link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
Do not change this default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PN'><glossterm>PN</glossterm>
|
|
<glossdef>
|
|
<para>This variable can have two separate functions depending on the context: a recipe
|
|
name or a resulting package name.</para>
|
|
<para><filename>PN</filename> refers to a recipe name in the context of a file used
|
|
by the OpenEmbedded build system as input to create a package.
|
|
The name is normally extracted from the recipe file name.
|
|
For example, if the recipe is named
|
|
<filename>expat_2.0.1.bb</filename>, then the default value of <filename>PN</filename>
|
|
will be "expat".</para>
|
|
<para>
|
|
The variable refers to a package name in the context of a file created or produced by the
|
|
OpenEmbedded build system.</para>
|
|
<para>If applicable, the <filename>PN</filename> variable also contains any special
|
|
suffix or prefix.
|
|
For example, using <filename>bash</filename> to build packages for the native
|
|
machine, <filename>PN</filename> is <filename>bash-native</filename>.
|
|
Using <filename>bash</filename> to build packages for the target and for Multilib,
|
|
<filename>PN</filename> would be <filename>bash</filename> and
|
|
<filename>lib64-bash</filename>, respectively.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PNBLACKLIST'><glossterm>PNBLACKLIST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists recipes you do not want the OpenEmbedded build system
|
|
to build.
|
|
This variable works in conjunction with the
|
|
<link linkend='ref-classes-blacklist'><filename>blacklist</filename></link>
|
|
class, which the recipe must inherit globally.
|
|
</para>
|
|
|
|
<para>
|
|
To prevent a recipe from being built, inherit the class
|
|
globally and use the variable in your
|
|
<filename>local.conf</filename> file.
|
|
Here is an example that prevents
|
|
<filename>myrecipe</filename> from being built:
|
|
<literallayout class='monospaced'>
|
|
INHERIT += "blacklist"
|
|
PNBLACKLIST[myrecipe] = "Not supported by our organization."
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PR'><glossterm>PR</glossterm>
|
|
<glossdef>
|
|
<para>The revision of the recipe.
|
|
The default value for this variable is "r0".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If multiple recipes provide an item, this variable
|
|
determines which recipe should be given preference.
|
|
You should always suffix the variable with the name of the
|
|
provided item, and you should set it to the
|
|
<link linkend='var-PN'><filename>PN</filename></link>
|
|
of the recipe to which you want to give precedence.
|
|
Some examples:
|
|
<literallayout class='monospaced'>
|
|
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
|
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
|
|
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If there are multiple versions of recipes available, this
|
|
variable determines which recipe should be given preference.
|
|
You must always suffix the variable with the
|
|
<link linkend='var-PN'><filename>PN</filename></link>
|
|
you want to select, and you should set the
|
|
<link linkend='var-PV'><filename>PV</filename></link>
|
|
accordingly for precedence.
|
|
You can use the "<filename>%</filename>" character as a
|
|
wildcard to match any number of characters, which can be
|
|
useful when specifying versions that contain long revision
|
|
numbers that could potentially change.
|
|
Here are two examples:
|
|
<literallayout class='monospaced'>
|
|
PREFERRED_VERSION_python = "2.7.3"
|
|
PREFERRED_VERSION_linux-yocto = "3.10%"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies additional paths from which the OpenEmbedded
|
|
build system gets source code.
|
|
When the build system searches for source code, it first
|
|
tries the local download directory.
|
|
If that location fails, the build system tries locations
|
|
defined by <filename>PREMIRRORS</filename>, the upstream
|
|
source, and then locations specified by
|
|
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
|
|
in that order.
|
|
</para>
|
|
|
|
<para>
|
|
Assuming your distribution
|
|
(<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
|
|
is "poky", the default value for
|
|
<filename>PREMIRRORS</filename> is defined in the
|
|
<filename>conf/distro/poky.conf</filename> file in the
|
|
<filename>meta-yocto</filename> Git repository.
|
|
</para>
|
|
|
|
<para>
|
|
Typically, you could add a specific server for the
|
|
build system to attempt before any others by adding
|
|
something like the following to the
|
|
<filename>local.conf</filename> configuration file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
|
|
<literallayout class='monospaced'>
|
|
PREMIRRORS_prepend = "\
|
|
git://.*/.* http://www.yoctoproject.org/sources/ \n \
|
|
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
|
|
http://.*/.* http://www.yoctoproject.org/sources/ \n \
|
|
https://.*/.* http://www.yoctoproject.org/sources/ \n"
|
|
</literallayout>
|
|
These changes cause the build system to intercept
|
|
Git, FTP, HTTP, and HTTPS requests and direct them to
|
|
the <filename>http://</filename> sources mirror.
|
|
You can use <filename>file://</filename> URLs to point
|
|
to local directories or network shares as well.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PRINC'><glossterm>PRINC</glossterm>
|
|
<glossdef>
|
|
<para>Causes the <link linkend='var-PR'><filename>PR</filename></link>
|
|
variable of <filename>.bbappend</filename> files to
|
|
dynamically increment.
|
|
This increment minimizes the impact of layer ordering.</para>
|
|
<para>In order to ensure multiple <filename>.bbappend</filename> files can co-exist,
|
|
<filename>PRINC</filename> should be self-referencing.
|
|
This variable defaults to 0.</para>
|
|
<para>Following is an example that increments <filename>PR</filename> by two:
|
|
<literallayout class='monospaced'>
|
|
PRINC := "${@int(PRINC) + 2}"
|
|
</literallayout>
|
|
It is advisable not to use strings such as ".= '.1'" with the variable because
|
|
this usage is very sensitive to layer ordering.
|
|
You should avoid explicit assignments as they cannot
|
|
adequately represent multiple
|
|
<filename>.bbappend</filename> files.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of aliases that a recipe also provides.
|
|
These aliases are useful for satisfying dependencies of
|
|
other recipes during the build (as specified by
|
|
<filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
|
|
<note>
|
|
A recipe's own
|
|
<filename><link linkend='var-PN'>PN</link></filename>
|
|
is implicitly already in its
|
|
<filename>PROVIDES</filename> list.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PV'><glossterm>PV</glossterm>
|
|
<glossdef>
|
|
<para>The version of the recipe.
|
|
The version is normally extracted from the recipe filename.
|
|
For example, if the recipe is named
|
|
<filename>expat_2.0.1.bb</filename>, then the default value of <filename>PV</filename>
|
|
will be "2.0.1".
|
|
<filename>PV</filename> is generally not overridden within
|
|
a recipe unless it is building an unstable (i.e. development) version from a source code repository
|
|
(e.g. Git or Subversion).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-q'><title>Q</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<glossdiv id='var-glossary-r'><title>R</title>
|
|
|
|
<glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of packages that conflict with packages.
|
|
Note that packages will not be installed if conflicting
|
|
packages are not first removed.
|
|
</para>
|
|
|
|
<para>
|
|
Like all package-controlling variables, you must always use
|
|
them in conjunction with a package name override.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
RCONFLICTS_${PN} = "another-conflicting-package-name"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
BitBake, which the OpenEmbedded build system uses, supports
|
|
specifying versioned dependencies.
|
|
Although the syntax varies depending on the packaging
|
|
format, BitBake hides these differences from you.
|
|
Here is the general syntax to specify versions with
|
|
the <filename>RCONFLICTS</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
RCONFLICTS_${PN} = "<package> (<operator> <version>)"
|
|
</literallayout>
|
|
For <filename>operator</filename>, you can specify the
|
|
following:
|
|
<literallayout class='monospaced'>
|
|
=
|
|
<
|
|
>
|
|
<=
|
|
>=
|
|
</literallayout>
|
|
For example, the following sets up a dependency on version
|
|
1.2 or greater of the package <filename>foo</filename>:
|
|
<literallayout class='monospaced'>
|
|
RCONFLICTS_${PN} = "foo (>= 1.2)"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists a package's runtime dependencies (i.e. other packages)
|
|
that must be installed in order for the built package to run
|
|
correctly.
|
|
If a package in this list cannot be found during the build,
|
|
you will get a build error.
|
|
</para>
|
|
|
|
<para>
|
|
When you use the <filename>RDEPENDS</filename> variable
|
|
in a recipe, you are essentially stating that the recipe's
|
|
<filename>do_build</filename> task depends on the existence
|
|
of a specific package.
|
|
Consider this simple example for two recipes named "a" and
|
|
"b" that produce similarly named packages.
|
|
In this example, the <filename>RDEPENDS</filename>
|
|
statement appears in the "a" recipe:
|
|
<literallayout class='monospaced'>
|
|
RDEPENDS_${PN} = "b"
|
|
</literallayout>
|
|
Here, the dependency is such that the
|
|
<filename>do_build</filename> task for recipe "a" depends
|
|
on the <filename>do_package_write</filename> task
|
|
of recipe "b".
|
|
This means the package file for "b" must be available when
|
|
the output for recipe "a" has been completely built.
|
|
More importantly, package "a" will be marked as depending
|
|
on package "b" in a manner that is understood by the
|
|
package manager in use (i.e. rpm, opkg, or dpkg).
|
|
</para>
|
|
|
|
<para>
|
|
The names of the packages you list within
|
|
<filename>RDEPENDS</filename> must be the names of other
|
|
packages - they cannot be recipe names.
|
|
Although package names and recipe names usually match,
|
|
the important point here is that you are
|
|
providing package names within the
|
|
<filename>RDEPENDS</filename> variable.
|
|
For an example of the default list of packages created from
|
|
a recipe, see the
|
|
<link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
Because the <filename>RDEPENDS</filename> variable applies
|
|
to packages being built, you should always use the variable
|
|
in a form with an attached package name.
|
|
For example, suppose you are building a development package
|
|
that depends on the <filename>perl</filename> package.
|
|
In this case, you would use the following
|
|
<filename>RDEPENDS</filename> statement:
|
|
<literallayout class='monospaced'>
|
|
RDEPENDS_${PN}-dev += "perl"
|
|
</literallayout>
|
|
In the example, the development package depends on
|
|
the <filename>perl</filename> package.
|
|
Thus, the <filename>RDEPENDS</filename> variable has the
|
|
<filename>${PN}-dev</filename> package name as part of the
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
The package name you attach to the
|
|
<filename>RDEPENDS</filename> variable must appear
|
|
as it would in the <filename>PACKAGES</filename>
|
|
namespace before any renaming of the output package by
|
|
classes like <filename>debian.bbclass</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
In many cases you do not need to explicitly add
|
|
runtime dependencies using
|
|
<filename>RDEPENDS</filename> since some automatic
|
|
handling occurs:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>shlibdeps</filename></emphasis>: If
|
|
a runtime package contains a shared library
|
|
(<filename>.so</filename>), the build
|
|
processes the library in order to determine other
|
|
libraries to which it is dynamically linked.
|
|
The build process adds these libraries to
|
|
<filename>RDEPENDS</filename> when creating the runtime
|
|
package.</para></listitem>
|
|
<listitem><para><emphasis><filename>pcdeps</filename></emphasis>: If
|
|
the package ships a <filename>pkg-config</filename>
|
|
information file, the build process uses this file
|
|
to add items to the <filename>RDEPENDS</filename>
|
|
variable to create the runtime packages.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
BitBake, which the OpenEmbedded build system uses, supports
|
|
specifying versioned dependencies.
|
|
Although the syntax varies depending on the packaging
|
|
format, BitBake hides these differences from you.
|
|
Here is the general syntax to specify versions with
|
|
the <filename>RDEPENDS</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
RDEPENDS_${PN} = "<package> (<operator> <version>)"
|
|
</literallayout>
|
|
For <filename>operator</filename>, you can specify the
|
|
following:
|
|
<literallayout class='monospaced'>
|
|
=
|
|
<
|
|
>
|
|
<=
|
|
>=
|
|
</literallayout>
|
|
For example, the following sets up a dependency on version
|
|
1.2 or greater of the package <filename>foo</filename>:
|
|
<literallayout class='monospaced'>
|
|
RDEPENDS_${PN} = "foo (>= 1.2)"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For information on build-time dependencies, see the
|
|
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-REQUIRED_DISTRO_FEATURES'><glossterm>REQUIRED_DISTRO_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>distro_features_check</filename> class, this
|
|
variable identifies distribution features that must
|
|
exist in the current configuration in order for the
|
|
OpenEmbedded build system to build the recipe.
|
|
In other words, if the
|
|
<filename>REQUIRED_DISTRO_FEATURES</filename> variable
|
|
lists a feature that does not appear in
|
|
<filename>DISTRO_FEATURES</filename> within the
|
|
current configuration, an error occurs and the
|
|
build stops.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RM_OLD_IMAGE'><glossterm>RM_OLD_IMAGE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Reclaims disk space by removing previously built
|
|
versions of the same image from the
|
|
<filename>images</filename> directory pointed to by the
|
|
<link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
Set this variable to "1" in your
|
|
<filename>local.conf</filename> file to remove these
|
|
images.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RM_WORK_EXCLUDE'><glossterm>RM_WORK_EXCLUDE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
With <filename>rm_work</filename> enabled, this
|
|
variable specifies a list of recipes whose work directories
|
|
should not be removed.
|
|
See the "<link linkend='ref-classes-rm-work'>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></link>"
|
|
section for more details.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ROOTFS'><glossterm>ROOTFS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Indicates a filesystem image to include as the root
|
|
filesystem.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>ROOTFS</filename> variable is an optional
|
|
variable used with the
|
|
<link linkend='ref-classes-bootimg'><filename>buildimg</filename></link>
|
|
class.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ROOTFS_POSTPROCESS_COMMAND'><glossterm>ROOTFS_POSTPROCESS_COMMAND</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Added by classes to run post processing commands once the
|
|
OpenEmbedded build system has created the root filesystem.
|
|
You can specify shell commands separated by semicolons:
|
|
<literallayout class='monospaced'>
|
|
ROOTFS_POSTPROCESS_COMMAND += "<shell_command>; ... "
|
|
</literallayout>
|
|
If you need to pass the path to the root filesystem within
|
|
the command, you can use
|
|
<filename>${IMAGE_ROOTFS}</filename>, which points to
|
|
the root filesystem image.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of package name aliases that a package also provides.
|
|
These aliases are useful for satisfying runtime dependencies
|
|
of other packages both during the build and on the target
|
|
(as specified by
|
|
<filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
|
|
<note>
|
|
A package's own name is implicitly already in its
|
|
<filename>RPROVIDES</filename> list.
|
|
</note>
|
|
</para>
|
|
<para>
|
|
As with all package-controlling variables, you must always
|
|
use the variable in conjunction with a package name override.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
RPROVIDES_${PN} = "widget-abi-2"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of packages that extends the usability of a package
|
|
being built.
|
|
The package being built does not depend on this list of
|
|
packages in order to successfully build, but needs them for
|
|
the extended usability.
|
|
To specify runtime dependencies for packages, see the
|
|
<filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
The OpenEmbedded build process automatically installs the
|
|
list of packages as part of the built package.
|
|
However, you can remove these packages later if you want.
|
|
If, during the build, a package from the
|
|
<filename>RRECOMMENDS</filename> list cannot be
|
|
found, the build process continues without an error.
|
|
</para>
|
|
|
|
<para>
|
|
You can also prevent packages in the list from being
|
|
installed by using several variables.
|
|
See the
|
|
<link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>,
|
|
<link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>,
|
|
and
|
|
<link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
|
|
variables for more information.
|
|
</para>
|
|
|
|
<para>
|
|
Because the <filename>RRECOMMENDS</filename> variable
|
|
applies to packages being built, you should always attach
|
|
an override to the variable to specify the particular
|
|
package whose usability is being extended.
|
|
For example, suppose you are building a development package
|
|
that is extended to support wireless functionality.
|
|
In this case, you would use the following:
|
|
<literallayout class='monospaced'>
|
|
RRECOMMENDS_${PN}-dev += "<wireless_package_name>"
|
|
</literallayout>
|
|
In the example, the package name
|
|
(<filename>${<link linkend='var-PN'>PN</link>}-dev</filename>)
|
|
must appear as it would in the
|
|
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
|
|
namespace before any renaming of the output package by
|
|
classes such as <filename>debian.bbclass</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
BitBake, which the OpenEmbedded build system uses, supports
|
|
specifying versioned recommends.
|
|
Although the syntax varies depending on the packaging
|
|
format, BitBake hides these differences from you.
|
|
Here is the general syntax to specify versions with
|
|
the <filename>RRECOMMENDS</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
RRECOMMENDS_${PN} = "<package> (<operator> <version>)"
|
|
</literallayout>
|
|
For <filename>operator</filename>, you can specify the
|
|
following:
|
|
<literallayout class='monospaced'>
|
|
=
|
|
<
|
|
>
|
|
<=
|
|
>=
|
|
</literallayout>
|
|
For example, the following sets up a recommend on version
|
|
1.2 or greater of the package <filename>foo</filename>:
|
|
<literallayout class='monospaced'>
|
|
RRECOMMENDS_${PN} = "foo (>= 1.2)"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of packages replaced by a package.
|
|
The package manager uses this variable to determine which
|
|
package should be installed to replace other package(s)
|
|
during an upgrade.
|
|
In order to also have the other package(s) removed at the
|
|
same time, you must add the name of the other
|
|
package to the
|
|
<filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link></filename> variable.
|
|
</para>
|
|
<para>
|
|
As with all package-controlling variables, you must use
|
|
this variable in conjunction with a package name
|
|
override.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
RREPLACES_${PN} = "other-package-being-replaced"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
BitBake, which the OpenEmbedded build system uses, supports
|
|
specifying versioned replacements.
|
|
Although the syntax varies depending on the packaging
|
|
format, BitBake hides these differences from you.
|
|
Here is the general syntax to specify versions with
|
|
the <filename>RREPLACES</filename> variable:
|
|
<literallayout class='monospaced'>
|
|
RREPLACES_${PN} = "<package> (<operator> <version>)"
|
|
</literallayout>
|
|
For <filename>operator</filename>, you can specify the
|
|
following:
|
|
<literallayout class='monospaced'>
|
|
=
|
|
<
|
|
>
|
|
<=
|
|
>=
|
|
</literallayout>
|
|
For example, the following sets up a replacement using
|
|
version 1.2 or greater of the package
|
|
<filename>foo</filename>:
|
|
<literallayout class='monospaced'>
|
|
RREPLACES_${PN} = "foo (>= 1.2)"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RSUGGESTS'><glossterm>RSUGGESTS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of additional packages that you can suggest for
|
|
installation by the package manager at the time a package
|
|
is installed.
|
|
Not all package managers support this functionality.
|
|
</para>
|
|
<para>
|
|
As with all package-controlling variables, you must always
|
|
use this variable in conjunction with a package name
|
|
override.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
RSUGGESTS_${PN} = "useful-package another-package"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-s'><title>S</title>
|
|
|
|
<glossentry id='var-S'><glossterm>S</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
where unpacked recipe source code resides.
|
|
This location is within the work directory
|
|
(<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>),
|
|
which is not static.
|
|
The unpacked source location depends on the recipe name
|
|
(<filename><link linkend='var-PN'>PN</link></filename>) and
|
|
recipe version
|
|
(<filename><link linkend='var-PV'>PV</link></filename>) as
|
|
follows:
|
|
<literallayout class='monospaced'>
|
|
${WORKDIR}/${PN}-${PV}
|
|
</literallayout>
|
|
As an example, assume a
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
top-level folder named <filename>poky</filename> and a
|
|
default Build Directory at <filename>poky/build</filename>.
|
|
In this case, the work directory the build system uses
|
|
to keep the unpacked recipe for <filename>db</filename>
|
|
is the following:
|
|
<literallayout class='monospaced'>
|
|
poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of the host distribution identifiers that the
|
|
build system has been tested against.
|
|
Identifiers consist of the host distributor ID
|
|
followed by the release,
|
|
as reported by the <filename>lsb_release</filename> tool
|
|
or as read from <filename>/etc/lsb-release</filename>.
|
|
Separate the list items with explicit newline
|
|
characters (<filename>\n</filename>).
|
|
If <filename>SANITY_TESTED_DISTROS</filename> is not empty
|
|
and the current value of
|
|
<link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
|
|
does not appear in the list, then the build system reports
|
|
a warning that indicates the current host distribution has
|
|
not been tested as a build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDK_ARCH'><glossterm>SDK_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The target architecture for the SDK.
|
|
Typically, you do not directly set this variable.
|
|
Instead, use
|
|
<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDK_NAME'><glossterm>SDK_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The base name for SDK output files.
|
|
The name is derived from the
|
|
<link linkend='var-DISTRO'><filename>DISTRO</filename></link>,
|
|
<link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>,
|
|
<link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
|
|
<link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>,
|
|
and
|
|
<link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
|
|
variables:
|
|
<literallayout class='monospaced'>
|
|
SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>Equivalent to
|
|
<filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>.
|
|
However, this variable applies to the SDK generated from an
|
|
image using the following command:
|
|
<literallayout class='monospaced'>
|
|
$ bitbake -c populate_sdk imagename
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDKMACHINE'><glossterm>SDKMACHINE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The architecture of the machine that runs Application
|
|
Development Toolkit (ADT) items.
|
|
In other words, packages are built so that they will run
|
|
on the target you specify with the argument.
|
|
This implies that you can build out ADT/SDK items that
|
|
run on an architecture other than that of your build host.
|
|
For example, you can use an x86_64-based build host to
|
|
create packages that will run on an i686-based
|
|
SDK Machine.
|
|
</para>
|
|
|
|
<para>
|
|
You can use "i686" and "x86_64" as possible values for this
|
|
variable.
|
|
The variable defaults to "i686" and is set in the
|
|
<filename>local.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
<literallayout class='monospaced'>
|
|
SDKMACHINE ?= "i686"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
|
|
<glossdef>
|
|
<para>The section in which packages should be categorized.
|
|
Package management utilities can make use of this variable.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SELECTED_OPTIMIZATION'><glossterm>SELECTED_OPTIMIZATION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The variable takes the value of
|
|
<filename><link linkend='var-FULL_OPTIMIZATION'>FULL_OPTIMIZATION</link></filename>
|
|
unless <filename><link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></filename> = "1".
|
|
In this case the value of
|
|
<filename><link linkend='var-DEBUG_OPTIMIZATION'>DEBUG_OPTIMIZATION</link></filename> is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines a serial console (TTY) to enable using getty.
|
|
Provide a value that specifies the baud rate followed by
|
|
the TTY device name separated by a space.
|
|
You cannot specify more than one TTY device:
|
|
<literallayout class='monospaced'>
|
|
SERIAL_CONSOLE = "115200 ttyS0"
|
|
</literallayout>
|
|
<note>
|
|
The <filename>SERIAL_CONSOLE</filename> variable
|
|
is deprecated.
|
|
Please use the
|
|
<link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
|
|
variable.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SERIAL_CONSOLES'><glossterm>SERIAL_CONSOLES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the serial consoles (TTYs) to enable using getty.
|
|
Provide a value that specifies the baud rate followed by
|
|
the TTY device name separated by a semicolon.
|
|
Use spaces to separate multiple devices:
|
|
<literallayout class='monospaced'>
|
|
SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SERIAL_CONSOLES_CHECK'><glossterm>SERIAL_CONSOLES_CHECK</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Similar to
|
|
<link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
|
|
except the device is checked for existence before attempting
|
|
to enable it.
|
|
This variable is currently only supported with SysVinit
|
|
(i.e. not with systemd).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS'><glossterm>SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of recipe dependencies that should not be used to
|
|
determine signatures of tasks from one recipe when they
|
|
depend on tasks from another recipe.
|
|
For example:
|
|
<literallayout class='monospaced'>
|
|
SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
|
|
</literallayout>
|
|
In this example, <filename>intone</filename> depends on
|
|
<filename>mplayer2</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
Use of this variable is one mechanism to remove dependencies
|
|
that affect task signatures and thus force rebuilds when a
|
|
recipe changes.
|
|
<note><title>Caution</title>
|
|
If you add an inappropriate dependency for a recipe
|
|
relationship, the software might break during
|
|
runtime if the interface of the second recipe was
|
|
changed after the first recipe had been built.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of recipes that are completely stable and will
|
|
never change.
|
|
The ABI for the recipes in the list are presented by
|
|
output from the tasks run to build the recipe.
|
|
Use of this variable is one way to remove dependencies from
|
|
one recipe on another that affect task signatures and
|
|
thus force rebuilds when the recipe changes.
|
|
<note><title>Caution</title>
|
|
If you add an inappropriate variable to this list,
|
|
the software might break at runtime if the
|
|
interface of the recipe was changed after the other
|
|
had been built.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SITEINFO_BITS'><glossterm>SITEINFO_BITS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the number of bits for the target system CPU.
|
|
The value should be either "32" or "64".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SITEINFO_ENDIANNESS'><glossterm>SITEINFO_ENDIANNESS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the endian byte order of the target system.
|
|
The value should be either "le" for little-endian or "be" for big-endian.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Groups together machines based upon the same family
|
|
of SOC (System On Chip).
|
|
You typically set this variable in a common
|
|
<filename>.inc</filename> file that you include in the
|
|
configuration files of all the machines.
|
|
<note>
|
|
You must include
|
|
<filename>conf/machine/include/soc-family.inc</filename>
|
|
for this variable to appear in
|
|
<link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SOLIBS'><glossterm>SOLIBS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the suffix for shared libraries used on the
|
|
target platform.
|
|
By default, this suffix is ".so.*" for all Linux-based
|
|
systems and is defined in the
|
|
<filename>meta/conf/bitbake.conf</filename> configuration
|
|
file.
|
|
</para>
|
|
|
|
<para>
|
|
You will see this variable referenced in the default values
|
|
of <filename>FILES_${PN}</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SOLIBSDEV'><glossterm>SOLIBSDEV</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the suffix for the development symbolic link
|
|
(symlink) for shared libraries on the target platform.
|
|
By default, this suffix is ".so" for Linux-based
|
|
systems and is defined in the
|
|
<filename>meta/conf/bitbake.conf</filename> configuration
|
|
file.
|
|
</para>
|
|
|
|
<para>
|
|
You will see this variable referenced in the default values
|
|
of <filename>FILES_${PN}-dev</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SOURCE_MIRROR_URL'><glossterm>SOURCE_MIRROR_URL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines your own
|
|
<link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
|
|
from which to first fetch source before attempting to fetch
|
|
from the upstream specified in
|
|
<link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
To use this variable, you must globally inherit the
|
|
<link linkend='ref-classes-ownmirrors'><filename>ownmirrors</filename></link>
|
|
class and then provide the URL to your mirrors.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
INHERIT += "own-mirrors"
|
|
SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
|
|
</literallayout>
|
|
<note>
|
|
You can specify only a single URL in
|
|
<filename>SOURCE_MIRROR_URL</filename>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of prefixes for <link linkend='var-PN'><filename>PN</filename></link> used by the
|
|
OpenEmbedded build system to create variants of recipes or packages.
|
|
The list specifies the prefixes to strip off during certain circumstances
|
|
such as the generation of the <link linkend='var-BPN'><filename>BPN</filename></link> variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
|
|
<glossdef>
|
|
<para>The list of source files - local or remote.
|
|
This variable tells the OpenEmbedded build system which bits
|
|
to pull in for the build and how to pull them in.
|
|
For example, if the recipe or append file only needs to
|
|
fetch a tarball from the Internet, the recipe or
|
|
append file uses a single <filename>SRC_URI</filename>
|
|
entry.
|
|
On the other hand, if the recipe or append file needs to
|
|
fetch a tarball, apply two patches, and include a custom
|
|
file, the recipe or append file would include four
|
|
instances of the variable.</para>
|
|
<para>The following list explains the available URI protocols:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>file://</filename> -</emphasis>
|
|
Fetches files, which are usually files shipped with
|
|
the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
|
|
from the local machine.
|
|
The path is relative to the
|
|
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
|
|
variable.
|
|
Thus, the build system searches, in order, from the
|
|
following directories, which are assumed to be a
|
|
subdirectories of the directory in which the
|
|
recipe file (<filename>.bb</filename>) or
|
|
append file (<filename>.bbappend</filename>)
|
|
resides:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
|
|
The base recipe name without any special
|
|
suffix or version numbers.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
|
|
<filename>${<link linkend='var-BPN'>BPN</link>}-${PV}</filename>.
|
|
The base recipe name and version but without
|
|
any special package name suffix.
|
|
</para></listitem>
|
|
<listitem><para><emphasis>files -</emphasis>
|
|
Files within a directory, which is named
|
|
<filename>files</filename> and is also
|
|
alongside the recipe or append file.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
<note>
|
|
If you want the build system to pick up files
|
|
specified through a
|
|
<filename>SRC_URI</filename>
|
|
statement from your append file, you need to be
|
|
sure to extend the
|
|
<filename>FILESPATH</filename>
|
|
variable by also using the
|
|
<link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
|
|
variable from within your append file.
|
|
</note>
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
|
|
Bazaar revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
|
|
Git revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
|
|
an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
|
|
a repo (Git) repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>svk://</filename> -</emphasis> Fetches files from
|
|
an SVK revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
|
|
the Internet using <filename>http</filename>.</para></listitem>
|
|
<listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
|
|
from the Internet using <filename>https</filename>.</para></listitem>
|
|
<listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
|
|
from the Internet using <filename>ftp</filename>.</para></listitem>
|
|
<listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
|
|
a CVS revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
|
|
a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
|
|
a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
|
|
<listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
|
|
a secure shell.</para></listitem>
|
|
<listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
|
|
a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>Standard and recipe-specific options for <filename>SRC_URI</filename> exist.
|
|
Here are standard options:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>apply</filename> -</emphasis> Whether to apply
|
|
the patch or not.
|
|
The default action is to apply the patch.</para></listitem>
|
|
<listitem><para><emphasis><filename>striplevel</filename> -</emphasis> Which
|
|
striplevel to use when applying the patch.
|
|
The default level is 1.</para></listitem>
|
|
<listitem><para><emphasis><filename>patchdir</filename> -</emphasis> Specifies
|
|
the directory in which the patch should be applied.
|
|
The default is <filename>${</filename><link linkend='var-S'><filename>S</filename></link><filename>}</filename>.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>Here are options specific to recipes building code from a revision control system:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>mindate</filename> -</emphasis>
|
|
Apply the patch only if
|
|
<link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
|
|
is equal to or greater than <filename>mindate</filename>.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
|
|
Apply the patch only if <filename>SRCDATE</filename>
|
|
is not later than <filename>mindate</filename>.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>minrev</filename> -</emphasis>
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
is equal to or greater than <filename>minrev</filename>.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>maxrev</filename> -</emphasis>
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
is not later than <filename>maxrev</filename>.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>rev</filename> -</emphasis>
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
is equal to <filename>rev</filename>.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>notrev</filename> -</emphasis>
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
is not equal to <filename>rev</filename>.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>Here are some additional options worth mentioning:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
|
|
whether or not to unpack the file if it is an archive.
|
|
The default action is to unpack the file.</para></listitem>
|
|
<listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
|
|
(or extracts its contents) into the specified
|
|
subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
|
|
This option is useful for unusual tarballs or other archives that
|
|
do not have their files already in a subdirectory within the archive.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
|
|
name to be used for association with <filename>SRC_URI</filename> checksums
|
|
when you have more than one file specified in <filename>SRC_URI</filename>.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
|
|
the filename used when storing the downloaded file.</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
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 build system automatically changes
|
|
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>.
|
|
Setting this variable to "0" disables this behavior.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The date of the source code used to build the package.
|
|
This variable applies only if the source was fetched from a Source Code Manager (SCM).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SRCPV'><glossterm>SRCPV</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Returns the version string of the current package.
|
|
This string is used to help define the value of
|
|
<link linkend='var-PV'><filename>PV</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>SRCPV</filename> variable is defined in the
|
|
<filename>meta/conf/bitbake.conf</filename> configuration
|
|
file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
SRCPV = "${@bb.fetch2.get_srcrev(d)}"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
Recipes that need to define <filename>PV</filename> do so
|
|
with the help of the <filename>SRCPV</filename>.
|
|
For example, the <filename>ofono</filename> recipe
|
|
(<filename>ofono_git.bb</filename>) located in
|
|
<filename>meta/recipes-connectivity</filename> in the
|
|
Source Directory defines <filename>PV</filename> as
|
|
follows:
|
|
<literallayout class='monospaced'>
|
|
PV = "0.12-git${SRCPV}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The revision of the source code used to build the package.
|
|
This variable applies to Subversion, Git, Mercurial and Bazaar
|
|
only.
|
|
Note that if you wish to build a fixed revision and you wish
|
|
to avoid performing a query on the remote repository every time
|
|
BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
|
|
full revision identifier and not just a tag.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
|
|
<glossdef>
|
|
<para>The directory for the shared state cache.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SSTATE_MIRRORS'><glossterm>SSTATE_MIRRORS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Configures the OpenEmbedded build system to search other
|
|
mirror locations for prebuilt cache data objects before
|
|
building out the data.
|
|
This variable works like fetcher
|
|
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
|
|
and <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
|
|
and points to the cache locations to check for the shared
|
|
objects.
|
|
</para>
|
|
|
|
<para>
|
|
You can specify a filesystem directory or a remote URL such
|
|
as HTTP or FTP.
|
|
The locations you specify need to contain the shared state
|
|
cache (sstate-cache) results from previous builds.
|
|
The sstate-cache you point to can also be from builds on
|
|
other machines.
|
|
</para>
|
|
|
|
<para>
|
|
If a mirror uses the same structure as
|
|
<link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
|
|
you need to add
|
|
"PATH" at the end as shown in the examples below.
|
|
The build system substitutes the correct path within the
|
|
directory structure.
|
|
<literallayout class='monospaced'>
|
|
SSTATE_MIRRORS ?= "\
|
|
file://.* http://someserver.tld/share/sstate/PATH \n \
|
|
file://.* file:///some/local/dir/sstate/PATH"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The directory with kernel headers that are required to build out-of-tree
|
|
modules.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the base path used to create recipe stamp files.
|
|
The path to an actual stamp file is constructed by evaluating this
|
|
string and then appending additional information.
|
|
Currently, the default assignment for <filename>STAMP</filename>
|
|
as set in the <filename>meta/conf/bitbake.conf</filename> file
|
|
is:
|
|
<literallayout class='monospaced'>
|
|
STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
|
|
</literallayout>
|
|
See <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>,
|
|
<link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
|
|
<link linkend='var-PN'><filename>PN</filename></link>,
|
|
<link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>,
|
|
<link linkend='var-PV'><filename>PV</filename></link>, and
|
|
<link linkend='var-PR'><filename>PR</filename></link> for related variable
|
|
information.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the base directory in which the OpenEmbedded
|
|
build system places stamps.
|
|
The default directory is
|
|
<filename>${TMPDIR}/stamps</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
|
|
<glossdef>
|
|
<para>The short (72 characters or less) summary of the binary package for packaging
|
|
systems such as <filename>opkg</filename>, <filename>rpm</filename> or
|
|
<filename>dpkg</filename>.
|
|
By default, <filename>SUMMARY</filename> is used to define
|
|
the <link linkend='var-DESCRIPTION'><filename>DESCRIPTION</filename></link>
|
|
variable if <filename>DESCRIPTION</filename> is not set
|
|
in the recipe.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of functions to execute after files are staged into
|
|
the sysroot.
|
|
These functions are usually used to apply additional
|
|
processing on the staged files, or to stage additional
|
|
files.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-t'><title>T</title>
|
|
|
|
<glossentry id='var-T'><glossterm>T</glossterm>
|
|
<glossdef>
|
|
<para>This variable points to a directory were BitBake places
|
|
temporary files, which consist mostly of task logs and
|
|
scripts, when building a particular recipe.
|
|
The variable is typically set as follows:
|
|
<literallayout class='monospaced'>
|
|
T = "${WORKDIR}/temp"
|
|
</literallayout>
|
|
The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
|
|
is the directory into which BitBake unpacks and builds the
|
|
recipe.
|
|
The default <filename>bitbake.conf</filename> file sets this variable.</para>
|
|
<para>The <filename>T</filename> variable is not to be confused with
|
|
the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
|
|
which points to the root of the directory tree where BitBake
|
|
places the output of an entire build.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The target machine's architecture.
|
|
The OpenEmbedded build system supports many
|
|
architectures.
|
|
Here is an example list of architectures supported.
|
|
This list is by no means complete as the architecture
|
|
is configurable:
|
|
<literallayout class='monospaced'>
|
|
arm
|
|
i586
|
|
x86_64
|
|
powerpc
|
|
powerpc64
|
|
mips
|
|
mipsel
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Flags passed to the C compiler for the target system.
|
|
This variable evaluates to the same as
|
|
<filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
|
|
<glossentry id='var-TARGET_FPU'><glossterm>TARGET_FPU</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the method for handling FPU code.
|
|
For FPU-less targets, which include most ARM CPUs, the variable must be
|
|
set to "soft".
|
|
If not, the kernel emulation gets used, which results in a performance penalty.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the target's operating system.
|
|
The variable can be set to "linux" for <filename>eglibc</filename>-based systems and
|
|
to "linux-uclibc" for <filename>uclibc</filename>.
|
|
For ARM/EABI targets, there are also "linux-gnueabi" and
|
|
"linux-uclibc-gnueabi" values possible.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies which variant of the GNU standard C library (<filename>libc</filename>)
|
|
to use during the build process.
|
|
This variable replaces <filename>POKYLIBC</filename>, which is no longer
|
|
supported.
|
|
</para>
|
|
<para>
|
|
You can select <filename>eglibc</filename> or <filename>uclibc</filename>.
|
|
<note>
|
|
This release of the Yocto Project does not support the
|
|
<filename>glibc</filename> implementation of <filename>libc</filename>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The toolchain selector.
|
|
This variable replaces <filename>POKYMODE</filename>, which is no longer
|
|
supported.
|
|
</para>
|
|
<para>
|
|
The <filename>TCMODE</filename> variable selects the external toolchain
|
|
built using the OpenEmbedded build system or a few supported combinations of
|
|
the upstream GCC or CodeSourcery Labs toolchain.
|
|
The variable identifies the <filename>tcmode-*</filename> files used in
|
|
the <filename>meta/conf/distro/include</filename> directory, which is found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
<para>
|
|
By default, <filename>TCMODE</filename> is set to "default", which
|
|
chooses the <filename>tcmode-default.inc</filename> file.
|
|
The variable is similar to
|
|
<link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>, which controls
|
|
the variant of the GNU standard C library (<filename>libc</filename>)
|
|
used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TEST_IMAGE'><glossterm>TEST_IMAGE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Automatically runs the series of automated tests for
|
|
images when an image is successfully built.
|
|
<note>
|
|
Currently, there is only support for running these tests
|
|
under QEMU.
|
|
</note>
|
|
These tests are written in Python making use of the
|
|
<filename>unittest</filename> module, and the majority of
|
|
them run commands on the target system over
|
|
<filename>ssh</filename>.
|
|
You can set this variable to "1" in your
|
|
<filename>local.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
to have the OpenEmbedded build system automatically run
|
|
these tests after an image successfully builds:
|
|
<literallayout class='monospaced'>
|
|
TEST_IMAGE = "1"
|
|
</literallayout>
|
|
For more information on enabling, running, and writing
|
|
these tests, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
|
|
section in the Yocto Project Development Manual and the
|
|
"<link linkend='ref-classes-testimage'><filename>testimage.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TEST_QEMUBOOT_TIMEOUT'><glossterm>TEST_QEMUBOOT_TIMEOUT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The time in seconds allowed for an image to boot before
|
|
automated runtime tests begin to run against an
|
|
image.
|
|
The default timeout period to allow the boot process to
|
|
reach the login prompt is 500 seconds.
|
|
You can specify a different value in the
|
|
<filename>local.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on testing images, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TEST_SUITES'><glossterm>TEST_SUITES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An ordered list of tests (modules) to run against
|
|
an image when performing automated runtime testing.
|
|
</para>
|
|
|
|
<para>
|
|
The OpenEmbedded build system provides a core set of tests
|
|
that can be used against images.
|
|
<note>
|
|
Currently, there is only support for running these tests
|
|
under QEMU.
|
|
</note>
|
|
Tests include <filename>ping</filename>,
|
|
<filename>ssh</filename>, <filename>df</filename> among
|
|
others.
|
|
You can add your own tests to the list of tests by
|
|
appending <filename>TEST_SUITES</filename> as follows:
|
|
<literallayout class='monospaced'>
|
|
TEST_SUITES_append = " mytest"
|
|
</literallayout>
|
|
Alternatively, you can provide the "auto" option to
|
|
have all applicable tests run against the image.
|
|
<literallayout class='monospaced'>
|
|
TEST_SUITES_append = " auto"
|
|
</literallayout>
|
|
Using this option causes the build system to automatically
|
|
run tests that are applicable to the image.
|
|
Tests that are not applicable are skipped.
|
|
</para>
|
|
|
|
<para>
|
|
The order in which tests are run is important.
|
|
Tests that depend on another test must appear later in the
|
|
list than the test on which they depend.
|
|
For example, if you append the list of tests with two
|
|
tests (<filename>test_A</filename> and
|
|
<filename>test_B</filename>) where
|
|
<filename>test_B</filename> is dependent on
|
|
<filename>test_A</filename>, then you must order the tests
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
TEST_SUITES = " test_A test_B"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For more information on testing images, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-THISDIR'><glossterm>THISDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The directory in which the file BitBake is currently
|
|
parsing is located.
|
|
Do not manually set this variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable is the base directory the OpenEmbedded
|
|
build system uses for all build output and intermediate
|
|
files (other than the shared state cache).
|
|
By default, the <filename>TMPDIR</filename> variable points
|
|
to <filename>tmp</filename> within the
|
|
<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 and edit the following
|
|
statement in the
|
|
<filename>conf/local.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
|
|
<literallayout class='monospaced'>
|
|
#TMPDIR = "${TOPDIR}/tmp"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TOOLCHAIN_HOST_TASK'><glossterm>TOOLCHAIN_HOST_TASK</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable lists packages the OpenEmbedded build system
|
|
uses when building an SDK, which contains a
|
|
cross-development environment.
|
|
The packages specified by this variable are part of the
|
|
toolchain set that runs on the
|
|
<link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
|
|
and each package should usually have the prefix
|
|
"nativesdk-".
|
|
When building an SDK using
|
|
<filename>bitbake -c populate_sdk <imagename></filename>,
|
|
a default list of packages is set in this variable, but
|
|
you can add additional packages to the list.
|
|
</para>
|
|
|
|
<para>
|
|
For background information on cross-development toolchains
|
|
in the Yocto Project development environment, see the
|
|
"<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
|
|
section.
|
|
For information on setting up a cross-development
|
|
environment, 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>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TOOLCHAIN_TARGET_TASK'><glossterm>TOOLCHAIN_TARGET_TASK</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable lists packages the OpenEmbedded build system
|
|
uses when it creates the target part of an SDK
|
|
(i.e. the part built for the target hardware), which
|
|
includes libraries and headers.
|
|
</para>
|
|
|
|
<para>
|
|
For background information on cross-development toolchains
|
|
in the Yocto Project development environment, see the
|
|
"<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
|
|
section.
|
|
For information on setting up a cross-development
|
|
environment, 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>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable points to the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
BitBake automatically sets this variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TRANSLATED_TARGET_ARCH'><glossterm>TRANSLATED_TARGET_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A sanitized version of
|
|
<link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>.
|
|
This variable is used where the architecture is needed in
|
|
a value where underscores are not allowed, for example
|
|
within package filenames.
|
|
In this case, dash characters replace any underscore
|
|
characters used in TARGET_ARCH.
|
|
</para>
|
|
|
|
<para>
|
|
Do not edit this variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNE_PKGARCH'><glossterm>TUNE_PKGARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The package architecture understood by the packaging
|
|
system to define the architecture, ABI, and tuning of
|
|
output packages.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-u'><title>U</title>
|
|
|
|
<glossentry id='var-UBOOT_CONFIG'><glossterm>UBOOT_CONFIG</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Configures the
|
|
<link linkend='var-UBOOT_MACHINE'><filename>UBOOT_MACHINE</filename></link>
|
|
and can also define
|
|
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
|
|
for individual cases.
|
|
</para>
|
|
|
|
<para>
|
|
Following is an example from the
|
|
<filename>meta-fsl-arm</filename> layer.
|
|
<literallayout class='monospaced'>
|
|
UBOOT_CONFIG ??= "sd"
|
|
UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
|
|
UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
|
|
UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
|
|
UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"
|
|
</literallayout>
|
|
In this example, "sd" is selected as the configuration
|
|
of the possible four for the
|
|
<filename>UBOOT_MACHINE</filename>.
|
|
The "sd" configuration defines "mx6qsabreauto_config"
|
|
as the value for <filename>UBOOT_MACHINE</filename>, while
|
|
the "sdcard" specifies the
|
|
<filename>IMAGE_FSTYPES</filename> to use for the U-boot
|
|
image.
|
|
</para>
|
|
|
|
<para>
|
|
For more information on how the
|
|
<filename>UBOOT_CONFIG</filename> is handled, see the
|
|
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-config.bbclass'><filename>uboot-config</filename></ulink>
|
|
class.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_ENTRYPOINT'><glossterm>UBOOT_ENTRYPOINT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the entry point for the U-Boot image.
|
|
During U-Boot image creation, the
|
|
<filename>UBOOT_ENTRYPOINT</filename> variable is passed
|
|
as a command-line parameter to the
|
|
<filename>uboot-mkimage</filename> utility.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_LOADADDRESS'><glossterm>UBOOT_LOADADDRESS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the load address for the U-Boot image.
|
|
During U-Boot image creation, the
|
|
<filename>UBOOT_LOADADDRESS</filename> variable is passed
|
|
as a command-line parameter to the
|
|
<filename>uboot-mkimage</filename> utility.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_LOCALVERSION'><glossterm>UBOOT_LOCALVERSION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Appends a string to the name of the local version of the
|
|
U-Boot image.
|
|
For example, assuming the version of the U-Boot image
|
|
built was "2013.10, the full version string reported by
|
|
U-Boot would be "2013.10-yocto" given the following
|
|
statement:
|
|
<literallayout class='monospaced'>
|
|
UBOOT_LOCALVERSION = "-yocto"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_MACHINE'><glossterm>UBOOT_MACHINE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the value passed on the
|
|
<filename>make</filename> command line when building
|
|
a U-Boot image.
|
|
The value indicates the target platform configuration.
|
|
You typically set this variable from the machine
|
|
configuration file (i.e.
|
|
<filename>conf/machine/<machine_name>.conf</filename>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_MAKE_TARGET'><glossterm>UBOOT_MAKE_TARGET</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the target called in the
|
|
<filename>Makefile</filename>.
|
|
The default target is "all".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_SUFFIX'><glossterm>UBOOT_SUFFIX</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Points to the generated U-Boot extension.
|
|
For example, <filename>u-boot.sb</filename> has a
|
|
<filename>.sb</filename> extension.
|
|
</para>
|
|
|
|
<para>
|
|
The default U-Boot extension is
|
|
<filename>.bin</filename>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-UBOOT_TARGET'><glossterm>UBOOT_TARGET</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the target used for building U-Boot.
|
|
The target is passed directly as part of the "make" command
|
|
(e.g. SPL and AIS).
|
|
If you do not specifically set this variable, the
|
|
OpenEmbedded build process passes and uses "all" for the
|
|
target during the U-Boot building process.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-USER_CLASSES'><glossterm>USER_CLASSES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of classes to globally inherit.
|
|
These classes are used by the OpenEmbedded build system
|
|
to enable extra features (e.g.
|
|
<filename>buildstats</filename>,
|
|
<filename>image-mklibs</filename>, and so forth).
|
|
</para>
|
|
|
|
<para>
|
|
The default list is set in your
|
|
<filename>local.conf</filename> file:
|
|
<literallayout class='monospaced'>
|
|
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
|
|
</literallayout>
|
|
For more information, see
|
|
<filename>meta-yocto/conf/local.conf.sample</filename> in
|
|
the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-USERADD_PACKAGES'><glossterm>USERADD_PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>useradd</filename> class, this variable
|
|
specifies the individual packages within the recipe that
|
|
require users and/or groups to be added.
|
|
</para>
|
|
|
|
<para>
|
|
You must set this variable if the recipe inherits the
|
|
class.
|
|
For example, the following enables adding a user for the
|
|
main package in a recipe:
|
|
<literallayout class='monospaced'>
|
|
USERADD_PACKAGES = "${PN}"
|
|
</literallayout>
|
|
<note>
|
|
If follows that if you are going to use the
|
|
<filename>USERADD_PACKAGES</filename> variable,
|
|
you need to set one or more of the
|
|
<link linkend='var-USERADD_PARAM'><filename>USERADD_PARAM</filename></link>,
|
|
<link linkend='var-GROUPADD_PARAM'><filename>GROUPADD_PARAM</filename></link>,
|
|
or
|
|
<link linkend='var-GROUPMEMS_PARAM'><filename>GROUPMEMS_PARAM</filename></link>
|
|
variables.
|
|
</note>
|
|
</para>
|
|
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-USERADD_PARAM'><glossterm>USERADD_PARAM</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<filename>useradd</filename> class, this variable
|
|
specifies for a package what parameters should be passed
|
|
to the <filename>useradd</filename> command
|
|
if you wish to add a user to the system when the package
|
|
is installed.
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example from the <filename>dbus</filename>
|
|
recipe:
|
|
<literallayout class='monospaced'>
|
|
USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
|
|
--no-create-home --shell /bin/false \
|
|
--user-group messagebus"
|
|
</literallayout>
|
|
For information on the standard Linux shell command
|
|
<filename>useradd</filename>, see
|
|
<ulink url='http://linux.die.net/man/8/useradd'></ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-v'><title>V</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<glossdiv id='var-glossary-w'><title>W</title>
|
|
|
|
<glossentry id='var-WARN_QA'><glossterm>WARN_QA</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the quality assurance checks whose failures are
|
|
reported as warnings by the OpenEmbedded build system.
|
|
You set this variable in your distribution configuration
|
|
file.
|
|
For a list of the checks you can control with this variable,
|
|
see the
|
|
"<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The pathname of the work directory in which the OpenEmbedded build system
|
|
builds a recipe.
|
|
This directory is located within the
|
|
<link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> directory structure and changes
|
|
as different packages are built.
|
|
</para>
|
|
|
|
<para>
|
|
The actual <filename>WORKDIR</filename> directory depends on several things:
|
|
<itemizedlist>
|
|
<listitem>The temporary directory - <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link></listitem>
|
|
<listitem>The package architecture - <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link></listitem>
|
|
<listitem>The target machine - <link linkend='var-MACHINE'><filename>MACHINE</filename></link></listitem>
|
|
<listitem>The target operating system - <link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link></listitem>
|
|
<listitem>The recipe name - <link linkend='var-PN'><filename>PN</filename></link></listitem>
|
|
<listitem>The recipe version - <link linkend='var-PV'><filename>PV</filename></link></listitem>
|
|
<listitem>The recipe revision - <link linkend='var-PR'><filename>PR</filename></link></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
For packages that are not dependent on a particular machine,
|
|
<filename>WORKDIR</filename> is defined as follows:
|
|
<literallayout class='monospaced'>
|
|
${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
|
|
</literallayout>
|
|
As an example, assume a
|
|
<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 work directory the build system uses to build
|
|
the <filename>v86d</filename> package is the following:
|
|
<literallayout class='monospaced'>
|
|
poky/build/tmp/work/qemux86-poky-linux/v86d/01.9-r0
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For packages that are dependent on a particular machine, <filename>WORKDIR</filename>
|
|
is defined slightly differently:
|
|
<literallayout class='monospaced'>
|
|
${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
|
|
</literallayout>
|
|
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 work directory the build system uses to build
|
|
the <filename>acl</filename> recipe, which is being built for a
|
|
MIPS-based device, is the following:
|
|
<literallayout class='monospaced'>
|
|
poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-x'><title>X</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<!-- <glossdiv id='var-glossary-y'><title>Y</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<!-- <glossdiv id='var-glossary-z'><title>Z</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
</glossary>
|
|
</chapter>
|
|
<!--
|
|
vim: expandtab tw=80 ts=4
|
|
-->
|