summaryrefslogtreecommitdiffstats
path: root/bitbake/doc
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2014-01-18 16:25:25 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-01-27 21:03:24 +0000
commitbd4140578ebf3150691e453232ba9dc8fbcd96bc (patch)
tree5364a5398ef8fb8b9b25a58c05d2167566f5a25b /bitbake/doc
parent5cce95c6028ab610e148e4d6884330151881dd98 (diff)
downloadast2050-yocto-poky-bd4140578ebf3150691e453232ba9dc8fbcd96bc.zip
ast2050-yocto-poky-bd4140578ebf3150691e453232ba9dc8fbcd96bc.tar.gz
bitbake: user-manual-bitbakecommand: Various edits/cleanups
(Bitbake rev: f079e0886b1b191d84621057f9752cc32bfabb44) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/doc')
-rw-r--r--bitbake/doc/user-manual/user-manual-bitbakecommand.xml162
1 files changed, 88 insertions, 74 deletions
diff --git a/bitbake/doc/user-manual/user-manual-bitbakecommand.xml b/bitbake/doc/user-manual/user-manual-bitbakecommand.xml
index c816333..78da71d 100644
--- a/bitbake/doc/user-manual/user-manual-bitbakecommand.xml
+++ b/bitbake/doc/user-manual/user-manual-bitbakecommand.xml
@@ -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"
OpenPOWER on IntegriCloud