2014-01-20 19:09:43 +00:00
|
|
|
<!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 by BitBake 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-DEFAULT_PREFERENCE'>D</link>
|
|
|
|
<link linkend='var-EXCLUDE_FROM_WORLD'>E</link>
|
|
|
|
<link linkend='var-FILESPATH'>F</link>
|
|
|
|
<!-- <link linkend='var-GROUPADD_PARAM'>G</link> -->
|
|
|
|
<link linkend='var-HOMEPAGE'>H</link>
|
|
|
|
<!-- <link linkend='var-ICECC_DISABLED'>I</link> -->
|
|
|
|
<!-- <link linkend='var-glossary-j'>J</link> -->
|
|
|
|
<!-- <link linkend='var-KARCH'>K</link> -->
|
|
|
|
<link linkend='var-LAYERDEPENDS'>L</link>
|
|
|
|
<link linkend='var-MIRRORS'>M</link>
|
|
|
|
<!-- <link linkend='var-glossary-n'>N</link> -->
|
|
|
|
<link linkend='var-OVERRIDES'>O</link>
|
|
|
|
<link linkend='var-PACKAGES'>P</link>
|
|
|
|
<!-- <link linkend='var-QMAKE_PROFILES'>Q</link> -->
|
|
|
|
<link linkend='var-RDEPENDS'>R</link>
|
|
|
|
<link linkend='var-SECTION'>S</link>
|
|
|
|
<link linkend='var-T'>T</link>
|
|
|
|
<!-- <link linkend='var-UBOOT_CONFIG'>U</link> -->
|
|
|
|
<!-- <link linkend='var-glossary-v'>V</link> -->
|
|
|
|
<!-- <link linkend='var-WARN_QA'>W</link> -->
|
|
|
|
<!-- <link linkend='var-glossary-x'>X</link> -->
|
|
|
|
<!-- <link linkend='var-glossary-y'>Y</link> -->
|
|
|
|
<!-- <link linkend='var-glossary-z'>Z</link>-->
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
<glossdiv id='var-glossary-a'><title>A</title>
|
|
|
|
</glossdiv>
|
|
|
|
-->
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-b'><title>B</title>
|
|
|
|
|
|
|
|
<glossentry id='var-B'><glossterm>B</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
2014-01-21 23:20:55 +00:00
|
|
|
The directory in which BitBake executes functions
|
2014-01-20 19:09:43 +00:00
|
|
|
during a recipe's build process.
|
|
|
|
</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>
|
|
|
|
|
|
|
|
</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.
|
|
|
|
When setting this variable, 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.
|
|
|
|
|
|
|
|
<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 set
|
|
|
|
the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable.
|
|
|
|
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
|
2014-01-21 23:20:55 +00:00
|
|
|
build system also issues a
|
2014-01-20 19:09:43 +00:00
|
|
|
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>${TMPDIR}</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.
|
|
|
|
</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 BitBake to
|
|
|
|
issue subsequent warnings each time the available
|
|
|
|
disk space further reduces by 50 Mbytes or the number
|
|
|
|
of free inodes further reduces by 5 Kbytes in the
|
|
|
|
<filename>${SSTATE_DIR}</filename> directory.
|
|
|
|
Subsequent warnings based on the interval occur each time
|
|
|
|
a respective interval is reached beyond the initial warning
|
|
|
|
(i.e. 1 Gbytes and 100 Kbytes).
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Causes tarballs of the Git repositories, including the
|
|
|
|
Git metadata, to be placed in the
|
|
|
|
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
|
|
|
|
directory.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For performance reasons, creating and placing tarballs of
|
|
|
|
the Git repositories is not the default action by BitBake.
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BB_GENERATE_MIRROR_TARBALLS = "1"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>The maximum number of tasks BitBake should run in parallel at any one time.
|
|
|
|
If your host development system supports multiple cores, a good rule of thumb
|
|
|
|
is to set this variable to twice the number of cores.</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Allows you to extend a recipe so that it builds variants of the software.
|
|
|
|
Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
|
|
|
|
which is a copy of Quilt built to run on the build system;
|
|
|
|
"crosses" such as <filename>gcc-cross</filename>,
|
|
|
|
which is a compiler built to run on the build machine but produces binaries
|
|
|
|
that run on the target <filename>MACHINE</filename>;
|
|
|
|
"nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
|
|
|
|
and "mulitlibs" in the form "<filename>multilib:<multilib_name></filename>".
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To build a different variant of the recipe with a minimal amount of code, it usually
|
|
|
|
is as simple as adding the following to your recipe:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BBCLASSEXTEND =+ "native nativesdk"
|
|
|
|
BBCLASSEXTEND =+ "multilib:<multilib_name>"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>Lists the names of configured layers.
|
|
|
|
These names are used to find the other <filename>BBFILE_*</filename>
|
|
|
|
variables.
|
2014-01-21 23:20:55 +00:00
|
|
|
Typically, each layer appends its name to this variable in its
|
2014-01-20 19:09:43 +00:00
|
|
|
<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>
|
2014-01-21 23:20:55 +00:00
|
|
|
<para>List of recipe files BitBake uses to build software.</para>
|
2014-01-20 19:09:43 +00:00
|
|
|
</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
|
2014-01-21 23:25:41 +00:00
|
|
|
file in the build directory.
|
2014-01-20 19:09:43 +00:00
|
|
|
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 \
|
|
|
|
"
|
|
|
|
|
|
|
|
</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-BBMASK'><glossterm>BBMASK</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Prevents BitBake from processing recipes and recipe
|
|
|
|
append files.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
You can use the <filename>BBMASK</filename> variable
|
|
|
|
to "hide" these <filename>.bb</filename> and
|
|
|
|
<filename>.bbappend</filename> files.
|
|
|
|
BitBake ignores any recipe or recipe append files that
|
|
|
|
match the expression.
|
|
|
|
It is as if BitBake does not see them at all.
|
|
|
|
Consequently, matching files are not parsed or otherwise
|
|
|
|
used by BitBake.</para>
|
|
|
|
<para>
|
|
|
|
The value you provide is passed to Python's regular
|
|
|
|
expression compiler.
|
|
|
|
The expression is compared against the full paths to
|
|
|
|
the files.
|
|
|
|
For complete syntax information, see Python's
|
|
|
|
documentation at
|
|
|
|
<ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The following example uses a complete regular expression
|
|
|
|
to tell BitBake to ignore all recipe and recipe append
|
|
|
|
files in the <filename>meta-ti/recipes-misc/</filename>
|
|
|
|
directory:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BBMASK = "meta-ti/recipes-misc/"
|
|
|
|
</literallayout>
|
|
|
|
If you want to mask out multiple directories or recipes,
|
|
|
|
use the vertical bar to separate the regular expression
|
|
|
|
fragments.
|
|
|
|
This next example masks out multiple directories and
|
|
|
|
individual recipes:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
|
|
|
|
BBMASK .= "|.*meta-oe/recipes-support/"
|
|
|
|
BBMASK .= "|.*openldap"
|
|
|
|
BBMASK .= "|.*opencv"
|
|
|
|
BBMASK .= "|.*lzma"
|
|
|
|
</literallayout>
|
|
|
|
Notice how the vertical bar is used to append the fragments.
|
|
|
|
<note>
|
|
|
|
When specifying a directory name, use the trailing
|
|
|
|
slash character to ensure you match just that directory
|
|
|
|
name.
|
|
|
|
</note>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
2014-01-21 23:20:55 +00:00
|
|
|
Used by BitBake to locate class
|
|
|
|
(<filename>.bbclass</filename>) and configuration
|
|
|
|
(<filename>.conf</filename>) files.
|
2014-01-20 19:09:43 +00:00
|
|
|
This variable is analogous to the
|
|
|
|
<filename>PATH</filename> variable.
|
|
|
|
<note>
|
|
|
|
If you run BitBake from a directory outside of the
|
2014-01-21 23:25:41 +00:00
|
|
|
build directory,
|
2014-01-20 19:09:43 +00:00
|
|
|
you must be sure to set
|
|
|
|
<filename>BBPATH</filename> to point to the
|
2014-01-21 23:25:41 +00:00
|
|
|
build directory.
|
2014-01-20 19:09:43 +00:00
|
|
|
Set the variable as you would any environment variable
|
|
|
|
and then run BitBake:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ BBPATH = "<build_directory>"
|
|
|
|
$ export BBPATH
|
|
|
|
$ bitbake <target>
|
|
|
|
</literallayout>
|
|
|
|
</note>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Points to the server that runs memory-resident BitBake.
|
|
|
|
The variable is only used when you employ memory-resident
|
|
|
|
BitBake.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<!--
|
|
|
|
<glossdiv id='var-glossary-c'><title>C</title>
|
|
|
|
</glossdiv>
|
|
|
|
-->
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-d'><title>D</title>
|
|
|
|
|
|
|
|
<glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Specifies a weak bias for recipe selection priority.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The most common usage of this is variable is to set
|
|
|
|
it to "-1" within a recipe for a development version of a
|
|
|
|
piece of software.
|
|
|
|
Using the variable in this way causes the stable version
|
|
|
|
of the recipe to build by default in the absence of
|
|
|
|
<filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
|
|
|
|
being used to build the development version.
|
|
|
|
</para>
|
|
|
|
<note>
|
|
|
|
The bias provided by <filename>DEFAULT_PREFERENCE</filename>
|
|
|
|
is weak and is overridden by
|
|
|
|
<filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
|
|
|
|
if that variable is different between two layers
|
|
|
|
that contain different versions of the same recipe.
|
|
|
|
</note>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Lists a recipe's build-time dependencies
|
|
|
|
(i.e. other recipe files).
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Consider this simple example for two recipes named "a" and
|
|
|
|
"b" that produce similarly named packages.
|
|
|
|
In this example, the <filename>DEPENDS</filename>
|
|
|
|
statement appears in the "a" recipe:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
DEPENDS = "b"
|
|
|
|
</literallayout>
|
|
|
|
Here, the dependency is such that the
|
|
|
|
<filename>do_configure</filename> task for recipe "a"
|
|
|
|
depends on the <filename>do_populate_sysroot</filename>
|
|
|
|
task of recipe "b".
|
|
|
|
This means anything that recipe "b" puts into sysroot
|
|
|
|
is available when recipe "a" is configuring itself.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For information on runtime dependencies, see the
|
|
|
|
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
|
|
|
|
variable.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
A long description for the recipe.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
The central download directory used by the build process to
|
|
|
|
store downloads.
|
|
|
|
By default, <filename>DL_DIR</filename> gets files
|
|
|
|
suitable for mirroring for everything except Git
|
|
|
|
repositories.
|
|
|
|
If you want tarballs of Git repositories, use the
|
|
|
|
<link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
|
|
|
|
variable.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
|
|
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-e'><title>E</title>
|
|
|
|
|
|
|
|
<glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Directs BitBake to exclude a recipe from world builds (i.e.
|
|
|
|
<filename>bitbake world</filename>).
|
|
|
|
During world builds, BitBake locates, parses and builds all
|
|
|
|
recipes found in every layer exposed in the
|
|
|
|
<filename>bblayers.conf</filename> configuration file.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To exclude a recipe from a world build using this variable,
|
|
|
|
set the variable to "1" in the recipe.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<note>
|
|
|
|
Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
|
|
|
|
may still be built during a world build in order to satisfy
|
|
|
|
dependencies of other recipes.
|
|
|
|
Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
|
|
|
|
only ensures that the recipe is not explicitly added
|
|
|
|
to the list of build targets in a world build.
|
|
|
|
</note>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-f'><title>F</title>
|
|
|
|
|
|
|
|
<glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
The default set of directories BitBake
|
|
|
|
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>
|
|
|
|
</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-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>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<!--
|
|
|
|
<glossdiv id='var-glossary-j'><title>J</title>
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-k'><title>K</title>
|
|
|
|
</glossdiv>
|
|
|
|
-->
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-l'><title>L</title>
|
|
|
|
|
|
|
|
<glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
|
|
|
|
<glossdef>
|
2014-01-21 23:20:55 +00:00
|
|
|
<para>Lists the layers, separated by spaces, upon which this recipe depends.
|
2014-01-20 19:09:43 +00:00
|
|
|
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).
|
2014-01-21 23:20:55 +00:00
|
|
|
BitBake produces an error if any dependency is missing or
|
|
|
|
the version numbers do not match exactly (if specified).</para>
|
|
|
|
<para>
|
|
|
|
You use this variable in the <filename>conf/layer.conf</filename> file.
|
|
|
|
You must also use the specific layer name as a suffix
|
|
|
|
to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
|
2014-01-20 19:09:43 +00:00
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>When used inside the <filename>layer.conf</filename> configuration
|
|
|
|
file, this variable provides the path of the current layer.
|
|
|
|
This variable is not available outside of <filename>layer.conf</filename>
|
|
|
|
and references are expanded immediately when parsing of the file completes.</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>Optionally specifies the version of a layer as a single number.
|
2014-01-21 23:20:55 +00:00
|
|
|
You can use this variable within
|
2014-01-20 19:09:43 +00:00
|
|
|
<link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
|
|
|
|
for another layer in order to depend on a specific version
|
2014-01-21 23:20:55 +00:00
|
|
|
of the layer.</para>
|
|
|
|
<para>
|
|
|
|
You use this variable in the <filename>conf/layer.conf</filename> file.
|
|
|
|
You must also use the specific layer name as a suffix
|
|
|
|
to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
|
2014-01-20 19:09:43 +00:00
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
The list of source licenses for the recipe.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-m'><title>M</title>
|
|
|
|
|
|
|
|
<glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
2014-01-21 23:20:55 +00:00
|
|
|
Specifies additional paths from which BitBake gets source code.
|
2014-01-20 19:09:43 +00:00
|
|
|
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 (<filename>DISTRO</filename>)
|
|
|
|
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>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<!--
|
|
|
|
<glossdiv id='var-glossary-n'><title>N</title>
|
|
|
|
</glossdiv>
|
|
|
|
-->
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-o'><title>O</title>
|
|
|
|
|
|
|
|
<glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
BitBake uses <filename>OVERRIDES</filename> to control
|
|
|
|
what variables are overridden after BitBake parses
|
|
|
|
recipes and configuration files.
|
|
|
|
You can find more information on how overrides are handled
|
2014-01-21 23:20:55 +00:00
|
|
|
in the
|
|
|
|
"<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>"
|
|
|
|
section.
|
2014-01-20 19:09:43 +00:00
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-p'><title>P</title>
|
|
|
|
|
|
|
|
<glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
|
|
|
|
<glossdef>
|
2014-01-21 23:20:55 +00:00
|
|
|
<para>The list of packages the recipe creates.
|
2014-01-20 19:09:43 +00:00
|
|
|
</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>)
|
2014-01-21 23:20:55 +00:00
|
|
|
of another package is satisfied during the build
|
|
|
|
through the <filename>PACKAGES_DYNAMIC</filename>
|
2014-01-20 19:09:43 +00:00
|
|
|
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>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PE'><glossterm>PE</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
The epoch of the recipe.
|
|
|
|
By default, this variable is unset.
|
2014-01-21 23:20:55 +00:00
|
|
|
The variable is used to make upgrades possible when the
|
2014-01-20 19:09:43 +00:00
|
|
|
versioning scheme changes in some backwards incompatible
|
|
|
|
way.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PF'><glossterm>PF</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Specifies the recipe or package name and includes all version and revision
|
|
|
|
numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
|
|
|
|
<filename>bash-4.2-r1/</filename>).
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PN'><glossterm>PN</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>The recipe name.</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PR'><glossterm>PR</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>The revision of the recipe.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
If multiple recipes provide an item, this variable
|
|
|
|
determines which recipe should be given preference.
|
|
|
|
You should always suffix the variable with the name of the
|
|
|
|
provided item, and you should set it to the
|
|
|
|
<link linkend='var-PN'><filename>PN</filename></link>
|
|
|
|
of the recipe to which you want to give precedence.
|
|
|
|
Some examples:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
|
|
|
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
|
|
|
|
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
If there are multiple versions of recipes available, this
|
|
|
|
variable determines which recipe should be given preference.
|
|
|
|
You must always suffix the variable with the
|
|
|
|
<link linkend='var-PN'><filename>PN</filename></link>
|
2014-01-21 23:20:55 +00:00
|
|
|
you want to select, and you should set
|
2014-01-20 19:09:43 +00:00
|
|
|
<link linkend='var-PV'><filename>PV</filename></link>
|
|
|
|
accordingly for precedence.
|
|
|
|
You can use the "<filename>%</filename>" character as a
|
|
|
|
wildcard to match any number of characters, which can be
|
|
|
|
useful when specifying versions that contain long revision
|
|
|
|
numbers that could potentially change.
|
|
|
|
Here are two examples:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
PREFERRED_VERSION_python = "2.7.3"
|
|
|
|
PREFERRED_VERSION_linux-yocto = "3.10%"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Specifies additional paths from which BitBake 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
|
|
|
|
(<filename>DISTRO</filename>)
|
|
|
|
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>
|
2014-01-21 23:20:55 +00:00
|
|
|
Typically, you would add a specific server for the
|
2014-01-20 19:09:43 +00:00
|
|
|
build system to attempt before any others by adding
|
|
|
|
something like the following to your configuration:
|
|
|
|
<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-PROVIDES'><glossterm>PROVIDES</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
A list of aliases that a recipe also provides.
|
|
|
|
These aliases are useful for satisfying dependencies of
|
|
|
|
other recipes during the build (as specified by
|
|
|
|
<filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
|
|
|
|
<note>
|
|
|
|
A recipe's own
|
|
|
|
<filename><link linkend='var-PN'>PN</link></filename>
|
|
|
|
is implicitly already in its
|
|
|
|
<filename>PROVIDES</filename> list.
|
|
|
|
</note>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
The network based
|
|
|
|
<link linkend='var-PR'><filename>PR</filename></link>
|
|
|
|
service host and port.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2014-01-21 23:20:55 +00:00
|
|
|
Following is an example of how the <filename>PRSERV_HOST</filename> variable is
|
2014-01-20 19:09:43 +00:00
|
|
|
set:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
PRSERV_HOST = "localhost:0"
|
|
|
|
</literallayout>
|
|
|
|
You must set the variable if you want to automatically
|
2014-01-21 23:20:55 +00:00
|
|
|
start a local PR service.
|
2014-01-20 19:09:43 +00:00
|
|
|
You can set <filename>PRSERV_HOST</filename> to other
|
|
|
|
values to use a remote PR service.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-PV'><glossterm>PV</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>The version of the recipe.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<!--
|
|
|
|
<glossdiv id='var-glossary-q'><title>Q</title>
|
|
|
|
</glossdiv>
|
|
|
|
-->
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-r'><title>R</title>
|
|
|
|
|
|
|
|
<glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
Lists a package's runtime dependencies (i.e. other packages)
|
|
|
|
that must be installed in order for the built package to run
|
|
|
|
correctly.
|
|
|
|
If a package in this list cannot be found during the build,
|
|
|
|
you will get a build error.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Because the <filename>RDEPENDS</filename> variable applies
|
|
|
|
to packages being built, you should always use the variable
|
|
|
|
in a form with an attached package name.
|
|
|
|
For example, suppose you are building a development package
|
|
|
|
that depends on the <filename>perl</filename> package.
|
|
|
|
In this case, you would use the following
|
|
|
|
<filename>RDEPENDS</filename> statement:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
RDEPENDS_${PN}-dev += "perl"
|
|
|
|
</literallayout>
|
|
|
|
In the example, the development package depends on
|
|
|
|
the <filename>perl</filename> package.
|
|
|
|
Thus, the <filename>RDEPENDS</filename> variable has the
|
|
|
|
<filename>${PN}-dev</filename> package name as part of the
|
|
|
|
variable.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
BitBake supports specifying versioned dependencies.
|
|
|
|
Although the syntax varies depending on the packaging
|
|
|
|
format, BitBake hides these differences from you.
|
|
|
|
Here is the general syntax to specify versions with
|
|
|
|
the <filename>RDEPENDS</filename> variable:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
RDEPENDS_${PN} = "<package> (<operator> <version>)"
|
|
|
|
</literallayout>
|
|
|
|
For <filename>operator</filename>, you can specify the
|
|
|
|
following:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
=
|
|
|
|
<
|
|
|
|
>
|
|
|
|
<=
|
|
|
|
>=
|
|
|
|
</literallayout>
|
|
|
|
For example, the following sets up a dependency on version
|
|
|
|
1.2 or greater of the package <filename>foo</filename>:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
RDEPENDS_${PN} = "foo (>= 1.2)"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For information on build-time dependencies, see the
|
|
|
|
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
|
|
|
|
variable.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
A list of package name aliases that a package also provides.
|
|
|
|
These aliases are useful for satisfying runtime dependencies
|
|
|
|
of other packages both during the build and on the target
|
|
|
|
(as specified by
|
|
|
|
<filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
As with all package-controlling variables, you must always
|
|
|
|
use the variable in conjunction with a package name override.
|
|
|
|
Here is an example:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
RPROVIDES_${PN} = "widget-abi-2"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
A list of packages that extends the usability of a package
|
|
|
|
being built.
|
|
|
|
The package being built does not depend on this list of
|
|
|
|
packages in order to successfully build, but needs them for
|
|
|
|
the extended usability.
|
|
|
|
To specify runtime dependencies for packages, see the
|
|
|
|
<filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
|
|
|
|
variable.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
BitBake supports specifying versioned recommends.
|
|
|
|
Although the syntax varies depending on the packaging
|
|
|
|
format, BitBake hides these differences from you.
|
|
|
|
Here is the general syntax to specify versions with
|
|
|
|
the <filename>RRECOMMENDS</filename> variable:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
RRECOMMENDS_${PN} = "<package> (<operator> <version>)"
|
|
|
|
</literallayout>
|
|
|
|
For <filename>operator</filename>, you can specify the
|
|
|
|
following:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
=
|
|
|
|
<
|
|
|
|
>
|
|
|
|
<=
|
|
|
|
>=
|
|
|
|
</literallayout>
|
|
|
|
For example, the following sets up a recommend on version
|
|
|
|
1.2 or greater of the package <filename>foo</filename>:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
RRECOMMENDS_${PN} = "foo (>= 1.2)"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-s'><title>S</title>
|
|
|
|
|
|
|
|
<glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>The section in which packages should be categorized.</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 BitBake which bits
|
|
|
|
to pull in for the build and how to pull them in.
|
|
|
|
For example, if the recipe or append file only needs to
|
|
|
|
fetch a tarball from the Internet, the recipe or
|
2014-01-21 23:20:55 +00:00
|
|
|
append file uses a <filename>SRC_URI</filename>
|
|
|
|
entry that specifies just the tarball.
|
2014-01-20 19:09:43 +00:00
|
|
|
On the other hand, if the recipe or append file needs to
|
|
|
|
fetch a tarball, apply two patches, and include a custom
|
2014-01-21 23:20:55 +00:00
|
|
|
file, the recipe or append file needs an
|
|
|
|
<filename>SRC_URI</filename> variable that specifies all
|
|
|
|
those sources.</para>
|
2014-01-20 19:09:43 +00:00
|
|
|
<para>The following list explains the available URI protocols:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para><emphasis><filename>file://</filename> -</emphasis>
|
|
|
|
Fetches files, which are usually files shipped with
|
2014-01-21 23:20:55 +00:00
|
|
|
the metadata,
|
2014-01-20 19:09:43 +00:00
|
|
|
from the local machine.
|
|
|
|
The path is relative to the
|
|
|
|
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
|
|
|
|
variable.
|
|
|
|
Thus, the build system searches, in order, from the
|
|
|
|
following directories, which are assumed to be a
|
|
|
|
subdirectories of the directory in which the
|
|
|
|
recipe file (<filename>.bb</filename>) or
|
|
|
|
append file (<filename>.bbappend</filename>)
|
|
|
|
resides:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
|
|
|
|
The base recipe name without any special
|
|
|
|
suffix or version numbers.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
|
|
|
|
<filename>${BPN}-${PV}</filename>.
|
|
|
|
The base recipe name and version but without
|
|
|
|
any special package name suffix.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis>files -</emphasis>
|
2014-01-21 23:20:55 +00:00
|
|
|
Files within a directory that is named
|
2014-01-20 19:09:43 +00:00
|
|
|
<filename>files</filename> and is also
|
|
|
|
alongside the recipe or append file.
|
|
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
|
|
If you want the build system to pick up files
|
|
|
|
specified through a
|
|
|
|
<filename>SRC_URI</filename>
|
|
|
|
statement from your append file, you need to be
|
|
|
|
sure to extend the
|
|
|
|
<filename>FILESPATH</filename>
|
|
|
|
variable by also using the
|
|
|
|
<filename>FILESEXTRAPATHS</filename>
|
|
|
|
variable from within your append file.
|
|
|
|
</note>
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
|
|
|
|
Bazaar revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
|
|
|
|
Git revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
|
|
|
|
an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
|
|
|
|
a repo (Git) repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>svk://</filename> -</emphasis> Fetches files from
|
|
|
|
an SVK revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
|
2014-01-21 23:20:55 +00:00
|
|
|
the Internet using HTTP.</para></listitem>
|
2014-01-20 19:09:43 +00:00
|
|
|
<listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
|
2014-01-21 23:20:55 +00:00
|
|
|
from the Internet using HTTPS.</para></listitem>
|
2014-01-20 19:09:43 +00:00
|
|
|
<listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
|
2014-01-21 23:20:55 +00:00
|
|
|
from the Internet using FTP.</para></listitem>
|
2014-01-20 19:09:43 +00:00
|
|
|
<listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
|
|
|
|
a CVS revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
|
|
|
|
a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
|
|
|
|
a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
|
|
|
|
a secure shell.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
|
|
|
|
a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>Standard and recipe-specific options for <filename>SRC_URI</filename> exist.
|
|
|
|
Here are standard options:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para><emphasis><filename>apply</filename> -</emphasis> Whether to apply
|
|
|
|
the patch or not.
|
|
|
|
The default action is to apply the patch.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>striplevel</filename> -</emphasis> Which
|
|
|
|
striplevel to use when applying the patch.
|
|
|
|
The default level is 1.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>patchdir</filename> -</emphasis> Specifies
|
|
|
|
the directory in which the patch should be applied.
|
|
|
|
The default is <filename>${S}</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>Here are options specific to recipes building code from a revision control system:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para><emphasis><filename>mindate</filename> -</emphasis>
|
|
|
|
Apply the patch only if
|
|
|
|
<link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
|
|
|
|
is equal to or greater than <filename>mindate</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
|
|
|
|
Apply the patch only if <filename>SRCDATE</filename>
|
|
|
|
is not later than <filename>mindate</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>minrev</filename> -</emphasis>
|
|
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
|
|
is equal to or greater than <filename>minrev</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>maxrev</filename> -</emphasis>
|
|
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
|
|
is not later than <filename>maxrev</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>rev</filename> -</emphasis>
|
|
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
|
|
is equal to <filename>rev</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>notrev</filename> -</emphasis>
|
|
|
|
Apply the patch only if <filename>SRCREV</filename>
|
|
|
|
is not equal to <filename>rev</filename>.
|
|
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>Here are some additional options worth mentioning:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
|
|
|
|
whether or not to unpack the file if it is an archive.
|
|
|
|
The default action is to unpack the file.</para></listitem>
|
|
|
|
<listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
|
|
|
|
(or extracts its contents) into the specified
|
|
|
|
subdirectory of <filename>WORKDIR</filename>.
|
|
|
|
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-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-SRCREV'><glossterm>SRCREV</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
|
|
|
The revision of the source code used to build the package.
|
2014-01-21 23:20:55 +00:00
|
|
|
This variable applies only when using Subversion, Git, Mercurial and Bazaar.
|
|
|
|
If you want to build a fixed revision and you want
|
2014-01-20 19:09:43 +00:00
|
|
|
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-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.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
2014-01-21 23:20:55 +00:00
|
|
|
A short summary for the recipe, which is 72 characters or less.
|
2014-01-20 19:09:43 +00:00
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
</glossdiv>
|
|
|
|
|
|
|
|
<glossdiv id='var-glossary-t'><title>T</title>
|
|
|
|
|
|
|
|
<glossentry id='var-T'><glossterm>T</glossterm>
|
|
|
|
<glossdef>
|
2014-01-21 23:20:55 +00:00
|
|
|
<para>Points to a directory were BitBake places
|
2014-01-20 19:09:43 +00:00
|
|
|
temporary files, which consist mostly of task logs and
|
|
|
|
scripts, when building a particular recipe.
|
|
|
|
</para>
|
|
|
|
</glossdef>
|
|
|
|
</glossentry>
|
|
|
|
|
|
|
|
<glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
|
|
|
|
<glossdef>
|
|
|
|
<para>
|
2014-01-21 23:25:41 +00:00
|
|
|
Points to the build directory.
|
2014-01-20 19:09:43 +00:00
|
|
|
BitBake automatically sets this variable.
|
|
|
|
</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>
|
|
|
|
</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
|
|
|
|
-->
|