Fixes [YOCTO #6499] Fixed a couple example INCOMPATIBLE_LICENSE examples so that they now use the canonical licensing names GPL-3.0 LGPL-3.0 AGPL-3.0. (From yocto-docs rev: d2d6be323d1a5ed9da88b7924954f9733a78da84) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
9847 lines
468 KiB
XML
9847 lines
468 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-ABIEXTENSION'>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-FEATURE_PACKAGES'>F</link>
|
|
<link linkend='var-GROUPADD_PARAM'>G</link>
|
|
<link linkend='var-HOMEPAGE'>H</link>
|
|
<link linkend='var-ICECC_DISABLED'>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-QMAKE_PROFILES'>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-ABIEXTENSION'><glossterm>ABIEXTENSION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Extension to the Application Binary Interface (ABI)
|
|
field of the GNU canonical architecture name
|
|
(e.g. "eabi").
|
|
</para>
|
|
|
|
<para>
|
|
ABI extensions are set in the machine include files.
|
|
For example, the
|
|
<filename>meta/conf/machine/include/arm/arch-arm.inc</filename>
|
|
file sets the following extension:
|
|
<literallayout class='monospaced'>
|
|
ABIEXTENSION = "eabi"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<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'><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'><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'><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
|
|
<link linkend='ref-tasks-install'><filename>do_install</filename></link>
|
|
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'><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-AUTO_SYSLINUXMENU'><glossterm>AUTO_SYSLINUXMENU</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Enables creating an automatic menu.
|
|
You must set this in your recipe.
|
|
The
|
|
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
|
|
class checks this variable.
|
|
</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>
|
|
|
|
<glossentry id='var-AVAILTUNES'><glossterm>AVAILTUNES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of defined CPU and Application Binary Interface
|
|
(ABI) tunings (i.e. "tunes") available for use by the
|
|
OpenEmbedded build system.
|
|
</para>
|
|
|
|
<para>
|
|
The list simply presents the tunes that are available.
|
|
Not all tunes may be compatible with a particular
|
|
machine configuration, or with each other in a
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Multilib</ulink>
|
|
configuration.
|
|
</para>
|
|
|
|
<para>
|
|
To add a tune to the list, be sure to append it with
|
|
spaces using the "+=" BitBake operator.
|
|
Do not simply replace the list by using the "=" operator.
|
|
See the
|
|
"<ulink url='&YOCTO_DOCS_BB_URL;#basic-syntax'>Basic Syntax</ulink>"
|
|
section in the BitBake User Manual for more information.
|
|
</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-BASE_LIB'><glossterm>BASE_LIB</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The library directory name for the CPU or Application
|
|
Binary Interface (ABI) tune.
|
|
The <filename>BASE_LIB</filename> applies only in the
|
|
Multilib context.
|
|
See the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Combining Multiple Versions of Library Files into One Image</ulink>"
|
|
section in the Yocto Project Development Manual for
|
|
information on Multilib.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>BASE_LIB</filename> variable is defined in
|
|
the machine include files in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
If Multilib is not being used, the value defaults to "lib".
|
|
</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, including the
|
|
Git metadata, to be placed in the
|
|
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
|
|
directory.
|
|
</para>
|
|
|
|
<para>
|
|
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>
|
|
|
|
<para>
|
|
The default value for <filename>BB_NUMBER_THREADS</filename>
|
|
is equal to the number of cores your build system has.
|
|
</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-BUILD_CFLAGS'><glossterm>BUILD_CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C compiler when building
|
|
for the build host.
|
|
When building in the <filename>-native</filename> context,
|
|
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILD_CPPFLAGS'><glossterm>BUILD_CPPFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C pre-processor
|
|
(i.e. to both the C and the C++ compilers) when building
|
|
for the build host.
|
|
When building in the <filename>native</filename> context,
|
|
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILD_CXXFLAGS'><glossterm>BUILD_CXXFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C++ compiler when
|
|
building for the build host.
|
|
When building in the <filename>native</filename> context,
|
|
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILD_LDFLAGS'><glossterm>BUILD_LDFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the linker when building
|
|
for the build host.
|
|
When building in the <filename>-native</filename> context,
|
|
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILD_OPTIMIZATION'><glossterm>BUILD_OPTIMIZATION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the optimization flags passed to the C compiler
|
|
when building for the build host or the SDK.
|
|
The flags are passed through the
|
|
<link linkend='var-BUILD_CFLAGS'><filename>BUILD_CFLAGS</filename></link>
|
|
and
|
|
<link linkend='var-BUILDSDK_CFLAGS'><filename>BUILDSDK_CFLAGS</filename></link>
|
|
default values.
|
|
</para>
|
|
|
|
<para>
|
|
The default value of the
|
|
<filename>BUILD_OPTIMIZATION</filename> variable is
|
|
"-O2 -pipe".
|
|
</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-BUILDHISTORY_COMMIT'><glossterm>BUILDHISTORY_COMMIT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting the
|
|
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
|
|
class, specifies whether or not to commit the build
|
|
history output in a local Git repository.
|
|
If set to "1", this local repository will be maintained
|
|
automatically by the
|
|
<filename>buildhistory</filename>
|
|
class and a commit will be created on every
|
|
build for changes to each top-level subdirectory of the
|
|
build history output (images, packages, and sdk).
|
|
If you want to track changes to build history over
|
|
time, you should set this value to "1".
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>buildhistory</filename> class
|
|
does not commit the build history output in a local
|
|
Git repository:
|
|
<literallayout class='monospaced'>
|
|
BUILDHISTORY_COMMIT ?= "0"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDHISTORY_COMMIT_AUTHOR'><glossterm>BUILDHISTORY_COMMIT_AUTHOR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting the
|
|
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
|
|
class, specifies the author to use for each Git commit.
|
|
In order for the <filename>BUILDHISTORY_COMMIT_AUTHOR</filename>
|
|
variable to work, the
|
|
<link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
|
|
variable must be set to "1".
|
|
</para>
|
|
|
|
<para>
|
|
Git requires that the value you provide for the
|
|
<filename>BUILDHISTORY_COMMIT_AUTHOR</filename> variable
|
|
takes the form of "name <email@host>".
|
|
Providing an email address or host that is not valid does
|
|
not produce an error.
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>buildhistory</filename> class
|
|
sets the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDHISTORY_DIR'><glossterm>BUILDHISTORY_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting the
|
|
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
|
|
class, specifies the directory in which build history
|
|
information is kept.
|
|
For more information on how the variable works, see the
|
|
<filename>buildhistory.class</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>buildhistory</filename> class
|
|
sets the directory as follows:
|
|
<literallayout class='monospaced'>
|
|
BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDHISTORY_FEATURES'><glossterm>BUILDHISTORY_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting the
|
|
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
|
|
class, specifies the build history features to be enabled.
|
|
For more information on how build history works, see the
|
|
"<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
You can specify three features in the form of a
|
|
space-separated list:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis>image:</emphasis>
|
|
Analysis of the contents of images, which
|
|
includes the list of installed packages among other
|
|
things.
|
|
</para></listitem>
|
|
<listitem><para><emphasis>package:</emphasis>
|
|
Analysis of the contents of individual packages.
|
|
</para></listitem>
|
|
<listitem><para><emphasis>sdk:</emphasis>
|
|
Analysis of the contents of the software
|
|
development kit (SDK).
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>buildhistory</filename> class
|
|
enables all three features:
|
|
<literallayout class='monospaced'>
|
|
BUILDHISTORY_FEATURES ?= "image package sdk"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDHISTORY_IMAGE_FILES'><glossterm>BUILDHISTORY_IMAGE_FILES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting the
|
|
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
|
|
class, specifies a list of paths to files copied from the
|
|
image contents into the build history directory under
|
|
an "image-files" directory in the directory for
|
|
the image, so that you can track the contents of each file.
|
|
The default is to copy <filename>/etc/passwd</filename>
|
|
and <filename>/etc/group</filename>, which allows you to
|
|
monitor for changes in user and group entries.
|
|
You can modify the list to include any file.
|
|
Specifying an invalid path does not produce an error.
|
|
Consequently, you can include files that might
|
|
not always be present.
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>buildhistory</filename> class
|
|
provides paths to the following files:
|
|
<literallayout class='monospaced'>
|
|
BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDHISTORY_PUSH_REPO'><glossterm>BUILDHISTORY_PUSH_REPO</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When inheriting the
|
|
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
|
|
class, optionally specifies a remote repository
|
|
to which build history pushes Git changes.
|
|
In order for <filename>BUILDHISTORY_PUSH_REPO</filename>
|
|
to work,
|
|
<link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
|
|
must be set to "1".
|
|
</para>
|
|
|
|
<para>
|
|
The repository should correspond to a remote
|
|
address that specifies a repository as understood by
|
|
Git, or alternatively to a remote name that you have
|
|
set up manually using <filename>git remote</filename>
|
|
within the local repository.
|
|
</para>
|
|
|
|
<para>
|
|
By default, the <filename>buildhistory</filename> class
|
|
sets the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
BUILDHISTORY_PUSH_REPO ?= ""
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDSDK_CFLAGS'><glossterm>BUILDSDK_CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C compiler when building
|
|
for the SDK.
|
|
When building in the <filename>nativesdk</filename>
|
|
context,
|
|
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDSDK_CPPFLAGS'><glossterm>BUILDSDK_CPPFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C pre-processor
|
|
(i.e. to both the C and the C++ compilers) when building
|
|
for the SDK.
|
|
When building in the <filename>nativesdk</filename>
|
|
context,
|
|
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDSDK_CXXFLAGS'><glossterm>BUILDSDK_CXXFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C++ compiler when
|
|
building for the SDK.
|
|
When building in the <filename>nativesdk</filename>
|
|
context,
|
|
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-BUILDSDK_LDFLAGS'><glossterm>BUILDSDK_LDFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the linker when building
|
|
for the SDK.
|
|
When building in the <filename>nativesdk-</filename>
|
|
context,
|
|
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</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>
|
|
Specifies the flags to pass to the C compiler.
|
|
This variable is exported to an environment
|
|
variable and thus made visible to the software being
|
|
built during the compilation step.
|
|
</para>
|
|
|
|
<para>
|
|
Default initialization for <filename>CFLAGS</filename>
|
|
varies depending on what is being built:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<link linkend='var-TARGET_CFLAGS'><filename>TARGET_CFLAGS</filename></link>
|
|
when building for the target
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILD_CFLAGS'><filename>BUILD_CFLAGS</filename></link>
|
|
when building for the build host (i.e.
|
|
<filename>-native</filename>)
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILDSDK_CFLAGS'><filename>BUILDSDK_CFLAGS</filename></link>
|
|
when building for an SDK (i.e.
|
|
<filename>nativesdk-</filename>)
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</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_INITRAMFS_SOURCE'><glossterm>CONFIG_INITRAMFS_SOURCE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Identifies the initial RAM disk (initramfs) source files.
|
|
The OpenEmbedded build system receives and uses
|
|
this kernel Kconfig variable as an environment variable.
|
|
By default, the variable is set to null ("").
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>CONFIG_INITRAMFS_SOURCE</filename> can be
|
|
either a single cpio archive with a
|
|
<filename>.cpio</filename> suffix or a
|
|
space-separated list of directories and files for building
|
|
the initramfs image.
|
|
A cpio archive should contain a filesystem archive
|
|
to be used as an initramfs image.
|
|
Directories should contain a filesystem layout to be
|
|
included in the initramfs image.
|
|
Files should contain entries according to the format
|
|
described by the
|
|
<filename>usr/gen_init_cpio</filename> program in the
|
|
kernel tree.
|
|
</para>
|
|
|
|
<para>
|
|
If you specify multiple directories and files, the
|
|
initramfs image will be the aggregate of all of them.
|
|
</para>
|
|
</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-COPY_LIC_DIRS'><glossterm>COPY_LIC_DIRS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If set to "1" along with the
|
|
<link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
|
|
variable, the OpenEmbedded build system copies
|
|
into the image the license files, which are located in
|
|
<filename>/usr/share/common-licenses</filename>,
|
|
for each package.
|
|
The license files are placed
|
|
in directories within the image itself.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COPY_LIC_MANIFEST'><glossterm>COPY_LIC_MANIFEST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If set to "1", the OpenEmbedded build system copies
|
|
the license manifest for the image to
|
|
<filename>/usr/share/common-licenses/license.manifest</filename>
|
|
within the image itself.
|
|
</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>
|
|
|
|
<glossentry id='var-CPPFLAGS'><glossterm>CPPFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C pre-processor
|
|
(i.e. to both the C and the C++ compilers).
|
|
This variable is exported to an environment
|
|
variable and thus made visible to the software being
|
|
built during the compilation step.
|
|
</para>
|
|
|
|
<para>
|
|
Default initialization for <filename>CPPFLAGS</filename>
|
|
varies depending on what is being built:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<link linkend='var-TARGET_CPPFLAGS'><filename>TARGET_CPPFLAGS</filename></link>
|
|
when building for the target
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILD_CPPFLAGS'><filename>BUILD_CPPFLAGS</filename></link>
|
|
when building for the build host (i.e.
|
|
<filename>-native</filename>)
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILDSDK_CPPFLAGS'><filename>BUILDSDK_CPPFLAGS</filename></link>
|
|
when building for an SDK (i.e.
|
|
<filename>nativesdk-</filename>)
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CXXFLAGS'><glossterm>CXXFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C++ compiler.
|
|
This variable is exported to an environment
|
|
variable and thus made visible to the software being
|
|
built during the compilation step.
|
|
</para>
|
|
|
|
<para>
|
|
Default initialization for <filename>CXXFLAGS</filename>
|
|
varies depending on what is being built:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<link linkend='var-TARGET_CXXFLAGS'><filename>TARGET_CXXFLAGS</filename></link>
|
|
when building for the target
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILD_CXXFLAGS'><filename>BUILD_CXXFLAGS</filename></link>
|
|
when building for the build host (i.e.
|
|
<filename>-native</filename>)
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link>
|
|
when building for an SDK (i.e.
|
|
<filename>nativesdk</filename>)
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-d'><title>D</title>
|
|
|
|
<glossentry id='var-D'><glossterm>D</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The destination directory.
|
|
The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
where components are installed by the
|
|
<link linkend='ref-tasks-install'><filename>do_install</filename></link>
|
|
task.
|
|
This location defaults to:
|
|
<literallayout class='monospaced'>
|
|
${WORKDIR}/image
|
|
</literallayout>
|
|
</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-DEFAULTTUNE'><glossterm>DEFAULTTUNE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The default CPU and Application Binary Interface (ABI)
|
|
tunings (i.e. the "tune") used by the OpenEmbedded build
|
|
system.
|
|
The <filename>DEFAULTTUNE</filename> helps define
|
|
<link linkend='var-TUNE_FEATURES'><filename>TUNE_FEATURES</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
The default tune is either implicitly or explicitly set
|
|
by the machine
|
|
(<link linkend='var-MACHINE'><filename>MACHINE</filename></link>).
|
|
However, you can override the setting using available tunes
|
|
as defined with
|
|
<link linkend='var-AVAILTUNES'><filename>AVAILTUNES</filename></link>.
|
|
</para>
|
|
</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
|
|
<link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
|
|
task for recipe "a" depends on the
|
|
<link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
|
|
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-DEPLOYDIR'><glossterm>DEPLOYDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
For recipes that inherit the
|
|
<link linkend='ref-classes-deploy'><filename>deploy</filename></link>
|
|
class, the <filename>DEPLOYDIR</filename> points to a
|
|
temporary work area for deployed files that is set in the
|
|
<filename>deploy</filename> class as follows:
|
|
<literallayout class='monospaced'>
|
|
DEPLOYDIR = "${WORKDIR}/deploy-${<link linkend='var-PN'><filename>PN</filename></link>}"
|
|
</literallayout>
|
|
Recipes inheriting the <filename>deploy</filename> class
|
|
should copy files to be deployed into
|
|
<filename>DEPLOYDIR</filename>, and the class will take
|
|
care of copying them into
|
|
<link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
|
|
afterwards.
|
|
</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-DISK_SIGNATURE'><glossterm>DISK_SIGNATURE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A 32-bit MBR disk signature used by
|
|
<filename>directdisk</filename> images.
|
|
</para>
|
|
|
|
<para>
|
|
By default, the signature is set to an automatically
|
|
generated random value that allows the OpenEmbedded
|
|
build system to create a boot loader.
|
|
You can override the signature in the image recipe
|
|
by setting <filename>DISK_SIGNATURE</filename> to an
|
|
8-digit hex string.
|
|
You might want to override
|
|
<filename>DISK_SIGNATURE</filename> if you want the disk
|
|
signature to remain constant between image builds.
|
|
</para>
|
|
|
|
<para>
|
|
When using Linux 3.8 or later, you can use
|
|
<filename>DISK_SIGNATURE</filename> to specify the root
|
|
by UUID to allow the kernel to locate the root device
|
|
even if the device name changes due to differences in
|
|
hardware configuration.
|
|
By default, <filename>SYSLINUX_ROOT</filename> is set
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
SYSLINUX_ROOT = "root=/dev/sda2"
|
|
</literallayout>
|
|
However, you can change this to locate the root device
|
|
using the disk signature instead:
|
|
<literallayout class='monospaced'>
|
|
SYSLINUX_ROOT = "root=PARTUUID=${DISK_SIGNATURE}-02"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
As previously mentioned, it is possible to set the
|
|
<filename>DISK_SIGNATURE</filename> variable in your
|
|
<filename>local.conf</filename> file to a fixed
|
|
value if you do not want <filename>syslinux.cfg</filename>
|
|
changing for each build.
|
|
You might find this useful when you want to upgrade the
|
|
root filesystem on a device without having to recreate or
|
|
modify the master boot record.
|
|
</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 the
|
|
<link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
|
|
task 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-ERR_REPORT_DIR'><glossterm>ERR_REPORT_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When used with the
|
|
<link linkend='ref-classes-report-error'><filename>report-error</filename></link>
|
|
class, specifies the path used for storing the debug files
|
|
created by the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool'>error reporting tool</ulink>,
|
|
which allows you to submit build errors you encounter to a
|
|
central database.
|
|
By default, the value of this variable is
|
|
<filename>${</filename><link linkend='var-LOG_DIR'><filename>LOG_DIR</filename></link><filename>}/error-report</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
You can set <filename>ERR_REPORT_DIR</filename> to the path
|
|
you want the error reporting tool to store the debug files
|
|
as follows in your <filename>local.conf</filename> file:
|
|
<literallayout class='monospaced'>
|
|
ERR_REPORT_DIR = "path"
|
|
</literallayout>
|
|
</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_IMAGECMD'><glossterm>EXTRA_IMAGECMD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies additional options for the image
|
|
creation command that has been specified in
|
|
<link linkend='var-IMAGE_CMD'><filename>IMAGE_CMD</filename></link>.
|
|
When setting this variable, you should
|
|
use an override for the associated type.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
EXTRA_IMAGECMD_ext3 ?= "-i 4096"
|
|
</literallayout>
|
|
</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_OESCONS'><glossterm>EXTRA_OESCONS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<link linkend='ref-classes-scons'><filename>scons</filename></link>
|
|
class, this variable specifies additional configuration
|
|
options you want to pass to the
|
|
<filename>scons</filename> command line.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_QMAKEVARS_POST'><glossterm>EXTRA_QMAKEVARS_POST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Configuration variables or options you want to pass to
|
|
<filename>qmake</filename>.
|
|
Use this variable when the arguments need to be after the
|
|
<filename>.pro</filename> file list on the command line.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is used with recipes that inherit the
|
|
<link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
|
|
class or other classes that inherit
|
|
<filename>qmake_base</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_QMAKEVARS_PRE'><glossterm>EXTRA_QMAKEVARS_PRE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Configuration variables or options you want to pass to
|
|
<filename>qmake</filename>.
|
|
Use this variable when the arguments need to be before the
|
|
<filename>.pro</filename> file list on the command line.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is used with recipes that inherit the
|
|
<link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
|
|
class or other classes that inherit
|
|
<filename>qmake_base</filename>.
|
|
</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-FEATURE_PACKAGES'><glossterm>FEATURE_PACKAGES</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>FEATURE_PACKAGES</filename>
|
|
should have the name of the feature item as an override.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
FEATURE_PACKAGES_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>FEATURE_PACKAGES</filename> are often package
|
|
groups.
|
|
While similarly named, you should not confuse the
|
|
<filename>FEATURE_PACKAGES</filename> variable with
|
|
package groups, which are discussed elsewhere in the
|
|
documentation.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<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 identify 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
|
|
<link linkend='var-CONFFILES'><filename>CONFFILES</filename></link>
|
|
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
|
|
<ulink url='&YOCTO_DOCS_BB_URL;'>BitBake Manual</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 containing font
|
|
files that need to be cached by Fontconfig.
|
|
By default, the <filename>fontcache</filename> class assumes
|
|
that fonts are in the recipe's main package
|
|
(i.e. <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
|
|
Use this variable if fonts you need are 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>
|
|
For recipes that inherit the
|
|
<link linkend='ref-classes-gtk-immodules-cache'><filename>gtk-immodules-cache</filename></link>
|
|
class, this variable specifies the packages that contain the
|
|
GTK+ input method modules being installed when the modules
|
|
are in packages other than the main package.
|
|
</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_CC_ARCH'><glossterm>HOST_CC_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific compiler flags that are
|
|
passed to the C compiler.
|
|
</para>
|
|
|
|
<para>
|
|
Default initialization for <filename>HOST_CC_ARCH</filename>
|
|
varies depending on what is being built:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<link linkend='var-TARGET_CC_ARCH'><filename>TARGET_CC_ARCH</filename></link>
|
|
when building for the target
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<filename>BUILD_CC_ARCH</filename>
|
|
when building for the build host (i.e.
|
|
<filename>native</filename>)
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<filename>BUILDSDK_CC_ARCH</filename>
|
|
when building for an SDK (i.e.
|
|
<filename>nativesdk</filename>)
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</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_DISABLED'><glossterm>ICECC_DISABLED</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Disables or enables the <filename>icecc</filename>
|
|
(Icecream) function.
|
|
For more information on this function and best practices
|
|
for using this variable, see the
|
|
"<link linkend='ref-classes-icecc'><filename>icecc.bbclass</filename></link>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
Setting this variable to "1" in your
|
|
<filename>local.conf</filename> disables the function:
|
|
<literallayout class='monospaced'>
|
|
ICECC_DISABLED ??= "1"
|
|
</literallayout>
|
|
To enable the function, set the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
ICECC_DISABLED = ""
|
|
</literallayout>
|
|
</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_PARALLEL_MAKE'><glossterm>ICECC_PARALLEL_MAKE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Extra options passed to the <filename>make</filename>
|
|
command during the
|
|
<link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
|
|
task that specify parallel compilation.
|
|
This variable usually takes the form of
|
|
<filename>-j 4</filename>, where the number
|
|
represents the maximum number of parallel threads
|
|
<filename>make</filename> can run.
|
|
<note>
|
|
The options passed affect builds on all enabled
|
|
machines on the network, which are machines running the
|
|
<filename>iceccd</filename> daemon.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
If your enabled machines support multiple cores,
|
|
coming up with the maximum number of parallel threads
|
|
that gives you the best performance could take some
|
|
experimentation since machine speed, network lag,
|
|
available memory, and existing machine loads can all
|
|
affect build time.
|
|
Consequently, unlike the
|
|
<link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
|
|
variable, there is no rule-of-thumb for setting
|
|
<filename>ICECC_PARALLEL_MAKE</filename> to achieve
|
|
optimal performance.
|
|
</para>
|
|
|
|
<para>
|
|
If you do not set <filename>ICECC_PARALLEL_MAKE</filename>,
|
|
the build system does not use it (i.e. the system does
|
|
not detect and assign the number of cores as is done with
|
|
<filename>PARALLEL_MAKE</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 recipes 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 recipes 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-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_CMD'><glossterm>IMAGE_CMD</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the command to create the image file for a
|
|
specific image type, which corresponds to the value set
|
|
set in
|
|
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>,
|
|
(e.g. <filename>ext3</filename>,
|
|
<filename>btrfs</filename>, and so forth).
|
|
When setting this variable, you should use
|
|
an override for the associated type.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \
|
|
--faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
|
|
${EXTRA_IMAGECMD}"
|
|
</literallayout>
|
|
You typically do not need to set this variable unless
|
|
you are adding support for a new image type.
|
|
For more examples on how to set this variable, see the
|
|
<link linkend='ref-classes-image_types'><filename>image_types</filename></link>
|
|
class file, which is
|
|
<filename>meta/classes/image_types.bbclass</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_DEVICE_TABLES'><glossterm>IMAGE_DEVICE_TABLES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies one or more files that contain custom device
|
|
tables that are passed to the
|
|
<filename>makedevs</filename> command as part of creating
|
|
an image.
|
|
These files list basic device nodes that should be
|
|
created under <filename>/dev</filename> within the image.
|
|
If <filename>IMAGE_DEVICE_TABLES</filename> is not set,
|
|
<filename>files/device_table-minimal.txt</filename> is
|
|
used, which is located by
|
|
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>.
|
|
For details on how you should write device table files,
|
|
see <filename>meta/files/device_table-minimal.txt</filename>
|
|
as an example.
|
|
</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.
|
|
<note>
|
|
When working with an
|
|
<link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
|
|
image, do not use the <filename>IMAGE_INSTALL</filename>
|
|
variable to specify packages for installation.
|
|
Instead, use the
|
|
<link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
|
|
variable, which allows the initial RAM disk (initramfs)
|
|
recipe to use a fixed set of packages and not be
|
|
affected by <filename>IMAGE_INSTALL</filename>.
|
|
</note>
|
|
</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_MANIFEST'><glossterm>IMAGE_MANIFEST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The manifest file for the image.
|
|
This file lists all the installed packages that make up
|
|
the image.
|
|
The file contains package information on a line-per-package
|
|
basis as follows:
|
|
<literallayout class='monospaced'>
|
|
<packagename> <packagearch> <version>
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
The
|
|
<link linkend='ref-classes-image'><filename>image</filename></link>
|
|
class defines the manifest file as follows:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_MANIFEST = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest"
|
|
</literallayout>
|
|
The location is derived using the
|
|
<link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
|
|
and
|
|
<link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>
|
|
variables.
|
|
You can find information on how the image
|
|
is created in the
|
|
"<link linkend='image-generation-dev-environment'>Image Generation</link>"
|
|
section.
|
|
</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_PKGTYPE'><glossterm>IMAGE_PKGTYPE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the package type (DEB, RPM, IPK, or TAR) used
|
|
by the OpenEmbedded build system.
|
|
The variable is defined appropriately by the
|
|
<link linkend='ref-classes-package_deb'><filename>package_deb</filename></link>,
|
|
<link linkend='ref-classes-package_rpm'><filename>package_rpm</filename></link>,
|
|
<link linkend='ref-classes-package_ipk'><filename>package_ipk</filename></link>,
|
|
or
|
|
<link linkend='ref-classes-package_tar'><filename>package_tar</filename></link>
|
|
class.
|
|
</para>
|
|
|
|
<para>
|
|
The
|
|
<link linkend='ref-classes-populate-sdk-*'><filename>package_sdk_base</filename></link>
|
|
and
|
|
<link linkend='ref-classes-image'><filename>image</filename></link>
|
|
classes use the <filename>IMAGE_PKGTYPE</filename> for
|
|
packaging up images and SDKs.
|
|
</para>
|
|
|
|
<para>
|
|
You should not set the <filename>IMAGE_PKGTYPE</filename>
|
|
manually.
|
|
Rather, the variable is set indirectly through the
|
|
appropriate
|
|
<link linkend='ref-classes-package'><filename>package_*</filename></link>
|
|
class using the
|
|
<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
|
|
variable.
|
|
The OpenEmbedded build system uses the first package type
|
|
(e.g. DEB, RPM, or IPK) that appears with the variable
|
|
<note>
|
|
Files using the <filename>.tar</filename> format are
|
|
never used as a substitute packaging format for DEB,
|
|
RPM, and IPK formatted files for your image or SDK.
|
|
</note>
|
|
</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 the
|
|
<link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
|
|
task).
|
|
This variable is not configurable.
|
|
Do not change it.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_ROOTFS_ALIGNMENT'><glossterm>IMAGE_ROOTFS_ALIGNMENT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the alignment for the output image file in
|
|
Kbytes.
|
|
If the size of the image is not a multiple of
|
|
this value, then the size is rounded up to the nearest
|
|
multiple of the value.
|
|
The default value is "1".
|
|
See
|
|
<link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
|
|
for additional information.
|
|
</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_TYPEDEP'><glossterm>IMAGE_TYPEDEP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a dependency from one image type on another.
|
|
Here is an example from the
|
|
<link linkend='ref-classes-image-live'><filename>image-live</filename></link>
|
|
class:
|
|
<literallayout class='monospaced'>
|
|
IMAGE_TYPEDEP_live = "ext3"
|
|
</literallayout>
|
|
In the previous example, the variable ensures that when
|
|
"live" is listed with the
|
|
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
|
|
variable, the OpenEmbedded build system produces an
|
|
<filename>ext3</filename> image first since one of the
|
|
components of the live
|
|
image is an <filename>ext3</filename>
|
|
formatted partition containing the root
|
|
filesystem.
|
|
</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
|
|
jffs2.sum
|
|
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 about 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 = "GPL-3.0 LGPL-3.0 AGPL-3.0"
|
|
</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 will be inherited at the
|
|
distribution level.
|
|
It is unlikely that you want to edit this variable.
|
|
</para>
|
|
|
|
<para>
|
|
The default value of 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-INITRAMFS_IMAGE'><glossterm>INITRAMFS_IMAGE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Causes the OpenEmbedded build system to build an additional
|
|
recipe as a dependency to your root filesystem recipe
|
|
(e.g. <filename>core-image-sato</filename>).
|
|
The additional recipe is used to create an initial RAM disk
|
|
(initramfs) that might be needed during the initial boot of
|
|
the target system to accomplish such things as loading
|
|
kernel modules prior to mounting the root file system.
|
|
</para>
|
|
|
|
<para>
|
|
When you set the variable, specify the name of the
|
|
initramfs you want created.
|
|
The following example, which is set in the
|
|
<filename>local.conf</filename> configuration file, causes
|
|
a separate recipe to be created that results in an
|
|
initramfs image named
|
|
<filename>core-image-sato-initramfs.bb</filename> to be
|
|
created:
|
|
<literallayout class='monospaced'>
|
|
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
|
|
</literallayout>
|
|
By default, the
|
|
<link linkend='ref-classes-kernel'><filename>kernel</filename></link>
|
|
class sets this variable to a null string as follows:
|
|
<literallayout class='monospaced'>
|
|
INITRAMFS_IMAGE = ""
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
|
|
file for additional information.
|
|
You can also reference the
|
|
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass'><filename>kernel.bbclass</filename></ulink>
|
|
file to see how the variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITRAMFS_IMAGE_BUNDLE'><glossterm>INITRAMFS_IMAGE_BUNDLE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Controls whether or not the image recipe specified by
|
|
<link linkend='var-INITRAMFS_IMAGE'><filename>INITRAMFS_IMAGE</filename></link>
|
|
is run through an extra pass during kernel compilation
|
|
in order to build a single binary that contains both the
|
|
kernel image and the initial RAM disk (initramfs).
|
|
Using an extra compilation pass ensures that when a kernel
|
|
attempts to use an initramfs, it does not encounter
|
|
circular dependencies should the initramfs include kernel
|
|
modules.
|
|
</para>
|
|
|
|
<para>
|
|
The combined binary is deposited into the
|
|
<filename>tmp/deploy</filename> directory, which is part
|
|
of the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
Setting the variable to "1" in a configuration file causes
|
|
the OpenEmbedded build system to make the extra pass during
|
|
kernel compilation:
|
|
<literallayout class='monospaced'>
|
|
INITRAMFS_IMAGE_BUNDLE = "1"
|
|
</literallayout>
|
|
By default, the
|
|
<link linkend='ref-classes-kernel'><filename>kernel</filename></link>
|
|
class sets this variable to a null string as follows:
|
|
<literallayout class='monospaced'>
|
|
INITRAMFS_IMAGE_BUNDLE = ""
|
|
</literallayout>
|
|
<note>
|
|
You must set the
|
|
<filename>INITRAMFS_IMAGE_BUNDLE</filename> variable in
|
|
a configuration file.
|
|
You cannot set the variable in a recipe file.
|
|
</note>
|
|
See the
|
|
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
|
|
file for additional information.
|
|
</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>bootimg</filename></link>
|
|
class.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-INITRD_IMAGE'><glossterm>INITRD_IMAGE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When building a "live" bootable image (i.e. when
|
|
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
|
|
contains "live"), <filename>INITRD_IMAGE</filename>
|
|
specifies the image recipe that should be built
|
|
to provide the initial RAM disk image.
|
|
The default value is "core-image-minimal-initramfs".
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-image-live'><filename>image-live</filename></link>
|
|
class for more information.
|
|
</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's default value is "defaults", which is
|
|
set in the
|
|
<link linkend='ref-classes-update-rc.d'><filename>update-rc.d</filename></link>
|
|
class.
|
|
</para>
|
|
<para>
|
|
The value in
|
|
<filename>INITSCRIPT_PARAMS</filename> is passed through
|
|
to the <filename>update-rc.d</filename> command.
|
|
For more information on valid parameters, please see the
|
|
<filename>update-rc.d</filename> manual page at
|
|
<ulink url='http://www.tin.org/bin/man.cgi?section=8&topic=update-rc.d'></ulink>.
|
|
</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.10 kernel, the kernel recipe file
|
|
is the
|
|
<filename>meta/recipes-kernel/linux/linux-yocto_3.10.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.10</filename>
|
|
kernel Git repository
|
|
<ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.10/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.10.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"
|
|
KERNEL_FEATURES_append_crownbay = " features/drm-emgd/drm-emgd-1.18 cfg/vesafb"
|
|
|
|
COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
|
|
KMACHINE_crownbay-noemgd = "crownbay"
|
|
KBRANCH_crownbay-noemgd = "standard/crownbay"
|
|
KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb"
|
|
</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_IMAGE_BASE_NAME'><glossterm>KERNEL_IMAGE_BASE_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The base name of the kernel image.
|
|
This variable is set in the
|
|
<link linkend='ref-classes-kernel'>kernel</link> class
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
|
|
</literallayout>
|
|
See the
|
|
<link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>,
|
|
<link linkend='var-PKGE'><filename>PKGE</filename></link>,
|
|
<link linkend='var-PKGV'><filename>PKGV</filename></link>,
|
|
<link linkend='var-PKGR'><filename>PKGR</filename></link>,
|
|
<link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
|
|
and
|
|
<link linkend='var-DATETIME'><filename>DATETIME</filename></link>
|
|
variables for additional information.
|
|
</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>
|
|
To help maximize compatibility with out-of-tree drivers
|
|
used to build modules, the OpenEmbedded build system also
|
|
recognizes and uses the
|
|
<link linkend='var-KERNEL_SRC'><filename>KERNEL_SRC</filename></link>
|
|
variable, which is identical to the
|
|
<filename>KERNEL_PATH</filename> variable.
|
|
Both variables are common variables used by external
|
|
Makefiles to point to the kernel source directory.
|
|
</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>
|
|
To help maximize compatibility with out-of-tree drivers
|
|
used to build modules, the OpenEmbedded build system also
|
|
recognizes and uses the
|
|
<link linkend='var-KERNEL_PATH'><filename>KERNEL_PATH</filename></link>
|
|
variable, which is identical to the
|
|
<filename>KERNEL_SRC</filename> variable.
|
|
Both variables are common variables used by external
|
|
Makefiles to point to the kernel source directory.
|
|
</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-LDFLAGS'><glossterm>LDFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the linker.
|
|
This variable is exported to an environment
|
|
variable and thus made visible to the software being
|
|
built during the compilation step.
|
|
</para>
|
|
|
|
<para>
|
|
Default initialization for <filename>LDFLAGS</filename>
|
|
varies depending on what is being built:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<link linkend='var-TARGET_LDFLAGS'><filename>TARGET_LDFLAGS</filename></link>
|
|
when building for the target
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILD_LDFLAGS'><filename>BUILD_LDFLAGS</filename></link>
|
|
when building for the build host (i.e.
|
|
<filename>-native</filename>)
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<link linkend='var-BUILDSDK_LDFLAGS'><filename>BUILDSDK_LDFLAGS</filename></link>
|
|
when building for an SDK (i.e.
|
|
<filename>nativesdk-</filename>)
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LEAD_SONAME'><glossterm>LEAD_SONAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the lead (or primary) compiled library file
|
|
(<filename>.so</filename>) that the
|
|
<link linkend='ref-classes-debian'><filename>debian</filename></link>
|
|
class applies its naming policy to given a recipe that
|
|
packages multiple libraries.
|
|
</para>
|
|
|
|
<para>
|
|
This variable works in conjunction with the
|
|
<filename>debian</filename> class.
|
|
</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>
|
|
<listitem><para>For standard licenses, use the names
|
|
of the files in
|
|
<filename>meta/files/common-licenses/</filename>
|
|
or the
|
|
<link linkend='var-SPDXLICENSEMAP'><filename>SPDXLICENSEMAP</filename></link>
|
|
flag names defined in
|
|
<filename>meta/conf/licenses.conf</filename>.
|
|
</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_FLAGS'><glossterm>LICENSE_FLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies additional flags for a recipe you must
|
|
whitelist through
|
|
<link linkend='var-LICENSE_FLAGS_WHITELIST'><filename>LICENSE_FLAGS_WHITELIST</filename></link>
|
|
in order to allow the recipe to be built.
|
|
When providing multiple flags, separate them with
|
|
spaces.
|
|
</para>
|
|
|
|
<para>
|
|
This value is independent of
|
|
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
|
|
and is typically used to mark recipes that might
|
|
require additional licenses in order to be used in a
|
|
commercial product.
|
|
For more information, see the
|
|
"<link linkend='enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</link>"
|
|
section.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LICENSE_FLAGS_WHITELIST'><glossterm>LICENSE_FLAGS_WHITELIST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists license flags that when specified in
|
|
<link linkend='var-LICENSE_FLAGS'><filename>LICENSE_FLAGS</filename></link>
|
|
within a recipe should not prevent that recipe from being
|
|
built.
|
|
This practice is otherwise known as "whitelisting"
|
|
license flags.
|
|
For more information, see the
|
|
<link linkend='enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</link>"
|
|
section.
|
|
</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 ?= "beaglebone"
|
|
MACHINE ?= "mpc8315e-rdb"
|
|
MACHINE ?= "edgerouter"
|
|
</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_ARCH'><glossterm>MACHINE_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the name of the machine-specific architecture.
|
|
This variable is set automatically from
|
|
<link linkend='var-MACHINE'><filename>MACHINE</filename></link>
|
|
or
|
|
<link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>.
|
|
You should not hand-edit the
|
|
<filename>MACHINE_ARCH</filename> variable.
|
|
</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-full-cmdline</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-full-cmdline</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_autoload'><glossterm>module_autoload</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists kernel modules that need to be auto-loaded during
|
|
boot.
|
|
</para>
|
|
|
|
<para>
|
|
You can use this variable anywhere that it can be
|
|
recognized by the kernel recipe or out-of-tree kernel
|
|
module recipe (e.g. a machine configuration file, a
|
|
distribution configuration file, an append file for the
|
|
recipe, or the recipe itself).
|
|
</para>
|
|
|
|
<para>
|
|
Specify it as follows:
|
|
<literallayout class='monospaced'>
|
|
module_autoload_<modname> = "modname1 modname2 modname3"
|
|
</literallayout>
|
|
You must use the kernel module name override.
|
|
</para>
|
|
|
|
<para>
|
|
Including <filename>module_autoload</filename> causes the
|
|
OpenEmbedded build system to populate the
|
|
<filename>/etc/modules-load.d/modname.conf</filename>
|
|
file with the list of modules to be auto-loaded on boot.
|
|
The modules appear one-per-line in the file.
|
|
Here is an example of the most common use case:
|
|
<literallayout class='monospaced'>
|
|
module_autoload_modname = "modname"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For information on how to populate the
|
|
<filename>modname.conf</filename> file with
|
|
<filename>modprobe.d</filename> syntax lines, see the
|
|
<link linkend='var-module_conf'><filename>module_conf</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-module_conf'><glossterm>module_conf</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies <filename>modprobe.d</filename> syntax lines
|
|
for inclusion in the
|
|
<filename>/etc/modprobe.d/modname.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
You can use this variable anywhere that it can be
|
|
recognized by the kernel recipe or out-of-tree kernel
|
|
module recipe (e.g. a machine configuration file, a
|
|
distribution configuration file, an append file for the
|
|
recipe, or the recipe itself).
|
|
</para>
|
|
|
|
<para>
|
|
Here is the general syntax:
|
|
<literallayout class='monospaced'>
|
|
module_conf_<modname> = "modprobe.d-syntax"
|
|
</literallayout>
|
|
You must use the kernel module name override.
|
|
</para>
|
|
|
|
<para>
|
|
Run <filename>man modprobe.d</filename> in the shell to
|
|
find out more information on the exact syntax for lines
|
|
you want to provide with <filename>module_conf</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
Including <filename>module_conf</filename> causes the
|
|
OpenEmbedded build system to populate the
|
|
<filename>/etc/modprobe.d/modname.conf</filename>
|
|
file with <filename>modprobe.d</filename> syntax lines.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
module_conf_<modname> = "options modname arg1=val1 arg2=val2"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For information on how to specify kernel modules to
|
|
auto-load on boot, see the
|
|
<link linkend='var-module_autoload'><filename>module_autoload</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MODULE_IMAGE_BASE_NAME'><glossterm>MODULE_IMAGE_BASE_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The base name of the kernel modules tarball.
|
|
This variable is set in the
|
|
<link linkend='ref-classes-kernel'>kernel</link> class
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
|
|
</literallayout>
|
|
See the
|
|
<link linkend='var-PKGE'><filename>PKGE</filename></link>,
|
|
<link linkend='var-PKGV'><filename>PKGV</filename></link>,
|
|
<link linkend='var-PKGR'><filename>PKGR</filename></link>,
|
|
<link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
|
|
and
|
|
<link linkend='var-DATETIME'><filename>DATETIME</filename></link>
|
|
variables for additional information.
|
|
</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>bootimg</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>bootimg</filename></link>
|
|
class.
|
|
Set the variable to "1" to prevent the ISO image from
|
|
being built.
|
|
To enable building an ISO image, set the variable to "0".
|
|
</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 contains 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
|
|
"<ulink url='&YOCTO_DOCS_BB_URL;#conditional-syntax-overrides'>Conditional Syntax (Overrides)</ulink>"
|
|
section of the BitBake User Manual.
|
|
</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>
|
|
|
|
<para>
|
|
By default, the value of this variable is set to
|
|
<link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
|
|
when building for the target,
|
|
<filename>BUILD_ARCH</filename> when building for the
|
|
build host and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building
|
|
for the SDK.
|
|
However, if your recipe's output packages are built
|
|
specific to the target machine rather than general for
|
|
the architecture of the machine, you should set
|
|
<filename>PACKAGE_ARCH</filename> to the value of
|
|
<link linkend='var-MACHINE_ARCH'><filename>MACHINE_ARCH</filename></link>
|
|
in the recipe as follows:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_ARCH = "${MACHINE_ARCH}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_ARCHS'><glossterm>PACKAGE_ARCHS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a list of architectures compatible with
|
|
the target machine.
|
|
This variable is set automatically and should not
|
|
normally be hand-edited.
|
|
Entries are separated using spaces and listed in order
|
|
of priority.
|
|
The default value for
|
|
<filename>PACKAGE_ARCHS</filename> is "all any noarch
|
|
${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}".
|
|
</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;#build-directory'>Build Directory</ulink>,
|
|
specifies the package manager the OpenEmbedded build system
|
|
uses when packaging data.
|
|
</para>
|
|
|
|
<para>
|
|
You can provide one or more of the following arguments for
|
|
the variable:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar"
|
|
</literallayout>
|
|
The build system uses only the first argument in the list
|
|
as the package manager when creating your image or SDK.
|
|
However, packages will be created using any additional
|
|
packaging classes you specify.
|
|
For example, if you use the following in your
|
|
<filename>local.conf</filename> file:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_CLASSES ?= "package_ipk package_tar"
|
|
</literallayout>
|
|
The OpenEmbedded build system uses the IPK package manager
|
|
to create your image or SDK as well as generating
|
|
TAR packages.
|
|
</para>
|
|
|
|
<para>
|
|
You cannot specify the
|
|
<link linkend='ref-classes-package_tar'><filename>package_tar</filename></link>
|
|
class first in the list.
|
|
Files using the <filename>.tar</filename> format cannot
|
|
be used as a substitute packaging format
|
|
for DEB, RPM, and IPK formatted files for your image or SDK.
|
|
</para>
|
|
|
|
<para>
|
|
For information on packaging and build performance effects
|
|
as a result of the package manager in use, see the
|
|
"<link linkend='ref-classes-package'><filename>package.bbclass</filename></link>"
|
|
section.
|
|
</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>
|
|
The <filename>PACKAGE_GROUP</filename> variable has been
|
|
renamed to
|
|
<link linkend='var-FEATURE_PACKAGES'><filename>FEATURE_PACKAGES</filename></link>.
|
|
See the variable description for
|
|
<filename>FEATURE_PACKAGES</filename> for information.
|
|
</para>
|
|
|
|
<para>
|
|
If if you use the <filename>PACKAGE_GROUP</filename>
|
|
variable, the OpenEmbedded build system issues a warning
|
|
message.
|
|
</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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
This variable is internal to the image construction
|
|
code.
|
|
Consequently, in general, you should use the
|
|
<link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
|
|
variable to specify packages for installation.
|
|
The exception to this is when working with
|
|
the
|
|
<link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
|
|
image.
|
|
When working with an initial RAM disk (initramfs)
|
|
image, use the <filename>PACKAGE_INSTALL</filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_PREPROCESS_FUNCS'><glossterm>PACKAGE_PREPROCESS_FUNCS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a list of functions run to pre-process the
|
|
<link linkend='var-PKGD'><filename>PKGD</filename></link>
|
|
directory prior to splitting the files out to individual
|
|
packages.
|
|
</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-PACKAGESPLITFUNCS'><glossterm>PACKAGESPLITFUNCS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a list of functions run to perform additional
|
|
splitting of files into individual packages.
|
|
Recipes can either prepend to this variable or prepend
|
|
to the <filename>populate_packages</filename> function
|
|
in order to perform additional package splitting.
|
|
In either case, the function should set
|
|
<link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>,
|
|
<link linkend='var-FILES'><filename>FILES</filename></link>,
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
|
|
and other packaging variables appropriately in order to
|
|
perform the desired splitting.
|
|
</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 the
|
|
<link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
|
|
task.
|
|
</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 passed to the <filename>make</filename>
|
|
command during the
|
|
<link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
|
|
task in order to specify parallel compilation on the local
|
|
build host.
|
|
This variable is usually in the form "-j <x>",
|
|
where x represents the maximum number of parallel threads
|
|
<filename>make</filename> can run.
|
|
</para>
|
|
|
|
<para>
|
|
If your development host supports multiple cores, a good
|
|
rule of thumb is to set this variable to twice the number
|
|
of cores on the host.
|
|
If you do not set <filename>PARALLEL_MAKE</filename>, it
|
|
defaults to the number of cores your build system has.
|
|
<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
|
|
<link linkend='ref-tasks-install'><filename>do_install</filename></link>
|
|
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 the
|
|
<link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
|
|
task.
|
|
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 variable 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-PIXBUF_PACKAGES'><glossterm>PIXBUF_PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When a recipe inherits the
|
|
<link linkend='ref-classes-pixbufcache'><filename>pixbufcache</filename></link>
|
|
class, this variable identifies packages that contain
|
|
the pixbuf loaders used with
|
|
<filename>gdk-pixbuf</filename>.
|
|
By default, the <filename>pixbufcache</filename> class
|
|
assumes that the loaders are in the recipe's main package
|
|
(i.e. <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
|
|
Use this variable if the loaders you need are in a package
|
|
other than that main package.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKG'><glossterm>PKG</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The name of the resulting package created by the
|
|
OpenEmbedded build system.
|
|
<note>
|
|
When using the <filename>PKG</filename> variable, you
|
|
must use a package name override.
|
|
</note>
|
|
For example, when the
|
|
<link linkend='ref-classes-debian'><filename>debian</filename></link>
|
|
class renames the output package, it does so by setting
|
|
<filename>PKG_<packagename></filename>.
|
|
</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
|
|
<link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
|
|
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
|
|
<link linkend='ref-tasks-package'><filename>do_package</filename></link>
|
|
task to write output from the
|
|
<link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
|
|
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-PKGE'><glossterm>PKGE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The epoch of the output package built by the
|
|
OpenEmbedded build system.
|
|
By default, <filename>PKGE</filename> is set to
|
|
<link linkend='var-PE'><filename>PE</filename></link>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKGR'><glossterm>PKGR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The revision of the output package built by the
|
|
OpenEmbedded build system.
|
|
By default, <filename>PKGR</filename> is set to
|
|
<link linkend='var-PR'><filename>PR</filename></link>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PKGV'><glossterm>PKGV</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The version of the output package built by the
|
|
OpenEmbedded build system.
|
|
By default, <filename>PKGV</filename> is set to
|
|
<link linkend='var-PV'><filename>PV</filename></link>.
|
|
</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>
|
|
The <filename>PRINC</filename> variable has been deprecated
|
|
and triggers a warning if detected during a build.
|
|
For
|
|
<link linkend='var-PR'><filename>PR</filename></link>
|
|
increments on changes, use the PR service instead.
|
|
You can find out more about this service in the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>Working With a PR Service</ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
<!--
|
|
|
|
<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-PRIVATE_LIBS'><glossterm>PRIVATE_LIBS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies libraries installed within a recipe that
|
|
should be ignored by the OpenEmbedded build system's
|
|
shared library resolver.
|
|
This variable is typically used when software being
|
|
built by a recipe has its own private versions of a
|
|
library normally provided by another recipe.
|
|
In this case, you would not want the package containing
|
|
the private libraries to be set as a dependency on other
|
|
unrelated packages that should instead depend on the
|
|
package providing the standard version of the library.
|
|
</para>
|
|
|
|
<para>
|
|
Libraries specified in this variable should be specified
|
|
by their file name.
|
|
For example, from the Firefox recipe in meta-browser:
|
|
<literallayout class='monospaced'>
|
|
PRIVATE_LIBS = "libmozjs.so \
|
|
libxpcom.so \
|
|
libnspr4.so \
|
|
libxul.so \
|
|
libmozalloc.so \
|
|
libplc4.so \
|
|
libplds4.so"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of aliases by which a particular recipe can be
|
|
known.
|
|
By default, a recipe's own
|
|
<filename><link linkend='var-PN'>PN</link></filename>
|
|
is implicitly already in its <filename>PROVIDES</filename>
|
|
list.
|
|
If a recipe uses <filename>PROVIDES</filename>, the
|
|
additional aliases are synonyms for the recipe and can
|
|
be useful satisfying dependencies of other recipes during
|
|
the build as specified by
|
|
<filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
|
|
</para>
|
|
|
|
<para>
|
|
Consider the following example
|
|
<filename>PROVIDES</filename> statement from a recipe
|
|
file <filename>libav_0.8.11.bb</filename>:
|
|
<literallayout class='monospaced'>
|
|
PROVIDES += "libpostproc"
|
|
</literallayout>
|
|
The <filename>PROVIDES</filename> statement results in
|
|
the "libav" recipe also being known as "libpostproc".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The network based
|
|
<link linkend='var-PR'><filename>PR</filename></link>
|
|
service host and port.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>conf/local.conf.sample.extended</filename>
|
|
configuration file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
shows how the <filename>PRSERV_HOST</filename> variable is
|
|
set:
|
|
<literallayout class='monospaced'>
|
|
PRSERV_HOST = "localhost:0"
|
|
</literallayout>
|
|
You must set the variable if you want to automatically
|
|
start a local
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>PR service</ulink>.
|
|
You can set <filename>PRSERV_HOST</filename> to other
|
|
values to use a remote PR service.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PTEST_ENABLED'><glossterm>PTEST_ENABLED</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies whether or not
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Package Test</ulink>
|
|
(ptest) functionality is enabled when building a recipe.
|
|
You should not set this variable directly.
|
|
Enabling and disabling building Package Tests
|
|
at build time should be done by adding "ptest" to (or
|
|
removing it from)
|
|
<link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
|
|
</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>
|
|
|
|
<glossentry id='var-PYTHON_ABI'><glossterm>PYTHON_ABI</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When used by recipes that inherit the
|
|
<link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>,
|
|
<link linkend='ref-classes-setuptools3'><filename>setuptools3</filename></link>,
|
|
<link linkend='ref-classes-distutils'><filename>distutils</filename></link>,
|
|
or
|
|
<link linkend='ref-classes-setuptools'><filename>setuptools</filename></link>
|
|
classes, denotes the Application Binary Interface (ABI)
|
|
currently in use for Python.
|
|
By default, the ABI is "m".
|
|
You do not have to set this variable as the OpenEmbedded
|
|
build system sets it for you.
|
|
</para>
|
|
|
|
<para>
|
|
The OpenEmbedded build system uses the ABI to construct
|
|
directory names used when installing the Python headers
|
|
and libraries in sysroot
|
|
(e.g. <filename>.../python3.3m/...</filename>).
|
|
</para>
|
|
|
|
<para>
|
|
Recipes that inherit the
|
|
<link linkend='ref-classes-distutils'><filename>distutils</filename></link>
|
|
class during cross-builds also use this variable to
|
|
locate the headers and libraries of the appropriate Python
|
|
that the extension is targeting.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PYTHON_PN'><glossterm>PYTHON_PN</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When used by recipes that inherit the
|
|
<link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>,
|
|
<link linkend='ref-classes-setuptools3'><filename>setuptools3</filename></link>,
|
|
<link linkend='ref-classes-distutils'><filename>distutils</filename></link>,
|
|
or
|
|
<link linkend='ref-classes-setuptools'><filename>setuptools</filename></link>
|
|
classes, specifies the major Python version being built.
|
|
For Python 2.x, <filename>PYTHON_PN</filename> would
|
|
be "python2". For Python 3.x, the variable would be
|
|
"python3".
|
|
You do not have to set this variable as the
|
|
OpenEmbedded build system automatically sets it for you.
|
|
</para>
|
|
|
|
<para>
|
|
The variable allows recipes to use common infrastructure
|
|
such as the following:
|
|
<literallayout class='monospaced'>
|
|
DEPENDS += "${PYTHON_PN}-native"
|
|
</literallayout>
|
|
In the previous example, the version of the dependency
|
|
is <filename>PYTHON_PN</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-q'><title>Q</title>
|
|
|
|
<glossentry id='var-QMAKE_PROFILES'><glossterm>QMAKE_PROFILES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies your own subset of <filename>.pro</filename>
|
|
files to be built for use with
|
|
<filename>qmake</filename>.
|
|
If you do not set this variable, all
|
|
<filename>.pro</filename> files in the directory pointed to
|
|
by <link linkend='var-S'><filename>S</filename></link>
|
|
will be built by default.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is used with recipes that inherit the
|
|
<link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
|
|
class or other classes that inherit
|
|
<filename>qmake_base</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</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
|
|
<link linkend='ref-tasks-build'><filename>do_build</filename></link>
|
|
task depends on the existence of a specific package.
|
|
Consider this simple example for two recipes named "a" and
|
|
"b" that produce similarly named IPK 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
|
|
<link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>
|
|
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.
|
|
</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
|
|
<link linkend='ref-classes-debian'><filename>debian.bbclass</filename></link>.
|
|
</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'><filename>rm_work.bbclass</filename></link>"
|
|
section for more details.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-ROOT_HOME'><glossterm>ROOT_HOME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the root home directory.
|
|
By default, this directory is set as follows in the
|
|
BitBake configuration file:
|
|
<literallayout class='monospaced'>
|
|
ROOT_HOME ??= "/home/root"
|
|
</literallayout>
|
|
<note>
|
|
This default value is likely used because some
|
|
embedded solutions prefer to have a read-only root
|
|
filesystem and prefer to keep writeable data in one
|
|
place.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
You can override the default by setting the variable
|
|
in any layer or in the <filename>local.conf</filename> file.
|
|
Because the default is set using a "weak" assignment
|
|
(i.e. "??="), you can use either of the following forms
|
|
to define your override:
|
|
<literallayout class='monospaced'>
|
|
ROOT_HOME = "/root"
|
|
ROOT_HOME ?= "/root"
|
|
</literallayout>
|
|
These override examples use <filename>/root</filename>,
|
|
which is probably the most commonly used override.
|
|
</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>bootimg</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.
|
|
See the
|
|
<link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
|
|
variable for more information.
|
|
</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_DEPLOY'><glossterm>SDK_DEPLOY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The directory set up and used by the
|
|
<link linkend='ref-classes-populate-sdk'><filename>populate_sdk_base</filename></link>
|
|
to which the SDK is deployed.
|
|
The <filename>populate_sdk_base</filename> class defines
|
|
<filename>SDK_DEPLOY</filename> as follows:
|
|
<literallayout class='monospaced'>
|
|
SDK_DEPLOY = "${<link linkend='var-TMPDIR'>TMPDIR</link>}/deploy/sdk"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDK_DIR'><glossterm>SDK_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The parent directory used by the OpenEmbedded build system
|
|
when creating SDK output.
|
|
The
|
|
<link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
|
|
class defines the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
SDK_DIR = "${<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>}/sdk"
|
|
</literallayout>
|
|
<note>
|
|
The <filename>SDK_DIR</filename> directory is a
|
|
temporary directory as it is part of
|
|
<filename>WORKDIR</filename>.
|
|
The final output directory is
|
|
<link linkend='var-SDK_DEPLOY'><filename>SDK_DEPLOY</filename></link>.
|
|
</note>
|
|
</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-SDK_OUTPUT'><glossterm>SDK_OUTPUT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location used by the OpenEmbedded build system when
|
|
creating SDK output.
|
|
The
|
|
<link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
|
|
class defines the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
SDK_OUTPUT = "${<link linkend='var-SDK_DIR'>SDK_DIR</link>}/image"
|
|
</literallayout>
|
|
<note>
|
|
The <filename>SDK_OUTPUT</filename> directory is a
|
|
temporary directory as it is part of
|
|
<filename>WORKDIR</filename> by way of
|
|
<filename>SDK_DIR</filename>.
|
|
The final output directory is
|
|
<link linkend='var-SDK_DEPLOY'><filename>SDK_DEPLOY</filename></link>.
|
|
</note>
|
|
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDK_PACKAGE_ARCHS'><glossterm>SDK_PACKAGE_ARCHS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a list of architectures compatible with
|
|
the SDK machine.
|
|
This variable is set automatically and should not
|
|
normally be hand-edited.
|
|
Entries are separated using spaces and listed in order
|
|
of priority.
|
|
The default value for
|
|
<filename>SDK_PACKAGE_ARCHS</filename> is "all any noarch
|
|
${SDK_ARCH}-${SDKPKGSUFFIX}".
|
|
</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 machine for which the Application Development Toolkit
|
|
(ADT) or SDK is built.
|
|
In other words, the SDK or ADT is built such that it
|
|
runs on the target you specify with the
|
|
<filename>SDKMACHINE</filename> value.
|
|
The value points to a corresponding
|
|
<filename>.conf</filename> file under
|
|
<filename>conf/machine-sdk/</filename>.
|
|
</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 local.conf file in the Build Directory.
|
|
<literallayout class='monospaced'>
|
|
SDKMACHINE ?= "i686"
|
|
</literallayout>
|
|
<note>
|
|
You cannot set the <filename>SDKMACHINE</filename>
|
|
variable in your distribution configuration file.
|
|
If you do, the configuration will not take affect.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SDKPATH'><glossterm>SDKPATH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the path offered to the user for installation
|
|
of the SDK that is generated by the OpenEmbedded build
|
|
system.
|
|
The path appears as the default location for installing
|
|
the SDK when you run the SDK's installation script.
|
|
You can override the offered path when you run the
|
|
script.
|
|
</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>
|
|
Specifies the optimization flags passed to the C compiler
|
|
when building for the target.
|
|
The flags are passed through the default value of the
|
|
<link linkend='var-TARGET_CFLAGS'><filename>TARGET_CFLAGS</filename></link>
|
|
variable.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>SELECTED_OPTIMIZATION</filename> 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".
|
|
If that is the 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-own-mirrors'><filename>own-mirrors</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-SPDXLICENSEMAP'><glossterm>SPDXLICENSEMAP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Maps commonly used license names to their SPDX counterparts
|
|
found in <filename>meta/files/common-licenses/</filename>.
|
|
For the default <filename>SPDXLICENSEMAP</filename>
|
|
mappings, see the
|
|
<filename>meta/conf/licenses.conf</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
For additional information, see the
|
|
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
|
|
variable.
|
|
</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_MIRROR_ALLOW_NETWORK'><glossterm>SSTATE_MIRROR_ALLOW_NETWORK</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If set to "1", allows fetches from
|
|
mirrors that are specified in
|
|
<link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
|
|
to work even when fetching from the network has been
|
|
disabled by setting <filename>BB_NO_NETWORK</filename>
|
|
to "1".
|
|
Using the
|
|
<filename>SSTATE_MIRROR_ALLOW_NETWORK</filename>
|
|
variable is useful if you have set
|
|
<filename>SSTATE_MIRRORS</filename> to point to an
|
|
internal server for your shared state cache, but
|
|
you want to disable any other fetching from the network.
|
|
</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_BASE_LIBDIR_NATIVE'><glossterm>STAGING_BASE_LIBDIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/lib</filename>
|
|
subdirectory of the sysroot directory for the
|
|
build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_BASELIBDIR'><glossterm>STAGING_BASELIBDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/lib</filename>
|
|
subdirectory of the sysroot directory for the target
|
|
for which the current recipe is being built
|
|
(<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_BINDIR'><glossterm>STAGING_BINDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the
|
|
<filename>/usr/bin</filename> subdirectory of the
|
|
sysroot directory for the target for which the current
|
|
recipe is being built
|
|
(<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_BINDIR_CROSS'><glossterm>STAGING_BINDIR_CROSS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the directory containing binary
|
|
configuration scripts.
|
|
These scripts provide configuration information for
|
|
other software that wants to make use of libraries or
|
|
include files provided by the software associated with
|
|
the script.
|
|
<note>
|
|
This style of build configuration has been largely
|
|
replaced by <filename>pkg-config</filename>.
|
|
Consequently, if <filename>pkg-config</filename>
|
|
is supported by the library to which you are linking,
|
|
it is recommended you use
|
|
<filename>pkg-config</filename> instead of a
|
|
provided configuration script.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_BINDIR_NATIVE'><glossterm>STAGING_BINDIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the
|
|
<filename>/usr/bin</filename> subdirectory of the
|
|
sysroot directory for the build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_DATADIR'><glossterm>STAGING_DATADIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/usr/share</filename>
|
|
subdirectory of the sysroot directory for the target
|
|
for which the current recipe is being built
|
|
(<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_DIR'><glossterm>STAGING_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the top-level sysroots directory
|
|
(i.e.
|
|
<filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/sysroots</filename>).
|
|
<note>
|
|
Recipes should never write files directly under
|
|
this directory because the OpenEmbedded build system
|
|
manages the directory automatically.
|
|
Instead, files should be installed to
|
|
<filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>
|
|
within your recipe's
|
|
<link linkend='ref-tasks-install'><filename>do_install</filename></link>
|
|
task and then the OpenEmbedded build system will
|
|
stage a subset of those files into the sysroot.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_DIR_HOST'><glossterm>STAGING_DIR_HOST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the primary sysroot directory for
|
|
which the target is being built.
|
|
Depending on the type of recipe and the build target, the
|
|
recipe's value is as follows:
|
|
<itemizedlist>
|
|
<listitem><para>For recipes building for the target
|
|
machine, the value is "${STAGING_DIR}/${MACHINE}".
|
|
</para></listitem>
|
|
<listitem><para>For <filename>native</filename>
|
|
recipes building
|
|
for the build host, the value is empty given the
|
|
assumption that when building for the build host,
|
|
the build host's own directories should be used.
|
|
</para></listitem>
|
|
<listitem><para>For <filename>nativesdk</filename>
|
|
recipes that Build for the SDK, the value is
|
|
"${STAGING_DIR}/${MULTIMACH_HOST_SYS}".
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_DATADIR_NATIVE'><glossterm>STAGING_DATADIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/usr/share</filename>
|
|
subdirectory of the sysroot directory for the build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-STAGING_DIR_NATIVE'><glossterm>STAGING_DIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the sysroot directory for the
|
|
build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_DIR_TARGET'><glossterm>STAGING_DIR_TARGET</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the sysroot directory for the
|
|
target for which the current recipe is being built.
|
|
In most cases, this path is the
|
|
<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
Some recipes build binaries that can run on the target
|
|
system but those binaries in turn generate code for
|
|
another different system (e.g. cross-canadian recipes).
|
|
Using terminology from GNU, the primary system is referred
|
|
to as the "HOST" and the secondary, or different, system is
|
|
referred to as the "TARGET".
|
|
Thus, the binaries run on the "HOST" system and
|
|
and generate binaries for the "TARGET" system.
|
|
<filename>STAGING_DIR_TARGET</filename> points to the
|
|
sysroot used for the "TARGET" system.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_ETCDIR_NATIVE'><glossterm>STAGING_ETCDIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/etc</filename>
|
|
subdirectory of the sysroot directory for the
|
|
build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_EXECPREFIXDIR'><glossterm>STAGING_EXECPREFIXDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/usr</filename>
|
|
subdirectory of the sysroot directory for the target
|
|
for which the current recipe is being built
|
|
(<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_INCDIR'><glossterm>STAGING_INCDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the
|
|
<filename>/usr/include</filename> subdirectory of the
|
|
sysroot directory for the target for which the current
|
|
recipe being built
|
|
(<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_INCDIR_NATIVE'><glossterm>STAGING_INCDIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/usr/include</filename>
|
|
subdirectory of the sysroot directory for the build host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_LIBDIR'><glossterm>STAGING_LIBDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/usr/lib</filename>
|
|
subdirectory of the sysroot directory for the target for
|
|
which the current recipe is being built
|
|
(<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_LIBDIR_NATIVE'><glossterm>STAGING_LIBDIR_NATIVE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the path to the <filename>/usr/lib</filename>
|
|
subdirectory of the sysroot directory for the build host.
|
|
</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-SYSLINUX_DEFAULT_CONSOLE'><glossterm>SYSLINUX_DEFAULT_CONSOLE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the kernel boot default console.
|
|
If you want to use a console other than the default,
|
|
set this variable in your recipe as follows where "X" is
|
|
the console number you want to use:
|
|
<literallayout class='monospaced'>
|
|
SYSLINUX_DEFAULT_CONSOLE = "console=ttyX"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
The
|
|
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
|
|
class initially sets this variable to null but then checks
|
|
for a value later.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSLINUX_OPTS'><glossterm>SYSLINUX_OPTS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists additional options to add to the syslinux file.
|
|
You need to set this variable in your recipe.
|
|
If you want to list multiple options, separate the options
|
|
with a semicolon character (<filename>;</filename>).
|
|
</para>
|
|
|
|
<para>
|
|
The
|
|
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
|
|
class uses this variable to create a set of options.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSLINUX_SERIAL'><glossterm>SYSLINUX_SERIAL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the alternate serial port or turns it off.
|
|
To turn off serial, set this variable to an empty string
|
|
in your recipe.
|
|
The variable's default value is set in the
|
|
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
SYSLINUX_SERIAL ?= "0 115200"
|
|
</literallayout>
|
|
The class checks for and uses the variable as needed. </para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSLINUX_SPLASH'><glossterm>SYSLINUX_SPLASH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <filename>.LSS</filename> file used as the background
|
|
for the VGA boot menu when you are using the boot menu.
|
|
You need to set this variable in your recipe.
|
|
</para>
|
|
|
|
<para>
|
|
The
|
|
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
|
|
class checks for this variable and if found, the
|
|
OpenEmbedded build system installs the splash screen.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSLINUX_SERIAL_TTY'><glossterm>SYSLINUX_SERIAL_TTY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the alternate console=tty... kernel boot argument.
|
|
The variable's default value is set in the
|
|
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
|
|
as follows:
|
|
<literallayout class='monospaced'>
|
|
SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200"
|
|
</literallayout>
|
|
The class checks for and uses the variable as needed.
|
|
</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>
|
|
|
|
<glossentry id='var-SYSTEMD_AUTO_ENABLE'><glossterm>SYSTEMD_AUTO_ENABLE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
For recipes that inherit the
|
|
<link linkend='ref-classes-systemd'><filename>systemd</filename></link>
|
|
class, this variable specifies whether the service you have
|
|
specified in
|
|
<link linkend='var-SYSTEMD_SERVICE'><filename>SYSTEMD_SERVICE</filename></link>
|
|
should be started automatically or not.
|
|
By default, the service is enabled to automatically start
|
|
at boot time.
|
|
The default setting is in the
|
|
<link linkend='ref-classes-systemd'><filename>systemd</filename></link>
|
|
class as follows:
|
|
<literallayout class='monospaced'>
|
|
SYSTEMD_AUTO_ENABLE ??= "enable"
|
|
</literallayout>
|
|
You can disable the service by setting the variable to
|
|
"disable".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSTEMD_PACKAGES'><glossterm>SYSTEMD_PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
For recipes that inherit the
|
|
<link linkend='ref-classes-systemd'><filename>systemd</filename></link>
|
|
class, this variable locates the systemd unit files when
|
|
they are not found in the main recipe's package.
|
|
By default, the
|
|
<filename>SYSTEMD_PACKAGES</filename> variable is set
|
|
such that the systemd unit files are assumed to reside in
|
|
the recipes main package:
|
|
<literallayout class='monospaced'>
|
|
SYSTEMD_PACKAGES ?= "${PN}"
|
|
</literallayout>
|
|
If these unit files are not in this recipe's main
|
|
package, you need to use
|
|
<filename>SYSTEMD_PACKAGES</filename> to list the package
|
|
or packages in which the build system can find the systemd
|
|
unit files.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSTEMD_SERVICE'><glossterm>SYSTEMD_SERVICE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
For recipes that inherit the
|
|
<link linkend='ref-classes-systemd'><filename>systemd</filename></link>
|
|
class, this variable specifies the systemd service name for
|
|
a package.
|
|
</para>
|
|
|
|
<para>
|
|
When you specify this file in your recipe, use a package
|
|
name override to indicate the package to which the value
|
|
applies.
|
|
Here is an example from the connman recipe:
|
|
<literallayout class='monospaced'>
|
|
SYSTEMD_SERVICE_${PN} = "connman.service"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SYSVINIT_ENABLED_GETTYS'><glossterm>SYSVINIT_ENABLED_GETTYS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When using
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>,
|
|
specifies a space-separated list of the virtual terminals
|
|
that should be running a
|
|
<ulink url='http://en.wikipedia.org/wiki/Getty_%28Unix%29'>getty</ulink>
|
|
(allowing login), assuming
|
|
<link linkend='var-USE_VT'><filename>USE_VT</filename></link>
|
|
is not set to "0".
|
|
</para>
|
|
|
|
<para>
|
|
The default value for
|
|
<filename>SYSVINIT_ENABLED_GETTYS</filename> is "1"
|
|
(i.e. only run a getty on the first virtual terminal).
|
|
</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>
|
|
For additional information on machine architectures, see
|
|
the
|
|
<link linkend='var-TUNE_ARCH'><filename>TUNE_ARCH</filename></link>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_AS_ARCH'><glossterm>TARGET_AS_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific assembler flags for the
|
|
target system.
|
|
<filename>TARGET_AS_ARCH</filename> is initialized from
|
|
<link linkend='var-TUNE_ASARGS'><filename>TUNE_ASARGS</filename></link>
|
|
by default in the BitBake configuration file
|
|
(<filename>meta/conf/bitbake.conf</filename>):
|
|
<literallayout class='monospaced'>
|
|
TARGET_AS_ARCH = "${TUNE_ASARGS}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CC_ARCH'><glossterm>TARGET_CC_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific C compiler flags for the
|
|
target system.
|
|
<filename>TARGET_CC_ARCH</filename> is initialized from
|
|
<link linkend='var-TUNE_CCARGS'><filename>TUNE_CCARGS</filename></link>
|
|
by default.
|
|
<note>
|
|
It is a common workaround to append
|
|
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
|
|
to <filename>TARGET_CC_ARCH</filename>
|
|
in recipes that build software for the target that
|
|
would not otherwise respect the exported
|
|
<filename>LDFLAGS</filename> variable.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CC_KERNEL_ARCH'><glossterm>TARGET_CC_KERNEL_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This is a specific kernel compiler flag for a CPU or
|
|
Application Binary Interface (ABI) tune.
|
|
The flag is used rarely and only for cases where a
|
|
userspace
|
|
<link linkend='var-TUNE_CCARGS'><filename>TUNE_CCARGS</filename></link>
|
|
is not compatible with the kernel compilation.
|
|
The <filename>TARGET_CC_KERNEL_ARCH</filename> variable
|
|
allows the kernel (and associated modules) to use a
|
|
different configuration.
|
|
See the
|
|
<filename>meta/conf/machine/include/arm/feature-arm-thumb.inc</filename>
|
|
file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
for an example.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C compiler when building
|
|
for the target.
|
|
When building in the target context,
|
|
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, the SDK's environment setup script sets
|
|
the
|
|
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
|
|
variable in the environment to the
|
|
<filename>TARGET_CFLAGS</filename> value so that
|
|
executables built using the SDK also have the flags
|
|
applied.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CPPFLAGS'><glossterm>TARGET_CPPFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C pre-processor
|
|
(i.e. to both the C and the C++ compilers) when building
|
|
for the target.
|
|
When building in the target context,
|
|
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, the SDK's environment setup script sets
|
|
the
|
|
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
|
|
variable in the environment to the
|
|
<filename>TARGET_CPPFLAGS</filename> value so that
|
|
executables built using the SDK also have the flags
|
|
applied.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CXXFLAGS'><glossterm>TARGET_CXXFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the C++ compiler when
|
|
building for the target.
|
|
When building in the target context,
|
|
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, the SDK's environment setup script sets
|
|
the
|
|
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
|
|
variable in the environment to the
|
|
<filename>TARGET_CXXFLAGS</filename> value so that
|
|
executables built using the SDK also have the flags
|
|
applied.
|
|
</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_LD_ARCH'><glossterm>TARGET_LD_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific linker flags for the
|
|
target system.
|
|
<filename>TARGET_LD_ARCH</filename> is initialized from
|
|
<link linkend='var-TUNE_LDARGS'><filename>TUNE_LDARGS</filename></link>
|
|
by default in the BitBake configuration file
|
|
(<filename>meta/conf/bitbake.conf</filename>):
|
|
<literallayout class='monospaced'>
|
|
TARGET_LD_ARCH = "${TUNE_LDARGS}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_LDFLAGS'><glossterm>TARGET_LDFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the flags to pass to the linker when building
|
|
for the target.
|
|
When building in the target context,
|
|
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
|
|
is set to the value of this variable by default.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, the SDK's environment setup script sets
|
|
the
|
|
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
|
|
variable in the environment to the
|
|
<filename>TARGET_LDFLAGS</filename> value so that
|
|
executables built using the SDK also have the flags
|
|
applied.
|
|
</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 the GNU standard C library (<filename>libc</filename>)
|
|
variant to use during the build process.
|
|
This variable replaces <filename>POKYLIBC</filename>, which is no longer
|
|
supported.
|
|
</para>
|
|
<para>
|
|
You can select "eglibc" or "uclibc".
|
|
<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>
|
|
Specifies the toolchain selector.
|
|
<filename>TCMODE</filename> controls the characteristics
|
|
of the generated packages and images by telling the
|
|
OpenEmbedded build system which toolchain profile to use.
|
|
By default, the OpenEmbedded build system builds its own
|
|
internal toolchain.
|
|
The variable's default value is "default", which uses
|
|
that internal toolchain.
|
|
<note>
|
|
If <filename>TCMODE</filename> is set to a value
|
|
other than "default", then it is your responsibility
|
|
to ensure that the toolchain is compatible with the
|
|
default toolchain.
|
|
Using older or newer versions of these components
|
|
might cause build problems.
|
|
See the
|
|
<ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
|
|
for the specific components with which the toolchain
|
|
must be compatible.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
With additional layers, it is possible to use a pre-compiled
|
|
external toolchain.
|
|
One example is the Sourcery G++ Toolchain.
|
|
The support for this toolchain resides in the separate
|
|
<filename>meta-sourcery</filename> layer at
|
|
<ulink url='http://github.com/MentorEmbedded/meta-sourcery/'></ulink>.
|
|
You can use <filename>meta-sourcery</filename> as a
|
|
template for adding support for other external toolchains.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>TCMODE</filename> variable points the build
|
|
system to a file in
|
|
<filename>conf/distro/include/tcmode-${TCMODE}.inc</filename>.
|
|
Thus, for <filename>meta-sourcery</filename>,
|
|
which has <filename>conf/distro/include/tcmode-external-sourcery.inc</filename>,
|
|
you would set the variable as follows:
|
|
<literallayout class='monospaced'>
|
|
TCMODE ?= "external-sourcery"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
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_EXPORT_DIR'><glossterm>TEST_EXPORT_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location the OpenEmbedded build system uses to export
|
|
tests when the
|
|
<link linkend='var-TEST_EXPORT_ONLY'><filename>TEST_EXPORT_ONLY</filename></link>
|
|
variable is set to "1".
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>TEST_EXPORT_DIR</filename> variable defaults
|
|
to <filename>"${TMPDIR}/testimage/${PN}"</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TEST_EXPORT_ONLY'><glossterm>TEST_EXPORT_ONLY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies to export the tests only.
|
|
Set this variable to "1" if you do not want to run the
|
|
tests but you want them to be exported in a manner that
|
|
you to run them outside of the build system.
|
|
</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.
|
|
</para>
|
|
|
|
<para>
|
|
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_LOG_DIR'><glossterm>TEST_LOG_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Holds the SSH log and the boot log for QEMU machines.
|
|
The <filename>TEST_LOG_DIR</filename> variable defaults
|
|
to <filename>"${WORKDIR}/testimage"</filename>.
|
|
<note>
|
|
Actual test results reside in the task log
|
|
(<filename>log.do_testimage</filename>), which is in
|
|
the <filename>${WORKDIR}/temp/</filename> directory.
|
|
</note>
|
|
</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_SERVER_IP'><glossterm>TEST_SERVER_IP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The IP address of the build machine (host machine).
|
|
This IP address is usually automatically detected.
|
|
However, if detection fails, this variable needs to be set
|
|
to the IP address of the build machine (i.e. where
|
|
the build is taking place).
|
|
<note>
|
|
The <filename>TEST_SERVER_IP</filename> variable
|
|
is only used for a small number of tests such as
|
|
the "smart" test suite, which needs to download
|
|
packages from <filename>DEPLOY_DIR/rpm</filename>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TEST_TARGET'><glossterm>TEST_TARGET</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the target controller to use when running tests
|
|
against a test image.
|
|
The default controller to use is "qemu":
|
|
<literallayout class='monospaced'>
|
|
TEST_TARGET = "qemu"
|
|
</literallayout>
|
|
A target controller is a class that defines how an
|
|
image gets deployed on a target and how a target is started.
|
|
A layer can extend the controllers by adding a module
|
|
in the layer's <filename>/lib/oeqa/controllers</filename>
|
|
directory and by inheriting the
|
|
<filename>BaseTarget</filename> class, which is an abstract
|
|
class that cannot be used as a value of
|
|
<filename>TEST_TARGET</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
You can provide the following arguments with
|
|
<filename>TEST_TARGET</filename>:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis>"qemu" and "QemuTarget":</emphasis>
|
|
Boots a QEMU image and runs the tests.
|
|
See the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>"
|
|
section in the Yocto Project Development Manual for
|
|
more information.
|
|
</para></listitem>
|
|
<listitem><para><emphasis>"simpleremote" and "SimpleRemoteTarget":</emphasis>
|
|
Runs the tests on target hardware that is already
|
|
up and running.
|
|
The hardware can be on the network or it can be
|
|
a device running an image on QEMU.
|
|
You must also set
|
|
<link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link>
|
|
when you use "simpleremote" or "SimpleRemoteTarget".
|
|
<note>
|
|
This argument is defined in
|
|
<filename>meta/lib/oeqa/targetcontrol.py</filename>.
|
|
The small caps names are kept for compatibility
|
|
reasons.
|
|
</note>
|
|
</para></listitem>
|
|
<listitem><para><emphasis>"GummibootTarget":</emphasis>
|
|
Automatically deploys and runs tests on an
|
|
EFI-enabled machine that has a master image
|
|
installed.
|
|
<note>
|
|
This argument is defined in
|
|
<filename>meta/lib/oeqa/controllers/masterimage.py</filename>.
|
|
</note>
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
For information on running tests on hardware, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests'>Enabling Runtime Tests on Hardware</ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TEST_TARGET_IP'><glossterm>TEST_TARGET_IP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The IP address of your hardware under test.
|
|
The <filename>TEST_TARGET_IP</filename> variable has no
|
|
effect when
|
|
<link linkend='var-TEST_TARGET'><filename>TEST_TARGET</filename></link>
|
|
is set to "qemu".
|
|
</para>
|
|
|
|
<para>
|
|
When you specify the IP address, you can also include a
|
|
port.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
TEST_TARGET_IP = "192.168.1.4:2201"
|
|
</literallayout>
|
|
Specifying a port is useful when SSH is started on a
|
|
non-standard port or in cases when your hardware under test
|
|
is behind a firewall or network that is not directly
|
|
accessible from your host and you need to do port address
|
|
translation.
|
|
</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>
|
|
An example use for this scenario is to set
|
|
<filename>TMPDIR</filename> to a local disk, which does
|
|
not use NFS, while having the Build Directory use NFS.
|
|
</para>
|
|
|
|
<para>
|
|
The filesystem used by <filename>TMPDIR</filename> must
|
|
have standard filesystem semantics (i.e. mixed-case files
|
|
are unique, POSIX file locking, and persistent inodes).
|
|
Due to various issues with NFS and bugs in some
|
|
implementations, NFS does not meet this minimum
|
|
requirement.
|
|
Consequently, <filename>TMPDIR</filename> cannot be on
|
|
NFS.
|
|
</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>
|
|
The top-level
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
BitBake automatically sets this variable when you
|
|
initialize your build environment using either
|
|
<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
|
|
or
|
|
<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>.
|
|
</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_ARCH'><glossterm>TUNE_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The GNU canonical architecture for a specific architecture
|
|
(i.e. <filename>arm</filename>,
|
|
<filename>armeb</filename>,
|
|
<filename>mips</filename>,
|
|
<filename>mips64</filename>, and so forth).
|
|
BitBake uses this value to setup configuration.
|
|
</para>
|
|
|
|
<para>
|
|
<filename>TUNE_ARCH</filename> definitions are specific to
|
|
a given architecture.
|
|
The definitions can be a single static definition, or
|
|
can be dynamically adjusted.
|
|
You can see details for a given CPU family by looking at
|
|
the architecture's <filename>README</filename> file.
|
|
For example, the
|
|
<filename>meta/conf/machine/include/mips/README</filename>
|
|
file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
provides information for <filename>TUNE_ARCH</filename>
|
|
specific to the <filename>mips</filename> architecture.
|
|
</para>
|
|
|
|
<para>
|
|
<filename>TUNE_ARCH</filename> is tied closely to
|
|
<link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>,
|
|
which defines the target machine's architecture.
|
|
The BitBake configuration file
|
|
(<filename>meta/conf/bitbake.conf</filename>) sets
|
|
<filename>TARGET_ARCH</filename> as follows:
|
|
<literallayout class='monospaced'>
|
|
TARGET_ARCH = "${TUNE_ARCH}"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
The following list, which is by no means complete since
|
|
architectures are configurable, shows supported machine
|
|
architectures:
|
|
<literallayout class='monospaced'>
|
|
arm
|
|
i586
|
|
x86_64
|
|
powerpc
|
|
powerpc64
|
|
mips
|
|
mipsel
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNE_ASARGS'><glossterm>TUNE_ASARGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific assembler flags for
|
|
the target system.
|
|
The set of flags is based on the selected tune features.
|
|
<filename>TUNE_ASARGS</filename> is set using
|
|
the tune include files, which are typically under
|
|
<filename>meta/conf/machine/include/</filename> and are
|
|
influenced through <filename>TUNE_FEATURES</filename>.
|
|
For example, the
|
|
<filename>meta/conf/machine/include/x86/arch-x86.inc</filename>
|
|
file defines the flags for the x86 architecture as follows:
|
|
<literallayout class='monospaced'>
|
|
TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
|
|
</literallayout>
|
|
<note>
|
|
Board Support Packages (BSPs) can supply their own
|
|
set of flags.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNE_CCARGS'><glossterm>TUNE_CCARGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific C compiler flags for
|
|
the target system.
|
|
The set of flags is based on the selected tune features.
|
|
<filename>TUNE_CCARGS</filename> is set using
|
|
the tune include files, which are typically under
|
|
<filename>meta/conf/machine/include/</filename> and are
|
|
influenced through <filename>TUNE_FEATURES</filename>.
|
|
<note>
|
|
Board Support Packages (BSPs) can supply their own
|
|
set of flags.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNE_LDARGS'><glossterm>TUNE_LDARGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies architecture-specific linker flags for
|
|
the target system.
|
|
The set of flags is based on the selected tune features.
|
|
<filename>TUNE_LDARGS</filename> is set using
|
|
the tune include files, which are typically under
|
|
<filename>meta/conf/machine/include/</filename> and are
|
|
influenced through <filename>TUNE_FEATURES</filename>.
|
|
For example, the
|
|
<filename>meta/conf/machine/include/x86/arch-x86.inc</filename>
|
|
file defines the flags for the x86 architecture as follows:
|
|
<literallayout class='monospaced'>
|
|
TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
|
|
</literallayout>
|
|
<note>
|
|
Board Support Packages (BSPs) can supply their own
|
|
set of flags.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNE_FEATURES'><glossterm>TUNE_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Features used to "tune" a compiler for optimal use
|
|
given a specific processor.
|
|
The features are defined within the tune files and allow
|
|
arguments (i.e. <filename>TUNE_*ARGS</filename>) to be
|
|
dynamically generated based on the features.
|
|
</para>
|
|
|
|
<para>
|
|
The OpenEmbedded build system verifies the features
|
|
to be sure they are not conflicting and that they are
|
|
supported.
|
|
</para>
|
|
|
|
<para>
|
|
The BitBake configuration file
|
|
(<filename>meta/conf/bitbake.conf</filename>) defines
|
|
<filename>TUNE_FEATURES</filename> as follows:
|
|
<literallayout class='monospaced'>
|
|
TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
|
|
</literallayout>
|
|
See the
|
|
<link linkend='var-DEFAULTTUNE'><filename>DEFAULTTUNE</filename></link>
|
|
variable for more information.
|
|
</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>
|
|
|
|
<glossentry id='var-TUNE_PKGARCH_tune'><glossterm>TUNE_PKGARCH_tune</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The CPU or Application Binary Interface (ABI) specific
|
|
tuning of the
|
|
<link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
These tune-specific package architectures are defined in
|
|
the machine include files.
|
|
Here is an example of the "core2-32" tuning as used
|
|
in the
|
|
<filename>meta/conf/machine/include/tune-core2.inc</filename>
|
|
file:
|
|
<literallayout class='monospaced'>
|
|
TUNE_PKGARCH_tune-core2-32 = "core2-32"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNEABI'><glossterm>TUNEABI</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An underlying Application Binary Interface (ABI) used by
|
|
a particular tuning in a given toolchain layer.
|
|
Providers that use prebuilt libraries can use the
|
|
<filename>TUNEABI</filename>,
|
|
<link linkend='var-TUNEABI_OVERRIDE'><filename>TUNEABI_OVERRIDE</filename></link>,
|
|
and
|
|
<link linkend='var-TUNEABI_WHITELIST'><filename>TUNEABI_WHITELIST</filename></link>
|
|
variables to check compatibility of tunings against their
|
|
selection of libraries.
|
|
</para>
|
|
|
|
<para>
|
|
If <filename>TUNEABI</filename> is undefined, then every
|
|
tuning is allowed.
|
|
See the
|
|
<link linkend='ref-classes-sanity'><filename>sanity</filename></link>
|
|
class to see how the variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNEABI_OVERRIDE'><glossterm>TUNEABI_OVERRIDE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
If set, the OpenEmbedded system ignores the
|
|
<link linkend='var-TUNEABI_WHITELIST'><filename>TUNEABI_WHITELIST</filename></link>
|
|
variable.
|
|
Providers that use prebuilt libraries can use the
|
|
<filename>TUNEABI_OVERRIDE</filename>,
|
|
<filename>TUNEABI_WHITELIST</filename>,
|
|
and
|
|
<link linkend='var-TUNEABI'><filename>TUNEABI</filename></link>
|
|
variables to check compatibility of a tuning against their
|
|
selection of libraries.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-sanity'><filename>sanity</filename></link>
|
|
class to see how the variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNEABI_WHITELIST'><glossterm>TUNEABI_WHITELIST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A whitelist of permissible
|
|
<link linkend='var-TUNEABI'><filename>TUNEABI</filename></link>
|
|
values.
|
|
If <filename>TUNEABI_WHITELIST</filename> is not set,
|
|
all tunes are allowed.
|
|
Providers that use prebuilt libraries can use the
|
|
<filename>TUNEABI_WHITELIST</filename>,
|
|
<link linkend='var-TUNEABI_OVERRIDE'><filename>TUNEABI_OVERRIDE</filename></link>,
|
|
and <filename>TUNEABI</filename> variables to check
|
|
compatibility of a tuning against their selection of
|
|
libraries.
|
|
</para>
|
|
|
|
<para>
|
|
See the
|
|
<link linkend='ref-classes-sanity'><filename>sanity</filename></link>
|
|
class to see how the variable is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNECONFLICT'><glossterm>TUNECONFLICT[<feature>]</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies CPU or Application Binary Interface (ABI)
|
|
tuning features that conflict with >feature<.
|
|
</para>
|
|
|
|
<para>
|
|
Known tuning conflicts are specified in the machine include
|
|
files in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
Here is an example from the
|
|
<filename>meta/conf/machine/include/mips/arch-mips.inc</filename>
|
|
include file that lists the "o32" and "n64" features as
|
|
conflicting with the "n32" feature:
|
|
<literallayout class='monospaced'>
|
|
TUNECONFLICTS[n32] = "o32 n64"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TUNEVALID'><glossterm>TUNEVALID[<feature>]</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a valid CPU or Application Binary Interface (ABI)
|
|
tuning feature.
|
|
The specified feature is stored as a flag.
|
|
Valid features are specified in the machine include files
|
|
(e.g. <filename>meta/conf/machine/include/arm/arch-arm.inc</filename>).
|
|
Here is an example from that file:
|
|
<literallayout class='monospaced'>
|
|
TUNEVALID[bigendian] = "Enable big-endian mode."
|
|
</literallayout>
|
|
See the machine include files in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
|
for these features.
|
|
</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>
|
|
|
|
<para>
|
|
Please see the "Selection of Processor Architecture and
|
|
Board Type" section in the U-Boot README for valid values
|
|
for this variable.
|
|
</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-USE_VT'><glossterm>USE_VT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When using
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services'>SysVinit</ulink>,
|
|
determines whether or not to run a
|
|
<ulink url='http://en.wikipedia.org/wiki/Getty_%28Unix%29'>getty</ulink>
|
|
on any virtual terminals in order to enable logging in
|
|
through those terminals.
|
|
</para>
|
|
|
|
<para>
|
|
The default value used for <filename>USE_VT</filename>
|
|
is "1" when no default value is specifically set.
|
|
Typically, you would set <filename>USE_VT</filename>
|
|
to "0" in the machine configuration file for machines
|
|
that do not have a graphical display attached and
|
|
therefore do not need virtual terminal functionality.
|
|
</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_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Forces the OpenEmbedded build system to produce an error
|
|
if the user identification (<filename>uid</filename>) and
|
|
group identification (<filename>gid</filename>) values
|
|
are not defined in <filename>files/passwd</filename>
|
|
and <filename>files/group</filename> files.
|
|
</para>
|
|
|
|
<para>
|
|
The default behavior for the build system is to dynamically
|
|
apply <filename>uid</filename> and
|
|
<filename>gid</filename> values.
|
|
Consequently, the <filename>USERADD_ERROR_DYNAMIC</filename>
|
|
variable is by default not set.
|
|
If you plan on using statically assigned
|
|
<filename>gid</filename> and <filename>uid</filename>
|
|
values, you should set
|
|
the <filename>USERADD_ERROR_DYNAMIC</filename> variable in
|
|
your <filename>local.conf</filename> file as
|
|
follows:
|
|
<literallayout class='monospaced'>
|
|
USERADD_ERROR_DYNAMIC = "1"
|
|
</literallayout>
|
|
Overriding the default behavior implies you are going to
|
|
also take steps to set static <filename>uid</filename> and
|
|
<filename>gid</filename> values through use of the
|
|
<link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>,
|
|
<link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>,
|
|
and
|
|
<link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
|
|
variables.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-USERADD_GID_TABLES'><glossterm>USERADD_GID_TABLES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a password file to use for obtaining static
|
|
group identification (<filename>gid</filename>) values
|
|
when the OpenEmbedded build system adds a group to the
|
|
system during package installation.
|
|
</para>
|
|
|
|
<para>
|
|
When applying static group identification
|
|
(<filename>gid</filename>) values, the OpenEmbedded build
|
|
system looks in
|
|
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>
|
|
for a <filename>files/group</filename> file and then applies
|
|
those <filename>uid</filename> values.
|
|
Set the variable as follows in your
|
|
<filename>local.conf</filename> file:
|
|
<literallayout class='monospaced'>
|
|
USERADD_GID_TABLES = "files/group"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<note>
|
|
Setting the
|
|
<link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>
|
|
variable to "useradd-staticids" causes the build system
|
|
to use static <filename>gid</filename> values.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-USERADD_UID_TABLES'><glossterm>USERADD_UID_TABLES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies a password file to use for obtaining static
|
|
user identification (<filename>uid</filename>) values
|
|
when the OpenEmbedded build system adds a user to the
|
|
system during package installation.
|
|
</para>
|
|
|
|
<para>
|
|
When applying static user identification
|
|
(<filename>uid</filename>) values, the OpenEmbedded build
|
|
system looks in
|
|
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>
|
|
for a <filename>files/passwd</filename> file and then applies
|
|
those <filename>uid</filename> values.
|
|
Set the variable as follows in your
|
|
<filename>local.conf</filename> file:
|
|
<literallayout class='monospaced'>
|
|
USERADD_UID_TABLES = "files/passwd"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<note>
|
|
Setting the
|
|
<link linkend='var-USERADDEXTENSION'><filename>USERADDEXTENSION</filename></link>
|
|
variable to "useradd-staticids" causes the build system
|
|
to use static <filename>uid</filename> values.
|
|
</note>
|
|
</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>
|
|
|
|
<glossentry id='var-USERADDEXTENSION'><glossterm>USERADDEXTENSION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When set to "useradd-staticids", causes the
|
|
OpenEmbedded build system to base all user and group
|
|
additions on a static
|
|
<filename>passwd</filename> and
|
|
<filename>group</filename> files found in
|
|
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>.
|
|
</para>
|
|
|
|
<para>
|
|
To use static user identification (<filename>uid</filename>)
|
|
and group identification (<filename>gid</filename>)
|
|
values, set the variable
|
|
as follows in your <filename>local.conf</filename> file:
|
|
<literallayout class='monospaced'>
|
|
USERADDEXTENSION = "useradd-staticids"
|
|
</literallayout>
|
|
<note>
|
|
Setting this variable to use static
|
|
<filename>uid</filename> and <filename>gid</filename>
|
|
values causes the OpenEmbedded build system to employ
|
|
the
|
|
<link linkend='ref-classes-useradd-staticids'><filename>useradd-staticids</filename></link>
|
|
class.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
If you use static <filename>uid</filename> and
|
|
<filename>gid</filename> information, you must also
|
|
specify the <filename>files/passwd</filename> and
|
|
<filename>files/group</filename> files by setting the
|
|
<link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>
|
|
and
|
|
<link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
|
|
variables.
|
|
Additionally, you should also set the
|
|
<link linkend='var-USERADD_ERROR_DYNAMIC'><filename>USERADD_ERROR_DYNAMIC</filename></link>
|
|
variable.
|
|
</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 is specific to the recipe being
|
|
built and the system for which it is being built.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>WORKDIR</filename> directory is defined as
|
|
follows:
|
|
<literallayout class='monospaced'>
|
|
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
|
|
</literallayout>
|
|
The actual directory depends on several things:
|
|
<itemizedlist>
|
|
<listitem><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>:
|
|
The top-level build output directory</listitem>
|
|
<listitem><link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>:
|
|
The target system identifier</listitem>
|
|
<listitem><link linkend='var-PN'><filename>PN</filename></link>:
|
|
The recipe name</listitem>
|
|
<listitem><link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>:
|
|
The epoch - (if
|
|
<link linkend='var-PE'><filename>PE</filename></link>
|
|
is not specified, which is usually the case for most
|
|
recipes, then <filename>EXTENDPE</filename> is blank)</listitem>
|
|
<listitem><link linkend='var-PV'><filename>PV</filename></link>:
|
|
The recipe version</listitem>
|
|
<listitem><link linkend='var-PR'><filename>PR</filename></link>:
|
|
The recipe revision</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
As an example, assume a Source Directory top-level folder
|
|
name <filename>poky</filename>, a default Build Directory at
|
|
<filename>poky/build</filename>, and a
|
|
<filename>qemux86-poky-linux</filename> machine target
|
|
system.
|
|
Furthermore, suppose your recipe is named
|
|
<filename>foo_1.3.0-r0.bb</filename>.
|
|
In this case, the work directory the build system uses to
|
|
build the package would be as follows:
|
|
<literallayout class='monospaced'>
|
|
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
|
|
</literallayout>
|
|
</para>
|
|
</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
|
|
-->
|