Yocto - Bitbake Tasks - 1

最新推荐文章于 2024-10-15 22:00:00 发布

夜流冰

最新推荐文章于 2024-10-15 22:00:00 发布

阅读量400

点赞数 5

分类专栏： GNU/Linux 文章标签：笔记

本文链接：https://blog.csdn.net/guoqx/article/details/140341397

版权

GNU/Linux 专栏收录该内容

196 篇文章 9 订阅

订阅专栏

任务是 BitBake 的执行单位。配方（.bb 文件）使用任务来完成软件的配置、编译和打包。本章提供 OpenEmbedded 构建系统中定义的任务参考。

Tasks are units of execution for BitBake. Recipes (.bb files) use tasks to complete configuring, compiling, and packaging software. This chapter provides a reference of the tasks defined in the OpenEmbedded build system.

1, Normal Recipe Build Tasks

以下各节将介绍与构建配方相关的常规任务。

The following sections describe normal tasks associated with building a recipe.

1.1, do_build

所有配方的默认任务。该任务取决于构建配方所需的所有其他正常任务。

The default task for all recipes. This task depends on all other normal tasks required to build a recipe.

1.2, do_compile

编译源代码。该任务运行时的当前工作目录设置为 ${B}。

Compiles the source code. This task runs with the current working directory set to ${B}.

该任务的默认行为是，如果找到 makefile（Makefile、makefile 或 GNUmakefile），则运行 oe_runmake 函数。如果找不到此类文件，do_compile 任务将不执行任何操作。

The default behavior of this task is to run the oe_runmake function if a makefile (Makefile, makefile, or GNUmakefile) is found. If no such file is found, the do_compile task does nothing.

1.3, do_configure

通过启用或禁用正在构建的软件的任何构建时选项和配置选项来配置源代码。任务运行时的当前工作目录设置为 ${B}。

Configures the source by enabling and disabling any build-time and configuration options for the software being built. The task runs with the current working directory set to ${B}.

该任务的默认行为是，如果找到 makefile（Makefile、makefile 或 GNUmakefile），且 CLEANBROKEN 未设为 "1"，则运行 oe_runmake clean。如果找不到这样的文件，或者 CLEANBROKEN 变量被设置为 "1"，do_configure 任务将什么也不做。

The default behavior of this task is to run oe_runmake clean if a makefile (Makefile, makefile, or GNUmakefile) is found and CLEANBROKEN is not set to “1”. If no such file is found or the CLEANBROKEN variable is set to “1”, the do_configure task does nothing.

1.4, do_deploy

写入要部署到 ${DEPLOY_DIR_IMAGE} 的输出文件。任务运行时的当前工作目录设置为 ${B}。

Writes output files that are to be deployed to ${DEPLOY_DIR_IMAGE}. The task runs with the current working directory set to ${B}.

执行该任务的配方应继承 deploy 类，并将输出写入 ${DEPLOYDIR}，不要与 ${DEPLOY_DIR} 混淆。deploy 类将 do_deploy 设置为共享状态（sstate）任务，可通过使用 sstate 加速。sstate 机制负责将输出从 ${DEPLOYDIR} 复制到 ${DEPLOY_DIR_IMAGE}。

Recipes implementing this task should inherit the deploy class and should write the output to ${DEPLOYDIR}, which is not to be confused with ${DEPLOY_DIR}. The deploy class sets up do_deploy as a shared state (sstate) task that can be accelerated through sstate use. The sstate mechanism takes care of copying the output from ${DEPLOYDIR} to ${DEPLOY_DIR_IMAGE}.

注意

请勿将输出直接写入 ${DEPLOY_DIR_IMAGE}，否则会导致 sstate 机制失灵。

Note

Do not write the output directly to ${DEPLOY_DIR_IMAGE}, as this causes the sstate mechanism to malfunction.

do_deploy 任务默认不作为任务添加，因此需要手动添加。如果希望该任务在 do_compile 之后运行，可以通过以下操作添加：

The do_deploy task is not added as a task by default and consequently needs to be added manually. If you want the task to run after do_compile, you can add it by doing the following:

