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

handbook: review and modify CH4 (BSP) and Appendix B

Browse Source 
Besides basic corrections, also add .bbappend to bsp introduction
and update bitbake help to match latest output

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
This commit is contained in:
Zhai Edwin
2010-09-09 16:23:01 +08:00
committed by Richard Purdie
parent 2beaecb351
commit 8c7e1aced8
2 changed files with 66 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
handbook/ref-bitbake.xml
View File

@@ -6,7 +6,7 @@
<title>Reference: Bitbake</title>
<para>
Bitbake a program written in Python which interprets the metadata
Bitbake is a program written in Python that interprets the metadata
that makes up Poky. At some point, people wonder what actually happens
when you type <command>bitbake poky-image-sato</command>. This section
aims to give an overview of what happens behind the scenes from a
@@ -16,7 +16,7 @@
<para>
It is worth noting that bitbake aims to be a generic "task" executor
capable of handling complex dependency relationships. As such it has no
real knowledge of what the tasks its executing actually do. It just
real knowledge of what the tasks it is executing actually do. It just
considers a list of tasks with dependencies and handles metadata
consisting of variables in a certain format which get passed to the
tasks.
@@ -26,7 +26,7 @@
<title>Parsing</title>
<para>
The first thing BitBake does is work out its configuration by
The first thing BitBake does is that work out its configuration by
looking for a file called <filename>bitbake.conf</filename>.
Bitbake searches through the <varname>BBPATH</varname> environment
variable looking for a <filename class="directory">conf/</filename>
@@ -117,7 +117,7 @@
specified on the commandline) and looks for providers of that target.
Once a provider is selected, BitBake resolves all the dependencies for
the target. In the case of "poky-image-sato", it would lead to
<filename>task-oh.bb</filename> and <filename>task-base.bb</filename>
<filename>task-base.bb</filename>
which in turn would lead to packages like <application>Contacts</application>,
<application>Dates</application>, <application>BusyBox</application>
and these in turn depend on glibc and the toolchain.
@@ -154,7 +154,8 @@
"1" makes it likely the package will be used.
<glossterm><link
linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></glossterm> overrides
any default preference. <glossterm><link
any <glossterm><link
linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm>. <glossterm><link
linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm>
is often used to mark more
experimental new versions of packages until they've undergone sufficient
@@ -176,7 +177,7 @@
multi-core systems, BitBake considers each task as an independent
entity with a set of dependencies. There are many variables that
are used to signify these dependencies and more information can be found
found about these in the <ulink url='http://bitbake.berlios.de/manual/'>
about these in the <ulink url='http://bitbake.berlios.de/manual/'>
BitBake manual</ulink>. At a basic level it is sufficient to know
that BitBake uses the <glossterm><link
linkend='var-DEPENDS'>DEPENDS</link></glossterm> and
@@ -196,7 +197,7 @@
order. The build now starts with BitBake forking off threads up to
the limit set in the <glossterm><link
linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm> variable
as long there are tasks ready to run, i.e. tasks with all their
as long as there are tasks ready to run, i.e. tasks with all their
dependencies met.
</para>
@@ -271,9 +272,9 @@ Options:
target that failed, and those that depend on it,
cannot be remade, the other dependencies of these
targets can be processed all the same.
-a, --tryaltconfigs continue with builds by trying to use alternative
providers where possible.
-f, --force force run of specified cmd, regardless of stamp status
-i, --interactive drop into the interactive mode also called the BitBake
shell.
-c CMD, --cmd=CMD Specify task to execute. Note that this only executes
the specified task for the providee and the packages
it depends on, i.e. 'compile' does not implicitly call
@@ -286,6 +287,9 @@ Options:
-D, --debug Increase the debug level. You can specify this more
than once.
-n, --dry-run don't execute, just go through the motions
-S, --dump-signatures
don't execute, just dump out the signature
construction information
-p, --parse-only quit after parsing the BB files (developers only)
-d, --disable-psyco disable using the psyco just-in-time compiler (not
recommended)
@@ -294,13 +298,16 @@ Options:
what used to be bbread)
-g, --graphviz emit the dependency trees of the specified packages in
the dot syntax
-I IGNORED_DOT_DEPS, --ignore-deps=IGNORED_DOT_DEPS
Stop processing at the given list of dependencies when
generating dependency graphs. This can help to make
the graph more appealing
-I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
Assume these dependencies don't exist and are already
provided (equivalent to ASSUME_PROVIDED). Useful to
make dependency graphs more appealing
-l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
Show debug logging for the specified logging domains
-P, --profile profile the command and print a report</screen>
-P, --profile profile the command and print a report
-u UI, --ui=UI userinterface to use
--revisions-changed Set the exit code depending on whether upstream
floating revisions have changed or not</screen>
</section>