BitBake User Manual
1 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.
1.1 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 the 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.
1.2 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 project, which is being used to build and maintain Linux distributions such as the Poky Reference Distribution, developed under the umbrella of the Yocto Project.
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.
1.3 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.
1.3.1 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.
1.3.2 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.
1.3.3 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.
1.3.4 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.
1.3.5 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.
1.4 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 thegit clone
command if you want to call the new directory something other thanbitbake
. Here is an example that names the directorybbdev
:$ 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 https://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.
1.5 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.
1.5.1 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, taskexp or
teamcity - 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.
--skip-setscene Skip setscene tasks if they would be executed. Tasks
previously restored from sstate will be kept, unlike
--no-setscene
--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).
1.5.2 Examples
This section presents some examples showing how to use BitBake.
1.5.2.1 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.
1.5.2.2 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
1.5.2.3 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
1.5.2.4 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.
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
1.5.2.5 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 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
1.5.2.6 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.
2 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” 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 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.
2.1 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 and 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:
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” 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 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 variable
being set to the directory where the layer was found. The idea is these
files automatically set up 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”
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 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
}
2.2 Locating and Parsing Recipes
During the configuration phase, BitBake will have set
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 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 and
PV:
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
PV = "${@bb.parse.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_IGNORE_VARS) 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.
2.3 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 variable and explicitly through the recipe’s 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.
2.4 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 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 variable to specify a particular version. You can influence the order by using the 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 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 variable will be set to “a”, and the
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.
2.5 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 near the end of this manual. At a basic level, it is sufficient to know that BitBake uses the DEPENDS and RDEPENDS variables when calculating dependencies.
For more information on how BitBake handles dependencies, see the Dependencies section.
2.6 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 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 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 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)
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 section.
2.7 Executing Tasks
Tasks can be either a shell task or a Python task. For shell tasks,
BitBake writes a shell script to
${
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:
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.
2.8 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_BASEHASH_IGNORE_VARS 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_BASEHASH_IGNORE_VARS ?= "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 basic signature generator
OpenEmbedded-Core uses: “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 main feature of the “OEBasicHash” BB_SIGNATURE_HANDLER is that it adds the task hash to the stamp files. Thanks to this, any metadata change will change the task hash, automatically causing the task to be run again. This removes the need to bump PR values, and changes to metadata automatically ripple across the build.
It is also worth noting that the end result of 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.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 most recent
signature match it can (e.g. in the sstate cache) and then run
compare the matched signatures to determine the stamps and delta
where these two stamp trees diverge. This can be used to determine why
tasks need to be re-run in situations where that is not expected.
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 section.
2.9 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 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 function for each successful setscene task to know whether or not it needs to obtain the dependencies of that task.
You can find more information on setscene metadata in the Task Checksums and Setscene section.
2.10 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 facilities through the BB_LOGCONFIG variable. This variable defines a JSON or YAML logging configuration 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 valueFalse
. 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
, orfilters
, 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 namedmyhandler
, 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 toFalse
, that logger will be completely replaced by user configuration. In this case, no other rules will apply to that logger.All user defined
filter
andhandlers
properties for a given logger will be merged with corresponding properties from the default logger. For example, if the user configuration adds a filter calledmyFilter
to theBitBake.SigGen
, and the default configuration adds a filter calledBitBake.defaultFilter
, both filters will be applied to the logger
As a first example, you can create a hashequiv.json
user logging
configuration file to log all Hash Equivalence related messages of VERBOSE
or higher priority 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"]
}
}
}
Then set the BB_LOGCONFIG variable in conf/local.conf
:
BB_LOGCONFIG = "hashequiv.json"
Another example is this warn.json
file to log all WARNING
and
higher priority messages to a warn.log
file:
{
"version": 1,
"formatters": {
"warnlogFormatter": {
"()": "bb.msg.BBLogFormatter",
"format": "%(levelname)s: %(message)s"
}
},
"handlers": {
"warnlog": {
"class": "logging.FileHandler",
"formatter": "warnlogFormatter",
"level": "WARNING",
"filename": "warn.log"
}
},
"loggers": {
"BitBake": {
"handlers": ["warnlog"]
}
},
"@disable_existing_loggers": false
}
Note that BitBake’s helper classes for structured logging are implemented in
lib/bb/msg.py
.
3 Syntax and Operators
BitBake files have their own syntax. The syntax has similarities to several other languages but also has some unique features. This section describes the available syntax and operators as well as provides examples.
3.1 Basic Syntax
This section provides some basic syntax examples.
3.1.1 Basic Variable Setting
The following example sets VARIABLE
to “value”. This assignment
occurs immediately as the statement is parsed. It is a “hard”
assignment.
VARIABLE = "value"
As expected, if you include leading or trailing spaces as part of an assignment, the spaces are retained:
VARIABLE = " value"
VARIABLE = "value "
Setting VARIABLE
to “” sets
it to an empty string, while setting the variable to “ “ sets it to a
blank space (i.e. these are not the same values).
VARIABLE = ""
VARIABLE = " "
You can use single quotes instead of double quotes when setting a variable’s value. Doing so allows you to use values that contain the double quote character:
VARIABLE = 'I have a " in my value'
Note
Unlike in Bourne shells, single quotes work identically to double quotes in all other ways. They do not suppress variable expansions.
3.1.2 Modifying Existing Variables
Sometimes you need to modify existing variables. Following are some cases where you might find you want to modify an existing variable:
Customize a recipe that uses the variable.
Change a variable’s default value used in a
*.bbclass
file.Change the variable in a
*.bbappend
file to override the variable in the original recipe.Change the variable in a configuration file so that the value overrides an existing configuration.
Changing a variable value can sometimes depend on how the value was originally assigned and also on the desired intent of the change. In particular, when you append a value to a variable that has a default value, the resulting value might not be what you expect. In this case, the value you provide might replace the value rather than append to the default value.
If after you have changed a variable’s value and something unexplained occurs, you can use BitBake to check the actual value of the suspect variable. You can make these checks for both configuration and recipe level changes:
For configuration changes, use the following:
$ bitbake -e
This command displays variable values after the configuration files (i.e.
local.conf
,bblayers.conf
,bitbake.conf
and so forth) have been parsed.Note
Variables that are exported to the environment are preceded by the string “export” in the command’s output.
To find changes to a given variable in a specific recipe, use the following:
$ bitbake recipename -e | grep VARIABLENAME=\"
This command checks to see if the variable actually makes it into a specific recipe.
3.1.3 Line Joining
Outside of functions, BitBake joins any line ending in a backslash character (”\”) with the following line before parsing statements. The most common use for the “\” character is to split variable assignments over multiple lines, as in the following example:
FOO = "bar \
baz \
qaz"
Both the “\” character and the newline
character that follow it are removed when joining lines. Thus, no
newline characters end up in the value of FOO
.
Consider this additional example where the two assignments both assign
“barbaz” to FOO
:
FOO = "barbaz"
FOO = "bar\
baz"
Note
BitBake does not interpret escape sequences like “\n” in variable
values. For these to have an effect, the value must be passed to some
utility that interprets escape sequences, such as
printf
or echo -n
.
3.1.4 Variable Expansion
Variables can reference the contents of other variables using a syntax that is similar to variable expansion in Bourne shells. The following assignments result in A containing “aval” and B evaluating to “preavalpost”.
A = "aval"
B = "pre${A}post"
Note
Unlike in Bourne shells, the curly braces are mandatory: Only ${FOO}
and not
$FOO
is recognized as an expansion of FOO
.
The “=” operator does not immediately expand variable references in the right-hand side. Instead, expansion is deferred until the variable assigned to is actually used. The result depends on the current values of the referenced variables. The following example should clarify this behavior:
A = "${B} baz"
B = "${C} bar"
C = "foo"
*At this point, ${A} equals "foo bar baz"*
C = "qux"
*At this point, ${A} equals "qux bar baz"*
B = "norf"
*At this point, ${A} equals "norf baz"*
Contrast this behavior with the Immediate variable expansion (:=) operator.
If the variable expansion syntax is used on a variable that does not
exist, the string is kept as is. For example, given the following
assignment, BAR
expands to the literal string “${FOO}” as long as
FOO
does not exist.
BAR = "${FOO}"
3.1.5 Setting a default value (?=)
You can use the “?=” operator to achieve a “softer” assignment for a variable. This type of assignment allows you to define a variable if it is undefined when the statement is parsed, but to leave the value alone if the variable has a value. Here is an example:
A ?= "aval"
If A
is
set at the time this statement is parsed, the variable retains its
value. However, if A
is not set, the variable is set to “aval”.
Note
This assignment is immediate. Consequently, if multiple “?=” assignments to a single variable exist, the first of those ends up getting used.
3.1.6 Setting a weak default value (??=)
The weak default value of a variable is the value which that variable will expand to if no value has been assigned to it via any of the other assignment operators. The “??=” operator takes effect immediately, replacing any previously defined weak default value. Here is an example:
W ??= "x"
A := "${W}" # Immediate variable expansion
W ??= "y"
B := "${W}" # Immediate variable expansion
W ??= "z"
C = "${W}"
W ?= "i"
After parsing we will have:
A = "x"
B = "y"
C = "i"
W = "i"
Appending and prepending non-override style will not substitute the weak default value, which means that after parsing:
W ??= "x"
W += "y"
we will have:
W = " y"
On the other hand, override-style appends/prepends/removes are applied after any active weak default value has been substituted:
W ??= "x"
W:append = "y"
After parsing we will have:
W = "xy"
3.1.7 Immediate variable expansion (:=)
The “:=” operator results in a variable’s contents being expanded immediately, rather than when the variable is actually used:
T = "123"
A := "test ${T}"
T = "456"
B := "${T} ${C}"
C = "cval"
C := "${C}append"
In this example, A
contains “test 123”, even though the final value
of T is “456”. The variable B will end up containing “456
cvalappend”. This is because references to undefined variables are
preserved as is during (immediate)expansion. This is in contrast to GNU
Make, where undefined variables expand to nothing. The variable C
contains “cvalappend” since ${C}
immediately expands to “cval”.
3.1.8 Appending (+=) and prepending (=+) With Spaces
Appending and prepending values is common and can be accomplished using the “+=” and “=+” operators. These operators insert a space between the current value and prepended or appended value.
These operators take immediate effect during parsing. Here are some examples:
B = "bval"
B += "additionaldata"
C = "cval"
C =+ "test"
The variable B contains “bval additionaldata” and C
contains “test
cval”.
3.1.9 Appending (.=) and Prepending (=.) Without Spaces
If you want to append or prepend values without an inserted space, use the “.=” and “=.” operators.
These operators take immediate effect during parsing. Here are some examples:
B = "bval"
B .= "additionaldata"
C = "cval"
C =. "test"
The variable B contains “bvaladditionaldata” and C
contains
“testcval”.
3.1.10 Appending and Prepending (Override Style Syntax)
You can also append and prepend a variable’s value using an override style syntax. When you use this syntax, no spaces are inserted.
These operators differ from the “:=”, “.=”, “=.”, “+=”, and “=+” operators in that their effects are applied at variable expansion time rather than being immediately applied. Here are some examples:
B = "bval"
B:append = " additional data"
C = "cval"
C:prepend = "additional data "
D = "dval"
D:append = "additional data"
The variable B
becomes “bval additional data” and C
becomes “additional data cval”.
The variable D
becomes “dvaladditional data”.
Note
You must control all spacing when you use the override syntax.
Note
The overrides are applied in this order, “:append”, “:prepend”, “:remove”.
It is also possible to append and prepend to shell functions and BitBake-style Python functions. See the “Shell Functions” and “BitBake-Style Python Functions” sections for examples.
3.1.11 Removal (Override Style Syntax)
You can remove values from lists using the removal override style syntax. Specifying a value for removal causes all occurrences of that value to be removed from the variable. Unlike “:append” and “:prepend”, there is no need to add a leading or trailing space to the value.
When you use this syntax, BitBake expects one or more strings. Surrounding spaces and spacing are preserved. Here is an example:
FOO = "123 456 789 123456 123 456 123 456"
FOO:remove = "123"
FOO:remove = "456"
FOO2 = " abc def ghi abcdef abc def abc def def"
FOO2:remove = "\
def \
abc \
ghi \
"
The variable FOO
becomes
“ 789 123456 “ and FOO2
becomes “ abcdef “.
Like “:append” and “:prepend”, “:remove” is applied at variable expansion time.
Note
The overrides are applied in this order, “:append”, “:prepend”, “:remove”. This implies it is not possible to re-append previously removed strings. However, one can undo a “:remove” by using an intermediate variable whose content is passed to the “:remove” so that modifying the intermediate variable equals to keeping the string in:
FOOREMOVE = "123 456 789"
FOO:remove = "${FOOREMOVE}"
...
FOOREMOVE = "123 789"
This expands to FOO:remove = "123 789"
.
Note
Override application order may not match variable parse history, i.e.
the output of bitbake -e
may contain “:remove” before “:append”,
but the result will be removed string, because “:remove” is handled
last.
3.1.12 Override Style Operation Advantages
An advantage of the override style operations “:append”, “:prepend”, and
“:remove” as compared to the “+=” and “=+” operators is that the
override style operators provide guaranteed operations. For example,
consider a class foo.bbclass
that needs to add the value “val” to
the variable FOO
, and a recipe that uses foo.bbclass
as follows:
inherit foo
FOO = "initial"
If foo.bbclass
uses the “+=” operator,
as follows, then the final value of FOO
will be “initial”, which is
not what is desired:
FOO += "val"
If, on the other hand, foo.bbclass
uses the “:append” operator, then the final value of FOO
will be
“initial val”, as intended:
FOO:append = " val"
Note
It is never necessary to use “+=” together with “:append”. The following sequence of assignments appends “barbaz” to FOO:
FOO:append = "bar"
FOO:append = "baz"
The only effect of changing the second assignment in the previous example to use “+=” would be to add a space before “baz” in the appended value (due to how the “+=” operator works).
Another advantage of the override style operations is that you can combine them with other overrides as described in the “Conditional Syntax (Overrides)” section.
3.1.13 Variable Flag Syntax
Variable flags are BitBake’s implementation of variable properties or attributes. It is a way of tagging extra information onto a variable. You can find more out about variable flags in general in the “Variable Flags” section.
You can define, append, and prepend values to variable flags. All the standard syntax operations previously mentioned work for variable flags except for override style syntax (i.e. “:prepend”, “:append”, and “:remove”).
Here are some examples showing how to set variable flags:
FOO[a] = "abc"
FOO[b] = "123"
FOO[a] += "456"
The variable FOO
has two flags:
[a]
and [b]
. The flags are immediately set to “abc” and “123”,
respectively. The [a]
flag becomes “abc 456”.
No need exists to pre-define variable flags. You can simply start using them. One extremely common application is to attach some brief documentation to a BitBake variable as follows:
CACHE[doc] = "The directory holding the cache of the metadata."
Note
Variable flag names starting with an underscore (_
) character
are allowed but are ignored by d.getVarFlags("VAR")
in Python code. Such flag names are used internally by BitBake.
3.1.14 Inline Python Variable Expansion
You can use inline Python variable expansion to set variables. Here is an example:
DATE = "${@time.strftime('%Y%m%d',time.gmtime())}"
This example results in the DATE
variable being set to the current date.
Probably the most common use of this feature is to extract the value of
variables from BitBake’s internal data dictionary, d
. The following
lines select the values of a package name and its version number,
respectively:
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
Note
Inline Python expressions work just like variable expansions insofar as the “=” and “:=” operators are concerned. Given the following assignment, foo() is called each time FOO is expanded:
FOO = "${@foo()}"
Contrast this with the following immediate assignment, where foo() is only called once, while the assignment is parsed:
FOO := "${@foo()}"
For a different way to set variables with Python code during parsing, see the “Anonymous Python Functions” section.
3.1.15 Unsetting variables
It is possible to completely remove a variable or a variable flag from BitBake’s internal data dictionary by using the “unset” keyword. Here is an example:
unset DATE
unset do_fetch[noexec]
These two statements remove the DATE
and the do_fetch[noexec]
flag.
3.1.16 Providing Pathnames
When specifying pathnames for use with BitBake, do not use the tilde (“~”) character as a shortcut for your home directory. Doing so might cause BitBake to not recognize the path since BitBake does not expand this character in the same way a shell would.
Instead, provide a fuller path as the following example illustrates:
BBLAYERS ?= " \
/home/scott-lenovo/LayerA \
"
3.2 Exporting Variables to the Environment
You can export variables to the environment of running tasks by using
the export
keyword. For example, in the following example, the
do_foo
task prints “value from the environment” when run:
export ENV_VARIABLE
ENV_VARIABLE = "value from the environment"
do_foo() {
bbplain "$ENV_VARIABLE"
}
Note
BitBake does not expand $ENV_VARIABLE
in this case because it lacks the
obligatory {}
. Rather, $ENV_VARIABLE
is expanded by the shell.
It does not matter whether export ENV_VARIABLE
appears before or
after assignments to ENV_VARIABLE
.
It is also possible to combine export
with setting a value for the
variable. Here is an example:
export ENV_VARIABLE = "variable-value"
In the output of bitbake -e
, variables that are exported to the
environment are preceded by “export”.
Among the variables commonly exported to the environment are CC
and
CFLAGS
, which are picked up by many build systems.
3.3 Conditional Syntax (Overrides)
BitBake uses OVERRIDES to control what variables are overridden after BitBake parses recipes and configuration files. This section describes how you can use OVERRIDES as conditional metadata, talks about key expansion in relationship to OVERRIDES, and provides some examples to help with understanding.
3.3.1 Conditional Metadata
You can use OVERRIDES to conditionally select a specific version of a variable and to conditionally append or prepend the value of a variable.
Note
Overrides can only use lower-case characters, digits and dashes. In particular, colons are not permitted in override names as they are used to separate overrides from each other and from the variable name.
Selecting a Variable: The OVERRIDES variable is a colon-character-separated list that contains items for which you want to satisfy conditions. Thus, if you have a variable that is conditional on “arm”, and “arm” is in OVERRIDES, then the “arm”-specific version of the variable is used rather than the non-conditional version. Here is an example:
OVERRIDES = "architecture:os:machine" TEST = "default" TEST:os = "osspecific" TEST:nooverride = "othercondvalue"
In this example, the OVERRIDES variable lists three overrides: “architecture”, “os”, and “machine”. The variable
TEST
by itself has a default value of “default”. You select the os-specific version of theTEST
variable by appending the “os” override to the variable (i.e.TEST:os
).To better understand this, consider a practical example that assumes an OpenEmbedded metadata-based Linux kernel recipe file. The following lines from the recipe file first set the kernel branch variable
KBRANCH
to a default value, then conditionally override that value based on the architecture of the build:KBRANCH = "standard/base" KBRANCH:qemuarm = "standard/arm-versatile-926ejs" KBRANCH:qemumips = "standard/mti-malta32" KBRANCH:qemuppc = "standard/qemuppc" KBRANCH:qemux86 = "standard/common-pc/base" KBRANCH:qemux86-64 = "standard/common-pc-64/base" KBRANCH:qemumips64 = "standard/mti-malta64"
Appending and Prepending: BitBake also supports append and prepend operations to variable values based on whether a specific item is listed in OVERRIDES. Here is an example:
DEPENDS = "glibc ncurses" OVERRIDES = "machine:local" DEPENDS:append:machine = "libmad"
In this example, DEPENDS becomes “glibc ncurses libmad”.
Again, using an OpenEmbedded metadata-based kernel recipe file as an example, the following lines will conditionally append to the
KERNEL_FEATURES
variable based on the architecture:KERNEL_FEATURES:append = " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
Setting a Variable for a Single Task: BitBake supports setting a variable just for the duration of a single task. Here is an example:
FOO:task-configure = "val 1" FOO:task-compile = "val 2"
In the previous example,
FOO
has the value “val 1” while thedo_configure
task is executed, and the value “val 2” while thedo_compile
task is executed.Internally, this is implemented by prepending the task (e.g. “task-compile:”) to the value of OVERRIDES for the local datastore of the
do_compile
task.You can also use this syntax with other combinations (e.g. “
:prepend
”) as shown in the following example:EXTRA_OEMAKE:prepend:task-compile = "${PARALLEL_MAKE} "
Note
Before BitBake 1.52 (Honister 3.4), the syntax for OVERRIDES
used _
instead of :
, so you will still find a lot of documentation
using _append
, _prepend
, and _remove
, for example.
For details, see the Overrides Syntax Changes section in the Yocto Project manual migration notes.
3.3.2 Key Expansion
Key expansion happens when the BitBake datastore is finalized. To better understand this, consider the following example:
A${B} = "X"
B = "2"
A2 = "Y"
In this case, after all the parsing is complete, BitBake expands
${B}
into “2”. This expansion causes A2
, which was set to “Y”
before the expansion, to become “X”.
3.3.3 Examples
Despite the previous explanations that show the different forms of variable definitions, it can be hard to work out exactly what happens when variable operators, conditional overrides, and unconditional overrides are combined. This section presents some common scenarios along with explanations for variable interactions that typically confuse users.
There is often confusion concerning the order in which overrides and various “append” operators take effect. Recall that an append or prepend operation using “:append” and “:prepend” does not result in an immediate assignment as would “+=”, “.=”, “=+”, or “=.”. Consider the following example:
OVERRIDES = "foo"
A = "Z"
A:foo:append = "X"
For this case,
A
is unconditionally set to “Z” and “X” is unconditionally and
immediately appended to the variable A:foo
. Because overrides have
not been applied yet, A:foo
is set to “X” due to the append and
A
simply equals “Z”.
Applying overrides, however, changes things. Since “foo” is listed in
OVERRIDES, the conditional variable A
is replaced with the “foo”
version, which is equal to “X”. So effectively, A:foo
replaces
A
.
This next example changes the order of the override and the append:
OVERRIDES = "foo"
A = "Z"
A:append:foo = "X"
For this case, before
overrides are handled, A
is set to “Z” and A:append:foo
is set
to “X”. Once the override for “foo” is applied, however, A
gets
appended with “X”. Consequently, A
becomes “ZX”. Notice that spaces
are not appended.
This next example has the order of the appends and overrides reversed back as in the first example:
OVERRIDES = "foo"
A = "Y"
A:foo:append = "Z"
A:foo:append = "X"
For this case, before any overrides are resolved,
A
is set to “Y” using an immediate assignment. After this immediate
assignment, A:foo
is set to “Z”, and then further appended with “X”
leaving the variable set to “ZX”. Finally, applying the override for
“foo” results in the conditional variable A
becoming “ZX” (i.e.
A
is replaced with A:foo
).
This final example mixes in some varying operators:
A = "1"
A:append = "2"
A:append = "3"
A += "4"
A .= "5"
For this case, the type of append
operators are affecting the order of assignments as BitBake passes
through the code multiple times. Initially, A
is set to “1 45”
because of the three statements that use immediate operators. After
these assignments are made, BitBake applies the “:append” operations.
Those operations result in A
becoming “1 4523”.
3.5 Functions
As with most languages, functions are the building blocks that are used to build up operations into tasks. BitBake supports these types of functions:
Shell Functions: Functions written in shell script and executed either directly as functions, tasks, or both. They can also be called by other shell functions.
BitBake-Style Python Functions: Functions written in Python and executed by BitBake or other Python functions using
bb.build.exec_func()
.Python Functions: Functions written in Python and executed by Python.
Anonymous Python Functions: Python functions executed automatically during parsing.
Regardless of the type of function, you can only define them in class
(.bbclass
) and recipe (.bb
or .inc
) files.
3.5.1 Shell Functions
Functions written in shell script are executed either directly as functions, tasks, or both. They can also be called by other shell functions. Here is an example shell function definition:
some_function () {
echo "Hello World"
}
When you create these types of functions in
your recipe or class files, you need to follow the shell programming
rules. The scripts are executed by /bin/sh
, which may not be a bash
shell but might be something such as dash
. You should not use
Bash-specific script (bashisms).
Overrides and override-style operators like :append
and :prepend
can also be applied to shell functions. Most commonly, this application
would be used in a .bbappend
file to modify functions in the main
recipe. It can also be used to modify functions inherited from classes.
As an example, consider the following:
do_foo() {
bbplain first
fn
}
fn:prepend() {
bbplain second
}
fn() {
bbplain third
}
do_foo:append() {
bbplain fourth
}
Running do_foo
prints the following:
recipename do_foo: first
recipename do_foo: second
recipename do_foo: third
recipename do_foo: fourth
Note
Overrides and override-style operators can be applied to any shell function, not just tasks.
You can use the bitbake -e recipename
command to view the final
assembled function after all overrides have been applied.
3.5.2 BitBake-Style Python Functions
These functions are written in Python and executed by BitBake or other
Python functions using bb.build.exec_func()
.
An example BitBake function is:
python some_python_function () {
d.setVar("TEXT", "Hello World")
print d.getVar("TEXT")
}
Because the Python “bb” and “os” modules are already imported, you do not need to import these modules. Also in these types of functions, the datastore (“d”) is a global variable and is always automatically available.
Note
Variable expressions (e.g. ${X}
) are no longer expanded within Python
functions. This behavior is intentional in order to allow you to freely set
variable values to expandable expressions without having them expanded
prematurely. If you do wish to expand a variable within a Python function,
use d.getVar("X")
. Or, for more complicated expressions, use d.expand()
.
Similar to shell functions, you can also apply overrides and override-style operators to BitBake-style Python functions.
As an example, consider the following:
python do_foo:prepend() {
bb.plain("first")
}
python do_foo() {
bb.plain("second")
}
python do_foo:append() {
bb.plain("third")
}
Running do_foo
prints the following:
recipename do_foo: first
recipename do_foo: second
recipename do_foo: third
You can use the bitbake -e recipename
command to view
the final assembled function after all overrides have been applied.
3.5.3 Python Functions
These functions are written in Python and are executed by other Python code. Examples of Python functions are utility functions that you intend to call from in-line Python or from within other Python functions. Here is an example:
def get_depends(d):
if d.getVar('SOMECONDITION'):
return "dependencywithcond"
else:
return "dependency"
SOMECONDITION = "1"
DEPENDS = "${@get_depends(d)}"
This would result in DEPENDS containing dependencywithcond
.
Here are some things to know about Python functions:
Python functions can take parameters.
The BitBake datastore is not automatically available. Consequently, you must pass it in as a parameter to the function.
The “bb” and “os” Python modules are automatically available. You do not need to import them.
3.5.4 BitBake-Style Python Functions Versus Python Functions
Following are some important differences between BitBake-style Python functions and regular Python functions defined with “def”:
Only BitBake-style Python functions can be tasks.
Overrides and override-style operators can only be applied to BitBake-style Python functions.
Only regular Python functions can take arguments and return values.
Variable flags such as
[dirs]
,[cleandirs]
, and[lockfiles]
can be used on BitBake-style Python functions, but not on regular Python functions.BitBake-style Python functions generate a separate
${
T}/run.
function-name.
pid script that is executed to run the function, and also generate a log file in${T}/log.
function-name.
pid if they are executed as tasks.Regular Python functions execute “inline” and do not generate any files in
${T}
.Regular Python functions are called with the usual Python syntax. BitBake-style Python functions are usually tasks and are called directly by BitBake, but can also be called manually from Python code by using the
bb.build.exec_func()
function. Here is an example:bb.build.exec_func("my_bitbake_style_function", d)
Note
bb.build.exec_func()
can also be used to run shell functions from Python code. If you want to run a shell function before a Python function within the same task, then you can use a parent helper Python function that starts by running the shell function withbb.build.exec_func()
and then runs the Python code.To detect errors from functions executed with
bb.build.exec_func()
, you can catch thebb.build.FuncFailed
exception.Note
Functions in metadata (recipes and classes) should not themselves raise
bb.build.FuncFailed
. Rather,bb.build.FuncFailed
should be viewed as a general indicator that the called function failed by raising an exception. For example, an exception raised bybb.fatal()
will be caught insidebb.build.exec_func()
, and abb.build.FuncFailed
will be raised in response.
Due to their simplicity, you should prefer regular Python functions over
BitBake-style Python functions unless you need a feature specific to
BitBake-style Python functions. Regular Python functions in metadata are
a more recent invention than BitBake-style Python functions, and older
code tends to use bb.build.exec_func()
more often.
3.5.5 Anonymous Python Functions
Sometimes it is useful to set variables or perform other operations programmatically during parsing. To do this, you can define special Python functions, called anonymous Python functions, that run at the end of parsing. For example, the following conditionally sets a variable based on the value of another variable:
python () {
if d.getVar('SOMEVAR') == 'value':
d.setVar('ANOTHERVAR', 'value2')
}
An equivalent way to mark a function as an anonymous function is to give it the name “__anonymous”, rather than no name.
Anonymous Python functions always run at the end of parsing, regardless of where they are defined. If a recipe contains many anonymous functions, they run in the same order as they are defined within the recipe. As an example, consider the following snippet:
python () {
d.setVar('FOO', 'foo 2')
}
FOO = "foo 1"
python () {
d.appendVar('BAR',' bar 2')
}
BAR = "bar 1"
The previous example is conceptually equivalent to the following snippet:
FOO = "foo 1"
BAR = "bar 1"
FOO = "foo 2"
BAR += "bar 2"
FOO
ends up with the value “foo 2”, and
BAR
with the value “bar 1 bar 2”. Just as in the second snippet, the
values set for the variables within the anonymous functions become
available to tasks, which always run after parsing.
Overrides and override-style operators such as “:append
” are applied
before anonymous functions run. In the following example, FOO
ends
up with the value “foo from anonymous”:
FOO = "foo"
FOO:append = " from outside"
python () {
d.setVar("FOO", "foo from anonymous")
}
For methods you can use with anonymous Python functions, see the “Functions You Can Call From Within Python” section. For a different method to run Python code during parsing, see the “Inline Python Variable Expansion” section.
3.5.6 Flexible Inheritance for Class Functions
Through coding techniques and the use of EXPORT_FUNCTIONS
, BitBake
supports exporting a function from a class such that the class function
appears as the default implementation of the function, but can still be
called if a recipe inheriting the class needs to define its own version
of the function.
To understand the benefits of this feature, consider the basic scenario
where a class defines a task function and your recipe inherits the
class. In this basic scenario, your recipe inherits the task function as
defined in the class. If desired, your recipe can add to the start and
end of the function by using the “:prepend” or “:append” operations
respectively, or it can redefine the function completely. However, if it
redefines the function, there is no means for it to call the class
version of the function. EXPORT_FUNCTIONS
provides a mechanism that
enables the recipe’s version of the function to call the original
version of the function.
To make use of this technique, you need the following things in place:
The class needs to define the function as follows:
classname_functionname
For example, if you have a class file
bar.bbclass
and a function nameddo_foo
, the class must define the function as follows:bar_do_foo
The class needs to contain the
EXPORT_FUNCTIONS
statement as follows:EXPORT_FUNCTIONS functionname
For example, continuing with the same example, the statement in the
bar.bbclass
would be as follows:EXPORT_FUNCTIONS do_foo
You need to call the function appropriately from within your recipe. Continuing with the same example, if your recipe needs to call the class version of the function, it should call
bar_do_foo
. Assumingdo_foo
was a shell function andEXPORT_FUNCTIONS
was used as above, the recipe’s function could conditionally call the class version of the function as follows:do_foo() { if [ somecondition ] ; then bar_do_foo else # Do something else fi }
To call your modified version of the function as defined in your recipe, call it as
do_foo
.
With these conditions met, your single recipe can freely choose between the original function as defined in the class file and the modified function in your recipe. If you do not set up these conditions, you are limited to using one function or the other.
3.6 Tasks
Tasks are BitBake execution units that make up the steps that BitBake
can run for a given recipe. Tasks are only supported in recipes and
classes (i.e. in .bb
files and files included or inherited from
.bb
files). By convention, tasks have names that start with “do_”.
3.6.1 Promoting a Function to a Task
Tasks are either shell functions or
BitBake-style Python functions
that have been promoted to tasks by using the addtask
command. The
addtask
command can also optionally describe dependencies between
the task and other tasks. Here is an example that shows how to define a
task and declare some dependencies:
python do_printdate () {
import time
print time.strftime('%Y%m%d', time.gmtime())
}
addtask printdate after do_fetch before do_build
The first argument to addtask
is the name
of the function to promote to a task. If the name does not start with
“do_”, “do_” is implicitly added, which enforces the convention that all
task names start with “do_”.
In the previous example, the do_printdate
task becomes a dependency
of the do_build
task, which is the default task (i.e. the task run
by the bitbake
command unless another task is specified explicitly).
Additionally, the do_printdate
task becomes dependent upon the
do_fetch
task. Running the do_build
task results in the
do_printdate
task running first.
Note
If you try out the previous example, you might see that the
do_printdate
task is only run the first time you build the recipe with the
bitbake
command. This is because BitBake considers the task “up-to-date”
after that initial run. If you want to force the task to always be
rerun for experimentation purposes, you can make BitBake always
consider the task “out-of-date” by using the
[nostamp]
variable flag, as follows:
do_printdate[nostamp] = "1"
You can also explicitly run the task and provide the -f option as follows:
$ bitbake recipe -c printdate -f
When manually selecting a task to run with the bitbake recipe
-c task
command, you can omit the “do_” prefix as part of the task
name.
You might wonder about the practical effects of using addtask
without specifying any dependencies as is done in the following example:
addtask printdate
In this example, assuming dependencies have not been
added through some other means, the only way to run the task is by
explicitly selecting it with bitbake
recipe -c printdate
. You
can use the do_listtasks
task to list all tasks defined in a recipe
as shown in the following example:
$ bitbake recipe -c listtasks
For more information on task dependencies, see the “Dependencies” section.
See the “Variable Flags” section for information on variable flags you can use with tasks.
Note
While it’s infrequent, it’s possible to define multiple tasks as
dependencies when calling addtask
. For example, here’s a snippet
from the OpenEmbedded class file package_tar.bbclass
:
addtask package_write_tar before do_build after do_packagedata do_package
Note how the package_write_tar
task has to wait until both of
do_packagedata
and do_package
complete.
3.6.2 Deleting a Task
As well as being able to add tasks, you can delete them. Simply use the
deltask
command to delete a task. For example, to delete the example
task used in the previous sections, you would use:
deltask printdate
If you delete a task using the deltask
command and the task has
dependencies, the dependencies are not reconnected. For example, suppose
you have three tasks named do_a
, do_b
, and do_c
.
Furthermore, do_c
is dependent on do_b
, which in turn is
dependent on do_a
. Given this scenario, if you use deltask
to
delete do_b
, the implicit dependency relationship between do_c
and do_a
through do_b
no longer exists, and do_c
dependencies are not updated to include do_a
. Thus, do_c
is free
to run before do_a
.
If you want dependencies such as these to remain intact, use the
[noexec]
varflag to disable the task instead of using the
deltask
command to delete it:
do_b[noexec] = "1"
3.6.3 Passing Information Into the Build Task Environment
When running a task, BitBake tightly controls the shell execution environment of the build tasks to make sure unwanted contamination from the build machine cannot influence the build.
Note
By default, BitBake cleans the environment to include only those things exported or listed in its passthrough list to ensure that the build environment is reproducible and consistent. You can prevent this “cleaning” by setting the BB_PRESERVE_ENV variable.
Consequently, if you do want something to get passed into the build task environment, you must take these two steps:
Tell BitBake to load what you want from the environment into the datastore. You can do so through the BB_ENV_PASSTHROUGH and BB_ENV_PASSTHROUGH_ADDITIONS variables. For example, assume you want to prevent the build system from accessing your
$HOME/.ccache
directory. The following command adds the the environment variableCCACHE_DIR
to BitBake’s passthrough list to allow that variable into the datastore:export BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS CCACHE_DIR"
Tell BitBake to export what you have loaded into the datastore to the task environment of every running task. Loading something from the environment into the datastore (previous step) only makes it available in the datastore. To export it to the task environment of every running task, use a command similar to the following in your local configuration file
local.conf
or your distribution configuration file:export CCACHE_DIR
Note
A side effect of the previous steps is that BitBake records the variable as a dependency of the build process in things like the setscene checksums. If doing so results in unnecessary rebuilds of tasks, you can also flag the variable so that the setscene code ignores the dependency when it creates checksums.
Sometimes, it is useful to be able to obtain information from the original execution environment. BitBake saves a copy of the original environment into a special variable named BB_ORIGENV.
The BB_ORIGENV variable returns a datastore object that can be
queried using the standard datastore operators such as
getVar(, False)
. The datastore object is useful, for example, to
find the original DISPLAY
variable. Here is an example:
origenv = d.getVar("BB_ORIGENV", False)
bar = origenv.getVar("BAR", False)
The previous example returns BAR
from the original execution
environment.
3.7 Variable Flags
Variable flags (varflags) help control a task’s functionality and dependencies. BitBake reads and writes varflags to the datastore using the following command forms:
variable = d.getVarFlags("variable")
self.d.setVarFlags("FOO", {"func": True})
When working with varflags, the same syntax, with the exception of overrides, applies. In other words, you can set, append, and prepend varflags just like variables. See the “Variable Flag Syntax” section for details.
BitBake has a defined set of varflags available for recipes and classes. Tasks support a number of these flags which control various functionality of the task:
[cleandirs]
: Empty directories that should be created before the task runs. Directories that already exist are removed and recreated to empty them.[depends]
: Controls inter-task dependencies. See the DEPENDS variable and the “Inter-Task Dependencies” section for more information.[deptask]
: Controls task build-time dependencies. See the DEPENDS variable and the “Build Dependencies” section for more information.[dirs]
: Directories that should be created before the task runs. Directories that already exist are left as is. The last directory listed is used as the current working directory for the task.[file-checksums]
: Controls the file dependencies for a task. The baseline file list is the set of files associated with SRC_URI. May be used to set additional dependencies on files not associated with SRC_URI.The value set to the list is a file-boolean pair where the first value is the file name and the second is whether or not it physically exists on the filesystem.
do_configure[file-checksums] += "${MY_DIRPATH}/my-file.txt:True"
It is important to record any paths which the task looked at and which didn’t exist. This means that if these do exist at a later time, the task can be rerun with the new additional files. The “exists” True or False value after the path allows this to be handled.
[lockfiles]
: Specifies one or more lockfiles to lock while the task executes. Only one task may hold a lockfile, and any task that attempts to lock an already locked file will block until the lock is released. You can use this variable flag to accomplish mutual exclusion.[network]
: When set to “1”, allows a task to access the network. By default, only thedo_fetch
task is granted network access. Recipes shouldn’t access the network outside ofdo_fetch
as it usually undermines fetcher source mirroring, image and licence manifests, software auditing and supply chain security.[noexec]
: When set to “1”, marks the task as being empty, with no execution required. You can use the[noexec]
flag to set up tasks as dependency placeholders, or to disable tasks defined elsewhere that are not needed in a particular recipe.[nostamp]
: When set to “1”, tells BitBake to not generate a stamp file for a task, which implies the task should always be executed.Caution
Any task that depends (possibly indirectly) on a
[nostamp]
task will always be executed as well. This can cause unnecessary rebuilding if you are not careful.[number_threads]
: Limits tasks to a specific number of simultaneous threads during execution. This varflag is useful when your build host has a large number of cores but certain tasks need to be rate-limited due to various kinds of resource constraints (e.g. to avoid network throttling).number_threads
works similarly to the BB_NUMBER_THREADS variable but is task-specific.Set the value globally. For example, the following makes sure the
do_fetch
task uses no more than two simultaneous execution threads: do_fetch[number_threads] = “2”Warning
Setting the varflag in individual recipes rather than globally can result in unpredictable behavior.
Setting the varflag to a value greater than the value used in the BB_NUMBER_THREADS variable causes
number_threads
to have no effect.
[postfuncs]
: List of functions to call after the completion of the task.[prefuncs]
: List of functions to call before the task executes.[rdepends]
: Controls inter-task runtime dependencies. See the RDEPENDS variable, the RRECOMMENDS variable, and the “Inter-Task Dependencies” section for more information.[rdeptask]
: Controls task runtime dependencies. See the RDEPENDS variable, the RRECOMMENDS variable, and the “Runtime Dependencies” section for more information.[recideptask]
: When set in conjunction withrecrdeptask
, specifies a task that should be inspected for additional dependencies.[recrdeptask]
: Controls task recursive runtime dependencies. See the RDEPENDS variable, the RRECOMMENDS variable, and the “Recursive Dependencies” section for more information.[stamp-extra-info]
: Extra stamp information to append to the task’s stamp. As an example, OpenEmbedded uses this flag to allow machine-specific tasks.[umask]
: The umask to run the task under.
Several varflags are useful for controlling how signatures are calculated for variables. For more information on this process, see the “Checksums (Signatures)” section.
[vardeps]
: Specifies a space-separated list of additional variables to add to a variable’s dependencies for the purposes of calculating its signature. Adding variables to this list is useful, for example, when a function refers to a variable in a manner that does not allow BitBake to automatically determine that the variable is referred to.[vardepsexclude]
: Specifies a space-separated list of variables that should be excluded from a variable’s dependencies for the purposes of calculating its signature.[vardepvalue]
: If set, instructs BitBake to ignore the actual value of the variable and instead use the specified value when calculating the variable’s signature.[vardepvalueexclude]
: Specifies a pipe-separated list of strings to exclude from the variable’s value when calculating the variable’s signature.
3.8 Events
BitBake allows installation of event handlers within recipe and class
files. Events are triggered at certain points during operation, such as
the beginning of operation against a given recipe (i.e. *.bb
), the
start of a given task, a task failure, a task success, and so forth. The
intent is to make it easy to do things like email notification on build
failures.
Following is an example event handler that prints the name of the event and the content of the FILE variable:
addhandler myclass_eventhandler
python myclass_eventhandler() {
from bb.event import getName
print("The name of the Event is %s" % getName(e))
print("The file we run for is %s" % d.getVar('FILE'))
}
myclass_eventhandler[eventmask] = "bb.event.BuildStarted
bb.event.BuildCompleted"
In the previous example, an eventmask has been
set so that the handler only sees the “BuildStarted” and
“BuildCompleted” events. This event handler gets called every time an
event matching the eventmask is triggered. A global variable “e” is
defined, which represents the current event. With the getName(e)
method, you can get the name of the triggered event. The global
datastore is available as “d”. In legacy code, you might see “e.data”
used to get the datastore. However, realize that “e.data” is deprecated
and you should use “d” going forward.
The context of the datastore is appropriate to the event in question. For example, “BuildStarted” and “BuildCompleted” events run before any tasks are executed so would be in the global configuration datastore namespace. No recipe-specific metadata exists in that namespace. The “BuildStarted” and “BuildCompleted” events also run in the main cooker/server process rather than any worker context. Thus, any changes made to the datastore would be seen by other cooker/server events within the current build but not seen outside of that build or in any worker context. Task events run in the actual tasks in question consequently have recipe-specific and task-specific contents. These events run in the worker context and are discarded at the end of task execution.
During a standard build, the following common events might occur. The following events are the most common kinds of events that most metadata might have an interest in viewing:
bb.event.ConfigParsed()
: Fired when the base configuration; which consists ofbitbake.conf
,base.bbclass
and any global INHERIT statements; has been parsed. You can see multiple such events when each of the workers parse the base configuration or if the server changes configuration and reparses. Any given datastore only has one such event executed against it, however. If BB_INVALIDCONF is set in the datastore by the event handler, the configuration is reparsed and a new event triggered, allowing the metadata to update configuration.bb.event.HeartbeatEvent()
: Fires at regular time intervals of one second. You can configure the interval time using theBB_HEARTBEAT_EVENT
variable. The event’s “time” attribute is thetime.time()
value when the event is triggered. This event is useful for activities such as system state monitoring.bb.event.ParseStarted()
: Fired when BitBake is about to start parsing recipes. This event’s “total” attribute represents the number of recipes BitBake plans to parse.bb.event.ParseProgress()
: Fired as parsing progresses. This event’s “current” attribute is the number of recipes parsed as well as the “total” attribute.bb.event.ParseCompleted()
: Fired when parsing is complete. This event’s “cached”, “parsed”, “skipped”, “virtuals”, “masked”, and “errors” attributes provide statistics for the parsing results.bb.event.BuildStarted()
: Fired when a new build starts. BitBake fires multiple “BuildStarted” events (one per configuration) when multiple configuration (multiconfig) is enabled.bb.build.TaskStarted()
: Fired when a task starts. This event’s “taskfile” attribute points to the recipe from which the task originates. The “taskname” attribute, which is the task’s name, includes thedo_
prefix, and the “logfile” attribute point to where the task’s output is stored. Finally, the “time” attribute is the task’s execution start time.bb.build.TaskInvalid()
: Fired if BitBake tries to execute a task that does not exist.bb.build.TaskFailedSilent()
: Fired for setscene tasks that fail and should not be presented to the user verbosely.bb.build.TaskFailed()
: Fired for normal tasks that fail.bb.build.TaskSucceeded()
: Fired when a task successfully completes.bb.event.BuildCompleted()
: Fired when a build finishes.bb.cooker.CookerExit()
: Fired when the BitBake server/cooker shuts down. This event is usually only seen by the UIs as a sign they should also shutdown.
This next list of example events occur based on specific requests to the server. These events are often used to communicate larger pieces of information from the BitBake server to other parts of BitBake such as user interfaces:
bb.event.TreeDataPreparationStarted()
bb.event.TreeDataPreparationProgress()
bb.event.TreeDataPreparationCompleted()
bb.event.DepTreeGenerated()
bb.event.CoreBaseFilesFound()
bb.event.ConfigFilePathFound()
bb.event.FilesMatchingFound()
bb.event.ConfigFilesFound()
bb.event.TargetsTreeGenerated()
3.9 Variants — Class Extension Mechanism
BitBake supports multiple incarnations of a recipe file via the BBCLASSEXTEND variable.
The BBCLASSEXTEND variable is a space separated list of classes used to “extend” the recipe for each variant. Here is an example that results in a second incarnation of the current recipe being available. This second incarnation will have the “native” class inherited.
BBCLASSEXTEND = "native"
3.10 Dependencies
To allow for efficient parallel processing, BitBake handles dependencies at the task level. Dependencies can exist both between tasks within a single recipe and between tasks in different recipes. Following are examples of each:
For tasks within a single recipe, a recipe’s
do_configure
task might need to complete before itsdo_compile
task can run.For tasks in different recipes, one recipe’s
do_configure
task might require another recipe’sdo_populate_sysroot
task to finish first such that the libraries and headers provided by the other recipe are available.
This section describes several ways to declare dependencies. Remember, even though dependencies are declared in different ways, they are all simply dependencies between tasks.
3.10.1 Dependencies Internal to the .bb
File
BitBake uses the addtask
directive to manage dependencies that are
internal to a given recipe file. You can use the addtask
directive
to indicate when a task is dependent on other tasks or when other tasks
depend on that recipe. Here is an example:
addtask printdate after do_fetch before do_build
In this example, the do_printdate
task
depends on the completion of the do_fetch
task, and the do_build
task depends on the completion of the do_printdate
task.
Note
For a task to run, it must be a direct or indirect dependency of some other task that is scheduled to run.
For illustration, here are some examples:
The directive
addtask mytask before do_configure
causesdo_mytask
to run beforedo_configure
runs. Be aware thatdo_mytask
still only runs if its input checksum has changed since the last time it was run. Changes to the input checksum ofdo_mytask
also indirectly causedo_configure
to run.The directive
addtask mytask after do_configure
by itself never causesdo_mytask
to run.do_mytask
can still be run manually as follows:$ bitbake recipe -c mytask
Declaring
do_mytask
as a dependency of some other task that is scheduled to run also causes it to run. Regardless, the task runs afterdo_configure
.
3.10.2 Build Dependencies
BitBake uses the DEPENDS variable to manage
build time dependencies. The [deptask]
varflag for tasks signifies
the task of each item listed in DEPENDS that must complete before
that task can be executed. Here is an example:
do_configure[deptask] = "do_populate_sysroot"
In this example, the do_populate_sysroot
task
of each item in DEPENDS must complete before do_configure
can
execute.
3.10.3 Runtime Dependencies
BitBake uses the PACKAGES, RDEPENDS, and RRECOMMENDS variables to manage runtime dependencies.
The PACKAGES variable lists runtime packages. Each of those packages
can have RDEPENDS and RRECOMMENDS runtime dependencies. The
[rdeptask]
flag for tasks is used to signify the task of each item
runtime dependency which must have completed before that task can be
executed.
do_package_qa[rdeptask] = "do_packagedata"
In the previous
example, the do_packagedata
task of each item in RDEPENDS must
have completed before do_package_qa
can execute.
Although RDEPENDS contains entries from the
runtime dependency namespace, BitBake knows how to map them back
to the build-time dependency namespace, in which the tasks are defined.
3.10.4 Recursive Dependencies
BitBake uses the [recrdeptask]
flag to manage recursive task
dependencies. BitBake looks through the build-time and runtime
dependencies of the current recipe, looks through the task’s inter-task
dependencies, and then adds dependencies for the listed task. Once
BitBake has accomplished this, it recursively works through the
dependencies of those tasks. Iterative passes continue until all
dependencies are discovered and added.
The [recrdeptask]
flag is most commonly used in high-level recipes
that need to wait for some task to finish “globally”. For example,
image.bbclass
has the following:
do_rootfs[recrdeptask] += "do_packagedata"
This statement says that the do_packagedata
task of
the current recipe and all recipes reachable (by way of dependencies)
from the image recipe must run before the do_rootfs
task can run.
BitBake allows a task to recursively depend on itself by referencing itself in the task list:
do_a[recrdeptask] = "do_a do_b"
In the same way as before, this means that the do_a
and do_b
tasks of the current recipe and all
recipes reachable (by way of dependencies) from the recipe
must run before the do_a
task can run. In this
case BitBake will ignore the current recipe’s do_a
task circular dependency on itself.
3.10.5 Inter-Task Dependencies
BitBake uses the [depends]
flag in a more generic form to manage
inter-task dependencies. This more generic form allows for
inter-dependency checks for specific tasks rather than checks for the
data in DEPENDS. Here is an example:
do_patch[depends] = "quilt-native:do_populate_sysroot"
In this example, the do_populate_sysroot
task of the target quilt-native
must have completed before the do_patch
task can execute.
The [rdepends]
flag works in a similar way but takes targets in the
runtime namespace instead of the build-time dependency namespace.
3.11 Functions You Can Call From Within Python
BitBake provides many functions you can call from within Python functions. This section lists the most commonly used functions, and mentions where to find others.
3.11.1 Functions for Accessing Datastore Variables
It is often necessary to access variables in the BitBake datastore using Python functions. The BitBake datastore has an API that allows you this access. Here is a list of available operations:
Operation |
Description |
---|---|
|
Returns the value of variable “X”. Using “expand=True” expands the value. Returns “None” if the variable “X” does not exist. |
|
Sets the variable “X” to “value” |
|
Adds “value” to the end of the variable “X”. Acts like |
|
Adds “value” to the start of the variable “X”. Acts like
|
|
Deletes the variable “X” from the datastore. Does nothing if the variable “X” does not exist. |
|
Renames the variable “X” to “Y”. Does nothing if the variable “X” does not exist. |
|
Returns the value of variable “X”. Using “expand=True” expands the value. Returns “None” if either the variable “X” or the named flag does not exist. |
|
Sets the named flag for variable “X” to “value”. |
|
Appends “value” to the named flag on the variable “X”. Acts like
|
|
Prepends “value” to the named flag on the variable “X”. Acts like
|
|
Deletes the named flag on the variable “X” from the datastore. |
|
Sets the flags specified in the |
|
Returns a |
|
Deletes all the flags for the variable “X”. Does nothing if the variable “X” does not exist. |
|
Expands variable references in the specified string
expression. References to variables that do not exist are left as is. For
example, |
3.11.2 Other Functions
You can find many other functions that can be called from Python by
looking at the source code of the bb
module, which is in
bitbake/lib/bb
. For example, bitbake/lib/bb/utils.py
includes
the commonly used functions bb.utils.contains()
and
bb.utils.mkdirhier()
, which come with docstrings.
3.11.3 Extending Python Library Code
If you wish to add your own Python library code (e.g. to provide
functions/classes you can use from Python functions in the metadata)
you can do so from any layer using the addpylib
directive.
This directive is typically added to your layer configuration (
conf/layer.conf
) although it will be handled in any .conf
file.
Usage is of the form:
addpylib <directory> <namespace>
Where <directory> specifies the directory to add to the library path.
The specified <namespace> is imported automatically, and if the imported
module specifies an attribute named BBIMPORTS
, that list of
sub-modules is iterated and imported too.
3.11.4 Testing and Debugging BitBake Python code
The OpenEmbedded build system implements a convenient pydevshell
target which
you can use to access the BitBake datastore and experiment with your own Python
code. See Using a Python Development Shell in the Yocto
Project manual for details.
3.12 Task Checksums and Setscene
BitBake uses checksums (or signatures) along with the setscene to determine if a task needs to be run. This section describes the process. To help understand how BitBake does this, the section assumes an OpenEmbedded metadata-based example.
These checksums are stored in STAMP. You can examine the checksums using the following BitBake command:
$ bitbake-dumpsigs
This command returns the signature data in a readable
format that allows you to examine the inputs used when the OpenEmbedded
build system generates signatures. For example, using
bitbake-dumpsigs
allows you to examine the do_compile
task’s
“sigdata” for a C application (e.g. bash
). Running the command also
reveals that the “CC” variable is part of the inputs that are hashed.
Any changes to this variable would invalidate the stamp and cause the
do_compile
task to run.
The following list describes related variables:
BB_HASHCHECK_FUNCTION: Specifies the name of the function to call during the “setscene” part of the task’s execution in order to validate the list of task hashes.
BB_SETSCENE_DEPVALID: Specifies a function BitBake calls that determines whether BitBake requires a setscene dependency to be met.
BB_TASKHASH: Within an executing task, this variable holds the hash of the task as returned by the currently enabled signature generator.
STAMP: The base path to create stamp files.
STAMPCLEAN: Again, the base path to create stamp files but can use wildcards for matching a range of files for clean operations.
3.13 Wildcard Support in Variables
Support for wildcard use in variables varies depending on the context in
which it is used. For example, some variables and filenames allow
limited use of wildcards through the “%
” and “*
” characters.
Other variables or names support Python’s
glob syntax,
fnmatch
syntax, or
Regular Expression (re)
syntax.
For variables that have wildcard suport, the documentation describes which form of wildcard, its use, and its limitations.
4 Variable Context
Variables might only have an impact or can be used in certain contexts. Some
should only be used in global files like .conf
, while others are intended only
for local files like .bb
. This chapter aims to describe some important variable
contexts.
4.1 BitBake’s own configuration
Variables starting with BB_
usually configure the behaviour of BitBake itself.
For example, one could configure:
System resources, like disk space to be used (BB_DISKMON_DIRS), or the number of tasks to be run in parallel by BitBake (BB_NUMBER_THREADS).
How the fetchers shall behave, e.g., BB_FETCH_PREMIRRORONLY is used by BitBake to determine if BitBake’s fetcher shall search only PREMIRRORS for files.
Those variables are usually configured globally.
4.2 BitBake configuration
There are variables:
Like B or T, that are used to specify directories used by BitBake during the build of a particular recipe. Those variables are specified in
bitbake.conf
. Some, like B, are quite often overwritten in recipes.Starting with
FAKEROOT
, to configure how thefakeroot
command is handled. Those are usually set bybitbake.conf
and might get adapted in abbclass
.Detailing where BitBake will store and fetch information from, for data reuse between build runs like CACHE, DL_DIR or PERSISTENT_DIR. Those are usually global.
4.3 Layers and files
Variables starting with LAYER
configure how BitBake handles layers.
Additionally, variables starting with BB
configure how layers and files are
handled. For example:
LAYERDEPENDS is used to configure on which layers a given layer depends.
The configured layers are contained in BBLAYERS and files in BBFILES.
Those variables are often used in the files layer.conf
and bblayers.conf
.
4.4 Recipes and packages
Variables handling recipes and packages can be split into:
PN, PV or PF for example, contain information about the name or revision of a recipe or package. Usually, the default set in
bitbake.conf
is used, but those are from time to time overwritten in recipes.SUMMARY, DESCRIPTION, LICENSE or HOMEPAGE contain the expected information and should be set specifically for every recipe.
In recipes, variables are also used to control build and runtime dependencies between recipes/packages with other recipes/packages. The most common should be: PROVIDES, RPROVIDES, DEPENDS, and RDEPENDS.
There are further variables starting with
SRC
that specify the sources in a recipe like SRC_URI or SRCDATE. Those are also usually set in recipes.Which version or provider of a recipe should be given preference when multiple recipes would provide the same item, is controlled by variables starting with
PREFERRED_
. Those are normally set in the configuration files of aMACHINE
orDISTRO
.
5 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.
5.1 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
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 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 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:
https://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/ \
cvs://.*/.\* http://somemirror.org/sources/ \
git://.*/.\* http://somemirror.org/sources/ \
hg://.*/.\* http://somemirror.org/sources/ \
osc://.*/.\* http://somemirror.org/sources/ \
p4://.*/.\* http://somemirror.org/sources/ \
svn://.*/.\* http://somemirror.org/sources/"
MIRRORS =+ "\
ftp://.*/.\* http://somemirror.org/sources/ \
http://.*/.\* http://somemirror.org/sources/ \
https://.*/.\* http://somemirror.org/sources/"
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 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 is set, any download without a checksum triggers an error message. The 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.
If BB_CHECK_SSL_CERTS is set to 0
then SSL certificate checking will
be disabled. This variable defaults to 1
so SSL certificates are normally
checked.
5.2 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.striplevel: Strip specified number of leading components (levels) from file names on extraction
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.
5.3 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.
5.3.1 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 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 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"
5.3.2 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 when dealing with multiple files that
have the same name.
If a username and password are specified in the SRC_URI
, a Basic
Authorization header will be added to each request, including across redirects.
To instead limit the Authorization header to the first request, add
“redirectauth=0” to the list of parameters.
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"
5.3.3 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: 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 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.
“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"
5.3.4 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, 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"
5.3.5 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, 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”.
Note
When
protocol
is “ssh”, the URL expected in SRC_URI differs from the one that is typically passed togit clone
command and provided by the Git server to fetch from. For example, the URL returned by GitLab server formesa
when cloning over SSH isgit@gitlab.freedesktop.org:mesa/mesa.git
, however the expected URL in SRC_URI is the following:SRC_URI = "git://git@gitlab.freedesktop.org/mesa/mesa.git;branch=main;protocol=ssh;..."
Note the
:
character changed for a/
before the path to the project.“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 any namespace (branch, 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. Unless “nobranch” is set to “1”, this is a mandatory parameter. The number of branch parameters must 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 withAUTOREV
. The “usehead” parameter implies no branch and only works when the transfer protocol isfile://
.
Here are some example URLs:
SRC_URI = "git://github.com/fronteed/icheck.git;protocol=https;branch=${PV};tag=${PV}"
SRC_URI = "git://github.com/asciidoc/asciidoc-py;protocol=https;branch=main"
SRC_URI = "git://git@gitlab.freedesktop.org/mesa/mesa.git;branch=main;protocol=ssh;..."
Note
When using git
as the fetcher of the main source code of your software,
S
should be set accordingly:
S = "${WORKDIR}/git"
Note
Specifying passwords directly in git://
urls is not supported.
There are several reasons: SRC_URI is often written out to logs and
other places, and that could easily leak passwords; it is also all too
easy to share metadata without removing passwords. SSH keys, ~/.netrc
and ~/.ssh/config
files can be used as alternatives.
Using tags with the git fetcher may cause surprising behaviour. Bitbake needs to resolve the tag to a specific revision and to do that, it has to connect to and use the upstream repository. This is because the revision the tags point at can change and we’ve seen cases of this happening in well known public repositories. This can mean many more network connections than expected and recipes may be reparsed at every build. Source mirrors will also be bypassed as the upstream repository is the only source of truth to resolve the revision accurately. For these reasons, whilst the fetcher can support tags, we recommend being specific about revisions in recipes.
5.3.6 Git Submodule Fetcher (gitsm://
)
This fetcher submodule inherits from the Git fetcher and extends that fetcher’s behavior by fetching a repository’s submodules. SRC_URI is passed to the Git fetcher as described in the Git Fetcher (git://) 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.
5.3.7 ClearCase Fetcher (ccrc://
)
This fetcher submodule fetches code from a ClearCase repository.
To use this fetcher, make sure your recipe has proper SRC_URI, SRCREV, and 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
orhttps
.
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 ofcleartool
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.
5.3.8 Perforce Fetcher (p4://
)
This fetcher submodule fetches code from the
Perforce 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, 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, SRCREV, and
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 themodule
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/
.
5.3.9 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, which is usually
${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"
5.3.10 Az Fetcher (az://
)
This submodule fetches data from an Azure Storage account , it inherits its functionality from the HTTP wget fetcher, but modifies its behavior to accomodate the usage of a Shared Access Signature (SAS) for non-public data.
Such functionality is set by the variable:
AZ_SAS: The Azure Storage Shared Access Signature provides secure delegate access to resources, if this variable is set, the Az Fetcher will use it when fetching artifacts from the cloud.
You can specify the AZ_SAS variable as shown below:
AZ_SAS = "se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"
Here is an example URL:
SRC_URI = "az://<azure-storage-account>.blob.core.windows.net/<foo_container>/<bar_file>"
It can also be used when setting mirrors definitions using the PREMIRRORS variable.
5.3.11 GCP Fetcher (gs://
)
This submodule fetches data from a Google Cloud Storage Bucket. It uses the Google Cloud Storage Python Client to check the status of objects in the bucket and download them. The use of the Python client makes it substantially faster than using command line tools such as gsutil.
The fetcher requires the Google Cloud Storage Python Client to be installed, along with the gsutil tool.
The fetcher requires that the machine has valid credentials for accessing the chosen bucket. Instructions for authentication can be found in the Google Cloud documentation.
If it used from the OpenEmbedded build system, the fetcher can be used for
fetching sstate artifacts from a GCS bucket by specifying the
SSTATE_MIRRORS
variable as shown below:
SSTATE_MIRRORS ?= "\
file://.* gs://<bucket name>/PATH \
"
The fetcher can also be used in recipes:
SRC_URI = "gs://<bucket name>/<foo_container>/<bar_file>"
However, the checksum of the file should be also be provided:
SRC_URI[sha256sum] = "<sha256 string>"
5.3.12 Crate Fetcher (crate://
)
This submodule fetches code for Rust language “crates” corresponding to Rust libraries and programs to compile. Such crates are typically shared on https://crates.io/ but this fetcher supports other crate registries too.
The format for the SRC_URI setting must be:
SRC_URI = "crate://REGISTRY/NAME/VERSION"
Here is an example URL:
SRC_URI = "crate://crates.io/glob/0.2.11"
5.3.13 NPM Fetcher (npm://
)
This submodule fetches source code from an NPM Javascript package registry.
The format for the SRC_URI setting must be:
SRC_URI = "npm://some.registry.url;ParameterA=xxx;ParameterB=xxx;..."
This fetcher supports the following parameters:
“package”: The NPM package name. This is a mandatory parameter.
“version”: The NPM package version. This is a mandatory parameter.
“downloadfilename”: Specifies the filename used when storing the downloaded file.
“destsuffix”: Specifies the directory to use to unpack the package (default:
npm
).
Note that NPM fetcher only fetches the package source itself. The dependencies can be fetched through the npmsw-fetcher.
Here is an example URL with both fetchers:
SRC_URI = " \
npm://registry.npmjs.org/;package=cute-files;version=${PV} \
npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
"
See Creating Node Package Manager (NPM) Packages in the Yocto Project manual for details about using devtool to automatically create a recipe from an NPM URL.
5.3.14 NPM shrinkwrap Fetcher (npmsw://
)
This submodule fetches source code from an NPM shrinkwrap description file, which lists the dependencies of an NPM package while locking their versions.
The format for the SRC_URI setting must be:
SRC_URI = "npmsw://some.registry.url;ParameterA=xxx;ParameterB=xxx;..."
This fetcher supports the following parameters:
“dev”: Set this parameter to
1
to install “devDependencies”.“destsuffix”: Specifies the directory to use to unpack the dependencies (
${S}
by default).
Note that the shrinkwrap file can also be provided by the recipe for the package which has such dependencies, for example:
SRC_URI = " \
npm://registry.npmjs.org/;package=cute-files;version=${PV} \
npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
"
Such a file can automatically be generated using devtool as described in the Creating Node Package Manager (NPM) Packages section of the Yocto Project.
5.3.15 Other Fetchers
Fetch submodules also exist for the following:
Bazaar (
bzr://
)Mercurial (
hg://
)OSC (
osc://
)S3 (
s3://
)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.
5.4 Auto Revisions
We need to document AUTOREV
and SRCREV_FORMAT here.
6 Variables Glossary
This chapter lists common variables used by BitBake and gives an overview of their function and contents.
Note
Following are some points regarding the variables listed in this glossary:
The variables listed in this glossary are specific to BitBake. Consequently, the descriptions are limited to that context.
Also, variables exist in other systems that use BitBake (e.g. The Yocto Project and OpenEmbedded) that have names identical to those found in this glossary. For such cases, the variables in those systems extend the functionality of the variable as it is described here in this glossary.
- ASSUME_PROVIDED
Lists recipe names (PN values) BitBake does not attempt to build. Instead, BitBake assumes these recipes have already been built.
In OpenEmbedded-Core, ASSUME_PROVIDED mostly specifies native tools that should not be built. An example is
git-native
, which when specified allows for the Git binary from the host to be used rather than buildinggit-native
.- AZ_SAS
Azure Storage Shared Access Signature, when using the Azure Storage fetcher This variable can be defined to be used by the fetcher to authenticate and gain access to non-public artifacts:
AZ_SAS = ""se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>""
For more information see Microsoft’s Azure Storage documentation at https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview
- B
The directory in which BitBake executes functions during a recipe’s build process.
- BB_ALLOWED_NETWORKS
Specifies a space-delimited list of hosts that the fetcher is allowed to use to obtain the required source code. Following are considerations surrounding this variable:
This host list is only used if BB_NO_NETWORK is either not set or set to “0”.
Limited support for the “
*
” wildcard character for matching against the beginning of host names exists. For example, the following setting matchesgit.gnu.org
,ftp.gnu.org
, andfoo.git.gnu.org
.BB_ALLOWED_NETWORKS = "\*.gnu.org"
Important
The use of the “
*
” character only works at the beginning of a host name and it must be isolated from the remainder of the host name. You cannot use the wildcard character in any other location of the name or combined with the front part of the name.For example,
*.foo.bar
is supported, while*aa.foo.bar
is not.Mirrors not in the host list are skipped and logged in debug.
Attempts to access networks not in the host list cause a failure.
Using BB_ALLOWED_NETWORKS in conjunction with PREMIRRORS is very useful. Adding the host you want to use to PREMIRRORS results in the source code being fetched from an allowed location and avoids raising an error when a host that is not allowed is in a SRC_URI statement. This is because the fetcher does not attempt to use the host listed in SRC_URI after a successful fetch from the PREMIRRORS occurs.
- BB_BASEHASH_IGNORE_VARS
Lists variables that are excluded from checksum and dependency data. Variables that are excluded can therefore change without affecting the checksum mechanism. A common example would be the variable for the path of the build. BitBake’s output should not (and usually does not) depend on the directory in which it was built.
- BB_CACHEDIR
Specifies the code parser cache directory (distinct from CACHE and PERSISTENT_DIR although they can be set to the same value if desired). The default value is “${TOPDIR}/cache”.
- BB_CHECK_SSL_CERTS
Specifies if SSL certificates should be checked when fetching. The default value is
1
and certificates are not checked if the value is set to0
.- BB_CONSOLELOG
Specifies the path to a log file into which BitBake’s user interface writes output during the build.
- BB_CURRENTTASK
Contains the name of the currently running task. The name does not include the
do_
prefix.- BB_DANGLINGAPPENDS_WARNONLY
Defines how BitBake handles situations where an append file (
.bbappend
) has no corresponding recipe file (.bb
). This condition often occurs when layers get out of sync (e.g.oe-core
bumps a recipe version and the old recipe no longer exists and the other layer has not been updated to the new version of the recipe yet).The default fatal behavior is safest because it is the sane reaction given something is out of sync. It is important to realize when your changes are no longer being applied.
- BB_DEFAULT_TASK
The default task to use when none is specified (e.g. with the
-c
command line option). The task name specified should not include thedo_
prefix.- BB_DEFAULT_UMASK
The default umask to apply to tasks if specified and no task specific umask flag is set.
- BB_DISKMON_DIRS
Monitors disk space and available inodes during the build and allows you to control the build based on these parameters.
Disk space monitoring is disabled by default. When setting this variable, use the following form:
BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" where: <action> is: HALT: Immediately halt the build when a threshold is broken. STOPTASKS: Stop the build after the currently executing tasks have finished when a threshold is broken. WARN: Issue a warning but continue the build when a threshold is broken. Subsequent warnings are issued as defined by the BB_DISKMON_WARNINTERVAL variable, which must be defined. <dir> is: Any directory you choose. You can specify one or more directories to monitor by separating the groupings with a space. If two directories are on the same device, only the first directory is monitored. <threshold> is: Either the minimum available disk space, the minimum number of free inodes, or both. You must specify at least one. To omit one or the other, simply omit the value. Specify the threshold using G, M, K for Gbytes, Mbytes, and Kbytes, respectively. If you do not specify G, M, or K, Kbytes is assumed by default. Do not use GB, MB, or KB.
Here are some examples:
BB_DISKMON_DIRS = "HALT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" BB_DISKMON_DIRS = "HALT,${TMPDIR},,100K"
The first example works only if you also set the BB_DISKMON_WARNINTERVAL variable. This example causes the build system to immediately halt when either the disk space in
${TMPDIR}
drops below 1 Gbyte or the available free inodes drops below 100 Kbytes. Because two directories are provided with the variable, the build system also issues a warning when the disk space in the${SSTATE_DIR}
directory drops below 1 Gbyte or the number of free inodes drops below 100 Kbytes. Subsequent warnings are issued during intervals as defined by the BB_DISKMON_WARNINTERVAL variable.The second example stops the build after all currently executing tasks complete when the minimum disk space in the
${TMPDIR}
directory drops below 1 Gbyte. No disk monitoring occurs for the free inodes in this case.The final example immediately halts the build when the number of free inodes in the
${TMPDIR}
directory drops below 100 Kbytes. No disk space monitoring for the directory itself occurs in this case.- BB_DISKMON_WARNINTERVAL
Defines the disk space and free inode warning intervals.
If you are going to use the BB_DISKMON_WARNINTERVAL variable, you must also use the BB_DISKMON_DIRS variable and define its action as “WARN”. During the build, subsequent warnings are issued each time disk space or number of free inodes further reduces by the respective interval.
If you do not provide a BB_DISKMON_WARNINTERVAL variable and you do use BB_DISKMON_DIRS with the “WARN” action, the disk monitoring interval defaults to the following: BB_DISKMON_WARNINTERVAL = “50M,5K”
When specifying the variable in your configuration file, use the following form:
BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" where: <disk_space_interval> is: An interval of memory expressed in either G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB. <disk_inode_interval> is: An interval of free inodes expressed in either G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB.
Here is an example:
BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_WARNINTERVAL = "50M,5K"
These variables cause BitBake to issue subsequent warnings each time the available disk space further reduces by 50 Mbytes or the number of free inodes further reduces by 5 Kbytes in the
${SSTATE_DIR}
directory. Subsequent warnings based on the interval occur each time a respective interval is reached beyond the initial warning (i.e. 1 Gbytes and 100 Kbytes).- BB_ENV_PASSTHROUGH
Specifies the internal list of variables to allow through from the external environment into BitBake’s datastore. If the value of this variable is not specified (which is the default), the following list is used: BBPATH, BB_PRESERVE_ENV, BB_ENV_PASSTHROUGH, and BB_ENV_PASSTHROUGH_ADDITIONS.
Note
You must set this variable in the external environment in order for it to work.
- BB_ENV_PASSTHROUGH_ADDITIONS
Specifies an additional set of variables to allow through from the external environment into BitBake’s datastore. This list of variables are on top of the internal list set in BB_ENV_PASSTHROUGH.
Note
You must set this variable in the external environment in order for it to work.
- BB_FETCH_PREMIRRORONLY
When set to “1”, causes BitBake’s fetcher module to only search PREMIRRORS for files. BitBake will not search the main SRC_URI or MIRRORS.
- BB_FILENAME
Contains the filename of the recipe that owns the currently running task. For example, if the
do_fetch
task that resides in themy-recipe.bb
is executing, the BB_FILENAME variable contains “/foo/path/my-recipe.bb”.- BB_GENERATE_MIRROR_TARBALLS
Causes tarballs of the Git repositories, including the Git metadata, to be placed in the DL_DIR directory. Anyone wishing to create a source mirror would want to enable this variable.
For performance reasons, creating and placing tarballs of the Git repositories is not the default action by BitBake.
BB_GENERATE_MIRROR_TARBALLS = "1"
- BB_GENERATE_SHALLOW_TARBALLS
Setting this variable to “1” when BB_GIT_SHALLOW is also set to “1” causes bitbake to generate shallow mirror tarballs when fetching git repositories. The number of commits included in the shallow mirror tarballs is controlled by BB_GIT_SHALLOW_DEPTH.
If both BB_GIT_SHALLOW and BB_GENERATE_MIRROR_TARBALLS are enabled, bitbake will generate shallow mirror tarballs by default for git repositories. This separate variable exists so that shallow tarball generation can be enabled without needing to also enable normal mirror generation if it is not desired.
For example usage, see BB_GIT_SHALLOW.
- BB_GIT_SHALLOW
Setting this variable to “1” enables the support for fetching, using and generating mirror tarballs of shallow git repositories. The external git-make-shallow script is used for shallow mirror tarball creation.
When BB_GIT_SHALLOW is enabled, bitbake will attempt to fetch a shallow mirror tarball. If the shallow mirror tarball cannot be fetched, it will try to fetch the full mirror tarball and use that.
When a mirror tarball is not available, a full git clone will be performed regardless of whether this variable is set or not. Support for shallow clones is not currently implemented as git does not directly support shallow cloning a particular git commit hash (it only supports cloning from a tag or branch reference).
See also BB_GIT_SHALLOW_DEPTH and BB_GENERATE_SHALLOW_TARBALLS.
Example usage:
BB_GIT_SHALLOW ?= "1" # Keep only the top commit BB_GIT_SHALLOW_DEPTH ?= "1" # This defaults to enabled if both BB_GIT_SHALLOW and # BB_GENERATE_MIRROR_TARBALLS are enabled BB_GENERATE_SHALLOW_TARBALLS ?= "1"
- BB_GIT_SHALLOW_DEPTH
When used with BB_GENERATE_SHALLOW_TARBALLS, this variable sets the number of commits to include in generated shallow mirror tarballs. With a depth of 1, only the commit referenced in SRCREV is included in the shallow mirror tarball. Increasing the depth includes additional parent commits, working back through the commit history.
If this variable is unset, bitbake will default to a depth of 1 when generating shallow mirror tarballs.
For example usage, see BB_GIT_SHALLOW.
- BB_GLOBAL_PYMODULES
Specifies the list of Python modules to place in the global namespace. It is intended that only the core layer should set this and it is meant to be a very small list, typically just
os
andsys
. BB_GLOBAL_PYMODULES is expected to be set before the firstaddpylib
directive. See also “Extending Python Library Code”.- BB_HASH_CODEPARSER_VALS
Specifies values for variables to use when populating the codeparser cache. This can be used selectively to set dummy values for variables to avoid the codeparser cache growing on every parse. Variables that would typically be included are those where the value is not significant for where the codeparser cache is used (i.e. when calculating variable dependencies for code fragments.) The value is space-separated without quoting values, for example:
BB_HASH_CODEPARSER_VALS = "T=/ WORKDIR=/ DATE=1234 TIME=1234"
- BB_HASHCHECK_FUNCTION
Specifies the name of the function to call during the “setscene” part of the task’s execution in order to validate the list of task hashes. The function returns the list of setscene tasks that should be executed.
At this point in the execution of the code, the objective is to quickly verify if a given setscene function is likely to work or not. It’s easier to check the list of setscene functions in one pass than to call many individual tasks. The returned list need not be completely accurate. A given setscene task can still later fail. However, the more accurate the data returned, the more efficient the build will be.
- BB_HASHCONFIG_IGNORE_VARS
Lists variables that are excluded from base configuration checksum, which is used to determine if the cache can be reused.
One of the ways BitBake determines whether to re-parse the main metadata is through checksums of the variables in the datastore of the base configuration data. There are variables that you typically want to exclude when checking whether or not to re-parse and thus rebuild the cache. As an example, you would usually exclude
TIME
andDATE
because these variables are always changing. If you did not exclude them, BitBake would never reuse the cache.- BB_HASHSERVE
Specifies the Hash Equivalence server to use.
If set to
auto
, BitBake automatically starts its own server over a UNIX domain socket. An option is to connect this server to an upstream one, by setting BB_HASHSERVE_UPSTREAM.If set to
unix://path
, BitBake will connect to an existing hash server available over a UNIX domain socket.If set to
host:port
, BitBake will connect to a remote server on the specified host. This allows multiple clients to share the same hash equivalence data.The remote server can be started manually through the
bin/bitbake-hashserv
script provided by BitBake, which supports UNIX domain sockets too. This script also allows to start the server in read-only mode, to avoid accepting equivalences that correspond to Share State caches that are only available on specific clients.- BB_HASHSERVE_UPSTREAM
Specifies an upstream Hash Equivalence server.
This optional setting is only useful when a local Hash Equivalence server is started (setting BB_HASHSERVE to
auto
), and you wish the local server to query an upstream server for Hash Equivalence data.Example usage:
BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
- BB_INVALIDCONF
Used in combination with the
ConfigParsed
event to trigger re-parsing the base metadata (i.e. all the recipes). TheConfigParsed
event can set the variable to trigger the re-parse. You must be careful to avoid recursive loops with this functionality.- BB_LOADFACTOR_MAX
Setting this to a value will cause BitBake to check the system load average before executing new tasks. If the load average is above the the number of CPUs multipled by this factor, no new task will be started unless there is no task executing. A value of “1.5” has been found to work reasonably. This is helpful for systems which don’t have pressure regulation enabled, which is more granular. Pressure values take precedence over loadfactor.
- BB_LOGCONFIG
Specifies the name of a config file that contains the user logging configuration. See Logging for additional information
- BB_LOGFMT
Specifies the name of the log files saved into
${
T}
. By default, the BB_LOGFMT variable is undefined and the log filenames get created using the following form:log.{task}.{pid}
If you want to force log files to take a specific name, you can set this variable in a configuration file.
- BB_MULTI_PROVIDER_ALLOWED
Allows you to suppress BitBake warnings caused when building two separate recipes that provide the same output.
BitBake normally issues a warning when building two different recipes where each provides the same output. This scenario is usually something the user does not want. However, cases do exist where it makes sense, particularly in the
virtual/*
namespace. You can use this variable to suppress BitBake’s warnings.To use the variable, list provider names (e.g. recipe names,
virtual/kernel
, and so forth).- BB_NICE_LEVEL
Allows BitBake to run at a specific priority (i.e. nice level). System permissions usually mean that BitBake can reduce its priority but not raise it again. See BB_TASK_NICE_LEVEL for additional information.
- BB_NO_NETWORK
Disables network access in the BitBake fetcher modules. With this access disabled, any command that attempts to access the network becomes an error.
Disabling network access is useful for testing source mirrors, running builds when not connected to the Internet, and when operating in certain kinds of firewall environments.
- BB_NUMBER_PARSE_THREADS
Sets the number of threads BitBake uses when parsing. By default, the number of threads is equal to the number of cores on the system.
- BB_NUMBER_THREADS
The maximum number of tasks BitBake should run in parallel at any one time. If your host development system supports multiple cores, a good rule of thumb is to set this variable to twice the number of cores.
- BB_ORIGENV
Contains a copy of the original external environment in which BitBake was run. The copy is taken before any variable values configured to pass through from the external environment are filtered into BitBake’s datastore.
Note
The contents of this variable is a datastore object that can be queried using the normal datastore operations.
- BB_PRESERVE_ENV
Disables environment filtering and instead allows all variables through from the external environment into BitBake’s datastore.
Note
You must set this variable in the external environment in order for it to work.
- BB_PRESSURE_MAX_CPU
Specifies a maximum CPU pressure threshold, above which BitBake’s scheduler will not start new tasks (providing there is at least one active task). If no value is set, CPU pressure is not monitored when starting tasks.
The pressure data is calculated based upon what Linux kernels since version 4.20 expose under
/proc/pressure
. The threshold represents the difference in “total” pressure from the previous second. The minimum value is 1.0 (extremely slow builds) and the maximum is 1000000 (a pressure value unlikely to ever be reached).This threshold can be set in
conf/local.conf
as:BB_PRESSURE_MAX_CPU = "500"
- BB_PRESSURE_MAX_IO
Specifies a maximum I/O pressure threshold, above which BitBake’s scheduler will not start new tasks (providing there is at least one active task). If no value is set, I/O pressure is not monitored when starting tasks.
The pressure data is calculated based upon what Linux kernels since version 4.20 expose under
/proc/pressure
. The threshold represents the difference in “total” pressure from the previous second. The minimum value is 1.0 (extremely slow builds) and the maximum is 1000000 (a pressure value unlikely to ever be reached).At this point in time, experiments show that IO pressure tends to be short-lived and regulating just the CPU with BB_PRESSURE_MAX_CPU can help to reduce it.
- BB_PRESSURE_MAX_MEMORY
Specifies a maximum memory pressure threshold, above which BitBake’s scheduler will not start new tasks (providing there is at least one active task). If no value is set, memory pressure is not monitored when starting tasks.
The pressure data is calculated based upon what Linux kernels since version 4.20 expose under
/proc/pressure
. The threshold represents the difference in “total” pressure from the previous second. The minimum value is 1.0 (extremely slow builds) and the maximum is 1000000 (a pressure value unlikely to ever be reached).Memory pressure is experienced when time is spent swapping, refaulting pages from the page cache or performing direct reclaim. This is why memory pressure is rarely seen, but setting this variable might be useful as a last resort to prevent OOM errors if they are occurring during builds.
- BB_RUNFMT
Specifies the name of the executable script files (i.e. run files) saved into
${
T}
. By default, the BB_RUNFMT variable is undefined and the run filenames get created using the following form:run.{func}.{pid}
If you want to force run files to take a specific name, you can set this variable in a configuration file.
- BB_RUNTASK
Contains the name of the currently executing task. The value includes the “do_” prefix. For example, if the currently executing task is
do_config
, the value is “do_config”.- BB_SCHEDULER
Selects the name of the scheduler to use for the scheduling of BitBake tasks. Three options exist:
basic — the basic framework from which everything derives. Using this option causes tasks to be ordered numerically as they are parsed.
speed — executes tasks first that have more tasks depending on them. The “speed” option is the default.
completion — causes the scheduler to try to complete a given recipe once its build has started.
- BB_SCHEDULERS
Defines custom schedulers to import. Custom schedulers need to be derived from the
RunQueueScheduler
class.For information how to select a scheduler, see the BB_SCHEDULER variable.
- BB_SETSCENE_DEPVALID
Specifies a function BitBake calls that determines whether BitBake requires a setscene dependency to be met.
When running a setscene task, BitBake needs to know which dependencies of that setscene task also need to be run. Whether dependencies also need to be run is highly dependent on the metadata. The function specified by this variable returns a “True” or “False” depending on whether the dependency needs to be met.
- BB_SIGNATURE_EXCLUDE_FLAGS
Lists variable flags (varflags) that can be safely excluded from checksum and dependency data for keys in the datastore. When generating checksum or dependency data for keys in the datastore, the flags set against that key are normally included in the checksum.
For more information on varflags, see the “Variable Flags” section.
- BB_SIGNATURE_HANDLER
Defines the name of the signature handler BitBake uses. The signature handler defines the way stamp files are created and handled, if and how the signature is incorporated into the stamps, and how the signature itself is generated.
A new signature handler can be added by injecting a class derived from the
SignatureGenerator
class into the global namespace.- BB_SRCREV_POLICY
Defines the behavior of the fetcher when it interacts with source control systems and dynamic source revisions. The BB_SRCREV_POLICY variable is useful when working without a network.
The variable can be set using one of two policies:
cache — retains the value the system obtained previously rather than querying the source control system each time.
clear — queries the source controls system every time. With this policy, there is no cache. The “clear” policy is the default.
- BB_STRICT_CHECKSUM
Sets a more strict checksum mechanism for non-local URLs. Setting this variable to a value causes BitBake to report an error if it encounters a non-local URL that does not have at least one checksum specified.
- BB_TASK_IONICE_LEVEL
Allows adjustment of a task’s Input/Output priority. During Autobuilder testing, random failures can occur for tasks due to I/O starvation. These failures occur during various QEMU runtime timeouts. You can use the BB_TASK_IONICE_LEVEL variable to adjust the I/O priority of these tasks.
Note
This variable works similarly to the BB_TASK_NICE_LEVEL variable except with a task’s I/O priorities.
Set the variable as follows:
BB_TASK_IONICE_LEVEL = "class.prio"
For class, the default value is “2”, which is a best effort. You can use “1” for realtime and “3” for idle. If you want to use realtime, you must have superuser privileges.
For prio, you can use any value from “0”, which is the highest priority, to “7”, which is the lowest. The default value is “4”. You do not need any special privileges to use this range of priority values.
Note
In order for your I/O priority settings to take effect, you need the Completely Fair Queuing (CFQ) Scheduler selected for the backing block device. To select the scheduler, use the following command form where device is the device (e.g. sda, sdb, and so forth):
$ sudo sh -c "echo cfq > /sys/block/device/queu/scheduler"
- BB_TASK_NICE_LEVEL
Allows specific tasks to change their priority (i.e. nice level).
You can use this variable in combination with task overrides to raise or lower priorities of specific tasks. For example, on the Yocto Project autobuilder, QEMU emulation in images is given a higher priority as compared to build tasks to ensure that images do not suffer timeouts on loaded systems.
- BB_TASKHASH
Within an executing task, this variable holds the hash of the task as returned by the currently enabled signature generator.
- BB_VERBOSE_LOGS
Controls how verbose BitBake is during builds. If set, shell scripts echo commands and shell script output appears on standard out (stdout).
- BB_WORKERCONTEXT
Specifies if the current context is executing a task. BitBake sets this variable to “1” when a task is being executed. The value is not set when the task is in server context during parsing or event handling.
- BBCLASSEXTEND
Allows you to extend a recipe so that it builds variants of the software. Some examples of these variants for recipes from the OpenEmbedded-Core metadata are “natives” such as
quilt-native
, which is a copy of Quilt built to run on the build system; “crosses” such asgcc-cross
, which is a compiler built to run on the build machine but produces binaries that run on the targetMACHINE
; “nativesdk”, which targets the SDK machine instead ofMACHINE
; and “mulitlibs” in the form “multilib:
multilib_name”.To build a different variant of the recipe with a minimal amount of code, it usually is as simple as adding the variable to your recipe. Here are two examples. The “native” variants are from the OpenEmbedded-Core metadata:
BBCLASSEXTEND =+ "native nativesdk" BBCLASSEXTEND =+ "multilib:multilib_name"
Note
Internally, the BBCLASSEXTEND mechanism generates recipe variants by rewriting variable values and applying overrides such as
_class-native
. For example, to generate a native version of a recipe, a DEPENDS on “foo” is rewritten to a DEPENDS on “foo-native”.Even when using BBCLASSEXTEND, the recipe is only parsed once. Parsing once adds some limitations. For example, it is not possible to include a different file depending on the variant, since
include
statements are processed when the recipe is parsed.- BBDEBUG
Sets the BitBake debug output level to a specific value as incremented by the
-D
command line option.Note
You must set this variable in the external environment in order for it to work.
- BBFILE_COLLECTIONS
Lists the names of configured layers. These names are used to find the other
BBFILE_*
variables. Typically, each layer appends its name to this variable in itsconf/layer.conf
file.- BBFILE_PATTERN
Variable that expands to match files from BBFILES in a particular layer. This variable is used in the
conf/layer.conf
file and must be suffixed with the name of the specific layer (e.g.BBFILE_PATTERN_emenlow
).- BBFILE_PRIORITY
Assigns the priority for recipe files in each layer.
This variable is useful in situations where the same recipe appears in more than one layer. Setting this variable allows you to prioritize a layer against other layers that contain the same recipe — effectively letting you control the precedence for the multiple layers. The precedence established through this variable stands regardless of a recipe’s version (PV variable). For example, a layer that has a recipe with a higher PV value but for which the BBFILE_PRIORITY is set to have a lower precedence still has a lower precedence.
A larger value for the BBFILE_PRIORITY variable results in a higher precedence. For example, the value 6 has a higher precedence than the value 5. If not specified, the BBFILE_PRIORITY variable is set based on layer dependencies (see the LAYERDEPENDS variable for more information. The default priority, if unspecified for a layer with no dependencies, is the lowest defined priority + 1 (or 1 if no priorities are defined).
Tip
You can use the command bitbake-layers show-layers to list all configured layers along with their priorities.
- BBFILES
A space-separated list of recipe files BitBake uses to build software.
When specifying recipe files, you can pattern match using Python’s glob syntax. For details on the syntax, see the documentation by following the previous link.
- BBFILES_DYNAMIC
Activates content depending on presence of identified layers. You identify the layers by the collections that the layers define.
Use the BBFILES_DYNAMIC variable to avoid
.bbappend
files whose corresponding.bb
file is in a layer that attempts to modify other layers through.bbappend
but does not want to introduce a hard dependency on those other layers.Additionally you can prefix the rule with “!” to add
.bbappend
and.bb
files in case a layer is not present. Use this avoid hard dependency on those other layers.Use the following form for BBFILES_DYNAMIC:
collection_name:filename_pattern
The following example identifies two collection names and two filename patterns:
BBFILES_DYNAMIC += "\ clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ "
When the collection name is prefixed with “!” it will add the file pattern in case the layer is absent:
BBFILES_DYNAMIC += "\ !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \ "
This next example shows an error message that occurs because invalid entries are found, which cause parsing to fail:
ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not: /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
- BBINCLUDED
Contains a space-separated list of all of all files that BitBake’s parser included during parsing of the current file.
- BBINCLUDELOGS
If set to a value, enables printing the task log when reporting a failed task.
- BBINCLUDELOGS_LINES
If BBINCLUDELOGS is set, specifies the maximum number of lines from the task log file to print when reporting a failed task. If you do not set BBINCLUDELOGS_LINES, the entire log is printed.
- BBLAYERS
Lists the layers to enable during the build. This variable is defined in the
bblayers.conf
configuration file in the build directory. Here is an example:BBLAYERS = " \ /home/scottrif/poky/meta \ /home/scottrif/poky/meta-yocto \ /home/scottrif/poky/meta-yocto-bsp \ /home/scottrif/poky/meta-mykernel \ "
This example enables four layers, one of which is a custom, user-defined layer named
meta-mykernel
.- BBLAYERS_FETCH_DIR
Sets the base location where layers are stored. This setting is used in conjunction with
bitbake-layers layerindex-fetch
and tellsbitbake-layers
where to place the fetched layers.- BBMASK
Prevents BitBake from processing recipes and recipe append files.
You can use the BBMASK variable to “hide” these
.bb
and.bbappend
files. BitBake ignores any recipe or recipe append files that match any of the expressions. It is as if BitBake does not see them at all. Consequently, matching files are not parsed or otherwise used by BitBake.The values you provide are passed to Python’s regular expression compiler. Consequently, the syntax follows Python’s Regular Expression (re) syntax. The expressions are compared against the full paths to the files. For complete syntax information, see Python’s documentation at http://docs.python.org/3/library/re.html.
The following example uses a complete regular expression to tell BitBake to ignore all recipe and recipe append files in the
meta-ti/recipes-misc/
directory:BBMASK = "meta-ti/recipes-misc/"
If you want to mask out multiple directories or recipes, you can specify multiple regular expression fragments. This next example masks out multiple directories and individual recipes:
BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" BBMASK += "/meta-oe/recipes-support/" BBMASK += "/meta-foo/.*/openldap" BBMASK += "opencv.*\.bbappend" BBMASK += "lzma"
Note
When specifying a directory name, use the trailing slash character to ensure you match just that directory name.
- BBMULTICONFIG
Enables BitBake to perform multiple configuration builds and lists each separate configuration (multiconfig). You can use this variable to cause BitBake to build multiple targets where each target has a separate configuration. Define BBMULTICONFIG in your
conf/local.conf
configuration file.As an example, the following line specifies three multiconfigs, each having a separate configuration file:
BBMULTIFONFIG = "configA configB configC"
Each configuration file you use must reside in the build directory within a directory named
conf/multiconfig
(e.g. build_directory/conf/multiconfig/configA.conf
).For information on how to use BBMULTICONFIG in an environment that supports building targets with multiple configurations, see the “Executing a Multiple Configuration Build” section.
- BBPATH
A colon-separated list used by BitBake to locate class (
.bbclass
) and configuration (.conf
) files. This variable is analogous to thePATH
variable.If you run BitBake from a directory outside of the build directory, you must be sure to set BBPATH to point to the build directory. Set the variable as you would any environment variable and then run BitBake:
$ BBPATH="build_directory" $ export BBPATH $ bitbake target
- BBSERVER
Points to the server that runs memory-resident BitBake. The variable is only used when you employ memory-resident BitBake.
- BBTARGETS
Allows you to use a configuration file to add to the list of command-line target recipes you want to build.
- BITBAKE_UI
Used to specify the UI module to use when running BitBake. Using this variable is equivalent to using the
-u
command-line option.Note
You must set this variable in the external environment in order for it to work.
- BUILDNAME
A name assigned to the build. The name defaults to a datetime stamp of when the build was started but can be defined by the metadata.
- BZRDIR
The directory in which files checked out of a Bazaar system are stored.
- CACHE
Specifies the directory BitBake uses to store a cache of the metadata so it does not need to be parsed every time BitBake is started.
- CVSDIR
The directory in which files checked out under the CVS system are stored.
- DEFAULT_PREFERENCE
Specifies a weak bias for recipe selection priority.
The most common usage of this is variable is to set it to “-1” within a recipe for a development version of a piece of software. Using the variable in this way causes the stable version of the recipe to build by default in the absence of PREFERRED_VERSION being used to build the development version.
Note
The bias provided by DEFAULT_PREFERENCE is weak and is overridden by BBFILE_PRIORITY if that variable is different between two layers that contain different versions of the same recipe.
- DEPENDS
Lists a recipe’s build-time dependencies (i.e. other recipe files).
Consider this simple example for two recipes named “a” and “b” that produce similarly named packages. In this example, the DEPENDS statement appears in the “a” recipe:
DEPENDS = "b"
Here, the dependency is such that the
do_configure
task for recipe “a” depends on thedo_populate_sysroot
task of recipe “b”. This means anything that recipe “b” puts into sysroot is available when recipe “a” is configuring itself.For information on runtime dependencies, see the RDEPENDS variable.
- DESCRIPTION
A long description for the recipe.
- DL_DIR
The central download directory used by the build process to store downloads. By default, DL_DIR gets files suitable for mirroring for everything except Git repositories. If you want tarballs of Git repositories, use the BB_GENERATE_MIRROR_TARBALLS variable.
- EXCLUDE_FROM_WORLD
Directs BitBake to exclude a recipe from world builds (i.e.
bitbake world
). During world builds, BitBake locates, parses and builds all recipes found in every layer exposed in thebblayers.conf
configuration file.To exclude a recipe from a world build using this variable, set the variable to “1” in the recipe. Set it to “0” to add it back to world build.
Note
Recipes added to EXCLUDE_FROM_WORLD may still be built during a world build in order to satisfy dependencies of other recipes. Adding a recipe to EXCLUDE_FROM_WORLD only ensures that the recipe is not explicitly added to the list of build targets in a world build.
- FAKEROOT
Contains the command to use when running a shell script in a fakeroot environment. The FAKEROOT variable is obsolete and has been replaced by the other
FAKEROOT*
variables. See these entries in the glossary for more information.- FAKEROOTBASEENV
Lists environment variables to set when executing the command defined by FAKEROOTCMD that starts the bitbake-worker process in the fakeroot environment.
- FAKEROOTCMD
Contains the command that starts the bitbake-worker process in the fakeroot environment.
- FAKEROOTDIRS
Lists directories to create before running a task in the fakeroot environment.
- FAKEROOTENV
Lists environment variables to set when running a task in the fakeroot environment. For additional information on environment variables and the fakeroot environment, see the FAKEROOTBASEENV variable.
- FAKEROOTNOENV
Lists environment variables to set when running a task that is not in the fakeroot environment. For additional information on environment variables and the fakeroot environment, see the FAKEROOTENV variable.
- FETCHCMD
Defines the command the BitBake fetcher module executes when running fetch operations. You need to use an override suffix when you use the variable (e.g.
FETCHCMD_git
orFETCHCMD_svn
).- FILE
Points at the current file. BitBake sets this variable during the parsing process to identify the file being parsed. BitBake also sets this variable when a recipe is being executed to identify the recipe file.
- FILE_LAYERNAME
During parsing and task execution, this is set to the name of the layer containing the recipe file. Code can use this to identify which layer a recipe is from.
- FILESPATH
Specifies directories BitBake uses when searching for patches and files. The “local” fetcher module uses these directories when handling
file://
URLs. The variable behaves like a shellPATH
environment variable. The value is a colon-separated list of directories that are searched left-to-right in order.- GITDIR
The directory in which a local copy of a Git repository is stored when it is cloned.
- HGDIR
The directory in which files checked out of a Mercurial system are stored.
- HOMEPAGE
Website where more information about the software the recipe is building can be found.
- INHERIT
Causes the named class or classes to be inherited globally. Anonymous functions in the class or classes are not executed for the base configuration and in each individual recipe. The OpenEmbedded build system ignores changes to INHERIT in individual recipes.
For more information on INHERIT, see the “INHERIT Configuration Directive” section.
- LAYERDEPENDS
Lists the layers, separated by spaces, upon which this recipe depends. Optionally, you can specify a specific layer version for a dependency by adding it to the end of the layer name with a colon, (e.g. “anotherlayer:3” to be compared against LAYERVERSION
_anotherlayer
in this case). BitBake produces an error if any dependency is missing or the version numbers do not match exactly (if specified).You use this variable in the
conf/layer.conf
file. You must also use the specific layer name as a suffix to the variable (e.g.LAYERDEPENDS_mylayer
).- LAYERDIR
When used inside the
layer.conf
configuration file, this variable provides the path of the current layer. This variable is not available outside oflayer.conf
and references are expanded immediately when parsing of the file completes.- LAYERDIR_RE
When used inside the
layer.conf
configuration file, this variable provides the path of the current layer, escaped for use in a regular expression (BBFILE_PATTERN). This variable is not available outside oflayer.conf
and references are expanded immediately when parsing of the file completes.- LAYERSERIES_COMPAT
Lists the versions of the OpenEmbedded-Core (OE-Core) for which a layer is compatible. Using the LAYERSERIES_COMPAT variable allows the layer maintainer to indicate which combinations of the layer and OE-Core can be expected to work. The variable gives the system a way to detect when a layer has not been tested with new releases of OE-Core (e.g. the layer is not maintained).
To specify the OE-Core versions for which a layer is compatible, use this variable in your layer’s
conf/layer.conf
configuration file. For the list, use the Yocto Project release name (e.g. “kirkstone”, “mickledore”). To specify multiple OE-Core versions for the layer, use a space-separated list:LAYERSERIES_COMPAT_layer_root_name = "kirkstone mickledore"
Note
Setting LAYERSERIES_COMPAT is required by the Yocto Project Compatible version 2 standard. The OpenEmbedded build system produces a warning if the variable is not set for any given layer.
- LAYERVERSION
Optionally specifies the version of a layer as a single number. You can use this variable within LAYERDEPENDS for another layer in order to depend on a specific version of the layer.
You use this variable in the
conf/layer.conf
file. You must also use the specific layer name as a suffix to the variable (e.g.LAYERDEPENDS_mylayer
).- LICENSE
The list of source licenses for the recipe.
- MIRRORS
Specifies additional paths from which BitBake gets source code. When the build system searches for source code, it first tries the local download directory. If that location fails, the build system tries locations defined by PREMIRRORS, the upstream source, and then locations specified by MIRRORS in that order.
- OVERRIDES
A colon-separated list that BitBake uses to control what variables are overridden after BitBake parses recipes and configuration files.
Following is a simple example that uses an overrides list based on machine architectures: OVERRIDES = “arm:x86:mips:powerpc” You can find information on how to use OVERRIDES in the “Conditional Syntax (Overrides)” section.
- P4DIR
The directory in which a local copy of a Perforce depot is stored when it is fetched.
- PACKAGES
The list of packages the recipe creates.
- PACKAGES_DYNAMIC
A promise that your recipe satisfies runtime dependencies for optional modules that are found in other recipes. PACKAGES_DYNAMIC does not actually satisfy the dependencies, it only states that they should be satisfied. For example, if a hard, runtime dependency (RDEPENDS) of another package is satisfied during the build through the PACKAGES_DYNAMIC variable, but a package with the module name is never actually produced, then the other package will be broken.
- PE
The epoch of the recipe. By default, this variable is unset. The variable is used to make upgrades possible when the versioning scheme changes in some backwards incompatible way.
- PERSISTENT_DIR
Specifies the directory BitBake uses to store data that should be preserved between builds. In particular, the data stored is the data that uses BitBake’s persistent data API and the data used by the PR Server and PR Service.
- PF
Specifies the recipe or package name and includes all version and revision numbers (i.e.
eglibc-2.13-r20+svnr15508/
andbash-4.2-r1/
).- PN
The recipe name.
- PR
The revision of the recipe.
- PREFERRED_PROVIDER
Determines which recipe should be given preference when multiple recipes provide the same item. You should always suffix the variable with the name of the provided item, and you should set it to the PN of the recipe to which you want to give precedence. Some examples:
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
- PREFERRED_PROVIDERS
Determines which recipe should be given preference for cases where multiple recipes provide the same item. Functionally, PREFERRED_PROVIDERS is identical to PREFERRED_PROVIDER. However, the PREFERRED_PROVIDERS variable lets you define preferences for multiple situations using the following form:
PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."
This form is a convenient replacement for the following:
PREFERRED_PROVIDER_xxx = "yyy" PREFERRED_PROVIDER_aaa = "bbb"
- PREFERRED_VERSION
If there are multiple versions of a recipe available, this variable determines which version should be given preference. You must always suffix the variable with the PN you want to select, and you should set PV accordingly for precedence.
The PREFERRED_VERSION variable supports limited wildcard use through the “
%
” character. You can use the character to match any number of characters, which can be useful when specifying versions that contain long revision numbers that potentially change. Here are two examples:PREFERRED_VERSION_python = "2.7.3" PREFERRED_VERSION_linux-yocto = "4.12%"
Important
The use of the “ % “ character is limited in that it only works at the end of the string. You cannot use the wildcard character in any other location of the string.
If a recipe with the specified version is not available, a warning message will be shown. See REQUIRED_VERSION if you want this to be an error instead.
- PREMIRRORS
Specifies additional paths from which BitBake gets source code. When the build system searches for source code, it first tries the local download directory. If that location fails, the build system tries locations defined by PREMIRRORS, the upstream source, and then locations specified by MIRRORS in that order.
Typically, you would add a specific server for the build system to attempt before any others by adding something like the following to your configuration:
PREMIRRORS:prepend = "\ git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ ftp://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ http://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ https://.*/.* http://downloads.yoctoproject.org/mirror/sources/"
These changes cause the build system to intercept Git, FTP, HTTP, and HTTPS requests and direct them to the
http://
sources mirror. You can usefile://
URLs to point to local directories or network shares as well.- PROVIDES
A list of aliases by which a particular recipe can be known. By default, a recipe’s own PN is implicitly already in its PROVIDES list. If a recipe uses PROVIDES, the additional aliases are synonyms for the recipe and can be useful satisfying dependencies of other recipes during the build as specified by DEPENDS.
Consider the following example PROVIDES statement from a recipe file
libav_0.8.11.bb
:PROVIDES += "libpostproc"
The PROVIDES statement results in the “libav” recipe also being known as “libpostproc”.
In addition to providing recipes under alternate names, the PROVIDES mechanism is also used to implement virtual targets. A virtual target is a name that corresponds to some particular functionality (e.g. a Linux kernel). Recipes that provide the functionality in question list the virtual target in PROVIDES. Recipes that depend on the functionality in question can include the virtual target in DEPENDS to leave the choice of provider open.
Conventionally, virtual targets have names on the form “virtual/function” (e.g. “virtual/kernel”). The slash is simply part of the name and has no syntactical significance.
- PRSERV_HOST
The network based PR service host and port.
Following is an example of how the PRSERV_HOST variable is set:
PRSERV_HOST = "localhost:0"
You must set the variable if you want to automatically start a local PR service. You can set PRSERV_HOST to other values to use a remote PR service.
- PV
The version of the recipe.
- RDEPENDS
Lists a package’s runtime dependencies (i.e. other packages) that must be installed in order for the built package to run correctly. If a package in this list cannot be found during the build, you will get a build error.
Because the RDEPENDS variable applies to packages being built, you should always use the variable in a form with an attached package name. For example, suppose you are building a development package that depends on the
perl
package. In this case, you would use the following RDEPENDS statement:RDEPENDS:${PN}-dev += "perl"
In the example, the development package depends on the
perl
package. Thus, the RDEPENDS variable has the${PN}-dev
package name as part of the variable.BitBake supports specifying versioned dependencies. Although the syntax varies depending on the packaging format, BitBake hides these differences from you. Here is the general syntax to specify versions with the RDEPENDS variable:
RDEPENDS:${PN} = "package (operator version)"
For
operator
, you can specify the following:= < > <= >=
For example, the following sets up a dependency on version 1.2 or greater of the package
foo
:RDEPENDS:${PN} = "foo (>= 1.2)"
For information on build-time dependencies, see the DEPENDS variable.
- REPODIR
The directory in which a local copy of a
google-repo
directory is stored when it is synced.- REQUIRED_VERSION
If there are multiple versions of a recipe available, this variable determines which version should be given preference. REQUIRED_VERSION works in exactly the same manner as PREFERRED_VERSION, except that if the specified version is not available then an error message is shown and the build fails immediately.
If both REQUIRED_VERSION and PREFERRED_VERSION are set for the same recipe, the REQUIRED_VERSION value applies.
- RPROVIDES
A list of package name aliases that a package also provides. These aliases are useful for satisfying runtime dependencies of other packages both during the build and on the target (as specified by RDEPENDS).
As with all package-controlling variables, you must always use the variable in conjunction with a package name override. Here is an example:
RPROVIDES:${PN} = "widget-abi-2"
- RRECOMMENDS
A list of packages that extends the usability of a package being built. The package being built does not depend on this list of packages in order to successfully build, but needs them for the extended usability. To specify runtime dependencies for packages, see the RDEPENDS variable.
BitBake supports specifying versioned recommends. Although the syntax varies depending on the packaging format, BitBake hides these differences from you. Here is the general syntax to specify versions with the RRECOMMENDS variable:
RRECOMMENDS:${PN} = "package (operator version)"
For
operator
, you can specify the following:= < > <= >=
For example, the following sets up a recommend on version 1.2 or greater of the package
foo
:RRECOMMENDS:${PN} = "foo (>= 1.2)"
- SECTION
The section in which packages should be categorized.
- SRC_URI
The list of source files — local or remote. This variable tells BitBake which bits to pull for the build and how to pull them. For example, if the recipe or append file needs to fetch a single tarball from the Internet, the recipe or append file uses a SRC_URI entry that specifies that tarball. On the other hand, if the recipe or append file needs to fetch a tarball, apply two patches, and include a custom file, the recipe or append file needs an SRC_URI variable that specifies all those sources.
The following list explains the available URI protocols. URI protocols are highly dependent on particular BitBake Fetcher submodules. Depending on the fetcher BitBake uses, various URL parameters are employed. For specifics on the supported Fetchers, see the Fetchers section.
az://
: Fetches files from an Azure Storage account using HTTPS.bzr://
: Fetches files from a Bazaar revision control repository.ccrc://
: Fetches files from a ClearCase repository.cvs://
: Fetches files from a CVS revision control repository.file://
: Fetches files, which are usually files shipped with the Metadata, from the local machine. The path is relative to the FILESPATH variable. Thus, the build system searches, in order, from the following directories, which are assumed to be a subdirectories of the directory in which the recipe file (.bb
) or append file (.bbappend
) resides:${BPN}
: the base recipe name without any special suffix or version numbers.${BP}
-${BPN}-${PV}
: the base recipe name and version but without any special package name suffix.files
: files within a directory, which is namedfiles
and is also alongside the recipe or append file.
ftp://
: Fetches files from the Internet using FTP.git://
: Fetches files from a Git revision control repository.gitsm://
: Fetches submodules from a Git revision control repository.hg://
: Fetches files from a Mercurial (hg
) revision control repository.http://
: Fetches files from the Internet using HTTP.https://
: Fetches files from the Internet using HTTPS.npm://
: Fetches JavaScript modules from a registry.osc://
: Fetches files from an OSC (OpenSUSE Build service) revision control repository.p4://
: Fetches files from a Perforce (p4
) revision control repository.repo://
: Fetches files from a repo (Git) repository.ssh://
: Fetches files from a secure shell.svn://
: Fetches files from a Subversion (svn
) revision control repository.
Here are some additional options worth mentioning:
downloadfilename
: Specifies the filename used when storing the downloaded file.name
: Specifies a name to be used for association with SRC_URI checksums or SRCREV when you have more than one file or git repository specified in SRC_URI. For example:SRC_URI = "git://example.com/foo.git;branch=main;name=first \ git://example.com/bar.git;branch=main;name=second \ http://example.com/file.tar.gz;name=third" SRCREV_first = "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15" SRCREV_second = "e242ed3bffccdf271b7fbaf34ed72d089537b42f" SRC_URI[third.sha256sum] = "13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de"
subdir
: Places the file (or extracts its contents) into the specified subdirectory. This option is useful for unusual tarballs or other archives that do not have their files already in a subdirectory within the archive.subpath
: Limits the checkout to a specific subpath of the tree when using the Git fetcher is used.unpack
: Controls whether or not to unpack the file if it is an archive. The default action is to unpack the file.
- SRCDATE
The date of the source code used to build the package. This variable applies only if the source was fetched from a Source Code Manager (SCM).
- SRCREV
The revision of the source code used to build the package. This variable applies only when using Subversion, Git, Mercurial and Bazaar. If you want to build a fixed revision and you want to avoid performing a query on the remote repository every time BitBake parses your recipe, you should specify a SRCREV that is a full revision identifier and not just a tag.
- SRCREV_FORMAT
Helps construct valid SRCREV values when multiple source controlled URLs are used in SRC_URI.
The system needs help constructing these values under these circumstances. Each component in the SRC_URI is assigned a name and these are referenced in the SRCREV_FORMAT variable. Consider an example with URLs named “machine” and “meta”. In this case, SRCREV_FORMAT could look like “machine_meta” and those names would have the SCM versions substituted into each position. Only one
AUTOINC
placeholder is added and if needed. And, this placeholder is placed at the start of the returned string.- STAMP
Specifies the base path used to create recipe stamp files. The path to an actual stamp file is constructed by evaluating this string and then appending additional information.
- STAMPCLEAN
Specifies the base path used to create recipe stamp files. Unlike the STAMP variable, STAMPCLEAN can contain wildcards to match the range of files a clean operation should remove. BitBake uses a clean operation to remove any other stamps it should be removing when creating a new stamp.
- SUMMARY
A short summary for the recipe, which is 72 characters or less.
- SVNDIR
The directory in which files checked out of a Subversion system are stored.
- T
Points to a directory were BitBake places temporary files, which consist mostly of task logs and scripts, when building a particular recipe.
- TOPDIR
Points to the build directory. BitBake automatically sets this variable.
7 Hello World Example
7.1 BitBake Hello World
The simplest example commonly used to demonstrate any new programming language or tool is the “Hello World” 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.
7.2 Obtaining BitBake
See the 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 108
drwxr-xr-x 9 fawkh 10000 4096 feb 24 12:10 .
drwx------ 36 fawkh 10000 4096 mar 2 17:00 ..
-rw-r--r-- 1 fawkh 10000 365 feb 24 12:10 AUTHORS
drwxr-xr-x 2 fawkh 10000 4096 feb 24 12:10 bin
-rw-r--r-- 1 fawkh 10000 16501 feb 24 12:10 ChangeLog
drwxr-xr-x 2 fawkh 10000 4096 feb 24 12:10 classes
drwxr-xr-x 2 fawkh 10000 4096 feb 24 12:10 conf
drwxr-xr-x 5 fawkh 10000 4096 feb 24 12:10 contrib
drwxr-xr-x 6 fawkh 10000 4096 feb 24 12:10 doc
drwxr-xr-x 8 fawkh 10000 4096 mar 2 16:26 .git
-rw-r--r-- 1 fawkh 10000 31 feb 24 12:10 .gitattributes
-rw-r--r-- 1 fawkh 10000 392 feb 24 12:10 .gitignore
drwxr-xr-x 13 fawkh 10000 4096 feb 24 12:11 lib
-rw-r--r-- 1 fawkh 10000 1224 feb 24 12:10 LICENSE
-rw-r--r-- 1 fawkh 10000 15394 feb 24 12:10 LICENSE.GPL-2.0-only
-rw-r--r-- 1 fawkh 10000 1286 feb 24 12:10 LICENSE.MIT
-rw-r--r-- 1 fawkh 10000 229 feb 24 12:10 MANIFEST.in
-rw-r--r-- 1 fawkh 10000 2413 feb 24 12:10 README
-rw-r--r-- 1 fawkh 10000 43 feb 24 12:10 toaster-requirements.txt
-rw-r--r-- 1 fawkh 10000 2887 feb 24 12:10 TODO
At this point, you should have BitBake cloned to a directory that matches the previous listing except for dates and user names.
7.3 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 2.3.1
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.
7.4 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 https://lists.openembedded.org/g/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, Classes, and 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.
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.
Run BitBake: At this point, you have nothing but a project directory. Run the
bitbake
command and see what it does:$ bitbake ERROR: 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?
When you run BitBake, it begins looking for metadata files. The 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 thebitbake.conf
file.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.
Run BitBake: Now that you have BBPATH defined, run the
bitbake
command again:$ bitbake ERROR: Unable to parse /home/scott-lenovo/bitbake/lib/bb/parse/__init__.py Traceback (most recent call last): File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 127, in resolve_file(fn='conf/bitbake.conf', d=<bb.data_smart.DataSmart object at 0x7f22919a3df0>): if not newfn: > raise IOError(errno.ENOENT, "file %s not found in %s" % (fn, bbpath)) fn = newfn FileNotFoundError: [Errno 2] file conf/bitbake.conf not found in <projectdirectory>
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 aconf/bitbake.conf
file.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 thebitbake.conf
file, see https://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 thebitbake.conf
so that it contains the following:PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" TMPDIR = "${TOPDIR}/tmp" CACHE = "${TMPDIR}/cache" STAMP = "${TMPDIR}/${PN}/stamps" T = "${TMPDIR}/${PN}/work" 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 thelocal.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 process. Here, theTMPDIR
directory is set tohello/tmp
.Tip
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, check PN, TOPDIR, CACHE, STAMP, T or B to take you to the definitions in the glossary.
Run BitBake: After making sure that the
conf/bitbake.conf
file exists, you can run thebitbake
command again:$ bitbake ERROR: Unable to parse /home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py Traceback (most recent call last): File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 67, in inherit(files=['base'], fn='configuration INHERITs', lineno=0, d=<bb.data_smart.DataSmart object at 0x7fab6815edf0>): if not os.path.exists(file): > raise ParseError("Could not inherit file %s" % (file), fn, lineno) bb.parse.ParseError: 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.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. Thebase
class is implicitly inherited by every recipe. BitBake looks for the class in theclasses
directory of the project (i.ehello/classes
in this example).Create the
classes
directory as follows:$ cd $HOME/hello $ mkdir classes
Move to the
classes
directory and then create thebase.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, thebase.bbclass
can have much more depending on which build environments BitBake is supporting.Run BitBake: After making sure that the
classes/base.bbclass
file exists, you can run thebitbake
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.
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 theconf
directory:$ cd $HOME $ mkdir mylayer $ cd mylayer $ mkdir conf
Move to the
conf
directory and create alayer.conf
file that has the following:BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/*.bb" BBFILE_COLLECTIONS += "mylayer" BBFILE_PATTERN_mylayer := "^${LAYERDIR_RE}/" LAYERSERIES_CORENAMES = "hello_world_example" LAYERSERIES_COMPAT_mylayer = "hello_world_example"
For information on these variables, click on BBFILES, LAYERDIR, BBFILE_COLLECTIONS, BBFILE_PATTERN_mylayer or LAYERSERIES_COMPAT to go to the definitions in the glossary.
Note
We are setting both
LAYERSERIES_CORENAMES
and LAYERSERIES_COMPAT in this particular case, because we are using bitbake without OpenEmbedded. You should usually just use LAYERSERIES_COMPAT to specify the OE-Core versions for which your layer is compatible, and add the meta-openembedded layer to your project.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 = "Prints Hello World" PN = 'printhello' 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 DESCRIPTION, PN or PV follow the links to the glossary.- 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.
- Creating conf/bblayers.conf: BitBake uses the
conf/bblayers.conf
file to locate layers needed for the project. This file must reside in theconf
directory of the project (i.e.hello/conf
for this example).Set your working directory to the
hello/conf
directory and then create thebblayers.conf
file so that it contains the following:BBLAYERS ?= " \ /home/<you>/mylayer \ "
You need to provide your own information for
you
in the file.
- Run BitBake With a Target: Now that you have supplied the
bblayers.conf
file, run thebitbake
command and provide the target:$ bitbake printhello Loading cache: 100% | Loaded 0 entries from dependency cache. Parsing recipes: 100% |##################################################################################| 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 Initialising tasks: 100% |###############################################################################| NOTE: No setscene tasks NOTE: Executing Tasks ******************** * * * Hello, World! * * * ******************** NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
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.
Index
BitBake Supported Release Manuals
Release Series 5.0 (scarthgap)
Release Series 4.0 (kirkstone)
Release Series 3.1 (dunfell)
BitBake Outdated Release Manuals
Release Series 4.3 (nanbield)
Release Series 4.2 (mickledore)
Release Series 4.1 (langdale)
Release Series 3.4 (honister)
Release Series 3.3 (hardknott)
Release Series 3.2 (gatesgarth)
Release Series 3.1 (dunfell first versions)
Release Series 3.0 (zeus)
Release Series 2.7 (warrior)
Release Series 2.6 (thud)
Release Series 2.5 (sumo)
Release Series 2.4 (rocko)
Release Series 2.3 (pyro)
Release Series 2.2 (morty)
Release Series 2.1 (krogoth)
Release Series 2.0 (jethro)
Release Series 1.8 (fido)
Release Series 1.7 (dizzy)
Release Series 1.6 (daisy)
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.