addtask deploy after do_compile

在其他任务后添加 do_deploy 也是同样的方法。

Adding do_deploy after other tasks works the same way.

1.5 do_fetch

获取源代码。该任务使用 SRC_URI 变量和参数的前缀来确定正确的获取模块。

Fetches the source code. This task uses the SRC_URI variable and the argument’s prefix to determine the correct fetcher module.

1.6 do_image

启动映像生成流程。do_image 任务在 OpenEmbedded 构建系统运行 do_rootfs 任务后运行，在此期间，将识别要安装到映像中的软件包，并创建根文件系统，完成后处理。

Starts the image generation process. The do_image task runs after the OpenEmbedded build system has run the do_rootfs task during which packages are identified for installation into the image and the root filesystem is created, complete with post-processing.

1.7 do_image_complete

完成镜像生成过程。do_image_complete 任务在 OpenEmbedded 构建系统运行 do_image这个镜像预处理任务后运行，并通过动态生成的 do_image_* 任务构建图像。

Completes the image generation process. The do_image_complete task runs after the OpenEmbedded build system has run the do_image task during which image pre-processing occurs and through dynamically generated do_image_* tasks the image is constructed.

1.8 do_install

将需要打包的文件复制到保存区域 ${D}。该任务运行时的当前工作目录设置为 ${B}，即编译目录。do_install 任务以及其他直接或间接依赖于已安装文件的任务（例如 do_package、do_package_write_* 和 do_rootfs）都在 fakeroot 下运行。

Copies files that are to be packaged into the holding area ${D}. This task runs with the current working directory set to ${B}, which is the compilation directory. The do_install task, as well as other tasks that either directly or indirectly depend on the installed files (e.g. do_package, do_package_write_*, and do_rootfs), run under fakeroot.

注意事项

安装文件时，请注意不要将已安装文件的所有者和组 ID 设置为非预期值。某些复制文件的方法，特别是使用递归 cp 命令时，会保留原始文件的 UID 和/或 GID，这通常不是你想要的。主机用户污染 QA 检查会检查可能拥有错误所有权的文件。

安装文件的安全方法包括以下几种：

* 使用install命令。该实用程序是首选方法。

* 带有 --no-preserve=ownership 选项的 cp 命令。

* 带有 --no-same-owner 选项的 tar 命令。有关示例，请参阅源代码目录下 meta/classes-recipe 子目录中的 bin_package.bbclass 文件。

Note

When installing files, be careful not to set the owner and group IDs of the installed files to unintended values. Some methods of copying files, notably when using the recursive cp command, can preserve the UID and/or GID of the original file, which is usually not what you want. The host-user-contaminated QA check checks for files that probably have the wrong ownership.

Safe methods for installing files include the following:

* The install utility. This utility is the preferred method.

* The cp command with the --no-preserve=ownership option.

* The tar command with the --no-same-owner option. See the bin_package.bbclass file in the meta/classes-recipe subdirectory of the Source Directory for an example.

1.9 do_package

分析保存区域 ${D} 的内容，并根据可用的软件包和文件将内容拆分成子集。这项任务使用了 PACKAGES 和 FILES 变量。

Analyzes the content of the holding area ${D} and splits the content into subsets based on available packages and files. This task makes use of the PACKAGES and FILES variables.

1.10 do_patch

查找补丁文件并将其应用到源代码中。

Locates patch files and applies them to the source code.

在获取并解压源文件后，构建系统会使用配方的 SRC_URI 语句来定位并将补丁文件应用到源代码中。

After fetching and unpacking source files, the build system uses the recipe’s SRC_URI statements to locate and apply patch files to the source code.

注意

在搜索补丁时，编译系统会使用 FILESPATH 变量来确定默认的目录集。使用Bitabke -e命令查看此变量，发现是很长一串。一般bb文件都使用files文件夹，或者还可以使用bb构建target的名字（即bb文件名的下划线之前部分）来作为文件夹名，用以保存patch文件。

Note

The build system uses the FILESPATH variable to determine the default set of directories when searching for patches.

