mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-08 17:19:20 +00:00
Code Issues Projects Releases Wiki Activity

bitbake: sphinx: initial sphinx support

Browse Source 
This commit is autogenerated pandoc to generate an inital set
of reST files based on DocBook XML files.

A .rst file is generated for each .xml files in all manuals with this
command:

cd <manual>
for i in *.xml; do \
  pandoc -f docbook -t rst --shift-heading-level-by=-1 \
  $i -o $(basename $i .xml).rst \
done

The conversion was done with: pandoc 2.9.2.1-91 (Arch Linux).

Also created an initial top level index file for each document, and
added all 'books' to the top leve index.rst file.

The YP manuals layout is organized as:

Book
  Chapter
    Section
      Section
        Section

Sphinx uses section headers to create the document structure.
ReStructuredText defines sections headers like that:

   To break longer text up into sections, you use section headers. These
   are a single line of text (one or more words) with adornment: an
   underline alone, or an underline and an overline together, in dashes
   "-----", equals "======", tildes "~~~~~~" or any of the
   non-alphanumeric characters = - ` : ' " ~ ^ _ * + # < > that you feel
   comfortable with. An underline-only adornment is distinct from an
   overline-and-underline adornment using the same character. The
   underline/overline must be at least as long as the title text. Be
   consistent, since all sections marked with the same adornment style
   are deemed to be at the same level:

Let's define the following convention when converting from Docbook:

Book                => overline ===   (Title)
  Chapter           => overline ***   (1.)
    Section         => ====           (1.1)
      Section       => ----           (1.1.1)
        Section     => ~~~~           (1.1.1.1)
          Section   => ^^^^           (1.1.1.1.1)

During the conversion with pandoc, we used --shift-heading-level=-1 to
convert most of DocBook headings automatically. However with this
setting, the Chapter header was removed, so I added it back
manually. Without this setting all headings were off by one, which was
more difficult to manually fix.

At least with this change, we now have the same TOC with Sphinx and
DocBook.

(Bitbake rev: 6bf6c8d63787aed7624793c24af3fa603b5ac961)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Nicolas Dechesne
2020-07-01 17:00:17 +02:00
committed by Richard Purdie
parent 69ed72025a
commit 080f80d912
7 changed files with 5204 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst
+654
View File
@@ -0,0 +1,654 @@
=========
Execution
=========
The primary purpose for running BitBake is to produce some kind of
output such as a single installable package, a kernel, a software
development kit, or even a full, board-specific bootable Linux image,
complete with bootloader, kernel, and root filesystem. Of course, you
can execute the ``bitbake`` command with options that cause it to
execute single tasks, compile single recipe files, capture or clear
data, or simply return information about the execution environment.
This chapter describes BitBake's execution process from start to finish
when you use it to create an image. The execution process is launched
using the following command form: $ bitbake target For information on
the BitBake command and its options, see "`The BitBake
Command <#bitbake-user-manual-command>`__" section.
.. note::
Prior to executing BitBake, you should take advantage of available
parallel thread execution on your build host by setting the
```BB_NUMBER_THREADS`` <#var-bb-BB_NUMBER_THREADS>`__ variable in
your project's ``local.conf`` configuration file.
A common method to determine this value for your build host is to run
the following: $ grep processor /proc/cpuinfo This command returns
the number of processors, which takes into account hyper-threading.
Thus, a quad-core build host with hyper-threading most likely shows
eight processors, which is the value you would then assign to
``BB_NUMBER_THREADS``.
A possibly simpler solution is that some Linux distributions (e.g.
Debian and Ubuntu) provide the ``ncpus`` command.
Parsing the Base Configuration Metadata
=======================================
The first thing BitBake does is parse base configuration metadata. Base
configuration metadata consists of your project's ``bblayers.conf`` file
to determine what layers BitBake needs to recognize, all necessary
``layer.conf`` files (one from each layer), and ``bitbake.conf``. The
data itself is of various types:
- *Recipes:* Details about particular pieces of software.
- *Class Data:* An abstraction of common build information (e.g. how to
build a Linux kernel).
- *Configuration Data:* Machine-specific settings, policy decisions,
and so forth. Configuration data acts as the glue to bind everything
together.
The ``layer.conf`` files are used to construct key variables such as
```BBPATH`` <#var-bb-BBPATH>`__ and ```BBFILES`` <#var-bb-BBFILES>`__.
``BBPATH`` is used to search for configuration and class files under the
``conf`` and ``classes`` directories, respectively. ``BBFILES`` is used
to locate both recipe and recipe append files (``.bb`` and
``.bbappend``). If there is no ``bblayers.conf`` file, it is assumed the
user has set the ``BBPATH`` and ``BBFILES`` directly in the environment.
Next, the ``bitbake.conf`` file is located using the ``BBPATH`` variable
that was just constructed. The ``bitbake.conf`` file may also include
other configuration files using the ``include`` or ``require``
directives.
Prior to parsing configuration files, BitBake looks at certain
variables, including:
- ```BB_ENV_WHITELIST`` <#var-bb-BB_ENV_WHITELIST>`__
- ```BB_ENV_EXTRAWHITE`` <#var-bb-BB_ENV_EXTRAWHITE>`__
- ```BB_PRESERVE_ENV`` <#var-bb-BB_PRESERVE_ENV>`__
- ```BB_ORIGENV`` <#var-bb-BB_ORIGENV>`__
- ```BITBAKE_UI`` <#var-bb-BITBAKE_UI>`__
The first four variables in this list relate to how BitBake treats shell
environment variables during task execution. By default, BitBake cleans
the environment variables and provides tight control over the shell
execution environment. However, through the use of these first four
variables, you can apply your control regarding the environment
variables allowed to be used by BitBake in the shell during execution of
tasks. See the "`Passing Information Into the Build Task
Environment <#passing-information-into-the-build-task-environment>`__"
section and the information about these variables in the variable
glossary for more information on how they work and on how to use them.
The base configuration metadata is global and therefore affects all
recipes and tasks that are executed.
BitBake first searches the current working directory for an optional
``conf/bblayers.conf`` configuration file. This file is expected to
contain a ```BBLAYERS`` <#var-bb-BBLAYERS>`__ variable that is a
space-delimited list of 'layer' directories. Recall that if BitBake
cannot find a ``bblayers.conf`` file, then it is assumed the user has
set the ``BBPATH`` and ``BBFILES`` variables directly in the
environment.
For each directory (layer) in this list, a ``conf/layer.conf`` file is
located and parsed with the ```LAYERDIR`` <#var-bb-LAYERDIR>`__ variable
being set to the directory where the layer was found. The idea is these
files automatically set up ```BBPATH`` <#var-bb-BBPATH>`__ and other
variables correctly for a given build directory.
BitBake then expects to find the ``conf/bitbake.conf`` file somewhere in
the user-specified ``BBPATH``. That configuration file generally has
include directives to pull in any other metadata such as files specific
to the architecture, the machine, the local environment, and so forth.
Only variable definitions and include directives are allowed in BitBake
``.conf`` files. Some variables directly influence BitBake's behavior.
These variables might have been set from the environment depending on
the environment variables previously mentioned or set in the
configuration files. The "`Variables
Glossary <#ref-bb-variables-glos>`__" chapter presents a full list of
variables.
After parsing configuration files, BitBake uses its rudimentary
inheritance mechanism, which is through class files, to inherit some
standard classes. BitBake parses a class when the inherit directive
responsible for getting that class is encountered.
The ``base.bbclass`` file is always included. Other classes that are
specified in the configuration using the
```INHERIT`` <#var-bb-INHERIT>`__ variable are also included. BitBake
searches for class files in a ``classes`` subdirectory under the paths
in ``BBPATH`` in the same way as configuration files.
A good way to get an idea of the configuration files and the class files
used in your execution environment is to run the following BitBake
command: $ bitbake -e > mybb.log Examining the top of the ``mybb.log``
shows you the many configuration files and class files used in your
execution environment.
.. note::
You need to be aware of how BitBake parses curly braces. If a recipe
uses a closing curly brace within the function and the character has
no leading spaces, BitBake produces a parsing error. If you use a
pair of curly braces in a shell function, the closing curly brace
must not be located at the start of the line without leading spaces.
Here is an example that causes BitBake to produce a parsing error:
fakeroot create_shar() { cat << "EOF" >
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh usage() { echo "test" ######
The following "}" at the start of the line causes a parsing error
###### } EOF } Writing the recipe this way avoids the error: fakeroot
create_shar() { cat << "EOF" >
${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh usage() { echo "test"
######The following "}" with a leading space at the start of the line
avoids the error ###### } EOF }
Locating and Parsing Recipes
============================
During the configuration phase, BitBake will have set
```BBFILES`` <#var-bb-BBFILES>`__. BitBake now uses it to construct a
list of recipes to parse, along with any append files (``.bbappend``) to
apply. ``BBFILES`` is a space-separated list of available files and
supports wildcards. An example would be: BBFILES =
"/path/to/bbfiles/*.bb /path/to/appends/*.bbappend" BitBake parses each
recipe and append file located with ``BBFILES`` and stores the values of
various variables into the datastore.
.. note::
Append files are applied in the order they are encountered in
BBFILES
.
For each file, a fresh copy of the base configuration is made, then the
recipe is parsed line by line. Any inherit statements cause BitBake to
find and then parse class files (``.bbclass``) using
```BBPATH`` <#var-bb-BBPATH>`__ as the search path. Finally, BitBake
parses in order any append files found in ``BBFILES``.
One common convention is to use the recipe filename to define pieces of
metadata. For example, in ``bitbake.conf`` the recipe name and version
are used to set the variables ```PN`` <#var-bb-PN>`__ and
```PV`` <#var-bb-PV>`__: PN =
"${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or
'defaultpkgname'}" PV =
"${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or
'1.0'}" In this example, a recipe called "something_1.2.3.bb" would set
``PN`` to "something" and ``PV`` to "1.2.3".
By the time parsing is complete for a recipe, BitBake has a list of
tasks that the recipe defines and a set of data consisting of keys and
values as well as dependency information about the tasks.
BitBake does not need all of this information. It only needs a small
subset of the information to make decisions about the recipe.
Consequently, BitBake caches the values in which it is interested and
does not store the rest of the information. Experience has shown it is
faster to re-parse the metadata than to try and write it out to the disk
and then reload it.
Where possible, subsequent BitBake commands reuse this cache of recipe
information. The validity of this cache is determined by first computing
a checksum of the base configuration data (see
```BB_HASHCONFIG_WHITELIST`` <#var-bb-BB_HASHCONFIG_WHITELIST>`__) and
then checking if the checksum matches. If that checksum matches what is
in the cache and the recipe and class files have not changed, BitBake is
able to use the cache. BitBake then reloads the cached information about
the recipe instead of reparsing it from scratch.
Recipe file collections exist to allow the user to have multiple
repositories of ``.bb`` 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. Here is an example: BBFILES = "/stuff/openembedded/*/*.bb
/stuff/openembedded.modified/*/*.bb" BBFILE_COLLECTIONS = "upstream
local" BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
BBFILE_PRIORITY_upstream = "5" BBFILE_PRIORITY_local = "10"
.. note::
The layers mechanism is now the preferred method of collecting code.
While the collections code remains, its main use is to set layer
priorities and to deal with overlap (conflicts) between layers.
.. _bb-bitbake-providers:
Providers
=========
Assuming BitBake has been instructed to execute a target and that all
the recipe files have been parsed, BitBake starts to figure out how to
build the target. BitBake looks through the ``PROVIDES`` list for each
of the recipes. A ``PROVIDES`` list is the list of names by which the
recipe can be known. Each recipe's ``PROVIDES`` list is created
implicitly through the recipe's ```PN`` <#var-bb-PN>`__ variable and
explicitly through the recipe's ```PROVIDES`` <#var-bb-PROVIDES>`__
variable, which is optional.
When a recipe uses ``PROVIDES``, that recipe's functionality can be
found under an alternative name or names other than the implicit ``PN``
name. As an example, suppose a recipe named ``keyboard_1.0.bb``
contained the following: PROVIDES += "fullkeyboard" The ``PROVIDES``
list for this recipe becomes "keyboard", which is implicit, and
"fullkeyboard", which is explicit. Consequently, the functionality found
in ``keyboard_1.0.bb`` can be found under two different names.
.. _bb-bitbake-preferences:
Preferences
===========
The ``PROVIDES`` list is only part of the solution for figuring out a
target's recipes. Because targets might have multiple providers, BitBake
needs to prioritize providers by determining provider preferences.
A common example in which a target has multiple providers is
"virtual/kernel", which is on the ``PROVIDES`` list for each kernel
recipe. Each machine often selects the best kernel provider by using a
line similar to the following in the machine configuration file:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" The default
```PREFERRED_PROVIDER`` <#var-bb-PREFERRED_PROVIDER>`__ is the provider
with the same name as the target. BitBake iterates through each target
it needs to build and resolves them and their dependencies using this
process.
Understanding how providers are chosen is made complicated by the fact
that multiple versions might exist for a given provider. BitBake
defaults to the highest version of a provider. Version comparisons are
made using the same method as Debian. You can use the
```PREFERRED_VERSION`` <#var-bb-PREFERRED_VERSION>`__ variable to
specify a particular version. You can influence the order by using the
```DEFAULT_PREFERENCE`` <#var-bb-DEFAULT_PREFERENCE>`__ variable.
By default, files have a preference of "0". Setting
``DEFAULT_PREFERENCE`` to "-1" makes the recipe unlikely to be used
unless it is explicitly referenced. Setting ``DEFAULT_PREFERENCE`` to
"1" makes it likely the recipe is used. ``PREFERRED_VERSION`` overrides
any ``DEFAULT_PREFERENCE`` setting. ``DEFAULT_PREFERENCE`` is often used
to mark newer and more experimental recipe versions until they have
undergone sufficient testing to be considered stable.
When there are multiple “versions” of a given recipe, BitBake defaults
to selecting the most recent version, unless otherwise specified. If the
recipe in question has a
```DEFAULT_PREFERENCE`` <#var-bb-DEFAULT_PREFERENCE>`__ 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 recipe files
to specify their preference for the default selected version.
Additionally, the user can specify their preferred version.
If the first recipe is named ``a_1.1.bb``, then the
```PN`` <#var-bb-PN>`__ variable will be set to “a”, and the
```PV`` <#var-bb-PV>`__ variable will be set to 1.1.
Thus, if a recipe named ``a_1.2.bb`` exists, BitBake will choose 1.2 by
default. However, if you define the following variable in a ``.conf``
file that BitBake parses, you can change that preference:
PREFERRED_VERSION_a = "1.1"
.. note::
It is common for a recipe to provide two versions -- a stable,
numbered (and preferred) version, and a version that is automatically
checked out from a source code repository that is considered more
"bleeding edge" but can be selected only explicitly.
For example, in the OpenEmbedded codebase, there is a standard,
versioned recipe file for BusyBox, ``busybox_1.22.1.bb``, but there
is also a Git-based version, ``busybox_git.bb``, which explicitly
contains the line DEFAULT_PREFERENCE = "-1" to ensure that the
numbered, stable version is always preferred unless the developer
selects otherwise.
.. _bb-bitbake-dependencies:
Dependencies
============
Each target BitBake builds consists of multiple tasks such as ``fetch``,
``unpack``, ``patch``, ``configure``, and ``compile``. For best
performance on multi-core systems, BitBake considers each task as an
independent entity with its own set of dependencies.
Dependencies are defined through several variables. You can find
information about variables BitBake uses in the `Variables
Glossary <#ref-bb-variables-glos>`__ near the end of this manual. At a
basic level, it is sufficient to know that BitBake uses the
```DEPENDS`` <#var-bb-DEPENDS>`__ and
```RDEPENDS`` <#var-bb-RDEPENDS>`__ variables when calculating
dependencies.
For more information on how BitBake handles dependencies, see the
"`Dependencies <#dependencies>`__" section.
.. _ref-bitbake-tasklist:
The Task List
=============
Based on the generated list of providers and the dependency information,
BitBake can now calculate exactly what tasks it needs to run and in what
order it needs to run them. The "`Executing Tasks <#executing-tasks>`__"
section has more information on how BitBake chooses which task to
execute next.
The build now starts with BitBake forking off threads up to the limit
set in the ```BB_NUMBER_THREADS`` <#var-bb-BB_NUMBER_THREADS>`__
variable. BitBake continues to fork threads as long as there are tasks
ready to run, those tasks have all their dependencies met, and the
thread threshold has not been exceeded.
It is worth noting that you can greatly speed up the build time by
properly setting the ``BB_NUMBER_THREADS`` variable.
As each task completes, a timestamp is written to the directory
specified by the ```STAMP`` <#var-bb-STAMP>`__ variable. On subsequent
runs, BitBake looks in the build directory within ``tmp/stamps`` and
does not rerun tasks that are already completed unless a timestamp is
found to be invalid. Currently, invalid timestamps are only considered
on a per recipe file basis. So, for example, if the configure stamp has
a timestamp greater than the compile timestamp for a given target, then
the compile task would rerun. Running the compile task again, however,
has no effect on other providers that depend on that target.
The exact format of the stamps is partly configurable. In modern
versions of BitBake, a hash is appended to the stamp so that if the
configuration changes, the stamp becomes invalid and the task is
automatically rerun. This hash, or signature used, is governed by the
signature policy that is configured (see the "`Checksums
(Signatures) <#checksums>`__" section for information). It is also
possible to append extra metadata to the stamp using the
``[stamp-extra-info]`` task flag. For example, OpenEmbedded uses this
flag to make some tasks machine-specific.
.. note::
Some tasks are marked as "nostamp" tasks. No timestamp file is
created when these tasks are run. Consequently, "nostamp" tasks are
always rerun.
For more information on tasks, see the "`Tasks <#tasks>`__" section.
Executing Tasks
===============
Tasks can be either a shell task or a Python task. For shell tasks,
BitBake writes a shell script to
``${``\ ```T`` <#var-bb-T>`__\ ``}/run.do_taskname.pid`` and then
executes the script. The generated shell script contains all the
exported variables, and the shell functions with all variables expanded.
Output from the shell script goes to the file
``${T}/log.do_taskname.pid``. Looking at the expanded shell functions in
the run file and the output in the log files is a useful debugging
technique.
For Python tasks, BitBake executes the task internally and logs
information to the controlling terminal. Future versions of BitBake will
write the functions to files similar to the way shell tasks are handled.
Logging will be handled in a way similar to shell tasks as well.
The order in which BitBake runs the tasks is controlled by its task
scheduler. It is possible to configure the scheduler and define custom
implementations for specific use cases. For more information, see these
variables that control the behavior:
- ```BB_SCHEDULER`` <#var-bb-BB_SCHEDULER>`__
- ```BB_SCHEDULERS`` <#var-bb-BB_SCHEDULERS>`__
It is possible to have functions run before and after a task's main
function. This is done using the ``[prefuncs]`` and ``[postfuncs]``
flags of the task that lists the functions to run.
.. _checksums:
Checksums (Signatures)
======================
A checksum is a unique signature of a task's inputs. The signature of a
task can be used to determine if a task needs to be run. Because it is a
change in a task's inputs that triggers running the task, BitBake needs
to detect all the inputs to a given task. For shell tasks, this turns
out to be fairly easy because BitBake generates a "run" shell script for
each task and it is possible to create a checksum that gives you a good
idea of when the task's data changes.
To complicate the problem, some things should not be included in the
checksum. First, there is the actual specific build path of a given task
- the working directory. It does not matter if the working directory
changes because it should not affect the output for target packages. The
simplistic approach for excluding the working directory is to set it to
some fixed value and create the checksum for the "run" script. BitBake
goes one step better and uses the
```BB_HASHBASE_WHITELIST`` <#var-bb-BB_HASHBASE_WHITELIST>`__ variable
to define a list of variables that should never be included when
generating the signatures.
Another problem results from the "run" scripts containing functions that
might or might not get called. The incremental build solution contains
code that figures out dependencies between shell functions. This code is
used to prune the "run" scripts down to the minimum set, thereby
alleviating this problem and making the "run" scripts much more readable
as a bonus.
So far we have solutions for shell scripts. What about Python tasks? The
same approach applies even though these tasks are more difficult. The
process needs to figure out what variables a Python function accesses
and what functions it calls. Again, the incremental build solution
contains code that first figures out the variable and function
dependencies, and then creates a checksum for the data used as the input
to the task.
Like the working directory case, situations exist where dependencies
should be ignored. For these cases, you can instruct the build process
to ignore a dependency by using a line like the following:
PACKAGE_ARCHS[vardepsexclude] = "MACHINE" This example ensures that the
``PACKAGE_ARCHS`` variable does not depend on the value of ``MACHINE``,
even if it does reference it.
Equally, there are cases where we need to add dependencies BitBake is
not able to find. You can accomplish this by using a line like the
following: PACKAGE_ARCHS[vardeps] = "MACHINE" This example explicitly
adds the ``MACHINE`` variable as a dependency for ``PACKAGE_ARCHS``.
Consider a case with in-line Python, for example, where BitBake is not
able to figure out dependencies. When running in debug mode (i.e. using
``-DDD``), BitBake produces output when it discovers something for which
it cannot figure out dependencies.
Thus far, this section has limited discussion to the direct inputs into
a task. Information based on direct inputs is referred to as the
"basehash" in the code. However, there is still the question of a task's
indirect inputs - the things that were already built and present in the
build directory. The checksum (or signature) for a particular task needs
to add the hashes of all the tasks on which the particular task depends.
Choosing which dependencies to add is a policy decision. However, the
effect is to generate a master checksum that combines the basehash and
the hashes of the task's dependencies.
At the code level, there are a variety of ways both the basehash and the
dependent task hashes can be influenced. Within the BitBake
configuration file, we can give BitBake some extra information to help
it construct the basehash. The following statement effectively results
in a list of global variable dependency excludes - variables never
included in any checksum. This example uses variables from OpenEmbedded
to help illustrate the concept: BB_HASHBASE_WHITELIST ?= "TMPDIR FILE
PATH PWD BB_TASKHASH BBPATH DL_DIR \\ SSTATE_DIR THISDIR FILESEXTRAPATHS
FILE_DIRNAME HOME LOGNAME SHELL \\ USER FILESPATH STAGING_DIR_HOST
STAGING_DIR_TARGET COREBASE PRSERV_HOST \\ PRSERV_DUMPDIR
PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ CCACHE_DIR
EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" The
previous example excludes the work directory, which is part of
``TMPDIR``.
The rules for deciding which hashes of dependent tasks to include
through dependency chains are more complex and are generally
accomplished with a Python function. The code in
``meta/lib/oe/sstatesig.py`` shows two examples of this and also
illustrates how you can insert your own policy into the system if so
desired. This file defines the two basic signature generators
OpenEmbedded-Core uses: "OEBasic" and "OEBasicHash". By default, there
is a dummy "noop" signature handler enabled in BitBake. This means that
behavior is unchanged from previous versions. ``OE-Core`` uses the
"OEBasicHash" signature handler by default through this setting in the
``bitbake.conf`` file: BB_SIGNATURE_HANDLER ?= "OEBasicHash" The
"OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same as the "OEBasic"
version but adds the task hash to the stamp files. This results in any
metadata change that changes the task hash, automatically causing the
task to be run again. This removes the need to bump
```PR`` <#var-bb-PR>`__ values, and changes to metadata automatically
ripple across the build.
It is also worth noting that the end result of these signature
generators is to make some dependency and hash information available to
the build. This information includes:
- ``BB_BASEHASH_task-``\ taskname: The base hashes for each task in the
recipe.
- ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
dependent task.
- ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for
each task.
- ``BB_TASKHASH``: The hash of the currently running task.
It is worth noting that BitBake's "-S" option lets you debug BitBake's
processing of signatures. The options passed to -S allow different
debugging modes to be used, either using BitBake's own debug functions
or possibly those defined in the metadata/signature handler itself. The
simplest parameter to pass is "none", which causes a set of signature
information to be written out into ``STAMPS_DIR`` corresponding to the
targets specified. The other currently available parameter is
"printdiff", which causes BitBake to try to establish the closest
signature match it can (e.g. in the sstate cache) and then run
``bitbake-diffsigs`` over the matches to determine the stamps and delta
where these two stamp trees diverge.
.. note::
It is likely that future versions of BitBake will provide other
signature handlers triggered through additional "-S" parameters.
You can find more information on checksum metadata in the "`Task
Checksums and Setscene <#task-checksums-and-setscene>`__" section.
Setscene
========
The setscene process enables BitBake to handle "pre-built" artifacts.
The ability to handle and reuse these artifacts allows BitBake the
luxury of not having to build something from scratch every time.
Instead, BitBake can use, when possible, existing build artifacts.
BitBake needs to have reliable data indicating whether or not an
artifact is compatible. Signatures, described in the previous section,
provide an ideal way of representing whether an artifact is compatible.
If a signature is the same, an object can be reused.
If an object can be reused, the problem then becomes how to replace a
given task or set of tasks with the pre-built artifact. BitBake solves
the problem with the "setscene" process.
When BitBake is asked to build a given target, before building anything,
it first asks whether cached information is available for any of the
targets it's building, or any of the intermediate targets. If cached
information is available, BitBake uses this information instead of
running the main tasks.
BitBake first calls the function defined by the
```BB_HASHCHECK_FUNCTION`` <#var-bb-BB_HASHCHECK_FUNCTION>`__ variable
with a list of tasks and corresponding hashes it wants to build. This
function is designed to be fast and returns a list of the tasks for
which it believes in can obtain artifacts.
Next, for each of the tasks that were returned as possibilities, BitBake
executes a setscene version of the task that the possible artifact
covers. Setscene versions of a task have the string "_setscene" appended
to the task name. So, for example, the task with the name ``xxx`` has a
setscene task named ``xxx_setscene``. The setscene version of the task
executes and provides the necessary artifacts returning either success
or failure.
As previously mentioned, an artifact can cover more than one task. For
example, it is pointless to obtain a compiler if you already have the
compiled binary. To handle this, BitBake calls the
```BB_SETSCENE_DEPVALID`` <#var-bb-BB_SETSCENE_DEPVALID>`__ function for
each successful setscene task to know whether or not it needs to obtain
the dependencies of that task.
Finally, after all the setscene tasks have executed, BitBake calls the
function listed in
```BB_SETSCENE_VERIFY_FUNCTION2`` <#var-bb-BB_SETSCENE_VERIFY_FUNCTION2>`__
with the list of tasks BitBake thinks has been "covered". The metadata
can then ensure that this list is correct and can inform BitBake that it
wants specific tasks to be run regardless of the setscene result.
You can find more information on setscene metadata in the "`Task
Checksums and Setscene <#task-checksums-and-setscene>`__" section.
Logging
=======
In addition to the standard command line option to control how verbose
builds are when execute, bitbake also supports user defined
configuration of the `Python
logging <https://docs.python.org/3/library/logging.html>`__ facilities
through the ```BB_LOGCONFIG`` <#var-bb-BB_LOGCONFIG>`__ variable. This
variable defines a json or yaml `logging
configuration <https://docs.python.org/3/library/logging.config.html>`__
that will be intelligently merged into the default configuration. The
logging configuration is merged using the following rules:
- The user defined configuration will completely replace the default
configuration if top level key ``bitbake_merge`` is set to the value
``False``. In this case, all other rules are ignored.
- The user configuration must have a top level ``version`` which must
match the value of the default configuration.
- Any keys defined in the ``handlers``, ``formatters``, or ``filters``,
will be merged into the same section in the default configuration,
with the user specified keys taking replacing a default one if there
is a conflict. In practice, this means that if both the default
configuration and user configuration specify a handler named
``myhandler``, the user defined one will replace the default. To
prevent the user from inadvertently replacing a default handler,
formatter, or filter, all of the default ones are named with a prefix
of "``BitBake.``"
- If a logger is defined by the user with the key ``bitbake_merge`` set
to ``False``, that logger will be completely replaced by user
configuration. In this case, no other rules will apply to that
logger.
- All user defined ``filter`` and ``handlers`` properties for a given
logger will be merged with corresponding properties from the default
logger. For example, if the user configuration adds a filter called
``myFilter`` to the ``BitBake.SigGen``, and the default configuration
adds a filter called ``BitBake.defaultFilter``, both filters will be
applied to the logger
As an example, consider the following user logging configuration file
which logs all Hash Equivalence related messages of VERBOSE or higher to
a file called ``hashequiv.log`` { "version": 1, "handlers": {
"autobuilderlog": { "class": "logging.FileHandler", "formatter":
"logfileFormatter", "level": "DEBUG", "filename": "hashequiv.log",
"mode": "w" } }, "formatters": { "logfileFormatter": { "format":
"%(name)s: %(levelname)s: %(message)s" } }, "loggers": {
"BitBake.SigGen.HashEquiv": { "level": "VERBOSE", "handlers":
["autobuilderlog"] }, "BitBake.RunQueue.HashEquiv": { "level":
"VERBOSE", "handlers": ["autobuilderlog"] } } }
bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
+629
View File
@@ -0,0 +1,629 @@
=====================
File Download Support
=====================
BitBake's fetch module is a standalone piece of library code that deals
with the intricacies of downloading source code and files from remote
systems. Fetching source code is one of the cornerstones of building
software. As such, this module forms an important part of BitBake.
The current fetch module is called "fetch2" and refers to the fact that
it is the second major version of the API. The original version is
obsolete and has been removed from the codebase. Thus, in all cases,
"fetch" refers to "fetch2" in this manual.
The Download (Fetch)
====================
BitBake takes several steps when fetching source code or files. The
fetcher codebase deals with two distinct processes in order: obtaining
the files from somewhere (cached or otherwise) and then unpacking those
files into a specific location and perhaps in a specific way. Getting
and unpacking the files is often optionally followed by patching.
Patching, however, is not covered by this module.
The code to execute the first part of this process, a fetch, looks
something like the following: src_uri = (d.getVar('SRC_URI') or
"").split() fetcher = bb.fetch2.Fetch(src_uri, d) fetcher.download()
This code sets up an instance of the fetch class. The instance uses a
space-separated list of URLs from the ```SRC_URI`` <#var-bb-SRC_URI>`__
variable and then calls the ``download`` method to download the files.
The instantiation of the fetch class is usually followed by: rootdir =
l.getVar('WORKDIR') fetcher.unpack(rootdir) This code unpacks the
downloaded files to the specified by ``WORKDIR``.
.. note::
For convenience, the naming in these examples matches the variables
used by OpenEmbedded. If you want to see the above code in action,
examine the OpenEmbedded class file
base.bbclass
.
The ``SRC_URI`` and ``WORKDIR`` variables are not hardcoded into the
fetcher, since those fetcher methods can be (and are) called with
different variable names. In OpenEmbedded for example, the shared state
(sstate) code uses the fetch module to fetch the sstate files.
When the ``download()`` method is called, BitBake tries to resolve the
URLs by looking for source files in a specific search order:
- *Pre-mirror Sites:* BitBake first uses pre-mirrors to try and find
source files. These locations are defined using the
```PREMIRRORS`` <#var-bb-PREMIRRORS>`__ variable.
- *Source URI:* If pre-mirrors fail, BitBake uses the original URL (e.g
from ``SRC_URI``).
- *Mirror Sites:* If fetch failures occur, BitBake next uses mirror
locations as defined by the ```MIRRORS`` <#var-bb-MIRRORS>`__
variable.
For each URL passed to the fetcher, the fetcher calls the submodule that
handles that particular URL type. This behavior can be the source of
some confusion when you are providing URLs for the ``SRC_URI`` variable.
Consider the following two URLs:
http://git.yoctoproject.org/git/poky;protocol=git
git://git.yoctoproject.org/git/poky;protocol=http In the former case,
the URL is passed to the ``wget`` fetcher, which does not understand
"git". Therefore, the latter case is the correct form since the Git
fetcher does know how to use HTTP as a transport.
Here are some examples that show commonly used mirror definitions:
PREMIRRORS ?= "\\ bzr://.*/.\* http://somemirror.org/sources/ \\n \\
cvs://.*/.\* http://somemirror.org/sources/ \\n \\ git://.*/.\*
http://somemirror.org/sources/ \\n \\ hg://.*/.\*
http://somemirror.org/sources/ \\n \\ osc://.*/.\*
http://somemirror.org/sources/ \\n \\ p4://.*/.\*
http://somemirror.org/sources/ \\n \\ svn://.*/.\*
http://somemirror.org/sources/ \\n" MIRRORS =+ "\\ ftp://.*/.\*
http://somemirror.org/sources/ \\n \\ http://.*/.\*
http://somemirror.org/sources/ \\n \\ https://.*/.\*
http://somemirror.org/sources/ \\n" It is useful to note that BitBake
supports cross-URLs. It is possible to mirror a Git repository on an
HTTP server as a tarball. This is what the ``git://`` mapping in the
previous example does.
Since network accesses are slow, BitBake maintains a cache of files
downloaded from the network. Any source files that are not local (i.e.
downloaded from the Internet) are placed into the download directory,
which is specified by the ```DL_DIR`` <#var-bb-DL_DIR>`__ variable.
File integrity is of key importance for reproducing builds. For
non-local archive downloads, the fetcher code can verify SHA-256 and MD5
checksums to ensure the archives have been downloaded correctly. You can
specify these checksums by using the ``SRC_URI`` variable with the
appropriate varflags as follows: SRC_URI[md5sum] = "value"
SRC_URI[sha256sum] = "value" You can also specify the checksums as
parameters on the ``SRC_URI`` as shown below: SRC_URI =
"http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
If multiple URIs exist, you can specify the checksums either directly as
in the previous example, or you can name the URLs. The following syntax
shows how you name the URIs: SRC_URI =
"http://example.com/foobar.tar.bz2;name=foo" SRC_URI[foo.md5sum] =
4a8e0f237e961fd7785d19d07fdb994d After a file has been downloaded and
has had its checksum checked, a ".done" stamp is placed in ``DL_DIR``.
BitBake uses this stamp during subsequent builds to avoid downloading or
comparing a checksum for the file again.
.. note::
It is assumed that local storage is safe from data corruption. If
this were not the case, there would be bigger issues to worry about.
If ```BB_STRICT_CHECKSUM`` <#var-bb-BB_STRICT_CHECKSUM>`__ is set, any
download without a checksum triggers an error message. The
```BB_NO_NETWORK`` <#var-bb-BB_NO_NETWORK>`__ variable can be used to
make any attempted network access a fatal error, which is useful for
checking that mirrors are complete as well as other things.
.. _bb-the-unpack:
The Unpack
==========
The unpack process usually immediately follows the download. For all
URLs except Git URLs, BitBake uses the common ``unpack`` method.
A number of parameters exist that you can specify within the URL to
govern the behavior of the unpack stage:
- *unpack:* Controls whether the URL components are unpacked. If set to
"1", which is the default, the components are unpacked. If set to
"0", the unpack stage leaves the file alone. This parameter is useful
when you want an archive to be copied in and not be unpacked.
- *dos:* Applies to ``.zip`` and ``.jar`` files and specifies whether
to use DOS line ending conversion on text files.
- *basepath:* Instructs the unpack stage to strip the specified
directories from the source path when unpacking.
- *subdir:* Unpacks the specific URL to the specified subdirectory
within the root directory.
The unpack call automatically decompresses and extracts files with ".Z",
".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm". ".srpm", ".deb" and
".bz2" extensions as well as various combinations of tarball extensions.
As mentioned, the Git fetcher has its own unpack method that is
optimized to work with Git trees. Basically, this method works by
cloning the tree into the final directory. The process is completed
using references so that there is only one central copy of the Git
metadata needed.
.. _bb-fetchers:
Fetchers
========
As mentioned earlier, the URL prefix determines which fetcher submodule
BitBake uses. Each submodule can support different URL parameters, which
are described in the following sections.
.. _local-file-fetcher:
Local file fetcher (``file://``)
--------------------------------
This submodule handles URLs that begin with ``file://``. The filename
you specify within the URL can be either an absolute or relative path to
a file. If the filename is relative, the contents of the
```FILESPATH`` <#var-bb-FILESPATH>`__ variable is used in the same way
``PATH`` is used to find executables. If the file cannot be found, it is
assumed that it is available in ```DL_DIR`` <#var-bb-DL_DIR>`__ by the
time the ``download()`` method is called.
If you specify a directory, the entire directory is unpacked.
Here are a couple of example URLs, the first relative and the second
absolute: SRC_URI = "file://relativefile.patch" SRC_URI =
"file:///Users/ich/very_important_software"
.. _http-ftp-fetcher:
HTTP/FTP wget fetcher (``http://``, ``ftp://``, ``https://``)
-------------------------------------------------------------
This fetcher obtains files from web and FTP servers. Internally, the
fetcher uses the wget utility.
The executable and parameters used are specified by the
``FETCHCMD_wget`` variable, which defaults to sensible values. The
fetcher supports a parameter "downloadfilename" that allows the name of
the downloaded file to be specified. Specifying the name of the
downloaded file is useful for avoiding collisions in
```DL_DIR`` <#var-bb-DL_DIR>`__ when dealing with multiple files that
have the same name.
Some example URLs are as follows: SRC_URI =
"http://oe.handhelds.org/not_there.aac" SRC_URI =
"ftp://oe.handhelds.org/not_there_as_well.aac" SRC_URI =
"ftp://you@oe.handhelds.org/home/you/secret.plan"
.. note::
Because URL parameters are delimited by semi-colons, this can
introduce ambiguity when parsing URLs that also contain semi-colons,
for example:
::
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
Such URLs should should be modified by replacing semi-colons with '&'
characters:
::
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"
In most cases this should work. Treating semi-colons and '&' in
queries identically is recommended by the World Wide Web Consortium
(W3C). Note that due to the nature of the URL, you may have to
specify the name of the downloaded file as well:
::
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2"
.. _cvs-fetcher:
CVS fetcher (``(cvs://``)
-------------------------
This submodule handles checking out files from the CVS version control
system. You can configure it using a number of different variables:
- *``FETCHCMD_cvs``:* The name of the executable to use when running
the ``cvs`` command. This name is usually "cvs".
- *``SRCDATE``:* The date to use when fetching the CVS source code. A
special value of "now" causes the checkout to be updated on every
build.
- ```CVSDIR`` <#var-bb-CVSDIR>`__\ *:* Specifies where a temporary
checkout is saved. The location is often ``DL_DIR/cvs``.
- *``CVS_PROXY_HOST``:* The name to use as a "proxy=" parameter to the
``cvs`` command.
- *``CVS_PROXY_PORT``:* The port number to use as a "proxyport="
parameter to the ``cvs`` command.
As well as the standard username and password URL syntax, you can also
configure the fetcher with various URL parameters:
The supported parameters are as follows:
- *"method":* The protocol over which to communicate with the CVS
server. By default, this protocol is "pserver". If "method" is set to
"ext", BitBake examines the "rsh" parameter and sets ``CVS_RSH``. You
can use "dir" for local directories.
- *"module":* Specifies the module to check out. You must supply this
parameter.
- *"tag":* Describes which CVS TAG should be used for the checkout. By
default, the TAG is empty.
- *"date":* Specifies a date. If no "date" is specified, the
```SRCDATE`` <#var-bb-SRCDATE>`__ of the configuration is used to
checkout a specific date. The special value of "now" causes the
checkout to be updated on every build.
- *"localdir":* Used to rename the module. Effectively, you are
renaming the output directory to which the module is unpacked. You
are forcing the module into a special directory relative to
```CVSDIR`` <#var-bb-CVSDIR>`__.
- *"rsh"* Used in conjunction with the "method" parameter.
- *"scmdata":* Causes the CVS metadata to be maintained in the tarball
the fetcher creates when set to "keep". The tarball is expanded into
the work directory. By default, the CVS metadata is removed.
- *"fullpath":* Controls whether the resulting checkout is at the
module level, which is the default, or is at deeper paths.
- *"norecurse":* Causes the fetcher to only checkout the specified
directory with no recurse into any subdirectories.
- *"port":* The port to which the CVS server connects.
Some example URLs are as follows: SRC_URI =
"cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" SRC_URI =
"cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
.. _svn-fetcher:
Subversion (SVN) Fetcher (``svn://``)
-------------------------------------
This fetcher submodule fetches code from the Subversion source control
system. The executable used is specified by ``FETCHCMD_svn``, which
defaults to "svn". The fetcher's temporary working directory is set by
```SVNDIR`` <#var-bb-SVNDIR>`__, which is usually ``DL_DIR/svn``.
The supported parameters are as follows:
- *"module":* The name of the svn module to checkout. You must provide
this parameter. You can think of this parameter as the top-level
directory of the repository data you want.
- *"path_spec":* A specific directory in which to checkout the
specified svn module.
- *"protocol":* The protocol to use, which defaults to "svn". If
"protocol" is set to "svn+ssh", the "ssh" parameter is also used.
- *"rev":* The revision of the source code to checkout.
- *"scmdata":* Causes the “.svn” directories to be available during
compile-time when set to "keep". By default, these directories are
removed.
- *"ssh":* An optional parameter used when "protocol" is set to
"svn+ssh". You can use this parameter to specify the ssh program used
by svn.
- *"transportuser":* When required, sets the username for the
transport. By default, this parameter is empty. The transport
username is different than the username used in the main URL, which
is passed to the subversion command.
Following are three examples using svn: SRC_URI =
"svn://myrepos/proj1;module=vip;protocol=http;rev=667" SRC_URI =
"svn://myrepos/proj1;module=opie;protocol=svn+ssh" SRC_URI =
"svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
.. _git-fetcher:
Git Fetcher (``git://``)
------------------------
This fetcher submodule fetches code from the Git source control system.
The fetcher works by creating a bare clone of the remote into
```GITDIR`` <#var-bb-GITDIR>`__, which is usually ``DL_DIR/git2``. This
bare clone is then cloned into the work directory during the unpack
stage when a specific tree is checked out. This is done using alternates
and by reference to minimize the amount of duplicate data on the disk
and make the unpack process fast. The executable used can be set with
``FETCHCMD_git``.
This fetcher supports the following parameters:
- *"protocol":* The protocol used to fetch the files. The default is
"git" when a hostname is set. If a hostname is not set, the Git
protocol is "file". You can also use "http", "https", "ssh" and
"rsync".
- *"nocheckout":* Tells the fetcher to not checkout source code when
unpacking when set to "1". Set this option for the URL where there is
a custom routine to checkout code. The default is "0".
- *"rebaseable":* Indicates that the upstream Git repository can be
rebased. You should set this parameter to "1" if revisions can become
detached from branches. In this case, the source mirror tarball is
done per revision, which has a loss of efficiency. Rebasing the
upstream Git repository could cause the current revision to disappear
from the upstream repository. This option reminds the fetcher to
preserve the local cache carefully for future use. The default value
for this parameter is "0".
- *"nobranch":* Tells the fetcher to not check the SHA validation for
the branch when set to "1". The default is "0". Set this option for
the recipe that refers to the commit that is valid for a tag instead
of the branch.
- *"bareclone":* Tells the fetcher to clone a bare clone into the
destination directory without checking out a working tree. Only the
raw Git metadata is provided. This parameter implies the "nocheckout"
parameter as well.
- *"branch":* The branch(es) of the Git tree to clone. If unset, this
is assumed to be "master". The number of branch parameters much match
the number of name parameters.
- *"rev":* The revision to use for the checkout. The default is
"master".
- *"tag":* Specifies a tag to use for the checkout. To correctly
resolve tags, BitBake must access the network. For that reason, tags
are often not used. As far as Git is concerned, the "tag" parameter
behaves effectively the same as the "rev" parameter.
- *"subpath":* Limits the checkout to a specific subpath of the tree.
By default, the whole tree is checked out.
- *"destsuffix":* The name of the path in which to place the checkout.
By default, the path is ``git/``.
- *"usehead":* Enables local ``git://`` URLs to use the current branch
HEAD as the revision for use with ``AUTOREV``. The "usehead"
parameter implies no branch and only works when the transfer protocol
is ``file://``.
Here are some example URLs: SRC_URI =
"git://git.oe.handhelds.org/git/vip.git;tag=version-1" SRC_URI =
"git://git.oe.handhelds.org/git/vip.git;protocol=http"
.. _gitsm-fetcher:
Git Submodule Fetcher (``gitsm://``)
------------------------------------
This fetcher submodule inherits from the `Git fetcher <#git-fetcher>`__
and extends that fetcher's behavior by fetching a repository's
submodules. ```SRC_URI`` <#var-bb-SRC_URI>`__ is passed to the Git
fetcher as described in the "`Git Fetcher
(``git://``) <#git-fetcher>`__" section.
.. note::
You must clean a recipe when switching between '``git://``' and
'``gitsm://``' URLs.
The Git Submodules fetcher is not a complete fetcher implementation.
The fetcher has known issues where it does not use the normal source
mirroring infrastructure properly. Further, the submodule sources it
fetches are not visible to the licensing and source archiving
infrastructures.
.. _clearcase-fetcher:
ClearCase Fetcher (``ccrc://``)
-------------------------------
This fetcher submodule fetches code from a
`ClearCase <http://en.wikipedia.org/wiki/Rational_ClearCase>`__
repository.
To use this fetcher, make sure your recipe has proper
```SRC_URI`` <#var-bb-SRC_URI>`__, ```SRCREV`` <#var-bb-SRCREV>`__, and
```PV`` <#var-bb-PV>`__ settings. Here is an example: SRC_URI =
"ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
SRCREV = "EXAMPLE_CLEARCASE_TAG" PV = "${@d.getVar("SRCREV",
False).replace("/", "+")}" The fetcher uses the ``rcleartool`` or
``cleartool`` remote client, depending on which one is available.
Following are options for the ``SRC_URI`` statement:
- *``vob``*: The name, which must include the prepending "/" character,
of the ClearCase VOB. This option is required.
- *``module``*: The module, which must include the prepending "/"
character, in the selected VOB.
.. note::
The
module
and
vob
options are combined to create the
load
rule in the view config spec. As an example, consider the
vob
and
module
values from the
SRC_URI
statement at the start of this section. Combining those values
results in the following:
::
load /example_vob/example_module
- *``proto``*: The protocol, which can be either ``http`` or ``https``.
By default, the fetcher creates a configuration specification. If you
want this specification written to an area other than the default, use
the ``CCASE_CUSTOM_CONFIG_SPEC`` variable in your recipe to define where
the specification is written.
.. note::
the
SRCREV
loses its functionality if you specify this variable. However,
SRCREV
is still used to label the archive after a fetch even though it does
not define what is fetched.
Here are a couple of other behaviors worth mentioning:
- When using ``cleartool``, the login of ``cleartool`` is handled by
the system. The login require no special steps.
- In order to use ``rcleartool`` with authenticated users, an
"rcleartool login" is necessary before using the fetcher.
.. _perforce-fetcher:
Perforce Fetcher (``p4://``)
----------------------------
This fetcher submodule fetches code from the
`Perforce <https://www.perforce.com/>`__ source control system. The
executable used is specified by ``FETCHCMD_p4``, which defaults to "p4".
The fetcher's temporary working directory is set by
```P4DIR`` <#var-bb-P4DIR>`__, which defaults to "DL_DIR/p4".
The fetcher does not make use of a perforce client, instead it
relies on ``p4 files`` to retrieve a list of
files and ``p4 print`` to transfer the content
of those files locally.
To use this fetcher, make sure your recipe has proper
```SRC_URI`` <#var-bb-SRC_URI>`__, ```SRCREV`` <#var-bb-SRCREV>`__, and
```PV`` <#var-bb-PV>`__ values. The p4 executable is able to use the
config file defined by your system's ``P4CONFIG`` environment variable
in order to define the Perforce server URL and port, username, and
password if you do not wish to keep those values in a recipe itself. If
you choose not to use ``P4CONFIG``, or to explicitly set variables that
``P4CONFIG`` can contain, you can specify the ``P4PORT`` value, which is
the server's URL and port number, and you can specify a username and
password directly in your recipe within ``SRC_URI``.
Here is an example that relies on ``P4CONFIG`` to specify the server URL
and port, username, and password, and fetches the Head Revision: SRC_URI
= "p4://example-depot/main/source/..." SRCREV = "${AUTOREV}" PV =
"p4-${SRCPV}" S = "${WORKDIR}/p4"
Here is an example that specifies the server URL and port, username, and
password, and fetches a Revision based on a Label: P4PORT =
"tcp:p4server.example.net:1666" SRC_URI =
"p4://user:passwd@example-depot/main/source/..." SRCREV = "release-1.0"
PV = "p4-${SRCPV}" S = "${WORKDIR}/p4"
.. note::
You should always set
S
to
"${WORKDIR}/p4"
in your recipe.
By default, the fetcher strips the depot location from the local file paths. In
the above example, the content of ``example-depot/main/source/`` will be placed
in ``${WORKDIR}/p4``. For situations where preserving parts of the remote depot
paths locally is desirable, the fetcher supports two parameters:
- **"module":**
The top-level depot location or directory to fetch. The value of this
parameter can also point to a single file within the depot, in which case
the local file path will include the module path.
- **"remotepath":**
When used with the value "``keep``", the fetcher will mirror the full depot
paths locally for the specified location, even in combination with the
``module`` parameter.
Here is an example use of the the ``module`` parameter: ::
SRC_URI = "p4://user:passwd@example-depot/main;module=source/..."
In this case, the content of the top-level directory ``source/`` will be fetched
to ``${P4DIR}``, including the directory itself. The top-level directory will
be accesible at ``${P4DIR}/source/``.
Here is an example use of the the ``remotepath`` parameter: ::
SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep"
In this case, the content of the top-level directory ``source/`` will be fetched
to ``${P4DIR}``, but the complete depot paths will be mirrored locally. The
top-level directory will be accessible at
``${P4DIR}/example-depot/main/source/``.
.. _repo-fetcher:
Repo Fetcher (``repo://``)
--------------------------
This fetcher submodule fetches code from ``google-repo`` source control
system. The fetcher works by initiating and syncing sources of the
repository into ```REPODIR`` <#var-bb-REPODIR>`__, which is usually
```DL_DIR`` <#var-bb-DL_DIR>`__\ ``/repo``.
This fetcher supports the following parameters:
- *"protocol":* Protocol to fetch the repository manifest (default:
git).
- *"branch":* Branch or tag of repository to get (default: master).
- *"manifest":* Name of the manifest file (default: ``default.xml``).
Here are some example URLs: SRC_URI =
"repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
SRC_URI =
"repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
Other Fetchers
--------------
Fetch submodules also exist for the following:
- Bazaar (``bzr://``)
- Mercurial (``hg://``)
- npm (``npm://``)
- OSC (``osc://``)
- Secure FTP (``sftp://``)
- Secure Shell (``ssh://``)
- Trees using Git Annex (``gitannex://``)
No documentation currently exists for these lesser used fetcher
submodules. However, you might find the code helpful and readable.
Auto Revisions
==============
We need to document ``AUTOREV`` and ``SRCREV_FORMAT`` here.
bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst
+361
View File
@@ -0,0 +1,361 @@
===================
Hello World Example
===================
BitBake Hello World
===================
The simplest example commonly used to demonstrate any new programming
language or tool is the "`Hello
World <http://en.wikipedia.org/wiki/Hello_world_program>`__" example.
This appendix demonstrates, in tutorial form, Hello World within the
context of BitBake. The tutorial describes how to create a new project
and the applicable metadata files necessary to allow BitBake to build
it.
Obtaining BitBake
=================
See the "`Obtaining BitBake <#obtaining-bitbake>`__" section for
information on how to obtain BitBake. Once you have the source code on
your machine, the BitBake directory appears as follows: $ ls -al total
100 drwxrwxr-x. 9 wmat wmat 4096 Jan 31 13:44 . drwxrwxr-x. 3 wmat wmat
4096 Feb 4 10:45 .. -rw-rw-r--. 1 wmat wmat 365 Nov 26 04:55 AUTHORS
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 bin drwxrwxr-x. 4 wmat wmat
4096 Jan 31 13:44 build -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55
ChangeLog drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 classes drwxrwxr-x.
2 wmat wmat 4096 Nov 26 04:55 conf drwxrwxr-x. 3 wmat wmat 4096 Nov 26
04:55 contrib -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 doc -rw-rw-r--. 1 wmat wmat 69
Nov 26 04:55 .gitignore -rw-rw-r--. 1 wmat wmat 849 Nov 26 04:55 HEADER
drwxrwxr-x. 5 wmat wmat 4096 Jan 31 13:44 lib -rw-rw-r--. 1 wmat wmat
195 Nov 26 04:55 MANIFEST.in -rw-rw-r--. 1 wmat wmat 2887 Nov 26 04:55
TODO
At this point, you should have BitBake cloned to a directory that
matches the previous listing except for dates and user names.
Setting Up the BitBake Environment
==================================
First, you need to be sure that you can run BitBake. Set your working
directory to where your local BitBake files are and run the following
command: $ ./bin/bitbake --version BitBake Build Tool Core version
1.23.0, bitbake version 1.23.0 The console output tells you what version
you are running.
The recommended method to run BitBake is from a directory of your
choice. To be able to run BitBake from any directory, you need to add
the executable binary to your binary to your shell's environment
``PATH`` variable. First, look at your current ``PATH`` variable by
entering the following: $ echo $PATH Next, add the directory location
for the BitBake binary to the ``PATH``. Here is an example that adds the
``/home/scott-lenovo/bitbake/bin`` directory to the front of the
``PATH`` variable: $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
You should now be able to enter the ``bitbake`` command from the command
line while working from any directory.
The Hello World Example
=======================
The overall goal of this exercise is to build a complete "Hello World"
example utilizing task and layer concepts. Because this is how modern
projects such as OpenEmbedded and the Yocto Project utilize BitBake, the
example provides an excellent starting point for understanding BitBake.
To help you understand how to use BitBake to build targets, the example
starts with nothing but the ``bitbake`` command, which causes BitBake to
fail and report problems. The example progresses by adding pieces to the
build to eventually conclude with a working, minimal "Hello World"
example.
While every attempt is made to explain what is happening during the
example, the descriptions cannot cover everything. You can find further
information throughout this manual. Also, you can actively participate
in the
` <http://lists.openembedded.org/mailman/listinfo/bitbake-devel>`__
discussion mailing list about the BitBake build tool.
.. note::
This example was inspired by and drew heavily from
Mailing List post - The BitBake equivalent of "Hello, World!"
.
As stated earlier, the goal of this example is to eventually compile
"Hello World". However, it is unknown what BitBake needs and what you
have to provide in order to achieve that goal. Recall that BitBake
utilizes three types of metadata files: `Configuration
Files <#configuration-files>`__, `Classes <#classes>`__, and
`Recipes <#recipes>`__. But where do they go? How does BitBake find
them? BitBake's error messaging helps you answer these types of
questions and helps you better understand exactly what is going on.
Following is the complete "Hello World" example.
1. *Create a Project Directory:* First, set up a directory for the
"Hello World" project. Here is how you can do so in your home
directory: $ mkdir ~/hello $ cd ~/hello This is the directory that
BitBake will use to do all of its work. You can use this directory
to keep all the metafiles needed by BitBake. Having a project
directory is a good way to isolate your project.
2. *Run BitBake:* At this point, you have nothing but a project
directory. Run the ``bitbake`` command and see what it does: $
bitbake The BBPATH variable is not set and bitbake did not find a
conf/bblayers.conf file in the expected location. Maybe you
accidentally invoked bitbake from the wrong directory? DEBUG:
Removed the following variables from the environment:
GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
\_, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS The
majority of this output is specific to environment variables that
are not directly relevant to BitBake. However, the very first
message regarding the ``BBPATH`` variable and the
``conf/bblayers.conf`` file is relevant.
When you run BitBake, it begins looking for metadata files. The
```BBPATH`` <#var-bb-BBPATH>`__ variable is what tells BitBake where
to look for those files. ``BBPATH`` is not set and you need to set
it. Without ``BBPATH``, BitBake cannot find any configuration files
(``.conf``) or recipe files (``.bb``) at all. BitBake also cannot
find the ``bitbake.conf`` file.
3. *Setting ``BBPATH``:* For this example, you can set ``BBPATH`` in
the same manner that you set ``PATH`` earlier in the appendix. You
should realize, though, that it is much more flexible to set the
``BBPATH`` variable up in a configuration file for each project.
From your shell, enter the following commands to set and export the
``BBPATH`` variable: $ BBPATH="projectdirectory" $ export BBPATH Use
your actual project directory in the command. BitBake uses that
directory to find the metadata it needs for your project.
.. note::
When specifying your project directory, do not use the tilde
("~") character as BitBake does not expand that character as the
shell would.
4. *Run BitBake:* Now that you have ``BBPATH`` defined, run the
``bitbake`` command again: $ bitbake ERROR: Traceback (most recent
call last): File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py",
line 163, in wrapped return func(fn, \*args) File
"/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in
parse_config_file return bb.parse.handle(fn, data, include) File
"/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in
handle return h['handle'](fn, data, include) File
"/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py",
line 120, in handle abs_fn = resolve_file(fn, data) File
"/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in
resolve_file raise IOError("file %s not found in %s" % (fn, bbpath))
IOError: file conf/bitbake.conf not found in
/home/scott-lenovo/hello ERROR: Unable to parse conf/bitbake.conf:
file conf/bitbake.conf not found in /home/scott-lenovo/hello This
sample output shows that BitBake could not find the
``conf/bitbake.conf`` file in the project directory. This file is
the first thing BitBake must find in order to build a target. And,
since the project directory for this example is empty, you need to
provide a ``conf/bitbake.conf`` file.
5. *Creating ``conf/bitbake.conf``:* The ``conf/bitbake.conf`` includes
a number of configuration variables BitBake uses for metadata and
recipe files. For this example, you need to create the file in your
project directory and define some key BitBake variables. For more
information on the ``bitbake.conf`` file, see
` <http://git.openembedded.org/bitbake/tree/conf/bitbake.conf>`__.
Use the following commands to create the ``conf`` directory in the
project directory: $ mkdir conf From within the ``conf`` directory,
use some editor to create the ``bitbake.conf`` so that it contains
the following: `PN <#var-bb-PN>`__ =
"${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0]
or 'defaultpkgname'}" TMPDIR = "${`TOPDIR <#var-bb-TOPDIR>`__}/tmp"
`CACHE <#var-bb-CACHE>`__ = "${TMPDIR}/cache"
`STAMP <#var-bb-STAMP>`__ = "${TMPDIR}/${PN}/stamps"
`T <#var-bb-T>`__ = "${TMPDIR}/${PN}/work" `B <#var-bb-B>`__ =
"${TMPDIR}/${PN}"
.. note::
Without a value for
PN
, the variables
STAMP
,
T
, and
B
, prevent more than one recipe from working. You can fix this by
either setting
PN
to have a value similar to what OpenEmbedded and BitBake use in
the default
bitbake.conf
file (see previous example). Or, by manually updating each recipe
to set
PN
. You will also need to include
PN
as part of the
STAMP
,
T
, and
B
variable definitions in the
local.conf
file.
The ``TMPDIR`` variable establishes a directory that BitBake uses
for build output and intermediate files other than the cached
information used by the `Setscene <#setscene>`__ process. Here, the
``TMPDIR`` directory is set to ``hello/tmp``.
.. note::
You can always safely delete the
tmp
directory in order to rebuild a BitBake target. The build process
creates the directory for you when you run BitBake.
For information about each of the other variables defined in this
example, click on the links to take you to the definitions in the
glossary.
6. *Run BitBake:* After making sure that the ``conf/bitbake.conf`` file
exists, you can run the ``bitbake`` command again: $ bitbake ERROR:
Traceback (most recent call last): File
"/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in
wrapped return func(fn, \*args) File
"/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in
\_inherit bb.parse.BBHandler.inherit(bbclass, "configuration
INHERITs", 0, data) File
"/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py",
line 92, in inherit include(fn, file, lineno, d, "inherit") File
"/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py",
line 100, in include raise ParseError("Could not %(error_out)s file
%(fn)s" % vars(), oldfn, lineno) ParseError: ParseError in
configuration INHERITs: Could not inherit file classes/base.bbclass
ERROR: Unable to parse base: ParseError in configuration INHERITs:
Could not inherit file classes/base.bbclass In the sample output,
BitBake could not find the ``classes/base.bbclass`` file. You need
to create that file next.
7. *Creating ``classes/base.bbclass``:* BitBake uses class files to
provide common code and functionality. The minimally required class
for BitBake is the ``classes/base.bbclass`` file. The ``base`` class
is implicitly inherited by every recipe. BitBake looks for the class
in the ``classes`` directory of the project (i.e ``hello/classes``
in this example).
Create the ``classes`` directory as follows: $ cd $HOME/hello $
mkdir classes Move to the ``classes`` directory and then create the
``base.bbclass`` file by inserting this single line: addtask build
The minimal task that BitBake runs is the ``do_build`` task. This is
all the example needs in order to build the project. Of course, the
``base.bbclass`` can have much more depending on which build
environments BitBake is supporting.
8. *Run BitBake:* After making sure that the ``classes/base.bbclass``
file exists, you can run the ``bitbake`` command again: $ bitbake
Nothing to do. Use 'bitbake world' to build everything, or run
'bitbake --help' for usage information. BitBake is finally reporting
no errors. However, you can see that it really does not have
anything to do. You need to create a recipe that gives BitBake
something to do.
9. *Creating a Layer:* While it is not really necessary for such a
small example, it is good practice to create a layer in which to
keep your code separate from the general metadata used by BitBake.
Thus, this example creates and uses a layer called "mylayer".
.. note::
You can find additional information on layers in the "
Layers
" section.
Minimally, you need a recipe file and a layer configuration file in
your layer. The configuration file needs to be in the ``conf``
directory inside the layer. Use these commands to set up the layer
and the ``conf`` directory: $ cd $HOME $ mkdir mylayer $ cd mylayer
$ mkdir conf Move to the ``conf`` directory and create a
``layer.conf`` file that has the following: BBPATH .=
":${`LAYERDIR <#var-bb-LAYERDIR>`__}" `BBFILES <#var-bb-BBFILES>`__
+= "${LAYERDIR}/*.bb"
`BBFILE_COLLECTIONS <#var-bb-BBFILE_COLLECTIONS>`__ += "mylayer"
`BBFILE_PATTERN_mylayer <#var-bb-BBFILE_PATTERN>`__ :=
"^${LAYERDIR_RE}/" For information on these variables, click the
links to go to the definitions in the glossary.
You need to create the recipe file next. Inside your layer at the
top-level, use an editor and create a recipe file named
``printhello.bb`` that has the following:
`DESCRIPTION <#var-bb-DESCRIPTION>`__ = "Prints Hello World"
`PN <#var-bb-PN>`__ = 'printhello' `PV <#var-bb-PV>`__ = '1' python
do_build() { bb.plain("********************"); bb.plain("\* \*");
bb.plain("\* Hello, World! \*"); bb.plain("\* \*");
bb.plain("********************"); } The recipe file simply provides
a description of the recipe, the name, version, and the ``do_build``
task, which prints out "Hello World" to the console. For more
information on these variables, follow the links to the glossary.
10. *Run BitBake With a Target:* Now that a BitBake target exists, run
the command and provide that target: $ cd $HOME/hello $ bitbake
printhello ERROR: no recipe files to build, check your BBPATH and
BBFILES? Summary: There was 1 ERROR message shown, returning a
non-zero exit code. We have created the layer with the recipe and
the layer configuration file but it still seems that BitBake cannot
find the recipe. BitBake needs a ``conf/bblayers.conf`` that lists
the layers for the project. Without this file, BitBake cannot find
the recipe.
11. *Creating ``conf/bblayers.conf``:* BitBake uses the
``conf/bblayers.conf`` file to locate layers needed for the project.
This file must reside in the ``conf`` directory of the project (i.e.
``hello/conf`` for this example).
Set your working directory to the ``hello/conf`` directory and then
create the ``bblayers.conf`` file so that it contains the following:
BBLAYERS ?= " \\ /home/<you>/mylayer \\ " You need to provide your
own information for ``you`` in the file.
12. *Run BitBake With a Target:* Now that you have supplied the
``bblayers.conf`` file, run the ``bitbake`` command and provide the
target: $ bitbake printhello Parsing recipes: 100%
\|##################################################################################\|
Time: 00:00:00 Parsing of 1 .bb files complete (0 cached, 1 parsed).
1 targets, 0 skipped, 0 masked, 0 errors. NOTE: Resolving any
missing task queue dependencies NOTE: Preparing RunQueue NOTE:
Executing RunQueue Tasks \*******************\* \* \* \* Hello,
World! \* \* \* \*******************\* NOTE: Tasks Summary:
Attempted 1 tasks of which 0 didn't need to be rerun and all
succeeded. BitBake finds the ``printhello`` recipe and successfully
runs the task.
.. note::
After the first execution, re-running
bitbake printhello
again will not result in a BitBake run that prints the same
console output. The reason for this is that the first time the
printhello.bb
recipe's
do_build
task executes successfully, BitBake writes a stamp file for the
task. Thus, the next time you attempt to run the task using that
same
bitbake
command, BitBake notices the stamp and therefore determines that
the task does not need to be re-run. If you delete the
tmp
directory or run
bitbake -c clean printhello
and then re-run the build, the "Hello, World!" message will be
printed again.
bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst
+571
View File
@@ -0,0 +1,571 @@
========
Overview
========
Welcome to the BitBake User Manual. This manual provides information on
the BitBake tool. The information attempts to be as independent as
possible regarding systems that use BitBake, such as OpenEmbedded and
the Yocto Project. In some cases, scenarios or examples within the
context of a build system are used in the manual to help with
understanding. For these cases, the manual clearly states the context.
.. _intro:
Introduction
============
Fundamentally, BitBake is a generic task execution engine that allows
shell and Python tasks to be run efficiently and in parallel while
working within complex inter-task dependency constraints. One of
BitBake's main users, OpenEmbedded, takes this core and builds embedded
Linux software stacks using a task-oriented approach.
Conceptually, BitBake is similar to GNU Make in some regards but has
significant differences:
- BitBake executes tasks according to provided metadata that builds up
the tasks. Metadata is stored in recipe (``.bb``) and related recipe
"append" (``.bbappend``) files, configuration (``.conf``) and
underlying include (``.inc``) files, and in class (``.bbclass``)
files. The metadata provides BitBake with instructions on what tasks
to run and the dependencies between those tasks.
- BitBake includes a fetcher library for obtaining source code from
various places such as local files, source control systems, or
websites.
- The instructions for each unit to be built (e.g. a piece of software)
are known as "recipe" files and contain all the information about the
unit (dependencies, source file locations, checksums, description and
so on).
- BitBake includes a client/server abstraction and can be used from a
command line or used as a service over XML-RPC and has several
different user interfaces.
History and Goals
=================
BitBake was originally a part of the OpenEmbedded project. It was
inspired by the Portage package management system used by the Gentoo
Linux distribution. On December 7, 2004, OpenEmbedded project team
member Chris Larson split the project into two distinct pieces:
- BitBake, a generic task executor
- OpenEmbedded, a metadata set utilized by BitBake
Today, BitBake is the primary basis of the
`OpenEmbedded <http://www.openembedded.org/>`__ project, which is being
used to build and maintain Linux distributions such as the `Angstrom
Distribution <http://www.angstrom-distribution.org/>`__, and which is
also being used as the build tool for Linux projects such as the `Yocto
Project <http://www.yoctoproject.org>`__.
Prior to BitBake, no other build tool adequately met the needs of an
aspiring embedded Linux distribution. All of the build systems used by
traditional desktop Linux distributions lacked important functionality,
and none of the ad hoc Buildroot-based systems, prevalent in the
embedded space, were scalable or maintainable.
Some important original goals for BitBake were:
- Handle cross-compilation.
- Handle inter-package dependencies (build time on target architecture,
build time on native architecture, and runtime).
- Support running any number of tasks within a given package,
including, but not limited to, fetching upstream sources, unpacking
them, patching them, configuring them, and so forth.
- Be Linux distribution agnostic for both build and target systems.
- Be architecture agnostic.
- Support multiple build and target operating systems (e.g. Cygwin, the
BSDs, and so forth).
- Be self-contained, rather than tightly integrated into the build
machine's root filesystem.
- Handle conditional metadata on the target architecture, operating
system, distribution, and machine.
- Be easy to use the tools to supply local metadata and packages
against which to operate.
- Be easy to use BitBake to collaborate between multiple projects for
their builds.
- Provide an inheritance mechanism to share common metadata between
many packages.
Over time it became apparent that some further requirements were
necessary:
- Handle variants of a base recipe (e.g. native, sdk, and multilib).
- Split metadata into layers and allow layers to enhance or override
other layers.
- Allow representation of a given set of input variables to a task as a
checksum. Based on that checksum, allow acceleration of builds with
prebuilt components.
BitBake satisfies all the original requirements and many more with
extensions being made to the basic functionality to reflect the
additional requirements. Flexibility and power have always been the
priorities. BitBake is highly extensible and supports embedded Python
code and execution of any arbitrary tasks.
.. _Concepts:
Concepts
========
BitBake is a program written in the Python language. At the highest
level, BitBake interprets metadata, decides what tasks are required to
run, and executes those tasks. Similar to GNU Make, BitBake controls how
software is built. GNU Make achieves its control through "makefiles",
while BitBake uses "recipes".
BitBake extends the capabilities of a simple tool like GNU Make by
allowing for the definition of much more complex tasks, such as
assembling entire embedded Linux distributions.
The remainder of this section introduces several concepts that should be
understood in order to better leverage the power of BitBake.
Recipes
-------
BitBake Recipes, which are denoted by the file extension ``.bb``, are
the most basic metadata files. These recipe files provide BitBake with
the following:
- Descriptive information about the package (author, homepage, license,
and so on)
- The version of the recipe
- Existing dependencies (both build and runtime dependencies)
- Where the source code resides and how to fetch it
- Whether the source code requires any patches, where to find them, and
how to apply them
- How to configure and compile the source code
- How to assemble the generated artifacts into one or more installable
packages
- Where on the target machine to install the package or packages
created
Within the context of BitBake, or any project utilizing BitBake as its
build system, files with the ``.bb`` extension are referred to as
recipes.
.. note::
The term "package" is also commonly used to describe recipes.
However, since the same word is used to describe packaged output from
a project, it is best to maintain a single descriptive term -
"recipes". Put another way, a single "recipe" file is quite capable
of generating a number of related but separately installable
"packages". In fact, that ability is fairly common.
Configuration Files
-------------------
Configuration files, which are denoted by the ``.conf`` extension,
define various configuration variables that govern the project's build
process. These files fall into several areas that define machine
configuration, distribution configuration, possible compiler tuning,
general common configuration, and user configuration. The main
configuration file is the sample ``bitbake.conf`` file, which is located
within the BitBake source tree ``conf`` directory.
Classes
-------
Class files, which are denoted by the ``.bbclass`` extension, contain
information that is useful to share between metadata files. The BitBake
source tree currently comes with one class metadata file called
``base.bbclass``. You can find this file in the ``classes`` directory.
The ``base.bbclass`` class files is special since it is always included
automatically for all recipes and classes. This class contains
definitions for standard basic tasks such as fetching, unpacking,
configuring (empty by default), compiling (runs any Makefile present),
installing (empty by default) and packaging (empty by default). These
tasks are often overridden or extended by other classes added during the
project development process.
Layers
------
Layers allow you to isolate different types of customizations from each
other. While you might find it tempting to keep everything in one layer
when working on a single project, the more modular your metadata, the
easier it is to cope with future changes.
To illustrate how you can use layers to keep things modular, consider
customizations you might make to support a specific target machine.
These types of customizations typically reside in a special layer,
rather than a general layer, called a Board Support Package (BSP) layer.
Furthermore, the machine customizations should be isolated from recipes
and metadata that support a new GUI environment, for example. This
situation gives you a couple of layers: one for the machine
configurations and one for the GUI environment. It is important to
understand, however, that the BSP layer can still make machine-specific
additions to recipes within the GUI environment layer without polluting
the GUI layer itself with those machine-specific changes. You can
accomplish this through a recipe that is a BitBake append
(``.bbappend``) file.
.. _append-bbappend-files:
Append Files
------------
Append files, which are files that have the ``.bbappend`` file
extension, extend or override information in an existing recipe file.
BitBake expects every append file to have a corresponding recipe file.
Furthermore, the append file and corresponding recipe file must use the
same root filename. The filenames can differ only in the file type
suffix used (e.g. ``formfactor_0.0.bb`` and
``formfactor_0.0.bbappend``).
Information in append files extends or overrides the information in the
underlying, similarly-named recipe files.
When you name an append file, you can use the "``%``" wildcard character
to allow for matching recipe names. For example, suppose you have an
append file named as follows: busybox_1.21.%.bbappend That append file
would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
the append file would match the following recipe names:
busybox_1.21.1.bb busybox_1.21.2.bb busybox_1.21.3.bb
.. note::
The use of the "
%
" character is limited in that it only works directly in front of the
.bbappend
portion of the append file's name. You cannot use the wildcard
character in any other location of the name.
If the ``busybox`` recipe was updated to ``busybox_1.3.0.bb``, the
append name would not match. However, if you named the append file
``busybox_1.%.bbappend``, then you would have a match.
In the most general case, you could name the append file something as
simple as ``busybox_%.bbappend`` to be entirely version independent.
Obtaining BitBake
=================
You can obtain BitBake several different ways:
- *Cloning BitBake:* Using Git to clone the BitBake source code
repository is the recommended method for obtaining BitBake. Cloning
the repository makes it easy to get bug fixes and have access to
stable branches and the master branch. Once you have cloned BitBake,
you should use the latest stable branch for development since the
master branch is for BitBake development and might contain less
stable changes.
You usually need a version of BitBake that matches the metadata you
are using. The metadata is generally backwards compatible but not
forward compatible.
Here is an example that clones the BitBake repository: $ git clone
git://git.openembedded.org/bitbake This command clones the BitBake
Git repository into a directory called ``bitbake``. Alternatively,
you can designate a directory after the ``git clone`` command if you
want to call the new directory something other than ``bitbake``. Here
is an example that names the directory ``bbdev``: $ git clone
git://git.openembedded.org/bitbake bbdev
- *Installation using your Distribution Package Management System:*
This method is not recommended because the BitBake version that is
provided by your distribution, in most cases, is several releases
behind a snapshot of the BitBake repository.
- *Taking a snapshot of BitBake:* Downloading a snapshot of BitBake
from the source code repository gives you access to a known branch or
release of BitBake.
.. note::
Cloning the Git repository, as described earlier, is the preferred
method for getting BitBake. Cloning the repository makes it easier
to update as patches are added to the stable branches.
The following example downloads a snapshot of BitBake version 1.17.0:
$ wget
http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz $
tar zxpvf bitbake-1.17.0.tar.gz After extraction of the tarball using
the tar utility, you have a directory entitled ``bitbake-1.17.0``.
- *Using the BitBake that Comes With Your Build Checkout:* A final
possibility for getting a copy of BitBake is that it already comes
with your checkout of a larger BitBake-based build system, such as
Poky. Rather than manually checking out individual layers and gluing
them together yourself, you can check out an entire build system. The
checkout will already include a version of BitBake that has been
thoroughly tested for compatibility with the other components. For
information on how to check out a particular BitBake-based build
system, consult that build system's supporting documentation.
.. _bitbake-user-manual-command:
The BitBake Command
===================
The ``bitbake`` command is the primary interface to the BitBake tool.
This section presents the BitBake command syntax and provides several
execution examples.
Usage and syntax
----------------
Following is the usage and syntax for BitBake: $ bitbake -h Usage:
bitbake [options] [recipename/target recipe:do_task ...] Executes the
specified task (default is 'build') for a given set of target recipes
(.bb files). It is assumed there is a conf/bblayers.conf available in
cwd or in BBPATH which will provide the layer, BBFILES and other
configuration information. Options: --version show program's version
number and exit -h, --help show this help message and exit -b BUILDFILE,
--buildfile=BUILDFILE Execute tasks from a specific .bb recipe directly.
WARNING: Does not handle any dependencies from other recipes. -k,
--continue Continue as much as possible after an error. While the target
that failed and anything depending on it cannot be built, as much as
possible will be built before stopping. -f, --force Force the specified
targets/task to run (invalidating any existing stamp file). -c CMD,
--cmd=CMD Specify the task to execute. The exact options available
depend on the metadata. Some examples might be 'compile' or
'populate_sysroot' or 'listtasks' may give a list of the tasks
available. -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
Invalidate the stamp for the specified task such as 'compile' and then
run the default task for the specified target(s). -r PREFILE,
--read=PREFILE Read the specified file before bitbake.conf. -R POSTFILE,
--postread=POSTFILE Read the specified file after bitbake.conf. -v,
--verbose Enable tracing of shell tasks (with 'set -x'). Also print
bb.note(...) messages to stdout (in addition to writing them to
${T}/log.do_<task>). -D, --debug Increase the debug level. You can
specify this more than once. -D sets the debug level to 1, where only
bb.debug(1, ...) messages are printed to stdout; -DD sets the debug
level to 2, where both bb.debug(1, ...) and bb.debug(2, ...) messages
are printed; etc. Without -D, no debug messages are printed. Note that
-D only affects output to stdout. All debug messages are written to
${T}/log.do_taskname, regardless of the debug level. -q, --quiet Output
less log message data to the terminal. You can specify this more than
once. -n, --dry-run Don't execute, just go through the motions. -S
SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER Dump out the
signature construction information, with no task execution. The
SIGNATURE_HANDLER parameter is passed to the handler. Two common values
are none and printdiff but the handler may define more/less. none means
only dump the signature, printdiff means compare the dumped signature
with the cached one. -p, --parse-only Quit after parsing the BB recipes.
-s, --show-versions Show current and preferred versions of all recipes.
-e, --environment Show the global or per-recipe environment complete
with information about where variables were set/changed. -g, --graphviz
Save dependency tree information for the specified targets in the dot
syntax. -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 save reports. -u UI, --ui=UI The user interface to use
(knotty, ncurses or taskexp - default knotty). --token=XMLRPCTOKEN
Specify the connection token to be used when connecting to a remote
server. --revisions-changed Set the exit code depending on whether
upstream floating revisions have changed or not. --server-only Run
bitbake without a UI, only starting a server (cooker) process. -B BIND,
--bind=BIND The name/address for the bitbake xmlrpc server to bind to.
-T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT Set timeout to unload
bitbake server due to inactivity, set to -1 means no unload, default:
Environment variable BB_SERVER_TIMEOUT. --no-setscene Do not run any
setscene tasks. sstate will be ignored and everything needed, built.
--setscene-only Only run setscene tasks, don't run any real tasks.
--remote-server=REMOTE_SERVER Connect to the specified server. -m,
--kill-server Terminate any running bitbake server. --observe-only
Connect to a server as an observing-only client. --status-only Check the
status of the remote bitbake server. -w WRITEEVENTLOG,
--write-log=WRITEEVENTLOG Writes the event log of the build to a bitbake
event json file. Use '' (empty string) to assign the name automatically.
--runall=RUNALL Run the specified task for any recipe in the taskgraph
of the specified target (even if it wouldn't otherwise have run).
--runonly=RUNONLY Run only the specified task within the taskgraph of
the specified targets (and any task dependencies those tasks may have).
.. _bitbake-examples:
Examples
--------
This section presents some examples showing how to use BitBake.
.. _example-executing-a-task-against-a-single-recipe:
Executing a Task Against a Single Recipe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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. If you do not specify a task, BitBake executes the
default task, which is "build”. BitBake obeys inter-task dependencies
when doing so.
The following command runs the build task, which is the default task, on
the ``foo_1.0.bb`` recipe file: $ bitbake -b foo_1.0.bb The following
command runs the clean task on the ``foo.bb`` recipe file: $ bitbake -b
foo.bb -c clean
.. note::
The "-b" option explicitly does not handle recipe dependencies. Other
than for debugging purposes, it is instead recommended that you use
the syntax presented in the next section.
Executing Tasks Against a Set of Recipe Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a number of additional complexities introduced when one wants
to manage multiple ``.bb`` files. Clearly there needs to be a way to
tell BitBake what files are available and, of those, which you want to
execute. There also needs to be a way for each recipe to express its
dependencies, both for build-time and runtime. There must be a way for
you to express recipe preferences when multiple recipes provide the same
functionality, or when there are multiple versions of a recipe.
The ``bitbake`` command, when not using "--buildfile" or "-b" only
accepts a "PROVIDES". You cannot provide anything else. By default, a
recipe file generally "PROVIDES" its "packagename" as shown in the
following example: $ bitbake foo This next example "PROVIDES" the
package name and also uses the "-c" option to tell BitBake to just
execute the ``do_clean`` task: $ bitbake -c clean foo
Executing a List of Task and Recipe Combinations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The BitBake command line supports specifying different tasks for
individual targets when you specify multiple targets. For example,
suppose you had two targets (or recipes) ``myfirstrecipe`` and
``mysecondrecipe`` and you needed BitBake to run ``taskA`` for the first
recipe and ``taskB`` for the second recipe: $ bitbake
myfirstrecipe:do_taskA mysecondrecipe:do_taskB
Generating Dependency Graphs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BitBake is able to generate dependency graphs using the ``dot`` syntax.
You can convert these graphs into images using the ``dot`` tool from
`Graphviz <http://www.graphviz.org>`__.
When you generate a dependency graph, BitBake writes two files to the
current working directory:
- *``task-depends.dot``:* Shows dependencies between tasks. These
dependencies match BitBake's internal task execution list.
- *``pn-buildlist``:* Shows a simple list of targets that are to be
built.
To stop depending on common depends, use the "-I" depend option and
BitBake omits them from the graph. Leaving this information out can
produce more readable graphs. This way, you can remove from the graph
``DEPENDS`` from inherited classes such as ``base.bbclass``.
Here are two examples that create dependency graphs. The second example
omits depends common in OpenEmbedded from the graph: $ bitbake -g foo $
bitbake -g -I virtual/kernel -I eglibc foo
Executing a Multiple Configuration Build
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BitBake is able to build multiple images or packages using a single
command where the different targets require different configurations
(multiple configuration builds). Each target, in this scenario, is
referred to as a "multiconfig".
To accomplish a multiple configuration build, you must define each
target's configuration separately using a parallel configuration file in
the build directory. The location for these multiconfig configuration
files is specific. They must reside in the current build directory in a
sub-directory of ``conf`` named ``multiconfig``. Following is an example
for two separate targets:
The reason for this required file hierarchy is because the ``BBPATH``
variable is not constructed until the layers are parsed. Consequently,
using the configuration file as a pre-configuration file is not possible
unless it is located in the current working directory.
Minimally, each configuration file must define the machine and the
temporary directory BitBake uses for the build. Suggested practice
dictates that you do not overlap the temporary directories used during
the builds.
Aside from separate configuration files for each target, you must also
enable BitBake to perform multiple configuration builds. Enabling is
accomplished by setting the
```BBMULTICONFIG`` <#var-bb-BBMULTICONFIG>`__ variable in the
``local.conf`` configuration file. As an example, suppose you had
configuration files for ``target1`` and ``target2`` defined in the build
directory. The following statement in the ``local.conf`` file both
enables BitBake to perform multiple configuration builds and specifies
the two extra multiconfigs: BBMULTICONFIG = "target1 target2"
Once the target configuration files are in place and BitBake has been
enabled to perform multiple configuration builds, use the following
command form to start the builds: $ bitbake [mc:multiconfigname:]target
[[[mc:multiconfigname:]target] ... ] Here is an example for two extra
multiconfigs: ``target1`` and ``target2``: $ bitbake mc::target
mc:target1:target mc:target2:target
.. _bb-enabling-multiple-configuration-build-dependencies:
Enabling Multiple Configuration Build Dependencies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes dependencies can exist between targets (multiconfigs) in a
multiple configuration build. For example, suppose that in order to
build an image for a particular architecture, the root filesystem of
another build for a different architecture needs to exist. In other
words, the image for the first multiconfig depends on the root
filesystem of the second multiconfig. This dependency is essentially
that the task in the recipe that builds one multiconfig is dependent on
the completion of the task in the recipe that builds another
multiconfig.
To enable dependencies in a multiple configuration build, you must
declare the dependencies in the recipe using the following statement
form: task_or_package[mcdepends] =
"mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"
To better show how to use this statement, consider an example with two
multiconfigs: ``target1`` and ``target2``: image_task[mcdepends] =
"mc:target1:target2:image2:rootfs_task" In this example, the
from_multiconfig is "target1" and the to_multiconfig is "target2". The
task on which the image whose recipe contains image_task depends on the
completion of the rootfs_task used to build out image2, which is
associated with the "target2" multiconfig.
Once you set up this dependency, you can build the "target1" multiconfig
using a BitBake command as follows: $ bitbake mc:target1:image1 This
command executes all the tasks needed to create image1 for the "target1"
multiconfig. Because of the dependency, BitBake also executes through
the rootfs_task for the "target2" multiconfig build.
Having a recipe depend on the root filesystem of another build might not
seem that useful. Consider this change to the statement in the image1
recipe: image_task[mcdepends] = "mc:target1:target2:image2:image_task"
In this case, BitBake must create image2 for the "target2" build since
the "target1" build depends on it.
Because "target1" and "target2" are enabled for multiple configuration
builds and have separate configuration files, BitBake places the
artifacts for each build in the respective temporary build directories.
bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
+1728
View File
File diff suppressed because it is too large Load Diff
bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
+1235
View File
File diff suppressed because it is too large Load Diff
bitbake/doc/index.rst
+26 -6
View File
@@ -1,11 +1,31 @@
.. The Yocto Project documentation master file, created by
sphinx-quickstart on Mon Apr 13 09:38:33 2020.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
===================
BitBake User Manual
===================
Welcome to Bitbake documentation!
=================================
.. include:: <xhtml1-lat1.txt>
| BitBake Community
| Copyright |copy| |copyright|
| <bitbake-devel@lists.openembedded.org>
This work is licensed under the Creative Commons Attribution License. To view a
copy of this license, visit http://creativecommons.org/licenses/by/2.5/ or send
a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View,
California 94041, USA.
.. toctree::
:caption: Table of Contents
:numbered:
bitbake-user-manual/bitbake-user-manual-intro
bitbake-user-manual/bitbake-user-manual-execution
bitbake-user-manual/bitbake-user-manual-metadata
bitbake-user-manual/bitbake-user-manual-fetching
bitbake-user-manual/bitbake-user-manual-ref-variables
bitbake-user-manual/bitbake-user-manual-hello
.. toctree::
:maxdepth: 1
:hidden:
genindex