mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-10 23:02:25 +02:00
Code Issues Packages Projects Releases Wiki Activity

bitbake: user-manual-bitbakecommand: Various edits/cleanups

Browse Source 
(Bitbake rev: f079e0886b1b191d84621057f9752cc32bfabb44)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Richard Purdie
2014-01-18 16:25:25 +00:00
parent 5cce95c602
commit bd4140578e
1 changed files with 88 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

162
bitbake/doc/user-manual/user-manual-bitbakecommand.xml
View File

@@ -2,16 +2,16 @@
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter>
<title>The BitBake command</title>
<title>The BitBake Command</title>
<section id='bitbake-command-introduction'>
<title>Introduction</title>
<para>
bitbake is the primary command in the system.
It facilitates executing tasks in a single .bb
Bitbake is the primary command in the system.
It facilitates executing tasks in a single <filename>.bb</filename>
file, or executing a given task on a set of multiple
.bb files, accounting for interdependencies
<filename>.bb</filename> files, accounting for interdependencies
amongst them.
</para>
</section>
@@ -20,8 +20,9 @@
<title>Usage and syntax</title>
<para>
Following is the usage and syntax for BitBake:
<literallayout class='monospaced'>
<prompt>$ </prompt>bitbake --help
$ bitbake -h
Usage: bitbake [options] [recipename/target ...]
Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
@@ -99,23 +100,30 @@ Options:
<section id='bitbake-examples'>
<title>Examples</title>
<para>
This section presents some examples showing how to use BitBake.
</para>
<section id='example-executing-a-task-against-a-single-recipe'>
<title>Executing a task against a single .bb</title>
<title>Executing a Task Against a Single Recipe</title>
<para>
Executing tasks for a single file is relatively simple.
You specify the file in question, and BitBake parses
it and executes the specified task (or <quote>build</quote> by default).
It obeys intertask dependencies when doing so.
Executing tasks for a single recipe file is relatively simple.
You specify the file in question, and BitBake parses
it and executes the specified task (or “build” by default).
BitBake obeys inter-task dependencies when doing
so.
</para>
<para>
<para><quote>clean</quote> task:</para>
The following command runs the clean task on the
<filename>foo_1.0.bb</filename> recipe file:
<literallayout class='monospaced'>
$ bitbake -b foo.bb -c clean
</literallayout>
<para><quote>build</quote> task:</para>
The following command runs the build task, which is
the default task, on the <filename>foo_1.0.bb</filename>
recipe file:
<literallayout class='monospaced'>
$ bitbake -b foo_1.0.bb
</literallayout>
@@ -123,20 +131,21 @@ Options:
</section>
<section id='executing-tasks-against-a-set-of-recipe-files'>
<title>Executing tasks against a set of .bb files</title>
<title>Executing Tasks Against a Set of Recipe Files</title>
<para>
There are a number of additional complexities introduced
when one wants to manage multiple .bb
when one wants to manage multiple <filename>.bb</filename>
files.
Clearly there needs to be a way to tell BitBake what
files are available, and of those, which we
want to execute at this time
There also needs to be a way for each .bb
to express its dependencies, both for build time and
want to execute at this time.
There also needs to be a way for each <filename>.bb</filename>
to express its dependencies, both for build-time and
runtime.
There must be a way for the user to express their preferences
when multiple .bb's provide the same functionality, or when
there are multiple versions of a .bb.
when multiple recipes provide the same functionality, or when
there are multiple versions of a <filename>.bb</filename> file.
</para>
<para>
@@ -144,10 +153,10 @@ Options:
</para>
<para>
Note that the bitbake command, when not using
--buildfile, accepts a <varname>PROVIDER</varname>, not a filename or
The <filename>bitbake</filename> command, when not using
"--buildfile", accepts a PROVIDER, not a filename or
anything else.
By default, a .bb generally PROVIDES its
By default, a <filename>.bb</filename> generally PROVIDES its
packagename, packagename-version, and packagename-version-revision.
<literallayout class='monospaced'>
$ bitbake foo
@@ -166,22 +175,23 @@ Options:
</section>
<section id='generating-dependency-graphs'>
<title>Generating dependency graphs</title>
<para>
BitBake is able to generate dependency graphs using
<title>Generating Dependency Graphs</title>
<para>
BitBake is able to generate dependency graphs using
the dot syntax.
These graphs can be converted to images using the <application>dot</application>
application from
<ulink url="http://www.graphviz.org">Graphviz</ulink>.
Two files will be written into the current working directory,
<emphasis>depends.dot</emphasis> containing dependency information
at the package level and <emphasis>task-depends.dot</emphasis>
These graphs can be converted to images using the dot
application from
<ulink url='http://www.graphviz.org'>Graphviz</ulink>.
Two files will be written into the current working directory:
<filename>depends.dot</filename> containing dependency information
at the package level and <filename>task-depends.dot</filename>
containing a breakdown of the dependencies at the task level.
To stop depending on common depends, one can use the <prompt>-I depend</prompt>
to omit these from the graph.
To stop depending on common depends, one can use the "-I" depend
option to omit these from the graph.
This can lead to more readable graphs.
This way, <varname>DEPENDS</varname> from inherited classes
such as base.bbclass can be removed from the
This way, <filename>DEPENDS</filename> from inherited classes
such as <filename>base.bbclass</filename> can be removed from the
graph.
<literallayout class='monospaced'>
$ bitbake -g foo
@@ -193,14 +203,14 @@ Options:
</section>
<section id='special-variables'>
<title>Special variables</title>
<title>Special Variables</title>
<para>
Certain variables affect BitBake operation:
</para>
<section id='bb-number-threads'>
<title><varname>BB_NUMBER_THREADS</varname></title>
<title><filename>BB_NUMBER_THREADS</filename></title>
<para>
The number of threads BitBake should run at once (default: 1).
@@ -211,34 +221,35 @@ Options:
<section id='bitbake-command-metadata'>
<title>Metadata</title>
<para>
As you may have seen in the usage information, or in the
information about .bb files, the
<varname>BBFILES</varname> variable is how the BitBake
tool locates its files.
This variable is a space separated list of files
that are available, and supports wildcards.
<para>
As you may have seen in the usage information, or in the
information about <filename>.bb</filename> files, the
<filename>BBFILES</filename> variable is how the BitBake
tool locates its files.
This variable is a space-separated list of files
that are available, and supports wildcards.
</para>
<section id='setting-bbfiles'>
<title>Setting BBFILES</title>
<title>Setting <filename>BBFILES</filename></title>
<para>
<literallayout class='monospaced'>
BBFILES = "/path/to/bbfiles/*.bb"
</literallayout>
With regard to dependencies, it expects the
.bb to define a
<varname>DEPENDS</varname> variable, which contains a
space separated list of <quote>package names</quote>, which themselves
are the <varname>PN</varname> variable. The
<varname>PN</varname> variable is, in general,
set to a component of the .bb
<filename>.bb</filename> to define a
<filename>DEPENDS</filename> variable, which contains a
space separated list of “package names”, which themselves
are the <filename>PN</filename> variable. The
<filename>PN</filename> variable is, in general,
set to a component of the <filename>.bb</filename>
filename by default.
</para>
</section>
<section id='depending-on-another-recipe-file'>
<title>Depending on another .bb</title>
<title>Depending on Another Recipe File</title>
<para>
<literallayout class='monospaced'>
@@ -255,10 +266,13 @@ Options:
</section>
<section id='using-provides'>
<title>Using PROVIDES</title>
<title>Using <filename>PROVIDES</filename></title>
<para>
This example shows the usage of the <varname>PROVIDES</varname> variable, which allows a given .bb to specify what functionality it provides.
This example shows the usage of the
<filename>PROVIDES</filename> variable, which allows a
given <filename>.bb</filename> to specify what
functionality it provides.
<literallayout class='monospaced'>
package1.bb:
@@ -273,7 +287,7 @@ This example shows the usage of the <varname>PROVIDES</varname> variable, which
PROVIDES += "virtual/package"
</literallayout>
As you can see, we have two different
.bb's that provide the same functionality
recipes that provide the same functionality
(virtual/package).
Clearly, there needs to be a way for the person running
BitBake to control which of those providers
@@ -282,7 +296,8 @@ This example shows the usage of the <varname>PROVIDES</varname> variable, which
</para>
<para>
The following would go into a .conf file, to select package1:
The following would go into a <filename>.conf</filename>
file, to select package1:
<literallayout class='monospaced'>
PREFERRED_PROVIDER_virtual/package = "package1"
</literallayout>
@@ -290,27 +305,27 @@ The following would go into a .conf file, to select package1:
</section>
<section id='specifying-version-preference'>
<title>Specifying version preference</title>
<title>Specifying Version Preference</title>
<para>
When there are multiple <quote>versions</quote> of a given package,
BitBake defaults to selecting the most recent version,
unless otherwise specified.
If the .bb in question has a
<varname>DEFAULT_PREFERENCE</varname> set lower than
the other .bb's (default is 0), then it will not be
When there are multiple “versions” of a given package,
BitBake defaults to selecting the most recent
version, unless otherwise specified.
If the <filename>.bb</filename> in question has a
<filename>DEFAULT_PREFERENCE</filename> set lower than
the other recipes (default is 0), then it will not be
selected.
This allows the person or persons maintaining
the repository of .bb files to specify
the repository of <filename>.bb</filename> files to specify
their preference for the default selected version.
In addition, the user can specify their preferred version.
</para>
<para>
If the first .bb is named
If the first <filename>.bb</filename> is named
<filename>a_1.1.bb</filename>, then the
<varname>PN</varname> variable will be set to
<quote>a</quote>, and the <varname>PV</varname> variable will be
<filename>PN</filename> variable will be set to
“a”, and the <filename>PV</filename> variable will be
set to 1.1.
</para>
@@ -318,27 +333,26 @@ The following would go into a .conf file, to select package1:
If we then have an <filename>a_1.2.bb</filename>, BitBake
will choose 1.2 by default.
However, if we define the following variable in a
.conf that BitBake parses, we
<filename>.conf</filename> file that BitBake parses, we
can change that.
<literallayout class='monospaced'>
PREFERRED_VERSION_a = "1.1"
</literallayout>
</para>
</section>
<section id='using-recipe-file-collections'>
<title>Using <quote>bbfile collections</quote></title>
<title>Using Recipe File Collections</title>
<para>
bbfile collections exist to allow the user to
Recipe file collections exist to allow the user to
have multiple repositories of
bbfiles that contain the same
<filename>.bb</filename> files that contain the same
exact package.
For example, one could easily use them to make one's
own local copy of an upstream repository, but with
custom modifications that one does not want upstream.
Usage:
Here is an example:
<literallayout class='monospaced'>
BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
BBFILE_COLLECTIONS = "upstream local"