BitBake用户手册：解析与执行

需积分: 9 20 浏览量更新于2024-07-09 收藏 544KB PDF 举报

"BitBake User Manual.pdf 是一本关于BitBake工具的手册，由Richard Purdie、Chris Larson和Phil Blundell编写，是BitBake社区的重要参考资料。该手册涵盖了BitBake的基本概念、执行过程、语法和操作符等内容，并遵循Creative Commons Attribution License进行授权。" BitBake是构建嵌入式Linux系统的核心工具，它主要用于OpenEmbedded和Yocto项目。手册首先介绍了BitBake的基本概览，包括它的历史背景和目标。BitBake最初设计用于自动化软件构建过程，特别是针对嵌入式设备的操作系统镜像。在基本概念部分，手册讲解了以下几个关键点： 1. **Recipes**：Recipe是BitBake的基本构建单元，定义了如何从源代码构建特定的软件包。它包含了获取源代码、配置、编译和打包等步骤的指令。 2. **Configuration Files**：配置文件用于设定构建环境的全局变量，比如主机类型、目标系统属性以及软件包的选择等。 3. **Classes**：Class是一组相关的函数和变量，可以被多个Recipe共享，用于实现通用功能，如编译选项的设置或者特定的构建步骤。 4. **Layers**：Layers是组织Recipe和Class的一种方式，允许不同的团队或项目管理各自的构建元素，同时保持相互之间的独立性。 5. **Append Files**：Append文件用于扩展或修改已有的Recipe，无需直接编辑Recipe文件，增加了灵活性。手册进一步深入到BitBake的执行流程，解释了如何解析基础配置元数据、定位并解析Recipe、确定提供者、处理偏好、解决依赖关系、生成任务列表以及执行任务的过程。此外，还详细讨论了校验和（Signatures）的使用，确保构建过程中文件的完整性和一致性。在语法和操作符章节，BitBake提供了丰富的变量设置和扩展机制，如基本的变量设置、变量展开、默认值设定（使用`?=`, `??=`）以及即时变量等。这些特性使得BitBake能够处理复杂的构建逻辑和条件表达式。 BitBake User Manual.pdf 是一份全面了解和掌握BitBake的必备文档，无论是初学者还是经验丰富的开发者，都能从中获益，更好地驾驭嵌入式系统的构建过程。

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:

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"

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 er

}

EOF

}

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.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or 'defaultpkgname'}"

PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[1] or '1.0'}"

In this example, a recipe called "something_1.2.3.bb" would set PN to "something" and PV to "1.2.3".

By the time parsing is complete for a recipe, BitBake has a list of tasks that the recipe defines and a set of

data consisting of keys and values as well as dependency information about the tasks.

BitBake does not need all of this information. It only needs a small subset of the information to make decisions

about the recipe. Consequently, BitBake caches the values in which it is interested and does not store the rest

of the information. Experience has shown it is faster to re-parse the metadata than to try and write it out to

the disk and then reload it.

Where possible, subsequent BitBake commands reuse this cache of recipe information. The validity of this

cache is determined by first computing a checksum of the base configuration data (see

BB_HASHCONFIG_WHITELIST) 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.