bitbake: user-manual-metadata: Editing pass over the manual chapter
(Bitbake rev: 6f326f2f2785d6d48d7753abee6e8162852d8702) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
98b41e41ff
commit
c8892fc919
|
@ -5,21 +5,27 @@
|
||||||
<title>Metadata</title>
|
<title>Metadata</title>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Description</title>
|
<title>Overview</title>
|
||||||
<itemizedlist>
|
|
||||||
<para>BitBake metadata can be classified into 3 major areas:</para>
|
|
||||||
<listitem>
|
|
||||||
<para>Configuration Files</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>.bb Files</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>Classes</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
<para>
|
<para>
|
||||||
What follows are a large number of examples of BitBake metadata. Any syntax which isn't supported
|
The BitBake task executor together with various types of configuration files form the OpenEmbedded
|
||||||
|
Core.
|
||||||
|
This section provides an overview of the BitBake task executor and the configuration files by
|
||||||
|
describing what they are used for and how they interact.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
BitBake handles the parsing and execution of the data files. The data itself is of various types:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem><para><emphasis>Recipes:</emphasis>
|
||||||
|
Provides details about particular pieces of software.</para></listitem>
|
||||||
|
<listitem><para><emphasis>Class Data:</emphasis>
|
||||||
|
An abstraction of common build information (e.g. how to build a Linux kernel).</para></listitem>
|
||||||
|
<listitem><para><emphasis>Configuration Data:</emphasis>
|
||||||
|
Defines machine-specific settings, policy decisions, etc. Configuration data acts
|
||||||
|
as the glue to bind everything together.</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
What follows are a large number of examples of BitBake metadata. Any syntax which isn't supported
|
||||||
in any of the aforementioned areas will be documented as such.
|
in any of the aforementioned areas will be documented as such.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -28,7 +34,7 @@
|
||||||
<title>Basic Syntax</title>
|
<title>Basic Syntax</title>
|
||||||
|
|
||||||
<section id='basic-variable-setting'>
|
<section id='basic-variable-setting'>
|
||||||
<title>Basic variable setting</title>
|
<title>Basic Variable Setting</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
|
@ -39,7 +45,7 @@
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='variable-expansion'>
|
<section id='variable-expansion'>
|
||||||
<title>Variable expansion</title>
|
<title>Variable Expansion</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake supports variables referencing one another's
|
BitBake supports variables referencing one another's
|
||||||
|
@ -69,8 +75,10 @@
|
||||||
it will retain its previous value.
|
it will retain its previous value.
|
||||||
If <filename>A</filename> is unset prior to the above call,
|
If <filename>A</filename> is unset prior to the above call,
|
||||||
<filename>A</filename> will be set to <filename>aval</filename>.
|
<filename>A</filename> will be set to <filename>aval</filename>.
|
||||||
Note that this assignment is immediate, so if there are multiple ?= assignments
|
<note>
|
||||||
|
This assignment is immediate, so if there are multiple "?=" assignments
|
||||||
to a single variable, the first of those will be used.
|
to a single variable, the first of those will be used.
|
||||||
|
</note>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
@ -86,11 +94,11 @@
|
||||||
it will retain that value.
|
it will retain that value.
|
||||||
If <filename>A</filename> is unset prior to the above,
|
If <filename>A</filename> is unset prior to the above,
|
||||||
<filename>A</filename> will be set to <filename>someothervalue</filename>.
|
<filename>A</filename> will be set to <filename>someothervalue</filename>.
|
||||||
This is a lazy/weak assignment in that the assignment does not occur until the end
|
This is a lazy or weak assignment in that the assignment does not occur until the end
|
||||||
of the parsing process, so that the last, rather than the first,
|
of the parsing process, so that the last, rather than the first,
|
||||||
??= assignment to a given variable will be used.
|
"??=" assignment to a given variable will be used.
|
||||||
Any other setting of <filename>A</filename> using = or ?=
|
Any other setting of <filename>A</filename> using "=" or "?="
|
||||||
will however override the value set with ??=
|
will, however, override the value set with "??=".
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
@ -98,8 +106,9 @@
|
||||||
<title>Immediate variable expansion (:=)</title>
|
<title>Immediate variable expansion (:=)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
:= results in a variable's contents being expanded immediately, rather than when the variable is actually used.
|
The ":=" operator results in a variable's contents being expanded immediately,
|
||||||
<literallayout class='monospaced'>
|
rather than when the variable is actually used:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
T = "123"
|
T = "123"
|
||||||
A := "${B} ${A} test ${T}"
|
A := "${B} ${A} test ${T}"
|
||||||
T = "456"
|
T = "456"
|
||||||
|
@ -107,7 +116,7 @@
|
||||||
C = "cval"
|
C = "cval"
|
||||||
C := "${C}append"
|
C := "${C}append"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
In that example, <filename>A</filename> would contain
|
In this example, <filename>A</filename> would contain
|
||||||
<filename>test 123</filename>, <filename>B</filename> would contain
|
<filename>test 123</filename>, <filename>B</filename> would contain
|
||||||
<filename>456 bval</filename>, and <filename>C</filename>
|
<filename>456 bval</filename>, and <filename>C</filename>
|
||||||
would be <filename>cvalappend</filename>.
|
would be <filename>cvalappend</filename>.
|
||||||
|
@ -131,7 +140,7 @@
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='appending-and-prepending-without-spaces'>
|
<section id='appending-and-prepending-without-spaces'>
|
||||||
<title>Appending (.=) and prepending (=.) without spaces</title>
|
<title>Appending (.=) and Prepending (=.) Without Spaces</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
|
@ -149,7 +158,7 @@
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='appending-and-prepending-override-style-syntax'>
|
<section id='appending-and-prepending-override-style-syntax'>
|
||||||
<title>Appending and Prepending (override style syntax)</title>
|
<title>Appending and Prepending (Override Style Syntax)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
|
@ -159,18 +168,20 @@
|
||||||
C_prepend = "additional data "
|
C_prepend = "additional data "
|
||||||
</literallayout>
|
</literallayout>
|
||||||
This example results in <filename>B</filename>
|
This example results in <filename>B</filename>
|
||||||
becoming <filename>bval additional data</filename>
|
becoming <filename>bval additional data</filename> and
|
||||||
and <filename>C</filename> becoming
|
<filename>C</filename> becoming
|
||||||
<filename>additional data cval</filename>.
|
<filename>additional data cval</filename>.
|
||||||
Note the spaces in the <filename>_append</filename>.
|
<note>
|
||||||
Unlike the += operator, additional space is not automatically added.
|
The spaces in <filename>_append</filename>.
|
||||||
You must take steps to add space
|
Unlike the "+=" operator, additional space is not automatically added.
|
||||||
yourself.
|
You must take steps to add space yourself.
|
||||||
|
</note>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='removing-override-style-syntax'>
|
<section id='removing-override-style-syntax'>
|
||||||
<title>Removing (override style syntax)</title>
|
<title>Removing (Override Style Syntax)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
FOO = "123 456 789 123456 123 456 123 456"
|
FOO = "123 456 789 123456 123 456 123 456"
|
||||||
|
@ -182,7 +193,7 @@ yourself.
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='variable-flags'>
|
<section id='variable-flags'>
|
||||||
<title>Variable flags</title>
|
<title>Variable Flags</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Variables can have associated flags which provide a way of tagging extra information onto a variable.
|
Variables can have associated flags which provide a way of tagging extra information onto a variable.
|
||||||
|
@ -192,12 +203,12 @@ yourself.
|
||||||
VARIABLE[SOMEFLAG] = "value"
|
VARIABLE[SOMEFLAG] = "value"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
In this example, <filename>VARIABLE</filename> has a flag,
|
In this example, <filename>VARIABLE</filename> has a flag,
|
||||||
<filename>SOMEFLAG</filename> which is set to <filename>value</filename>.
|
<filename>SOMEFLAG</filename> that is set to <filename>value</filename>.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='inline-python-variable-expansion'>
|
<section id='inline-python-variable-expansion'>
|
||||||
<title>Python variable expansion</title>
|
<title>Inline Python Variable Expansion</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
|
@ -207,18 +218,22 @@ yourself.
|
||||||
variable containing today's date.
|
variable containing today's date.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id='conditional-syntax-overrides'>
|
<section id='conditional-syntax-overrides'>
|
||||||
<title>Conditional metadata set</title>
|
<title>Conditional Syntax (Overrides)</title>
|
||||||
|
|
||||||
|
<section id='conditional-metadata'>
|
||||||
|
<title>Conditional Metadata</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<filename>OVERRIDES</filename> is a <quote>:</quote> separated variable containing
|
<filename>OVERRIDES</filename> is a “:” separated variable containing
|
||||||
each item you want to satisfy conditions.
|
each item for which you want to satisfy conditions.
|
||||||
So, if you have a variable which is conditional on <quote>arm</quote>, and <quote>arm</quote>
|
So, if you have a variable that is conditional on “arm”, and “arm”
|
||||||
is in <filename>OVERRIDES</filename>, then the <quote>arm</quote> specific
|
is in <filename>OVERRIDES</filename>, then the “arm” specific
|
||||||
version of the variable is used rather than the non-conditional
|
version of the variable is used rather than the non-conditional
|
||||||
version.
|
version.
|
||||||
Example:
|
Here is an example:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
OVERRIDES = "architecture:os:machine"
|
OVERRIDES = "architecture:os:machine"
|
||||||
TEST = "defaultvalue"
|
TEST = "defaultvalue"
|
||||||
|
@ -227,16 +242,17 @@ yourself.
|
||||||
</literallayout>
|
</literallayout>
|
||||||
In this example, <filename>TEST</filename> would be
|
In this example, <filename>TEST</filename> would be
|
||||||
<filename>osspecificvalue</filename>, due to the condition
|
<filename>osspecificvalue</filename>, due to the condition
|
||||||
<quote>os</quote> being in <filename>OVERRIDES</filename>.
|
“os” being in <filename>OVERRIDES</filename>.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='conditional-appending'>
|
<section id='conditional-appending'>
|
||||||
<title>Conditional appending</title>
|
<title>Conditional Appending</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake also supports appending and prepending to variables based
|
BitBake also supports appending and prepending to variables based
|
||||||
on whether something is in <filename>OVERRIDES</filename>. Example:
|
on whether something is in <filename>OVERRIDES</filename>.
|
||||||
|
Here is an example:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
DEPENDS = "glibc ncurses"
|
DEPENDS = "glibc ncurses"
|
||||||
OVERRIDES = "machine:local"
|
OVERRIDES = "machine:local"
|
||||||
|
@ -248,22 +264,22 @@ yourself.
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='variable-interaction-worked-examples'>
|
<section id='variable-interaction-worked-examples'>
|
||||||
<title>Variable interaction: Worked Examples</title>
|
<title>Variable Interaction: Worked Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Despite the documentation of the different forms of
|
Despite the documentation of the different forms of
|
||||||
variable definition above, it can be hard to work
|
variable definition above, it can be hard to work
|
||||||
out what happens when variable operators are combined.
|
out what happens when variable operators are combined.
|
||||||
This section documents some common questions people have
|
</para>
|
||||||
regarding the way variables interact.
|
|
||||||
|
<para>
|
||||||
|
Following are some common scenarios where variables interact
|
||||||
|
that can confuse users.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
There is often confusion about which order overrides and the
|
There is often confusion about which order overrides and the
|
||||||
various append operators take effect.
|
various "append" operators take effect:
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
OVERRIDES = "foo"
|
OVERRIDES = "foo"
|
||||||
A_foo_append = "X"
|
A_foo_append = "X"
|
||||||
|
@ -297,7 +313,7 @@ yourself.
|
||||||
A .= "5"
|
A .= "5"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
Would ultimately result in <filename>A</filename> taking the value
|
Would ultimately result in <filename>A</filename> taking the value
|
||||||
"1 4523" since the _append operator executes at the
|
"1 4523" since the "_append" operator executes at the
|
||||||
same time as the expansion of other overrides.
|
same time as the expansion of other overrides.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
@ -306,7 +322,7 @@ yourself.
|
||||||
<title>Key Expansion</title>
|
<title>Key Expansion</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Key expansion happens at the data store finalisation
|
Key expansion happens at the data store finalization
|
||||||
time just before overrides are expanded.
|
time just before overrides are expanded.
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
A${B} = "X"
|
A${B} = "X"
|
||||||
|
@ -322,10 +338,13 @@ yourself.
|
||||||
<title>Inheritance</title>
|
<title>Inheritance</title>
|
||||||
|
|
||||||
<section id='inheritance-directive'>
|
<section id='inheritance-directive'>
|
||||||
<title>Inheritance</title>
|
<title>Inheritance Directive</title>
|
||||||
<para><emphasis>NOTE:</emphasis>
|
|
||||||
This is only supported in .bb and .bbclass files.
|
<note>
|
||||||
</para>
|
This is only supported in <filename>.bb</filename> and
|
||||||
|
<filename>.bbclass</filename> files.
|
||||||
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The inherit directive is a means of specifying what classes
|
The inherit directive is a means of specifying what classes
|
||||||
of functionality your <filename>.bb</filename> requires.
|
of functionality your <filename>.bb</filename> requires.
|
||||||
|
@ -339,34 +358,42 @@ yourself.
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='inclusion-directive'>
|
<section id='inclusion-directive'>
|
||||||
<title>Inclusion</title>
|
<title>Inclusion Directive</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Next, there is the <filename>include</filename> directive, which causes BitBake to parse whatever file you specify,
|
This directive causes BitBake to parse whatever file you specify,
|
||||||
and insert it at that location, which is not unlike <command>make</command>.
|
and insert it at that location, which is not unlike Make.
|
||||||
However, if the path specified on the <filename>include</filename> line is a
|
However, if the path specified on the include line is a
|
||||||
relative path, BitBake will locate the first one it can find
|
relative path, BitBake will locate the first one it can find
|
||||||
within <filename>BBPATH</filename>.
|
within <filename>BBPATH</filename>.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='requiring-inclusion'>
|
<section id='requiring-inclusion'>
|
||||||
<title>Requiring inclusion</title>
|
<title>Requiring Inclusion</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In contrast to the <filename>include</filename> directive, <filename>require</filename> will
|
In contrast to the include directive, require will raise a
|
||||||
raise an
|
|
||||||
ParseError if the file to be included cannot
|
ParseError if the file to be included cannot
|
||||||
be found.
|
be found.
|
||||||
Otherwise it will behave just like the <filename>include</filename> directive.
|
Otherwise it will behave just like the include directive.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='defining-python-functions-into-the-global-python-namespace'>
|
<section id='defining-python-functions-into-the-global-python-namespace'>
|
||||||
<title>Defining Python functions into the global Python namespace</title>
|
<title>Defining Python Functions into the Global Python Namespace</title>
|
||||||
|
|
||||||
<para><emphasis>NOTE:</emphasis> This is only supported in .bb and .bbclass files
|
<note>
|
||||||
|
<para>
|
||||||
|
This is only supported in <filename>.bb</filename>
|
||||||
|
and <filename>.bbclass</filename> files.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Python functions are in the global namespace so should use
|
||||||
|
unique names.
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
def get_depends(d):
|
def get_depends(d):
|
||||||
if d.getVar('SOMECONDITION', True):
|
if d.getVar('SOMECONDITION', True):
|
||||||
|
@ -376,8 +403,10 @@ raise an
|
||||||
SOMECONDITION = "1"
|
SOMECONDITION = "1"
|
||||||
DEPENDS = "${@get_depends(d)}"
|
DEPENDS = "${@get_depends(d)}"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
This would result in <filename>DEPENDS</filename> containing <filename>dependencywithcond</filename>.
|
This would result in <filename>DEPENDS</filename>
|
||||||
|
containing <filename>dependencywithcond</filename>.
|
||||||
</para>
|
</para>
|
||||||
|
</note>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
|
@ -436,15 +465,15 @@ python do_printdate () {
|
||||||
<title>Configuration files</title>
|
<title>Configuration files</title>
|
||||||
<para>
|
<para>
|
||||||
The first kind of metadata in BitBake is configuration metadata.
|
The first kind of metadata in BitBake is configuration metadata.
|
||||||
This metadata is global, and therefore affects <emphasis>all</emphasis> packages and
|
This metadata is global, and therefore affects all packages and
|
||||||
tasks which are executed.
|
tasks that are executed.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake will first search the current working directory for an
|
BitBake will first search the current working directory for an
|
||||||
optional <filename>conf/bblayers.conf</filename> configuration file.
|
optional <filename>conf/bblayers.conf</filename> configuration file.
|
||||||
This file is expected to contain a <filename>BBLAYERS</filename>
|
This file is expected to contain a <filename>BBLAYERS</filename>
|
||||||
variable which is a space delimited list of 'layer' directories.
|
variable that is a space delimited list of 'layer' directories.
|
||||||
For each directory in this list, a <filename>conf/layer.conf</filename>
|
For each directory in this list, a <filename>conf/layer.conf</filename>
|
||||||
file will be searched for and parsed with the
|
file will be searched for and parsed with the
|
||||||
<filename>LAYERDIR</filename> variable being set to the directory where
|
<filename>LAYERDIR</filename> variable being set to the directory where
|
||||||
|
@ -456,10 +485,10 @@ python do_printdate () {
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake will then expect to find <filename>conf/bitbake.conf</filename>
|
BitBake will then expect to find <filename>conf/bitbake.conf</filename>
|
||||||
somewhere in the user specified <filename>BBPATH</filename>.
|
file somewhere in the user specified <filename>BBPATH</filename>.
|
||||||
That configuration file generally has include directives to pull
|
That configuration file generally has include directives to pull
|
||||||
in any other metadata (generally files specific to architecture,
|
in any other metadata (generally files specific to architecture,
|
||||||
machine, <emphasis>local</emphasis> and so on).
|
machine, local and so on).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -467,8 +496,10 @@ python do_printdate () {
|
||||||
in <filename>.conf</filename> files.
|
in <filename>.conf</filename> files.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='classes'>
|
<section id='classes'>
|
||||||
<title>Classes</title>
|
<title>Classes</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake classes are our rudimentary inheritance mechanism.
|
BitBake classes are our rudimentary inheritance mechanism.
|
||||||
As briefly mentioned in the metadata introduction, they're
|
As briefly mentioned in the metadata introduction, they're
|
||||||
|
@ -479,15 +510,15 @@ python do_printdate () {
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bb-files'>
|
<section id='bb-files'>
|
||||||
<title>.<filename>.bb</filename> files</title>
|
<title><filename>.bb</filename> Files</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake (<filename>.bb</filename>) file is a logical unit
|
A BitBake (<filename>.bb</filename>) file is a logical unit
|
||||||
of tasks to be executed.
|
of tasks to be executed.
|
||||||
Normally this is a package to be built.
|
Normally this is a package to be built.
|
||||||
Inter-<filename>.bb</filename> dependencies are obeyed.
|
Inter-<filename>.bb</filename> dependencies are obeyed.
|
||||||
The files themselves are located via
|
The files themselves are located via the
|
||||||
the <filename>BBFILES</filename> variable, which
|
<filename>BBFILES</filename> variable, which
|
||||||
is set to a space separated list of <filename>.bb</filename>
|
is set to a space separated list of <filename>.bb</filename>
|
||||||
files, and does handle wildcards.
|
files, and does handle wildcards.
|
||||||
</para>
|
</para>
|
||||||
|
@ -497,17 +528,17 @@ python do_printdate () {
|
||||||
<section id='events'>
|
<section id='events'>
|
||||||
<title>Events</title>
|
<title>Events</title>
|
||||||
|
|
||||||
<para>
|
<note>
|
||||||
<emphasis>NOTE:</emphasis>
|
This is only supported in <filename>.bb</filename>
|
||||||
This is only supported in <filename>.bb</filename>
|
|
||||||
and <filename>.bbclass</filename> files.
|
and <filename>.bbclass</filename> files.
|
||||||
</para>
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake allows installation of event handlers.
|
BitBake allows installation of event handlers.
|
||||||
Events are triggered at certain points during operation,
|
Events are triggered at certain points during operation,
|
||||||
such as the beginning of operation against a given
|
such as the beginning of operation against a given
|
||||||
<filename>.bb</filename>, the start of a given task,
|
<filename>.bb</filename>, the start of a given task,
|
||||||
task failure, task success, et cetera.
|
task failure, task success, and so forth.
|
||||||
The intent is to make it easy to do things like email
|
The intent is to make it easy to do things like email
|
||||||
notification on build failure.
|
notification on build failure.
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
|
@ -521,9 +552,9 @@ python do_printdate () {
|
||||||
</literallayout>
|
</literallayout>
|
||||||
This event handler gets called every time an event is
|
This event handler gets called every time an event is
|
||||||
triggered.
|
triggered.
|
||||||
A global variable <filename>e</filename> is defined.
|
A global variable "<filename>e</filename>" is defined.
|
||||||
<filename>e.data</filename> contains an instance of
|
"<filename>e.data</filename>" contains an instance of
|
||||||
<filename>bb.data</filename>.
|
"<filename>bb.data</filename>".
|
||||||
With the <filename>getName(e)</filename> method one can get
|
With the <filename>getName(e)</filename> method one can get
|
||||||
the name of the triggered event.
|
the name of the triggered event.
|
||||||
</para>
|
</para>
|
||||||
|
@ -535,7 +566,7 @@ python do_printdate () {
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='variants-class-extension-mechanism'>
|
<section id='variants-class-extension-mechanism'>
|
||||||
<title>Variants</title>
|
<title>Variants - Class Extension Mechanism</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Two BitBake features exist to facilitate the creation of
|
Two BitBake features exist to facilitate the creation of
|
||||||
|
@ -546,15 +577,12 @@ python do_printdate () {
|
||||||
The first is <filename>BBCLASSEXTEND</filename>.
|
The first is <filename>BBCLASSEXTEND</filename>.
|
||||||
This variable is a space separated list of classes used to "extend" the
|
This variable is a space separated list of classes used to "extend" the
|
||||||
recipe for each variant.
|
recipe for each variant.
|
||||||
As an example, setting
|
Here is an example that results in a second incarnation of the current
|
||||||
|
recipe being available.
|
||||||
|
This second incarnation will have the "native" class inherited.
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
BBCLASSEXTEND = "native"
|
BBCLASSEXTEND = "native"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
results in a second incarnation of the current
|
|
||||||
recipe being available.
|
|
||||||
This second incarnation will have the "native" class inherited.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
The second feature is <filename>BBVERSIONS</filename>.
|
The second feature is <filename>BBVERSIONS</filename>.
|
||||||
This variable allows a single recipe to build multiple versions of a
|
This variable allows a single recipe to build multiple versions of a
|
||||||
project from a single recipe file, and allows you to specify
|
project from a single recipe file, and allows you to specify
|
||||||
|
@ -568,7 +596,7 @@ python do_printdate () {
|
||||||
BBVERSIONS = "1.0.[0-6]:1.0.0+ \ 1.0.[7-9]:1.0.7+"
|
BBVERSIONS = "1.0.[0-6]:1.0.0+ \ 1.0.[7-9]:1.0.7+"
|
||||||
SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1"
|
SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
Note that the name of the range will default to the original version of the
|
The name of the range will default to the original version of the
|
||||||
recipe, so given OE, a recipe file of <filename>foo_1.0.0+.bb</filename>
|
recipe, so given OE, a recipe file of <filename>foo_1.0.0+.bb</filename>
|
||||||
will default the name of its versions to <filename>1.0.0+</filename>.
|
will default the name of its versions to <filename>1.0.0+</filename>.
|
||||||
This is useful, as the range name is not only placed into overrides;
|
This is useful, as the range name is not only placed into overrides;
|
||||||
|
@ -579,17 +607,21 @@ python do_printdate () {
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='dependencies'>
|
<section id='dependencies'>
|
||||||
<title>Dependency handling</title>
|
<title>Dependencies</title>
|
||||||
|
|
||||||
|
<section id='dependencies-overview'>
|
||||||
|
<title>Overview</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake handles dependencies at the task level since to
|
BitBake handles dependencies at the task level since to
|
||||||
allow for efficient operation with multiple
|
allow for efficient operation with multiple
|
||||||
processed executing in parallel. A robust method of
|
processes executing in parallel, a robust method of
|
||||||
specifying task dependencies is therefore needed.
|
specifying task dependencies is needed.
|
||||||
</para>
|
</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section id='dependencies-internal-to-the-bb-file'>
|
<section id='dependencies-internal-to-the-bb-file'>
|
||||||
<title>Dependencies internal to the <filename>.bb</filename> file</title>
|
<title>Dependencies Internal to the <filename>.bb</filename> File</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Where the dependencies are internal to a given
|
Where the dependencies are internal to a given
|
||||||
|
@ -609,7 +641,7 @@ python do_printdate () {
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
do_configure[deptask] = "do_populate_staging"
|
do_configure[deptask] = "do_populate_staging"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
means the <filename>do_populate_staging</filename>
|
In the previous example, the <filename>do_populate_staging</filename>
|
||||||
task of each item in <filename>DEPENDS</filename> must have completed before
|
task of each item in <filename>DEPENDS</filename> must have completed before
|
||||||
<filename>do_configure</filename> can execute.
|
<filename>do_configure</filename> can execute.
|
||||||
</para>
|
</para>
|
||||||
|
@ -628,7 +660,7 @@ python do_printdate () {
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
do_package_write[rdeptask] = "do_package"
|
do_package_write[rdeptask] = "do_package"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
means the <filename>do_package</filename>
|
In the previous example, the <filename>do_package</filename>
|
||||||
task of each item in <filename>RDEPENDS</filename> must have
|
task of each item in <filename>RDEPENDS</filename> must have
|
||||||
completed before <filename>do_package_write</filename> can execute.
|
completed before <filename>do_package_write</filename> can execute.
|
||||||
</para>
|
</para>
|
||||||
|
@ -639,7 +671,7 @@ python do_printdate () {
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These are specified with the 'recrdeptask' flag
|
These are specified with the 'recrdeptask' flag
|
||||||
which is used signify the task(s) of dependencies
|
which is used to signify the task(s) of dependencies
|
||||||
which must have completed before that task can be
|
which must have completed before that task can be
|
||||||
executed.
|
executed.
|
||||||
It works by looking though the build
|
It works by looking though the build
|
||||||
|
@ -655,29 +687,29 @@ python do_printdate () {
|
||||||
dependencies of those tasks but through the
|
dependencies of those tasks but through the
|
||||||
build and runtime dependencies of dependent tasks too.
|
build and runtime dependencies of dependent tasks too.
|
||||||
If that is the case, the taskname itself should
|
If that is the case, the taskname itself should
|
||||||
be referenced in the task list, e.g.
|
be referenced in the task list (e.g.
|
||||||
<filename>do_a[recrdeptask] = "do_a do_b"</filename>.
|
<filename>do_a[recrdeptask] = "do_a do_b"</filename>).
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='inter-task-dependencies'>
|
<section id='inter-task-dependencies'>
|
||||||
<title>Inter task</title>
|
<title>Inter-Task Dependencies</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The 'depends' flag for tasks is a more generic form of which
|
The 'depends' flag for tasks is a more generic form which
|
||||||
allows an interdependency on specific tasks rather than specifying
|
allows an inter-dependency on specific tasks rather than specifying
|
||||||
the data in <filename>DEPENDS</filename>.
|
the data in <filename>DEPENDS</filename>.
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
do_patch[depends] = "quilt-native:do_populate_staging"
|
do_patch[depends] = "quilt-native:do_populate_staging"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
means the <filename>do_populate_staging</filename>
|
In the previous example, the <filename>do_populate_staging</filename>
|
||||||
task of the target quilt-native must have completed before the
|
task of the target quilt-native must have completed before the
|
||||||
<filename>do_patch</filename> task can execute.
|
<filename>do_patch</filename> task can execute.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The 'rdepends' flag works in a similar way but takes targets
|
The 'rdepends' flag works in a similar way but takes targets
|
||||||
in the runtime namespace instead of the build time dependency
|
in the runtime namespace instead of the build-time dependency
|
||||||
namespace.
|
namespace.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
Loading…
Reference in New Issue