3511 lines
177 KiB
XML
3511 lines
177 KiB
XML
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
|
|
|
<!-- Dummy chapter -->
|
|
<chapter id='ref-variables-glos'>
|
|
|
|
<title>Variables Glossary</title>
|
|
|
|
<para>
|
|
This chapter lists common variables used in the OpenEmbedded build system and gives an overview
|
|
of their function and contents.
|
|
</para>
|
|
|
|
<glossary id='ref-variables-glossary'>
|
|
|
|
|
|
<para>
|
|
<link linkend='var-ALLOW_EMPTY'>A</link>
|
|
<link linkend='var-B'>B</link>
|
|
<link linkend='var-CFLAGS'>C</link>
|
|
<link linkend='var-D'>D</link>
|
|
<link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>E</link>
|
|
<link linkend='var-FILES'>F</link>
|
|
<!-- <link linkend='var-glossary-g'>G</link> -->
|
|
<link linkend='var-HOMEPAGE'>H</link>
|
|
<link linkend='var-IMAGE_FEATURES'>I</link>
|
|
<!-- <link linkend='var-glossary-j'>J</link> -->
|
|
<link linkend='var-KARCH'>K</link>
|
|
<link linkend='var-LAYERDEPENDS'>L</link>
|
|
<link linkend='var-MACHINE'>M</link>
|
|
<!-- <link linkend='var-glossary-n'>N</link> -->
|
|
<link linkend='var-OE_TERMINAL'>O</link>
|
|
<link linkend='var-P'>P</link>
|
|
<!-- <link linkend='var-glossary-q'>Q</link> -->
|
|
<link linkend='var-RCONFLICTS'>R</link>
|
|
<link linkend='var-S'>S</link>
|
|
<link linkend='var-T'>T</link>
|
|
<!-- <link linkend='var-glossary-u'>U</link> -->
|
|
<!-- <link linkend='var-glossary-v'>V</link> -->
|
|
<link linkend='var-WORKDIR'>W</link>
|
|
<!-- <link linkend='var-glossary-x'>X</link> -->
|
|
<!-- <link linkend='var-glossary-y'>Y</link> -->
|
|
<!-- <link linkend='var-glossary-z'>Z</link>-->
|
|
</para>
|
|
|
|
<glossdiv id='var-glossary-a'><title>A</title>
|
|
|
|
<glossentry id='var-ALLOW_EMPTY'><glossterm>ALLOW_EMPTY</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies if an output package should still be produced if it is empty.
|
|
By default, BitBake does not produce empty packages.
|
|
This default behavior can cause issues when there is an
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> or
|
|
some other runtime hard-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.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
ALLOW_EMPTY_${PN} = "1"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
|
|
<glossdef>
|
|
<para>The email address used to contact the original author
|
|
or authors in order to send patches and forward bugs.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
|
|
<glossdef>
|
|
<para>When <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
|
|
is set to the value of this variable, it specifies to use the latest
|
|
source revision in the repository.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
SRCREV = "${AUTOREV}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-b'><title>B</title>
|
|
|
|
<glossentry id='var-B'><glossterm>B</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
The OpenEmbedded build system places generated objects into the Build Directory
|
|
during a recipe's build process.
|
|
By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
|
|
directory:
|
|
<literallayout class='monospaced'>
|
|
B = ${WORKDIR}/${BPN}/{PV}/
|
|
</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>
|
|
A list of packages not to install despite being recommended by a recipe.
|
|
Support for this variable exists only when using the
|
|
IPK packaging backend.
|
|
</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" in the <filename>local.conf</filename>
|
|
file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
as follows:
|
|
<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-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-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-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
|
|
<glossdef>
|
|
<para>The maximum number of tasks BitBake should run in parallel at any one time.
|
|
If your host development system supports multiple cores a good rule of thumb
|
|
is to set this variable to twice the number of cores.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-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-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.</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>
|
|
Core layer for images cannot be removed
|
|
<para>Lists core layers that cannot be removed from the
|
|
<filename>bblayers.conf</filename> file.
|
|
In order for BitBake to build your image, 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-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-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>
|
|
script by passing in a Build Directory path when you run the
|
|
script.
|
|
If you run the script and do not provide a Build Directory
|
|
path, the <filename>BUILDDIR</filename> defaults to
|
|
<filename>build</filename> in the current directory.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-c'><title>C</title>
|
|
|
|
<glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Flags passed to the C compiler for the target system.
|
|
This variable evaluates to the same as
|
|
<filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMBINED_FEATURES'><glossterm>COMBINED_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>A set of features common between
|
|
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
|
|
and <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
|
|
See the glossary descriptions for these variables for more information.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
|
|
<glossdef>
|
|
<para>A regular expression that evaluates to match the machines
|
|
with which the recipe works.
|
|
You can use the variable to stop recipes from being run
|
|
on machines for which they are not compatible.
|
|
This is particularly useful with kernels.
|
|
The variable also helps to increase parsing speed as
|
|
further parsing of the recipe is skipped if it is found
|
|
the current machine is not compatible.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CONFFILES'><glossterm>CONFFILES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Identifies editable or configurable files that are part of a package.
|
|
If the Package Management System (PMS) is being used to update
|
|
packages on the target system, it is possible that
|
|
configuration files you have changed after the original installation
|
|
and that you now want to remain unchanged are overwritten.
|
|
In other words, editable files might exist in the package that you do not
|
|
want reset as part of the package update process.
|
|
You can use the <filename>CONFFILES</filename> variable to list the files in the
|
|
package that you wish to prevent the PMS from overwriting during this update process.
|
|
</para>
|
|
|
|
<para>
|
|
To use the <filename>CONFFILES</filename> variable, provide a package name
|
|
override that identifies the resulting package.
|
|
Then, provide a space-separated list of files.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
CONFFILES_${PN} += "${sysconfdir}/file1 \
|
|
${sysconfdir}/file2 ${sysconfdir}/file3"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
A relationship exists between the <filename>CONFFILES</filename> and
|
|
<filename><link linkend='var-FILES'>FILES</link></filename> variables.
|
|
The files listed within <filename>CONFFILES</filename> must be a subset of
|
|
the files listed within <filename>FILES</filename>.
|
|
Because the configuration files you provide with <filename>CONFFILES</filename>
|
|
are simply being identified so that the PMS will not overwrite them,
|
|
it makes sense that
|
|
the files must already be included as part of the package through the
|
|
<filename>FILES</filename> variable.
|
|
</para>
|
|
|
|
<note>
|
|
When specifying paths as part of the <filename>CONFFILES</filename> variable,
|
|
it is good practice to use appropriate path variables.
|
|
For example, <filename>${sysconfdir}</filename> rather than
|
|
<filename>/etc</filename> or <filename>${bindir}</filename> rather
|
|
than <filename>/usr/bin</filename>.
|
|
You can find a list of these variables at the top of the
|
|
<filename>/meta/conf/bitbake.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of files that contains <filename>autoconf</filename> test results relevant
|
|
to the current build.
|
|
This variable is used by the Autotools utilities when running
|
|
<filename>configure</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-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>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-d'><title>D</title>
|
|
|
|
<glossentry id='var-D'><glossterm>D</glossterm>
|
|
<glossdef>
|
|
<para>The destination directory.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-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 -g".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the priority of recipes.</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>
|
|
</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-DESTDIR'><glossterm>DESTDIR</glossterm>
|
|
<glossdef>
|
|
<para>the destination directory.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The short name of the distribution.
|
|
This variable corresponds to a file with the
|
|
extension <filename>.conf</filename>
|
|
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 must not contain spaces, and is typically all lower-case.
|
|
</para>
|
|
<para>
|
|
If the variable is blank, a set of default configuration
|
|
will be used, which is specified
|
|
within <filename>meta/conf/distro/defaultsetup.conf</filename>.
|
|
</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 features enabled for the distribution.
|
|
For a list of supported features that ship with the
|
|
Yocto Project, see the
|
|
"<link linkend='ref-features-distro'>Distro</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-DL_DIR'><glossterm>DL_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The central download directory used by the build process to store downloads.
|
|
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 uncomment 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-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-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>
|
|
Use the
|
|
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
|
|
variable from within a recipe to define the primary
|
|
list of features you want to add to the image.
|
|
</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">Images</link>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
For an example that shows how to customize your image by
|
|
using this variable, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
|
|
section in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_IMAGEDEPENDS'><glossterm>EXTRA_IMAGEDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>A list of recipes to build that do not provide packages
|
|
for installing into the root filesystem.
|
|
</para>
|
|
<para>Sometimes a recipe is required to build the final image but is not
|
|
needed in the root filesystem.
|
|
You can use the <filename>EXTRA_IMAGEDEPENDS</filename> variable to
|
|
list these recipes and thus, specify the dependencies.
|
|
A typical example is a required bootloader in a machine configuration.
|
|
</para>
|
|
<note>
|
|
To add packages to the root filesystem, see the various
|
|
<filename>*<link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
|
|
and <filename>*<link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></filename>
|
|
variables.
|
|
</note>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
|
|
<glossdef>
|
|
<para>Additional <filename>cmake</filename> options.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_OECONF'><glossterm>EXTRA_OECONF</glossterm>
|
|
<glossdef>
|
|
<para>Additional <filename>configure</filename> script options.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-EXTRA_OEMAKE'><glossterm>EXTRA_OEMAKE</glossterm>
|
|
<glossdef>
|
|
<para>Additional GNU <filename>make</filename> options.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-f'><title>F</title>
|
|
|
|
<glossentry id='var-FILES'><glossterm>FILES</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of directories or files that are placed in packages.
|
|
</para>
|
|
|
|
<para>
|
|
To use the <filename>FILES</filename> variable, provide a package name
|
|
override that identifies the resulting package.
|
|
Then, provide a space-separated list of files or paths that identifies the
|
|
files you want included as part of the resulting package.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<note>
|
|
When specifying paths as part of the <filename>FILES</filename> variable,
|
|
it is good practice to use appropriate path variables.
|
|
For example, <filename>${sysconfdir}</filename> rather than
|
|
<filename>/etc</filename> or <filename>${bindir}</filename> rather
|
|
than <filename>/usr/bin</filename>.
|
|
You can find a list of these variables at the top of the
|
|
<filename>/meta/conf/bitbake.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</note>
|
|
|
|
<para>
|
|
If some of the files you provide with the <filename>FILES</filename> variable
|
|
are editable and you know they should not be
|
|
overwritten during the package update process by the Package Management
|
|
System (PMS), you can identify these files so that the PMS will not
|
|
overwrite them.
|
|
See the <filename><link linkend='var-CONFFILES'>CONFFILES</link></filename>
|
|
variable for information on how to identify these files to the PMS.
|
|
</para>
|
|
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Extends the search path the OpenEmbedded build system uses
|
|
when looking for files and patches as it processes recipes.
|
|
The directories BitBake uses when it processes recipes are
|
|
defined by the
|
|
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable.
|
|
You can add directories to the search path by defining the
|
|
<filename>FILESEXTRAPATHS</filename> variable.
|
|
</para>
|
|
|
|
<para>
|
|
To add paths to the front of the search order, prepend
|
|
them and use the immediate expansion
|
|
(<filename>:=</filename>) operator.
|
|
Provide a list of directories and separate
|
|
each path using a colon character as follows:
|
|
<literallayout class='monospaced'>
|
|
FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
|
|
</literallayout>
|
|
You can add paths to the end of the search order by simply
|
|
adding them as follows:
|
|
<literallayout class='monospaced'>
|
|
FILESEXTRAPATHS := "path_1:path_2:path_3:"
|
|
</literallayout>
|
|
To maintain the integrity of the
|
|
<filename>FILESPATH</filename> variable, you must include
|
|
the appropriate beginning or ending (as needed) colon
|
|
character.
|
|
</para>
|
|
|
|
<para>
|
|
The <filename>FILESEXTRAPATHS</filename> variable is
|
|
intended for use in <filename>.bbappend</filename> files
|
|
to include any additional files provided in that layer.
|
|
You typically accomplish this with the following:
|
|
<literallayout class='monospaced'>
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
|
</literallayout>
|
|
</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>
|
|
Do not hand-edit the <filename>FILESPATH</filename> variable.
|
|
If you want to extend the set of pathnames that BitBake uses when searching for
|
|
files and patches, use 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 distros layer.
|
|
</para>
|
|
<para>
|
|
You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
|
|
<filename>conf/local.conf</filename> file, which is found in the
|
|
<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-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
|
|
"-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-g'><title>G</title>-->
|
|
<!-- </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>
|
|
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-i'><title>I</title>
|
|
|
|
<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>
|
|
Add extra features to the image by using 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">Images</link>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
For 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>Formats of root filesystem images that you want to have created.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the packages to install into an image.
|
|
The <filename>IMAGE_INSTALL</filename> variable is a mechanism for an image
|
|
recipe and you should use it with care to avoid ordering issues.
|
|
</para>
|
|
|
|
<para>
|
|
Image recipes set <filename>IMAGE_INSTALL</filename> to specify the
|
|
packages to install into an image through <filename>image.bbclass</filename>.
|
|
Additionally, "helper" classes exist, such as <filename>core-image.bbclass</filename>,
|
|
that can take
|
|
<filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename> lists
|
|
and turn these into auto-generated entries in
|
|
<filename>IMAGE_INSTALL</filename> in addition to its default contents.
|
|
</para>
|
|
|
|
<para>
|
|
Using <filename>IMAGE_INSTALL</filename> with the <filename>+=</filename>
|
|
operator from the <filename>/conf/local.conf</filename> file or from within
|
|
an image recipe is not recommended as it can cause ordering issues.
|
|
Since <filename>core-image.bbclass</filename> sets <filename>IMAGE_INSTALL</filename>
|
|
to a default value using the <filename>?=</filename> operator, using a
|
|
<filename>+=</filename> operation against <filename>IMAGE_INSTALL</filename>
|
|
will result in unexpected behavior when used in
|
|
<filename>/conf/local.conf</filename>.
|
|
Furthermore, the same operation from with 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.
|
|
</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
|
|
<filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
|
|
the variable.
|
|
</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>
|
|
</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-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-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
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-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_NAME'><glossterm>INITSCRIPT_NAME</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The filename of the initscript as installed to <filename>${etcdir}/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_PARAMS'><glossterm>INITSCRIPT_PARAMS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the options to pass to <filename>update-rc.d</filename>.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
|
|
</literallayout>
|
|
In this example, the script has a runlevel of 99,
|
|
starts the script in initlevels 2 and 5, and
|
|
stops the script in levels 0, 1 and 6.
|
|
</para>
|
|
<para>
|
|
The variable is mandatory and is used in recipes when using
|
|
<filename>update-rc.d.bbclass</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
|
|
</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
|
|
arm
|
|
i386
|
|
mips
|
|
powerpc
|
|
x86_64
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
You define the <filename>KARCH</filename> variable in the
|
|
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KBRANCH'><glossterm>KBRANCH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A regular expression used by the build process to explicitly identify the kernel
|
|
branch that is validated, patched and configured during a build.
|
|
The <filename>KBRANCH</filename> variable is optional.
|
|
You can use it to trigger checks to ensure the exact kernel branch you want is
|
|
being used by the build process.
|
|
</para>
|
|
|
|
<para>
|
|
Values for this variable are set in the kernel's recipe file and the kernel's
|
|
append file.
|
|
For example, if you are using the Yocto Project kernel that is based on the
|
|
Linux 3.4 kernel, the kernel recipe file is the
|
|
<filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename> file.
|
|
Following is the default value for <filename>KBRANCH</filename> and the default
|
|
override for the architectures the Yocto Project supports:
|
|
<literallayout class='monospaced'>
|
|
KBRANCH_DEFAULT = "standard/base"
|
|
KBRANCH = "${KBRANCH_DEFAULT}"
|
|
</literallayout>
|
|
This branch exists in the <filename>linux-yocto-3.4</filename> kernel Git
|
|
repository <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
This variable is also used from the kernel's append file to identify the kernel
|
|
branch specific to a particular machine or target hardware.
|
|
The kernel's append file is located in the BSP layer for a given machine.
|
|
For example, the kernel append file for the Crown Bay BSP is in the
|
|
<filename>meta-intel</filename> Git repository and is named
|
|
<filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend</filename>.
|
|
Here are the related statements from the append file:
|
|
<literallayout class='monospaced'>
|
|
COMPATIBLE_MACHINE_crownbay = "crownbay"
|
|
KMACHINE_crownbay = "crownbay"
|
|
KBRANCH_crownbay = "standard/crownbay"
|
|
|
|
COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
|
|
KMACHINE_crownbay-noemgd = "crownbay"
|
|
KBRANCH_crownbay-noemgd = "standard/crownbay"
|
|
</literallayout>
|
|
The <filename>KBRANCH_*</filename> statements identify the kernel branch to
|
|
use when building for the Crown Bay BSP.
|
|
In this case there are two identical statements: one for each type of
|
|
Crown Bay machine.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KBRANCH_DEFAULT'><glossterm>KBRANCH_DEFAULT</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the Linux kernel source repository's default
|
|
branch used to build the Linux kernel.
|
|
The <filename>KBRANCH_DEFAULT</filename> value is
|
|
the default value for
|
|
<link linkend='var-KBRANCH'><filename>KBRANCH</filename></link>.
|
|
Unless you specify otherwise,
|
|
<filename>KBRANCH_DEFAULT</filename> initializes to
|
|
"master".
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>Includes additional metadata from the Yocto Project kernel Git repository.
|
|
In the OpenEmbedded build system, the default Board Support Packages (BSPs)
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
|
|
is provided through
|
|
the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
|
|
and <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link> variables.
|
|
You can use the <filename>KERNEL_FEATURES</filename> variable to further
|
|
add metadata for all BSPs.</para>
|
|
<para>The metadata you add through this variable includes config fragments and
|
|
features descriptions,
|
|
which usually includes patches as well as config fragments.
|
|
You typically override the <filename>KERNEL_FEATURES</filename> variable
|
|
for a specific machine.
|
|
In this way, you can provide validated, but optional, sets of kernel
|
|
configurations and features.</para>
|
|
<para>For example, the following adds <filename>netfilter</filename> to all
|
|
the Yocto Project kernels and adds sound support to the <filename>qemux86</filename>
|
|
machine:
|
|
<literallayout class='monospaced'>
|
|
# Add netfilter to all linux-yocto kernels
|
|
KERNEL_FEATURES="features/netfilter"
|
|
|
|
# Add sound support to the qemux86 machine
|
|
KERNEL_FEATURES_append_qemux86=" cfg/sound"
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
|
|
<glossdef>
|
|
<para>The type of kernel to build for a device, usually set by the
|
|
machine configuration files and defaults to "zImage".
|
|
This variable is used
|
|
when building the kernel and is passed to <filename>make</filename> as the target to
|
|
build.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_PATH'><glossterm>KERNEL_PATH</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location of the kernel sources.
|
|
This variable is set to the value of the
|
|
<link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
|
|
within the <filename>module.bbclass</filename> class.
|
|
For information on how this variable is used, see the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
The <link linkend='var-KERNEL_SRC'><filename>KERNEL_SRC</filename></link>
|
|
variable is identical to the <filename>KERNEL_PATH</filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KERNEL_SRC'><glossterm>KERNEL_SRC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The location of the kernel sources.
|
|
This variable is set to the value of the
|
|
<link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
|
|
within the <filename>module.bbclass</filename> class.
|
|
For information on how this variable is used, see the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
The <link linkend='var-KERNEL_PATH'><filename>KERNEL_PATH</filename></link>
|
|
variable is identical to the <filename>KERNEL_SRC</filename>
|
|
variable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KFEATURE_DESCRIPTION'><glossterm>KFEATURE_DESCRIPTION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Provides a short description of a configuration fragment.
|
|
You use this variable in the <filename>.scc</filename>
|
|
file that describes a configuration fragment file.
|
|
Here is the variable used in a file named
|
|
<filename>smp.scc</filename> to describe SMP being
|
|
enabled:
|
|
<literallayout class='monospaced'>
|
|
define KFEATURE_DESCRIPTION "Enable SMP"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KMACHINE'><glossterm>KMACHINE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The machine as known by the kernel.
|
|
Sometimes the machine name used by the kernel does not match the machine name
|
|
used by the OpenEmbedded build system.
|
|
For example, the machine name that the OpenEmbedded build system understands as
|
|
<filename>qemuarm</filename> goes by a different name in the Linux Yocto kernel.
|
|
The kernel understands that machine as <filename>arm_versatile926ejs</filename>.
|
|
For cases like these, the <filename>KMACHINE</filename> variable maps the
|
|
kernel machine name to the OpenEmbedded build system machine name.
|
|
</para>
|
|
|
|
<para>
|
|
Kernel machine names are initially defined in the
|
|
Yocto Linux Kernel's <filename>meta</filename> branch.
|
|
From the <filename>meta</filename> branch, look in
|
|
the <filename>meta/cfg/kernel-cache/bsp/<bsp_name>/<bsp-name>-<kernel-type>.scc</filename> file.
|
|
For example, from the <filename>meta</filename> branch in the
|
|
<filename>linux-yocto-3.0</filename> kernel, the
|
|
<filename>meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</filename> file
|
|
has the following:
|
|
<literallayout class='monospaced'>
|
|
define KMACHINE cedartrail
|
|
define KTYPE standard
|
|
define KARCH i386
|
|
|
|
include ktypes/standard
|
|
branch cedartrail
|
|
|
|
include cedartrail.scc
|
|
</literallayout>
|
|
You can see that the kernel understands the machine name for
|
|
the Cedar Trail Board Support Package (BSP) as
|
|
<filename>cedartrail</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
If you look in the Cedar Trail BSP layer in the
|
|
<filename>meta-intel</filename>
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
|
|
at <filename>meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>,
|
|
you will find the following statements among others:
|
|
<literallayout class='monospaced'>
|
|
COMPATIBLE_MACHINE_cedartrail = "cedartrail"
|
|
KMACHINE_cedartrail = "cedartrail"
|
|
KBRANCH_cedartrail = "yocto/standard/cedartrail"
|
|
KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc"
|
|
KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc"
|
|
|
|
COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
|
|
KMACHINE_cedartrail-nopvr = "cedartrail"
|
|
KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
|
|
KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
|
|
</literallayout>
|
|
The <filename>KMACHINE</filename> statements in the kernel's append file make sure that
|
|
the OpenEmbedded build system and the Yocto Linux kernel understand the same machine
|
|
names.
|
|
</para>
|
|
|
|
<para>
|
|
This append file uses two <filename>KMACHINE</filename> statements.
|
|
The first is not really necessary but does ensure that the machine known to the
|
|
OpenEmbedded build system as <filename>cedartrail</filename> maps to the machine
|
|
in the kernel also known as <filename>cedartrail</filename>:
|
|
<literallayout class='monospaced'>
|
|
KMACHINE_cedartrail = "cedartrail"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
The second statement is a good example of why the <filename>KMACHINE</filename> variable
|
|
is needed.
|
|
In this example, the OpenEmbedded build system uses the <filename>cedartrail-nopvr</filename>
|
|
machine name to refer to the Cedar Trail BSP that does not support the proprietary
|
|
PowerVR driver.
|
|
The kernel, however, uses the machine name <filename>cedartrail</filename>.
|
|
Thus, the append file must map the <filename>cedartrail-nopvr</filename> machine name to
|
|
the kernel's <filename>cedartrail</filename> name:
|
|
<literallayout class='monospaced'>
|
|
KMACHINE_cedartrail-nopvr = "cedartrail"
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
BSPs that ship with the Yocto Project release provide all mappings between the Yocto
|
|
Project kernel machine names and the OpenEmbedded machine names.
|
|
Be sure to use the <filename>KMACHINE</filename> if you create a BSP and the machine
|
|
name you use is different than that used in the kernel.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-KTYPE'><glossterm>KTYPE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Defines the kernel type to be used in assembling the
|
|
configuration.
|
|
The linux-yocto recipes define "standard", "tiny",
|
|
and "preempt-rt" kernel types.
|
|
See the
|
|
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
|
|
section in the Yocto Project Linux Kernel Development
|
|
Manual for more information on kernel types.
|
|
</para>
|
|
|
|
<para>
|
|
You define the <filename>KTYPE</filename> variable in the
|
|
<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
|
|
The value you use must match the value used for the
|
|
<link linkend='var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></link>
|
|
value used by the kernel recipe.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-l'><title>L</title>
|
|
|
|
<glossentry id='var-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 requires immediate expansion
|
|
(see the BitBake manual) as lazy expansion can result in
|
|
the expansion happening in the wrong directory and therefore
|
|
giving the wrong value.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
|
|
<glossdef>
|
|
<para>Optionally specifies the version of a layer as a single number.
|
|
You can use this within
|
|
<link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
|
|
for another layer in order to depend on a specific version
|
|
of the layer.
|
|
This variable is used in the <filename>conf/layer.conf</filename> file
|
|
and must be suffixed with the name of the specific layer (e.g.
|
|
<filename>LAYERVERSION_mylayer</filename>).</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm>
|
|
<glossdef>
|
|
<para>Checksums of the license text in the recipe source code.</para>
|
|
<para>This variable tracks changes in license text of the source
|
|
code files.
|
|
If the license text is changed, it will trigger a build
|
|
failure, which gives the developer an opportunity to review any
|
|
license change.</para>
|
|
<para>
|
|
This variable must be defined for all recipes (unless
|
|
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
|
|
is set to "CLOSED")</para>
|
|
<para>For more information, see the
|
|
<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
|
|
Tracking License Changes</link> section</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The list of source licenses for the recipe.
|
|
Follow these rules:
|
|
<itemizedlist>
|
|
<listitem><para>Do not use spaces within individual
|
|
license names.</para></listitem>
|
|
<listitem><para>Separate license names using
|
|
| (pipe) when there is a choice between licenses.
|
|
</para></listitem>
|
|
<listitem><para>Separate license names using
|
|
& (ampersand) when multiple licenses exist
|
|
that cover different parts of the source.
|
|
</para></listitem>
|
|
<listitem><para>You can use spaces between license
|
|
names.</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
Here are some examples:
|
|
<literallayout class='monospaced'>
|
|
LICENSE = "LGPLv2.1 | GPLv3"
|
|
LICENSE = "MPL-1 & LGPLv2.1"
|
|
LICENSE = "GPLv2+"
|
|
</literallayout>
|
|
The first example is from the recipes for Qt, which the user
|
|
may choose to distribute under either the LGPL version
|
|
2.1 or GPL version 3.
|
|
The second example is from Cairo where two licenses cover
|
|
different parts of the source code.
|
|
The final example is from <filename>sysstat</filename>,
|
|
which presents a single license.
|
|
</para>
|
|
</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>
|
|
|
|
</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 ?= "atom-pc"
|
|
MACHINE ?= "beagleboard"
|
|
MACHINE ?= "mpc8315e-rdb"
|
|
MACHINE ?= "routerstationpro"
|
|
</literallayout>
|
|
The last four are Yocto Project reference hardware boards, which
|
|
are provided in the <filename>meta-yocto-bsp</filename> layer.
|
|
<note>Adding additional Board Support Package (BSP) layers
|
|
to your configuration adds new possible settings for
|
|
<filename>MACHINE</filename>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
A list of required machine-specific packages to install as part of
|
|
the image being built.
|
|
The build process depends on these packages being present.
|
|
Furthermore, because this is a "machine essential" variable, the list of
|
|
packages are essential for the machine to boot.
|
|
The impact of this variable affects images based on
|
|
<filename>packagegroup-core-boot</filename>,
|
|
including the <filename>core-image-minimal</filename> image.
|
|
</para>
|
|
<para>
|
|
This variable is similar to the
|
|
<filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename>
|
|
variable with the exception that the image being built has a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will not build if a file in this list is not found.
|
|
</para>
|
|
<para>
|
|
As an example, suppose the machine for which you are building requires
|
|
<filename>example-init</filename> to be run during boot to initialize the hardware.
|
|
In this case, you would use the following in the machine's
|
|
<filename>.conf</filename> configuration file:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
A list of recommended machine-specific packages to install as part of
|
|
the image being built.
|
|
The build process does not depend on these packages being present.
|
|
However, because this is a "machine essential" variable, the list of
|
|
packages are essential for the machine to boot.
|
|
The impact of this variable affects images based on
|
|
<filename>packagegroup-core-boot</filename>,
|
|
including the <filename>core-image-minimal</filename> image.
|
|
</para>
|
|
<para>
|
|
This variable is similar to the
|
|
<filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename>
|
|
variable with the exception that the image being built does not have a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will still build if a package in this list is not found.
|
|
Typically, this variable is used to handle essential kernel modules, whose
|
|
functionality may be selected to be built into the kernel rather than as a module,
|
|
in which case a package will not be produced.
|
|
</para>
|
|
<para>
|
|
Consider an example where you have a custom kernel where a specific touchscreen
|
|
driver is required for the machine to be usable.
|
|
However, the driver can be built as a module or
|
|
into the kernel depending on the kernel configuration.
|
|
If the driver is built as a module, you want it to be installed.
|
|
But, when the driver is built into the kernel, you still want the
|
|
build to succeed.
|
|
This variable sets up a "recommends" relationship so that in the latter case,
|
|
the build will not fail due to the missing package.
|
|
To accomplish this, assuming the package for the module was called
|
|
<filename>kernel-module-ab123</filename>, you would use the
|
|
following in the machine's <filename>.conf</filename> configuration
|
|
file:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
|
|
</literallayout>
|
|
</para>
|
|
<para>
|
|
Some examples of these machine essentials are flash, screen, keyboard, mouse,
|
|
or touchscreen drivers (depending on the machine).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A list of machine-specific packages to install as part of the
|
|
image being built that are not essential for the machine to boot.
|
|
However, the build process for more fully-featured images
|
|
depends on the packages being present.
|
|
</para>
|
|
<para>
|
|
This variable affects all images based on
|
|
<filename>packagegroup-base</filename>, which does not include the
|
|
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
|
|
images.
|
|
</para>
|
|
<para>
|
|
The variable is similar to the
|
|
<filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename>
|
|
variable with the exception that the image being built has a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will not build if a file in this list is not found.
|
|
</para>
|
|
<para>
|
|
An example is a machine that has WiFi capability but is not
|
|
essential for the machine to boot the image.
|
|
However, if you are building a more fully-featured image, you want to enable
|
|
the WiFi.
|
|
The package containing the firmware for the WiFi hardware is always
|
|
expected to exist, so it is acceptable for the build process to depend upon
|
|
finding the package.
|
|
In this case, assuming the package for the firmware was called
|
|
<filename>wifidriver-firmware</filename>, you would use the following in the
|
|
<filename>.conf</filename> file for the machine:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
|
|
<glossdef>
|
|
<para></para>
|
|
<para>
|
|
A list of machine-specific packages to install as part of the
|
|
image being built that are not essential for booting the machine.
|
|
The image being built has no build dependency on this list of packages.
|
|
</para>
|
|
<para>
|
|
This variable affects only images based on
|
|
<filename>packagegroup-base</filename>, which does not include the
|
|
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
|
|
images.
|
|
</para>
|
|
<para>
|
|
This variable is similar to the
|
|
<filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename>
|
|
variable with the exception that the image being built does not have a build
|
|
dependency on the variable's list of packages.
|
|
In other words, the image will build if a file in this list is not found.
|
|
</para>
|
|
<para>
|
|
An example is a machine that has WiFi capability but is not essential
|
|
For the machine to boot the image.
|
|
However, if you are building a more fully-featured image, you want to enable
|
|
WiFi.
|
|
In this case, the package containing the WiFi kernel module will not be produced
|
|
if the WiFi driver is built into the kernel, in which case you still want the
|
|
build to succeed instead of failing as a result of the package not being found.
|
|
To accomplish this, assuming the package for the module was called
|
|
<filename>kernel-module-examplewifi</filename>, you would use the
|
|
following in the <filename>.conf</filename> file for the machine:
|
|
<literallayout class='monospaced'>
|
|
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the list of hardware features the
|
|
<link linkend='var-MACHINE'>MACHINE</link> supports.
|
|
For example, including the "bluetooth" feature causes the
|
|
<filename>bluez</filename> bluetooth daemon to be built and
|
|
added to the image.
|
|
It also causes the <filename>connman</filename> recipe
|
|
to look at <filename>MACHINE_FEATURES</filename> and when it
|
|
finds "bluetooth" there it enables the bluetooth
|
|
support in ConnMan.
|
|
</para>
|
|
|
|
<para>
|
|
For a list of features supported by the Yocto Project as shipped,
|
|
see the "<link linkend='ref-features-machine'>Machine</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-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-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>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<glossdiv id='var-glossary-o'><title>O</title>
|
|
|
|
<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>
|
|
</glossdiv>
|
|
|
|
<glossdiv id='var-glossary-p'><title>P</title>
|
|
|
|
<glossentry id='var-P'><glossterm>P</glossterm>
|
|
<glossdef>
|
|
<para>The recipe name and version.
|
|
<filename>P</filename> is comprised of the following:
|
|
<literallayout class='monospaced'>
|
|
${PN}-${PV}
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm>
|
|
<glossdef>
|
|
<para>The architecture of the resulting package or packages.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_BEFORE_PN'><glossterm>PACKAGE_BEFORE_PN</glossterm>
|
|
<glossdef>
|
|
<para>Enables easily adding packages to
|
|
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
|
|
before <filename>${<link linkend='var-PN'>PN</link>}</filename>
|
|
so that the packages can pick up files that would normally be
|
|
included in the default package.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm>
|
|
<glossdef>
|
|
<para>This variable, which is set in the <filename>local.conf</filename> configuration
|
|
file found in the <filename>conf</filename> folder of the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
|
|
specifies the package manager to use when packaging data.
|
|
You can provide one or more arguments for the variable with the first
|
|
argument being the package manager used to create images:
|
|
<literallayout class='monospaced'>
|
|
PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
|
|
</literallayout>
|
|
For information on build performance effects as a result of the
|
|
package manager use, see
|
|
<link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>
|
|
in this manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGE_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-PACKAGECONFIG'><glossterm>PACKAGECONFIG</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable provides a means of enabling or disabling
|
|
features of a recipe on a per-recipe basis.
|
|
The <filename>PACKAGECONFIG</filename>
|
|
variable itself specifies a space-separated list of the
|
|
features to enable.
|
|
The features themselves are specified as flags on the
|
|
<filename>PACKAGECONFIG</filename> variable.
|
|
You can provide up to four arguments, which are separated by
|
|
commas, to determine the behavior of each feature
|
|
when it is enabled or disabled.
|
|
You can omit any argument you like but must retain the
|
|
separating commas.
|
|
The arguments specify 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 example 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>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
|
|
<glossdef>
|
|
<para>The list of packages to be created from the recipe.
|
|
The default value is the following:
|
|
<literallayout class='monospaced'>
|
|
${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
|
|
</literallayout></para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A promise that your recipe satisfies runtime dependencies
|
|
for optional modules that are found in other recipes.
|
|
<filename>PACKAGES_DYNAMIC</filename>
|
|
does not actually satisfy the dependencies, it only states that
|
|
they should be satisfied.
|
|
For example, if a hard, runtime dependency
|
|
(<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
|
|
of another package is satisfied
|
|
at build time through the <filename>PACKAGES_DYNAMIC</filename>
|
|
variable, but a package with the module name is never actually
|
|
produced, then the other package will be broken.
|
|
Thus, if you attempt to include that package in an image,
|
|
you will get a dependency failure from the packaging system
|
|
during <filename>do_rootfs</filename>.
|
|
</para>
|
|
<para>
|
|
Typically, if there is a chance that such a situation can
|
|
occur and the package that is not created is valid
|
|
without the dependency being satisfied, then you should use
|
|
<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
|
|
(a soft runtime dependency) instead of
|
|
<filename>RDEPENDS</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
For an example of how to use the <filename>PACKAGES_DYNAMIC</filename>
|
|
variable when you are splitting packages, see the
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging'>Handling Optional Module Packaging</ulink>" section
|
|
in the Yocto Project Development Manual.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PARALLEL_MAKE'><glossterm>PARALLEL_MAKE</glossterm>
|
|
<glossdef>
|
|
<para>Specifies extra options that are passed to the <filename>make</filename> command during the
|
|
compile tasks.
|
|
This variable is usually in the form <filename>-j 4</filename>, where the number
|
|
represents the maximum number of parallel threads make can run.
|
|
If you development host supports multiple cores a good rule of thumb is to set
|
|
this variable to twice the number of cores on the host.</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-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-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-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies additional paths from which the OpenEmbedded
|
|
build system gets source code.
|
|
When the build system searches for source code, it first
|
|
tries the local download directory.
|
|
If that location fails, the build system tries locations
|
|
defined by <filename>PREMIRRORS</filename>, the upstream
|
|
source, and then locations specified by
|
|
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
|
|
in that order.
|
|
</para>
|
|
|
|
<para>
|
|
Assuming your distribution
|
|
(<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
|
|
is "poky", the default value for
|
|
<filename>PREMIRRORS</filename> is defined in the
|
|
<filename>conf/distro/poky.conf</filename> file in the
|
|
<filename>meta-yocto</filename> Git repository.
|
|
</para>
|
|
|
|
<para>
|
|
Typically, you could add a specific server for the
|
|
build system to attempt before any others by adding
|
|
something like the following to the
|
|
<filename>local.conf</filename> configuration file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
|
|
<literallayout class='monospaced'>
|
|
PREMIRRORS_prepend = "\
|
|
git://.*/.* http://www.yoctoproject.org/sources/ \n \
|
|
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
|
|
http://.*/.* http://www.yoctoproject.org/sources/ \n \
|
|
https://.*/.* http://www.yoctoproject.org/sources/ \n"
|
|
</literallayout>
|
|
These changes cause the build system to intercept
|
|
Git, FTP, HTTP, and HTTPS requests and direct them to
|
|
the <filename>http://</filename> sources mirror.
|
|
You can use <filename>file://</filename> URLs to point
|
|
to local directories or network shares as well.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-PRINC'><glossterm>PRINC</glossterm>
|
|
<glossdef>
|
|
<para>Causes the <link linkend='var-PR'><filename>PR</filename></link>
|
|
variable of <filename>.bbappend</filename> files to
|
|
dynamically increment.
|
|
This increment minimizes the impact of layer ordering.</para>
|
|
<para>In order to ensure multiple <filename>.bbappend</filename> files can co-exist,
|
|
<filename>PRINC</filename> should be self referencing.
|
|
This variable defaults to 0.</para>
|
|
<para>Following is an example that increments <filename>PR</filename> by two:
|
|
<literallayout class='monospaced'>
|
|
PRINC := "${@int(PRINC) + 2}"
|
|
</literallayout>
|
|
It is advisable not to use strings such as ".= '.1'" with the variable because
|
|
this usage is very sensitive to layer ordering.
|
|
You should avoid explicit assignments as they cannot
|
|
adequately represent multiple
|
|
<filename>.bbappend</filename> files.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-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-PE'><glossterm>PE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
the epoch of the recipe.
|
|
The default value is "0".
|
|
The field is used to make upgrades possible when the versioning scheme changes in
|
|
some backwards incompatible way.
|
|
</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.
|
|
Here is an example:
|
|
<literallayout class='monospaced'>
|
|
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
|
|
</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 to 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 number that could
|
|
potentially change.
|
|
Here are two examples:
|
|
<literallayout class='monospaced'>
|
|
PREFERRED_VERSION_python = "2.6.6"
|
|
PREFERRED_VERSION_linux-yocto = "3.0+git%"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-q'><title>Q</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<glossdiv id='var-glossary-r'><title>R</title>
|
|
|
|
<glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
|
|
<glossdef>
|
|
<para>The list of packages that conflict with another package.
|
|
Note that the package will not be installed if the 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>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Lists a package's run-time dependencies (i.e. other packages)
|
|
that must be installed for the package to be built.
|
|
In other words, in order for the package to be built and
|
|
run correctly, it depends on the listed packages.
|
|
If a package in this list cannot be found, it is probable
|
|
that a dependency error would occur before the build.
|
|
</para>
|
|
|
|
<para>
|
|
The names of the variables you list with
|
|
<filename>RDEPENDS</filename> must be the names of other
|
|
packages as listed in the
|
|
<link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
|
|
variable.
|
|
You should not list recipe names
|
|
(<link linkend='var-PN'><filename>PN</filename></link>).
|
|
</para>
|
|
|
|
<para>
|
|
Because the <filename>RDEPENDS</filename> variable applies
|
|
to packages being built, you should
|
|
always attach a package name to the variable to specify the
|
|
particular run-time package that has the dependency.
|
|
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 package name
|
|
(<filename>${PN}-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 like <filename>debian.bbclass</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
In many cases you do not need to explicitly add dependencies
|
|
to <filename>RDEPENDS</filename> since some automatic
|
|
handling occurs:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>shlibdeps</filename></emphasis>: If
|
|
a run-time 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 run-time
|
|
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 run-time packages.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</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 them later if you want.
|
|
If, during the build, a package from the list cannot be found, the build
|
|
process continues without an error.
|
|
</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 like <filename>debian.bbclass</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
|
|
<glossdef>
|
|
<para>The list of packages replaced by the package in which
|
|
<filename>RREPLACES</filename> appears.</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 package source code resides.
|
|
This location is within the working directory
|
|
(<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>), which
|
|
is not static.
|
|
The unpacked source location depends on the package name
|
|
(<filename><link linkend='var-PN'>PN</link></filename>) and
|
|
package 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 working directory the build system uses to build
|
|
the <filename>db</filename> package 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-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-SECTION'><glossterm>SECTION</glossterm>
|
|
<glossdef>
|
|
<para>The section in which packages should be categorized.
|
|
Package management utilities can make use of this variable.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SELECTED_OPTIMIZATION'><glossterm>SELECTED_OPTIMIZATION</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The variable takes the value of
|
|
<filename><link linkend='var-FULL_OPTIMIZATION'>FULL_OPTIMIZATION</link></filename>
|
|
unless <filename><link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></filename> = "1".
|
|
In this case the value of
|
|
<filename><link linkend='var-DEBUG_OPTIMIZATION'>DEBUG_OPTIMIZATION</link></filename> is used.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
|
|
<glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm>
|
|
<glossdef>
|
|
<para>The speed and device for the serial port used to attach the serial console.
|
|
This variable is given to the kernel as the "console"
|
|
parameter and after booting occurs <filename>getty</filename> is started on that port
|
|
so remote login is possible.</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-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-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 only needs to fetch a tarball from the
|
|
Internet, the recipe uses a single <filename>SRC_URI</filename> entry.
|
|
On the other hand, if the recipe needs to fetch a tarball, apply
|
|
two patches, and include a custom file, the recipe 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 is usually
|
|
a file 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 resides:
|
|
<itemizedlist>
|
|
<listitem><para><emphasis><filename>${PN}</filename> -</emphasis> The recipe name
|
|
with any special suffix or prefix, if applicable.
|
|
For example, using <filename>bash</filename> to build for the native
|
|
machine, <filename>PN</filename> is <filename>bash-native</filename>.
|
|
Using <filename>bash</filename> to build for the target and for Multilib,
|
|
<link linkend='var-PN'><filename>PN</filename></link>
|
|
would be <filename>bash</filename> and
|
|
<filename>lib64-bash</filename>, respectively.
|
|
</para></listitem>
|
|
<listitem><para><emphasis><filename>${PF}</filename> - </emphasis>
|
|
<filename>${PN}-${EXTENDPE}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}</filename>.
|
|
The recipe name including all version and revision numbers
|
|
(i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
|
|
<filename>bash-4.2-r1/</filename>).</para></listitem>
|
|
<listitem><para><emphasis><filename>${P}</filename> -</emphasis>
|
|
<filename>${PN}-${PV}</filename>.
|
|
The recipe name and version (i.e. <filename>bash-4.2</filename>).
|
|
</para></listitem>
|
|
<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 beneath the directory in which the recipe
|
|
resides.</para></listitem>
|
|
<listitem><para><emphasis>Directory -</emphasis> The directory itself in which the recipe
|
|
resides.</para></listitem>
|
|
</itemizedlist></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>
|
|
</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 = "1.5.0+git${SRCPV}"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The revision of the source code used to build the package.
|
|
This variable applies to Subversion, Git, Mercurial and Bazaar
|
|
only.
|
|
Note that if you wish to build a fixed revision and you wish
|
|
to avoid performing a query on the remote repository every time
|
|
BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
|
|
full revision identifier and not just a tag.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
|
|
<glossdef>
|
|
<para>The directory for the shared state cache.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-SSTATE_MIRRORS'><glossterm>SSTATE_MIRRORS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Configures the OpenEmbedded build system to search other
|
|
mirror locations for prebuilt cache data objects before
|
|
building out the data.
|
|
This variable works like fetcher
|
|
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
|
|
and <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
|
|
and points to the cache locations to check for the shared
|
|
objects.
|
|
</para>
|
|
|
|
<para>
|
|
You can specify a filesystem directory or a remote URL such
|
|
as HTTP or FTP.
|
|
The locations you specify need to contain the shared state
|
|
cache (sstate-cache) results from previous builds.
|
|
The sstate-cache you point to can also be from builds on
|
|
other machines.
|
|
</para>
|
|
|
|
<para>
|
|
If a mirror uses the same structure as
|
|
<link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
|
|
you need to add
|
|
"PATH" at the end as shown in the examples below.
|
|
The build system substitutes the correct path within the
|
|
directory structure.
|
|
<literallayout class='monospaced'>
|
|
SSTATE_MIRRORS ?= "\
|
|
file://.* http://someserver.tld/share/sstate/PATH \n \
|
|
file://.* file:///some/local/dir/sstate/PATH"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The directory with kernel headers that are required to build out-of-tree
|
|
modules.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies the base path used to create recipe stamp files.
|
|
The path to an actual stamp file is constructed by evaluating this
|
|
string and then appending additional information.
|
|
Currently, the default assignment for <filename>STAMP</filename>
|
|
as set in the <filename>meta/conf/bitbake.conf</filename> file
|
|
is:
|
|
<literallayout class='monospaced'>
|
|
STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
|
|
</literallayout>
|
|
See <link linkend='var-TMPDIR'><filename>TMPDIR</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-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>
|
|
|
|
</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 when building a particular package.
|
|
It 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 package.
|
|
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 architecture of the device being built.
|
|
The OpenEmbedded build system supports the following
|
|
architectures:
|
|
<literallayout class='monospaced'>
|
|
arm
|
|
mips
|
|
ppc
|
|
x86
|
|
x86-64
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Flags passed to the C compiler for the target system.
|
|
This variable evaluates to the same as
|
|
<filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
|
|
<glossentry id='var-TARGET_FPU'><glossterm>TARGET_FPU</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the method for handling FPU code.
|
|
For FPU-less targets, which include most ARM CPUs, the variable must be
|
|
set to "soft".
|
|
If not, the kernel emulation gets used, which results in a performance penalty.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
|
|
<glossdef>
|
|
<para>Specifies the target's operating system.
|
|
The variable can be set to "linux" for <filename>eglibc</filename>-based systems and
|
|
to "linux-uclibc" for <filename>uclibc</filename>.
|
|
For ARM/EABI targets, there are also "linux-gnueabi" and
|
|
"linux-uclibc-gnueabi" values possible.</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Specifies which variant of the GNU standard C library (<filename>libc</filename>)
|
|
to use during the build process.
|
|
This variable replaces <filename>POKYLIBC</filename>, which is no longer
|
|
supported.
|
|
</para>
|
|
<para>
|
|
You can select <filename>eglibc</filename> or <filename>uclibc</filename>.
|
|
<note>
|
|
This release of the Yocto Project does not support the
|
|
<filename>glibc</filename> implementation of <filename>libc</filename>.
|
|
</note>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The toolchain selector.
|
|
This variable replaces <filename>POKYMODE</filename>, which is no longer
|
|
supported.
|
|
</para>
|
|
<para>
|
|
The <filename>TCMODE</filename> variable selects the external toolchain
|
|
built using the OpenEmbedded build system or a few supported combinations of
|
|
the upstream GCC or CodeSourcery Labs toolchain.
|
|
The variable identifies the <filename>tcmode-*</filename> files used in
|
|
the <filename>meta/conf/distro/include</filename> directory, which is found in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
|
</para>
|
|
<para>
|
|
By default, <filename>TCMODE</filename> is set to "default", which
|
|
chooses the <filename>tcmode-default.inc</filename> file.
|
|
The variable is similar to
|
|
<link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>, which controls
|
|
the variant of the GNU standard C library (<filename>libc</filename>)
|
|
used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable is the temporary directory the OpenEmbedded build system
|
|
uses when it does its work building images.
|
|
By default, the <filename>TMPDIR</filename> variable is named
|
|
<filename>tmp</filename> within the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
If you want to establish this directory in a location other than the
|
|
default, you can uncomment the following statement in the
|
|
<filename>conf/local.conf</filename> file in the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
|
|
<literallayout class='monospaced'>
|
|
#TMPDIR = "${TOPDIR}/tmp"
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
This variable is the
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
|
BitBake automatically sets this variable.
|
|
The OpenEmbedded build system uses the Build Directory when building images.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-u'><title>U</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<!-- <glossdiv id='var-glossary-v'><title>V</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<glossdiv id='var-glossary-w'><title>W</title>
|
|
|
|
<glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The pathname of the working directory in which the OpenEmbedded build system
|
|
builds a recipe.
|
|
This directory is located within the
|
|
<link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> directory structure and changes
|
|
as different packages are built.
|
|
</para>
|
|
|
|
<para>
|
|
The actual <filename>WORKDIR</filename> directory depends on several things:
|
|
<itemizedlist>
|
|
<listitem>The temporary directory - <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link></listitem>
|
|
<listitem>The package architecture - <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link></listitem>
|
|
<listitem>The target machine - <link linkend='var-MACHINE'><filename>MACHINE</filename></link></listitem>
|
|
<listitem>The target operating system - <link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link></listitem>
|
|
<listitem>The recipe name - <link linkend='var-PN'><filename>PN</filename></link></listitem>
|
|
<listitem>The recipe version - <link linkend='var-PV'><filename>PV</filename></link></listitem>
|
|
<listitem>The recipe revision - <link linkend='var-PR'><filename>PR</filename></link></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
For packages that are not dependent on a particular machine,
|
|
<filename>WORKDIR</filename> is defined as follows:
|
|
<literallayout class='monospaced'>
|
|
${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
|
|
</literallayout>
|
|
As an example, assume a
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> top-level
|
|
folder name <filename>poky</filename> and a default
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
|
at <filename>poky/build</filename>.
|
|
In this case, the working directory the build system uses to build
|
|
the <filename>v86d</filename> package is the following:
|
|
<literallayout class='monospaced'>
|
|
~/poky/build/tmp/work/qemux86-poky-linux/v86d/01.9-r0
|
|
</literallayout>
|
|
</para>
|
|
|
|
<para>
|
|
For packages that are dependent on a particular machine, <filename>WORKDIR</filename>
|
|
is defined slightly different:
|
|
<literallayout class='monospaced'>
|
|
${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
|
|
</literallayout>
|
|
As an example, again assume a Source Directory top-level folder
|
|
named <filename>poky</filename> and a default Build Directory
|
|
at <filename>poky/build</filename>.
|
|
In this case, the working directory the build system uses to build
|
|
the <filename>acl</filename> recipe, which is being built for a
|
|
MIPS-based device, is the following:
|
|
<literallayout class='monospaced'>
|
|
~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
|
|
</literallayout>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
<!-- <glossdiv id='var-glossary-x'><title>X</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<!-- <glossdiv id='var-glossary-y'><title>Y</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
<!-- <glossdiv id='var-glossary-z'><title>Z</title>-->
|
|
<!-- </glossdiv>-->
|
|
|
|
</glossary>
|
|
</chapter>
|
|
<!--
|
|
vim: expandtab tw=80 ts=4
|
|
-->
|