默认情况下，补丁文件是*.patch 和*.diff 文件，创建后保存在配方文件所在目录的子目录下。例如，请看 OE-Core 层（即 poky/meta）中的 bluez5 配方：

Patch files, by default, are *.patch and *.diff files created and kept in a subdirectory of the directory holding the recipe file. For example, consider the bluez5 recipe from the OE-Core layer (i.e. poky/meta):

poky/meta/recipes-connectivity/bluez5

此配方有两个补丁文件，位于此处：

This recipe has two patch files located here:

poky/meta/recipes-connectivity/bluez5/bluez5

在 bluez5 配方中，SRC_URI 语句指向构建软件包所需的源文件和补丁文件。

In the bluez5 recipe, the SRC_URI statements point to the source and patch files needed to build the package.

注释

在 bluez5_5.48.bb 配方中，SRC_URI 语句来自包含文件 bluez5.inc。

Note

In the case for the bluez5_5.48.bb recipe, the SRC_URI statements are from an include file bluez5.inc.

如前所述，编译系统会将文件类型为 .patch 和 .diff 的文件视为补丁文件。不过，你可以在 SRC_URI 语句中使用 "apply=yes "参数，将任何文件都表示为补丁文件：

As mentioned earlier, the build system treats files whose file types are .patch and .diff as patch files. However, you can use the “apply=yes” parameter with the SRC_URI statement to indicate any file as a patch file:

SRC_URI = " \

git://path_to_repo/some_package \

file://file;apply=yes \

相反，如果文件类型为 .patch 或 .diff 的文件需要排除在外，以便 do_patch 任务在补丁阶段不应用该文件，则可以在 SRC_URI 语句中使用 "apply=no "参数：

Conversely, if you have a file whose file type is .patch or .diff and you want to exclude it so that the do_patch task does not apply it during the patch phase, you can use the “apply=no” parameter with the SRC_URI statement:

SRC_URI = " \

git://path_to_repo/some_package \

file://file1.patch \

file://file2.patch;apply=no \

在上例中，默认情况下，file1.patch 将作为补丁应用，而 file2.patch 则不会应用。

In the previous example file1.patch would be applied as a patch by default while file2.patch would not be applied.

1.11 do_populate_lic

为配方写入许可证信息，这些信息将在以后构建图像时收集。

Writes license information for the recipe that is collected later when the image is constructed.

1.12 do_populate_sdk

创建可安装 SDK 的文件和目录结构。

Creates the file and directory structure for an installable SDK.

1.13 do_populate_sdk_ex

为可安装的可扩展 SDK（eSDK）创建文件和目录结构。

Creates the file and directory structure for an installable extensible SDK (eSDK).

1.14 do_populate_sysroot

将 do_install 任务安装的文件子集保存（复制）到相应的系统根中。

Stages (copies) a subset of the files installed by the do_install task into the appropriate sysroot.

do_populate_sysroot 任务是一个共享状态（sstate）任务，这意味着可以通过使用 sstate 来加速该任务。此外，如果重新执行该任务，之前的任何输出都会被删除（即 "清除"）。

The do_populate_sysroot task is a shared state (sstate) task, which means that the task can be accelerated through sstate use. Realize also that if the task is re-executed, any previous output is removed (i.e. “cleaned”).

1.15 do_unpack

在SRC_URI中的文件都会解打包到WORKDIR。比如源码仓库是git，则取到的源码会放入S变量的目录，即${WORKDIR}/git。

SRC_URI中文件会在直接copy到WORKDIR目录下，需要打patch的文件会apply到git目录里。

例如，需要在git源代码目录中添加一些文件，就要使用git/xxx/...的目录格式来在bb文件的files文件夹中添加内容。

将源代码解压到 ${WORKDIR} 指向的工作目录中。S 变量也会影响解压后源代码文件的最终存放位置。

Unpacks the source code into a working directory pointed to by ${WORKDIR}. The S variable also plays a role in where unpacked source files ultimately reside.

参考：

1，Yocto Docs

6 Tasks — The Yocto Project ® 5.0.2 documentation