https://www.yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html
bitbake中文手册
第1章概述
欢迎使用BitBake用户手册。本手册提供有关BitBake工具的信息。对于使用BitBake的系统，例如Yocto Project和OpenEmbedded，信息尝试尽可能独立。在某些情况下，在手册中使用编译系统上下文中的场景或示例来帮助理解。对于这些情况，手册清楚地说明了背景。
从根本上说，BitBake是一个通用的任务执行引擎，它允许shell和Python任务在复杂的任务间依赖限制环境下 可以高效的并行运行。BitBake的主要用户之一OpenEmbedded采用这个核心，并使用面向任务的方法编译嵌入式Linux软件堆栈。
从概念上讲，BitBake在某些方面类似于GNU Make，但有显着差异：
- BitBake执行的任务是根据提供的元数据构造的任务。元数据存储在recipe（.bb）和相关的recipe "append" (.bbappend)文件，configuration（.conf）和包含在include (.inc) 文件，class（.bbclass）文件中，并为BitBake提供有关要运行的任务以及这些任务之间的依赖关系的说明。
- BitBake包括一个fetcher库，用于从不同的地方获取源码，例如本地文件、源码控制系统（svn、git）或者网站。
- 要编译的每个单元的“说明”（例如一个软件）称为配方文件，包含有关单元的所有信息（依赖项，源文件位置，校验和，描述等）。
- BitBake包括客户端/服务器抽象类，可以从命令行使用或通过XML-RPC作为服务使用，并具有多个不同的用户界面。
BitBake最初是OpenEmbedded项目的一部分。它的灵感来自Gentoo Linux发行版使用的Portage包管理系统。2004年12月7日，OpenEmbedded项目团队成员Chris Larson将项目分为两个截然不同的部分：
- BitBake，一个通用任务执行器
- OpenEmbedded，BitBake使用的元数据集
今天，BitBake是OpenEmbedded项目的主要基础，该项目用于编译和维护诸如Angstrom Distribution之类的Linux发行版，并用作Linux项目（如Yocto项目）的编译工具。
在BitBake之前，没有任何其他构建工具能够充分满足日渐壮大的嵌入式Linux发行版的需求。传统桌面Linux发行版使用的所有编译系统都缺乏重要的功能，并且在嵌入式领域中普遍存在的基于Buildroot的临时系统都不具备可扩展性或可维护性。
BitBake的一些重要原始目标是：
- 处理交叉编译。
- 处理包间依赖关系（在目标体系结构上编译态，在本机体系结构上编译态和运行态）。
- 支持在给定包中运行任意数量的任务，包括但不限于获取上行源码，解压它们，补丁它们，配置它们等等。
- 对于编译和目标系统而言，Linux发行版是不可知的。
- 与机器/机制无关。
- 支持多个编译和目标操作系统（例如Cygwin，BSD等）。
- 是自包含的，而不是紧密集成到编译机器的根文件系统中。
- 处理目标体系结构、操作系统、分布和机器上的条件元数据。
- 易于使用这些工具去供应需要操作的本地元数据和包。
- 易于使用BitBake在多个项目之间进行协作编译。
- 提供在许多包之间共享公共元数据的继承机制。
随着时间的推移，显而易见的是 一些更进一步的需求时必要的：
- 处理基本配方的变量（例如native，sdk和multilib）。
- 将元数据拆分到layer图层并允许这些layer图层去增强或者重载其他layer。
- 允许将给定的一组输入到任务的变量表达式作为校验。基于该校验和，允许使用预编译组件加速编译。
BitBake满足所有原始要求以及更多包含扩展的基本功能，折射出其他要求。灵活性和强大始终是优先事项。BitBake具有高度可扩展性，支持嵌入式Python代码和任意任务的执行。
BitBake是一个用Python语言编写的程序。在最高级别，BitBake解释元数据，决定运行所需的任务，并执行这些任务。与GNU Make类似，BitBake控制着软件的构建方式。GNU Make通过“makefile”实现其控制。BitBake使用“配方”。
BitBake扩展了像GNU Make这样的简单工具的功能，允许完成更复杂的任务，例如组装整个嵌入式Linux发行版。
本节的其余部分介绍了应该理解的几个概念，以便更好地利用BitBake的功能。
BitBake Recipes，由文件扩展名表示.bb，是最基本的元数据文件。这些配方文件为BitBake提供以下内容：
- 有关包的描述性信息（作者、主页、license等）
- 配方的版本
- 存在依赖关系（包括编译和运行态的依赖）
- 源代码所在的位置和获取
- 源代码是否需要一些补丁、怎么找到他们、怎么使用他们
- 如何配置和编译源码
- 如何将生成的组件打包到一个或多个可安装的包内
- 将这些包安装到目标机器的哪些位置或者包生成的位置
在BitBake或任何使用BitBake作为其编译系统的项目的内容中，具有.bb 扩展名的文件称为配方。
术语“package”也通常用于描述配方。但是，由于这个词也用于描述项目的打包输出，因此最好保持一个单一描述性术语---“配方”，换句话说，用一个“recipe”文件就可以生成多个相关但独立的可安装“packages”，事实上，这个现象很普遍。
配置文件由.conf扩展表示，定义了管理项目编译过程的各种配置变量。这些文件分为几个区域，用于定义机器配置选项，分布配置选项，编译器优化选项，常规通用配置选项和用户配置选项。主配置文件是示例bitbake.conf文件，它位于BitBake源码树conf目录中。
由.bbclass扩展名表示的类文件，包含在元数据文件之间共享的有用信息。BitBake源代码树目前附带一个类元数据文件base.bbclass。可以在classes目录中找到此文件。base.bbclass是特殊的，因为它总是自动包含在所有配方和类中。此类包含标准的基本任务的定义，例如提取，解包，配置（默认为空），编译（运行任何Makefile），安装（默认为空）和打包（默认为空）。这些任务经常被项目开发过程中添加的其他类覆盖或扩展。
layer层允许您将不同定制的类型之间相互隔离。虽然在处理单个项目时，您可能会发现将所有内容都放在一个层中很诱人，但是元数据越模块化，就越容易应对未来的更改。
为了说明如何使用layer层来保持模块化，请考虑为支持特定的目标机器而可能进行的定制。这些类型的定制通常位于一个特殊层，而不是通用层，称为单板支持包(Board Support Package, BSP)层。。此外，例如，机器定制和支持新GUI环境应当在配方和元数据上进行隔离。这种情况提供了两个layer层：一个用于机器配置，另一个用于GUI环境。但是，重要的是要理解BSP layer层仍然可以在GUI环境层中对配方进行特定于机器的添加，而不会使用特定于机器的更改来污染GUI层本身。您可以通过BitBake附加的配方来完成此操作（.bbappend）文件。
附加文件，即具有.bbappend文件扩展名的文件，将构建信息添加或扩展到现有配方文件。
BitBake希望每个附加文件都有一个相应的配方文件。此外，扩展文件和相应的配方文件必须使用相同的根文件名。文件名只能在使用的文件类型后缀（例如formfactor_0.0.bb和formfactor_0.0.bbappend）中有所不同。
扩展文件中的信息将扩展或者覆盖类似命名的配方文件中的信息。
命名扩展文件时，可以使用通配符（％）来匹配配方名称。例如，假设您有一个名为如下的追加文件：
busybox_1.21％.bbappend该扩展文件将匹配任何busybox_1.21.x.bb 版本的配方。因此，append文件将匹配以下配方名称：
busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb重要：同配符 “%”只能使用在.bbappend之前作为扩展文件的名字，不同使用这个通配符到其他位置。
如果busybox配方更新为busybox_1.3.0.bb，则扩展文件名称将不匹配。但是，如果您命名了追加文件busybox_1.%.bbappend，那么您将获得匹配。
你可以通过几种不同的方式获得BitBake：
- 克隆BitBake：使用Git克隆BitBake源代码库是获取BitBake的推荐方法。克隆存储库可以轻松修复错误并访问稳定的分支和主分支。一旦克隆了BitBake，就应该使用最新的稳定分支进行开发，因为master分支用于BitBake开发，可能包含不太稳定的更改。
您通常需要一个与您正在使用的元数据匹配的BitBake版本。元数据通常是向后兼容的，但不是向前兼容的。
以下是克隆BitBake仓库的示例：
$ git clone git：//git.openembedded.org/bitbake此命令将BitBake Git仓库克隆到名为bitbake的目录中。或者你想用一个新的目录而不是bitbake，你可以指定一个目录名，在git clone命令后面，以下是命名目录bbdev的示例：
$ git clone git：//git.openembedded.org/bitbake bbdev- 使用分布包管理系统进行安装：建议不要使用此方法，因为在大多数情况下，您的发行版提供的BitBake版本是BitBake仓库快照后面的多个版本。
- 拍摄BitBake的快照：从源代码仓库下载BitBake的快照，可以访问已知的BitBake分支或版本。
如前所述，克隆Git仓库是获取BitBake的首选方法。克隆仓库使得更新更容易，因为补丁被添加到稳定分支。
以下示例下载BitBake版本1.17.0的快照：
$ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
$ tar zxpvf bitbake-1.17.0.tar.gz在使用tar提取tarball之后，您有一个名为bitbake-1.17.0的目录。
- 使用编译环境检出的bitbake：最后获取Bitbake的可能是，bitbake来自于你的更大的基于bitbake的编译系统，例如Poky。除了手动检出单独的layer层并将他们粘贴到一起，你还可以检出整个系统。这个检出已经包含了一个版本的bitbake，这个版本已经彻底的测试过，可以兼容其他的组件。如何检出具有基于Bitbake的编译系统，信息请参考编译系统的支持文档
该bitbake命令是BitBake工具的主要接口。本节介绍BitBake命令语法并提供了几个执行示例。
以下是BitBake的用法和语法：
$ bitbake -h
用法：bitbake [options] [recipename/target ...]
对给定的一组目标配方（.bb文件）执行指定的任务（默认为“build”）。
假设在cwd或BBPATH中有conf/bblayers.conf可用,conf/bblayers.conf将提供layer层，BBFILES和其他配置信息。
选项：
--version显示程序的版本号
-h， --help显示此帮助消息
-b BUILDFILE，--buildfile=BUILDFILE
直接从特定的.bb配方执行任务。
警告：不处理来自于其他的配方依赖项。
-k， --continue
在出错后尽可能继续。虽然失败的目标和任何依赖它的东西都不能编译，
尽可能在停止之前编译。
-f， --force
强制运行指定的目标/任务（使无效任何现有的邮戳文件）。
-c CMD， --cmd=CMD
指定要执行的任务。可用的确切选项取决于元数据。一些例子可能会可以是'compile'或
'populate_sysroot'或'listtasks'列出可用的任务。
-C INVALIDATE_STAMP，--clear-stamp=INVALIDATE_STAMP
使指定任务的标记失效，例如'compile'然后运行默认任务指定的目标。
-r PREFILE， --read=PREFILE
在bitbake.conf之前读取指定的文件。
-R POSTFILE，--posttread=POSTFILE
在bitbake.conf之后读取指定的文件。
-v， --verbose
使能shell任务的追踪（使用“set -x”），将bb.note(...)信息打印到标准输出
stdout（而不是将他们写到${T}/log.do_<task>中。
-D，--debug
增加调试级别。您可以指定更多不止一次。-D是设置等级为1，bb.debug(1, ...)
的信息被打印到stdout；-DD是设置等级为2，就是将bb.debug(1, ...)和
bb.debug(2, ...)信息都打印到stdout，等； 如果没有-D，没有条是信息被打印。
注意-D 只影响输出到stdout的内容，所有的调试信息会被写到 ${T}/log.do_taskname，
无视调试等级；
-q， --quiet
输出更少的日志信息数据到终端，您可以不止一次指定它。
-n， --dr-run
不执行，只有通过这个动作。
-S DUMP_SIGNATURES，--dump-signatures=DUMP_SIGNATURES
转储签名构造信息，而不用任务执行。参数DUMP_SIGNATURES传递给签名处理程序，
两个常见的值是none和printdiff，但处理程序可以定义更多或更少，None表示只转储签名，
printdiff表示将转储的签名与缓存的签名进行比较
-p， --parse-only
解析BB配方后退出。
-s， --show-versions
显示所有配方的当前和首选版本。
-e， --environment
显示全局或每个配方环境，并完整地显示出信息关于哪里的变量被设置/更改。
-g， --graphviz
使用点语法保存指定目标的依赖树信息；
-I EXTRA_ASSUME_PROVIDED， --signore-deps=EXTRA_ASSUME_PROVIDED
假设这些依赖项不存在，并且已经提供了(相当于ASSUME_PROVIDED)。有助于使
依赖关系图更具有吸引力
-l DEBUG_DOMAINS， --log-domains=DEBUG_DOMAINS
为指定的日志域显示调试日志
-P， --profile
解析命令并保存报告。
-u UI， --ui=UI
用户所使用接口（例如knotty、ncurses、taskexp，默认knotty）。
--token=XMLRPCTOKEN
指定连接到远程服务器时使用的连接令牌。
--revisions-changed
根据上游浮动版本是否已更改设置退出码。
--server-only
运行没有UI的bitbake，只启动服务器（cooker）进程。
-B BIND， --bind=BIND
要绑定的bitbake xmlrpc 服务器的名称/地址。
-T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
设置超时卸载bitbake，当不活动时，设置未-1是不卸载，默认：环境变量为
BB_SERVER_TIMEOUT
--no-setscene
不要运行任何setscene任务。sstate将被忽略一切都需要，编译。
--setscene-only
只跑setscene任务，不跑任何真实任务。
--remote-server= remote_server的
连接到指定的服务器。
-m， --kill-server
终止远程服务器。
--observe-only
作为一个仅观察的客户端连接到服务器。
--status-only
检查远程bitbake服务器的状态。
-w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
将编译的事件日志写到一个bitbake事件json文件中，使用’’(空字符串)去自动指定名称。
--runall=RUNALL
在指定的目标的任务图中，为任何一个配方运行指定的任务（即使它不能正常运行）
--runonly=RUNONLY
仅在指定目标的任务图中运行指定的任务(以及这些任务可能具有的任何任务依赖关系)。本节介绍一些如何使用BitBake的示例。
1.5.2.1。针对单个配方执行任务
执行单个配方文件的任务相对简单。指定所需的文件，BitBake解析它并执行指定的任务。如果没有指定任务，BitBake将执行默认任务，即“build”。BitBake在执行此操作时遵循任务间依赖性。
以下命令在foo_1.0.bb配方文件上运行构建任务，这是默认任务：
$ bitbake -b foo_1.0.bb以下命令在foo.bb配方文件上运行clean任务 ：
$ bitbake -b foo.bb -c clean“-b”选项显式不处理配方依赖项。除了用于调试目的之外，建议使用下一节中提供的语法。
1.5.2.2。执行一组配方文件的任务
当想要管理多个.bb 文件时，会引入许多额外的复杂性。显然，需要有一种方法来告诉BitBake哪些文件是可用的，以及那些想要执行的文件。每个配方都需要有一种方法来表达它的依赖关系，包括编译时和运行态。当多个配方提供相同的功能，或者有多个配方版本时，必须有一种表达配方首选项的方法。
该bitbake命令在不使用“--buildfile”或“-b”时仅接受“PROVIDES”。你不能提供任何其他东西。默认情况下，配方文件通常“提供”其“包名”，如以下示例所示：
$ bitbake foo下一个示例“提供”包名称，并使用“-c”选项告诉BitBake只执行 do_clean任务：
$ bitbake -c clean foo1.5.2.3。执行任务列表和配方和并
BitBake命令行当您指定多个目标时，BitBake命令行支持为单个目标指定不同的任务。例如，假设有恋歌目标（或配方）myfirstrecipe和mysecondrecipe，并且需要Bitbake为第一个配方运行taskA，为第二个配方运行taskB：
$ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB1.5.2.4。生成依赖关系图
BitBake能够使用dot语法生成依赖图。可以使用Graphviz中的dot工具 将这些图形转换为镜像。
生成依赖关系图时，BitBake会将2个文件写入当前工作目录：
- package-depends.dot： 显示两个任务间的依赖，这些依赖匹配Bitbake的内部任务执行列表。
- pn-buildlist： 显示要编译的目标的简单列表。
要停止依赖于常见，请使用“-I”依赖选项，BitBake会从图中省略它们。将此信息保留下来可以生成更易读的图形。这样，您就可以从图中删除 DEPENDS继承的类，例如base.bbclass。
以下是创建依赖关系图的两个示例。第二个示例省略了从图中的OpenEmbedded中常见的依赖：
$ bitbake -g foo
$ bitbake -g -I virtual / kernel -I eglibc foo1.5.2.5。执行多配置编译
Bitbake可以使用一个简单的命令编译多个镜像或者包，不同的目标target需要不同的配置（多配置编译），在脚本中，每个目标都称为“multiconfig”。为了完成多配置的编译，必须使用编译目录下的相似的配置文件去单独定义每一个目标的配置文件，这些multiconfig配置文件是特定的，他们必须位于当前编译目录下的conf子目录下叫做multiconfig。下图是两个单独的目标的例子。
之所以需要这种文件层次结构，是因为在解析layer层之前不会构造BBPATH变量，因此，除非配置文件位于当前工作目录中，否则不可能使用配置文件作为预配置文件。每个配置文件至少必须定义一个机器和Bitbake用于编译的临时目录，实践中建议，这些临时目录在编译期间最好不要重叠使用；除了为每个目标单独配置文件外，还必须使能BitBake执行多配置编译，通过在local.conf配置文件中设置BBMULTICONFIG 变量来使能，例如，假设在编译目录中定义letarget1和target2的配置文件，下面的local.conf中的语句即使能了Bitbake执行多配置文件编译，也指定了两个额外的multiconfig；
BBMULTICONFIG = "target1 target2"一旦目标配置文件就位，BitBake使能了多配置编译，就可以执行下面的编译命令：
$ bitbake [mc:multiconfigname:]target[[[mc:multiconfigname:]target] ... ]下面arget1 和 target2的两个额外multiconfig的例子：
$ bitbake mc::target mc:target1:target mc:target2:target1.5.2.6。使能多配置编译依赖
有时，依赖可以存在目标之间（multiconfigs）在一个多配置编译中，例如，假设要编译一个特定体系结构的镜像，另一个为不同体系结构编译的根文件系统要存在，换而言之，第一个多配置（multiconfig）的镜像决定了第二个多配置镜像的根文件系统。这个依赖关系本质上是，编译一个multiconfig的配方中的任务依赖于编译另一个multiconfig的配方中的任务的完成。
在多配置编译中使能依赖，必须使用下面的语句形式在recipe中声明依赖关系:
ask_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"这个语句刚好的使用方式，例如采用两个multiconfig的例子:target1h和target2：
image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"在这个例子中，from_multiconfig是"target1" 和 to_multiconfig 是 "target2"，包含image_task的配方的镜像所依赖的任务依赖于编译image2的rootfs_task的完成，该任务与“target2”multiconfig相关联。
一旦建立了这个依赖。可以使用下面的bitbake命令编译"target1"的multiconfig
$ bitbake mc:target1:image1该命令执行为“target1”multiconfig创建image1所需的所有任务。由于依赖关系，BitBake也通过rootfs_task执行“target2”multiconfig编译。让配方取决于另一个编译的根文件系统似乎没有那么有用。考虑一下image1配方中语句的更改:
image_task[mcdepends] = "mc:target1:target2:image2:image_task"
这种情况下，BitBake必须为"target2" 编译创建image2，因为"target1"的编译取决于它；
因为"target1" 和 "target2" 是使能多配置编译的和佩配置文件隔离，BitBake将每个编译红好的文件放置在各自的临时编译目录中。
3088
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
