Yocto - build/conf/local.conf文件

该文件是本地配置文件，所有本地用户设置都放置在此文件中。该文件中的注释为系统新用户可能需要更改的选项提供了一些指导，但几乎所有配置选项都可以在该文件中设置。更有冒险精神的用户可以查看 local.conf.sample.extended，其中包含了可以放在此文件中的其他配置示例，但新用户最初可能不需要其中任何一个。

This file is your local configuration file and is where all local user settings are placed. The comments in this file give some guide to the options a new user to the system might want to change but pretty much any configuration option can be set in this file. More adventurous users can look at local.conf.sample.extended which contains other examples of configuration which can be placed in this file but new users likely won't need any of them initially.

以 “#”字符开头的行会被注释掉，在某些情况下，默认值会作为注释提供给用户，以显示语法示例。启用该选项只需移除该字符，然后根据需要对变量进行修改即可。

Lines starting with the '#' character are commented out and in some cases the default values are provided as comments to show people example syntax. Enabling the option is a question of removing the character and making any change to the variable as required.

# Machine Selection

您需要选择一台特定的机器作为构建目标。有多种可在 QEMU 仿真器中启动和运行的仿真机器可供选择：

You need to select a specific machine to target the build with. There are a selection of emulated machines available which can boot and run in the QEMU emulator:

#MACHINE ?= "qemuarm"

#MACHINE ?= "qemuarm64"

#MACHINE ?= "qemumips"

#MACHINE ?= "qemumips64"

#MACHINE ?= "qemuppc"

#MACHINE ?= "qemux86"

#MACHINE ?= "qemux86-64"

此外，还包括以下用于演示的硬件板目标机：

There are also the following hardware board target machines included for demonstration purposes:

#MACHINE ?= "beaglebone-yocto"

#MACHINE ?= "genericx86"

#MACHINE ?= "genericx86-64"

#MACHINE ?= "edgerouter"

如果未选择其他机器，则将默认机器设置为 qemux86-64：

This sets the default machine to be qemux86-64 if no other machine is selected:

MACHINE ??= "qemux86-64"

# Where to place downloads

在首次构建过程中，系统会从不同的上游项目下载许多不同的源代码压缩包。这可能需要一段时间，尤其是在网络连接速度较慢的情况下。这些都存储在 DL_DIR 中。在擦除和重建时，可以保留该目录，以加快后续编译的速度。在同一台机器上进行多次编译时，也可以共享该目录。

During a first build the system will download many different source code tarballs  from various upstream projects. This can take a while, particularly if your network  connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you  can preserve this directory to speed up this part of subsequent builds. This directory  is safe to share between multiple builds on the same machine too.

默认情况下，下载目录位于构建目录 TOPDIR 下。

The default is a downloads directory under TOPDIR which is the build directory.

DL_DIR ?= "${TOPDIR}/downloads"

# Where to place shared-state files

BitBake 具备根据先前构建的输出加速构建的功能。这是通过使用 “共享状态 ”文件来实现的，这些文件可以被视为缓存对象，而该选项则决定了这些文件的位置。

BitBake has the capability to accelerate builds based on previously built output. This is done using "shared state" files which can be thought of as cache objects and this option determines where those files are placed.

你可以清除 TMPDIR，使该目录保持不变，如果配置没有更改，构建过程将从这些文件重新生成。如果对配置进行了更改，则只会使用状态仍然有效的共享状态文件（使用校验和完成）。

You can wipe out TMPDIR leaving this directory intact and the build would regenerate from these files if no changes were made to the configuration. If changes were made to the configuration, only shared state files where the state was still valid would be used (done using checksums).

默认情况下是 TOPDIR 下的 sstate-cache 目录。

The default is a sstate-cache directory under TOPDIR.

SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

# Where to place the build output

该选项指定了大部分构建工作应在何处完成，以及 BitBake 应在何处放置临时文件和输出结果。请注意，这包括许多应用程序和工具链的提取和编译，这可能会占用数千兆字节的硬盘空间。

This option specifies where the bulk of the building work should be done and where BitBake should place its temporary files and output. Keep in mind that this includes the extraction and compilation of many applications and the toolchain which can use Gigabytes of hard disk space.

默认情况下是 TOPDIR 下的 tmp 目录。

The default is a tmp directory under TOPDIR.

TMPDIR = "${TOPDIR}/tmp"

# Default policy config

发布相关设置控制哪些策略设置被用作默认值。对于一般的 Yocto 项目使用来说，默认值是没有问题的，至少最初是这样。最终，在创建自定义策略时，人们很可能会对这些默认值进行修改。

The distribution setting controls which policy settings are used as defaults. The default value is fine for general Yocto project use, at least initially. Ultimately when creating custom policy, people will likely end up subclassing these defaults.

DISTRO ?= "poky"

作为子类的一个例子，有一种 “ bleeding”先进策略配置，其中许多版本被设置为上游源码控制系统的绝对最新代码。这里只是举例说明，对大多数新用户并无用处。

As an example of a subclass there is a "bleeding" edge policy configuration where many versions are set to the absolute latest code from the upstream  source control systems. This is just mentioned here as an example, its not useful to most new users.

DISTRO ?= "poky-bleeding"

# Package Management configuration

该变量列出了要启用的打包格式。可以同时启用多个打包后端，变量中列出的第一项将用于生成根文件系统。

This variable lists which packaging formats to enable. Multiple package backends can be enabled at once and the first item listed in the variable will be used to generate the root filesystems.

Options are:

- 'package_deb' for debian style deb files

- 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)

- 'package_rpm' for rpm style packages

E.g.: 

PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"

我们默认使用 rpm：

We default to rpm:

PACKAGE_CLASSES ?= "package_rpm"

# SDK target architecture

该变量指定了构建 SDK 项目的体系结构，这意味着您可以为运行构建的机器以外的体系结构构建 SDK 软件包（例如，在 x86_64 主机上构建 i686 软件包）。

This variable specifies the architecture to build SDK items for and means you can build the SDK packages for architectures other than the machine you are running the build on (i.e. building i686 packages on an x86_64 host).

支持的值为 i686、x86_64、aarch64

Supported values are i686, x86_64, aarch64

SDKMACHINE ?= "i686"

# Extra image configuration defaults

EXTRA_IMAGE_FEATURES 变量允许在生成的图像中添加额外的软件包。其中一些选项会自动添加到某些图像类型中。该变量可包含以下选项：

The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated images. Some of these options are added to certain image types automatically. The variable can contain the following options:

"dbg-pkgs"       - add -dbg packages for all installed packages

                    (adds symbol information for debugging/profiling)

"src-pkgs"       - add -src packages for all installed packages

                    (adds source code for debugging)

"dev-pkgs"       - add -dev packages for all installed packages

                    (useful if you want to develop against libs in the image)

"ptest-pkgs"     - add -ptest packages for all ptest-enabled packages

                    (useful if you want to run the package test suites)

"tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)

"tools-debug"    - add debugging tools (gdb, strace)

"eclipse-debug"  - add Eclipse remote debugging support

"tools-profile"  - add profiling tools (oprofile, lttng, valgrind)

"tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)

"debug-tweaks"   - make an image suitable for development

                    e.g. ssh root access has a blank password

这里还可以使用其他应用程序目标，详情请参见 meta/classes/image.bbclass 和 meta/classes/core-image.bbclass。

There are other application targets that can be used here too, see meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.

我们默认启用调试配置。

We default to enabling the debugging tweaks.

EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

# Additional image features

下面列出了在构建图像时可以使用的附加类，这些类可以启用额外的功能。可包含在此变量中的一些可用选项有

The following is a list of additional classes to use when building images which enable extra features. Some available options which can be included in this variable are:

  - 'buildstats' collect build statistics

USER_CLASSES ?= "buildstats"

# Runtime testing of images

在创建任何根文件系统后，构建系统可在 qemu（模拟器）下测试启动虚拟机镜像，并针对这些镜像运行测试。它还可以针对构建的任何 SDK 运行测试。要启用此功能，请取消这些行的注释：

详情请参阅 classes/test{image,sdk}.bbclass。

The build system can test booting virtual machine images under qemu (an emulator) after any root filesystems are created and run tests against those images. It can also run tests against any SDK that are built. To enable this uncomment these lines.

See classes/test{image,sdk}.bbclass for further details.

IMAGE_CLASSES += "testimage testsdk"

TESTIMAGE_AUTO:qemuall = "1"

# Interactive shell configuration

在某些情况下，系统可能需要你的输入，为此它可以启动一个交互式 shell。之所以需要这样做，是因为构建是多线程的，需要能够处理多个并行进程可能需要用户注意的情况。默认情况下，它会遍历所有可用的终端类型，以找到一个合适的。

Under certain circumstances the system may need input from you and to do this it can launch an interactive shell. It needs to do this since the build is multithreaded and needs to be able to handle the case where more than one parallel process may require the user's attention. The default is iterate over the available terminal types to find one that works.

例如，在解决无法应用的补丁、使用 devshell 或内核 menuconfig 时，可能会出现这种情况。

Examples of the occasions this may happen are when resolving patches which cannot be applied, to use the devshell or the kernel menuconfig.

支持的值有：auto、gnome、xfce、rxvt、screen、konsole（仅限 KDE 3.x）、none。

注意：由于新版 Konsole 的行为方式，目前 Konsole 支持仅适用于 KDE 3.x。

Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none.

Note: currently, Konsole support only works for KDE 3.x due to the way newer Konsole versions behave.

OE_TERMINAL = "auto"

默认情况下，禁用交互式补丁解决（任务只会失败）：

By default disable interactive patch resolution (tasks will just fail instead):

PATCHRESOLVE = "noop"

# Disk Space Monitoring during the build

在构建过程中监控磁盘空间。如果任何关键编译位置（TMPDIR、DL_DIR、SSTATE_DIR）的空间小于 1GB，或 inodes 小于 100K，则逐步关闭编译。如果少于 100MB 或 1K inodes，则执行硬停止构建。这样做的原因是，空间完全耗尽会损坏文件，并对构建造成难以恢复的损害。

Monitor the disk space during the build. If there is less that 1GB of space or less  than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully  shutdown the build. If there is less than 100MB or 1K inodes, perform a hard halt  of the build. The reason for this is that running completely out of space can corrupt  files and damages the build in ways which may not be easily recoverable.

有必要对 /tmp 进行监控，如果没有剩余空间，编译就会失败，并出现非常奇特的错误。

It's necessary to monitor /tmp, if there is no space left the build will fail  with very exotic errors.

BB_DISKMON_DIRS ??= "\

    STOPTASKS,${TMPDIR},1G,100K \

    STOPTASKS,${DL_DIR},1G,100K \

    STOPTASKS,${SSTATE_DIR},1G,100K \

    STOPTASKS,/tmp,100M,100K \

    HALT,${TMPDIR},100M,1K \

    HALT,${DL_DIR},100M,1K \

    HALT,${SSTATE_DIR},100M,1K \

    HALT,/tmp,10M,1K"

# Shared-state files from other locations

如上所述，共享状态文件是预构建的缓存数据对象，可用于加快构建时间。该变量可用于配置系统在构建数据前搜索其他镜像位置以获取这些对象。

As mentioned above, shared state files are prebuilt cache data objects which can be  used to accelerate build time. This variable can be used to configure the system  to search other mirror locations for these objects before it builds the data itself.

镜像位置可以是文件系统目录，也可以是 https 或 ftp 等远程 url。这些镜像位置将包含之前构建的 sstate 缓存结果（可能来自其他机器）。该变量的作用类似于 fetcher MIRRORS/PREMIRRORS，指向缓存位置以检查共享对象。

This can be a filesystem directory, or a remote url such as https or ftp. These  would contain the sstate-cache results from previous builds (possibly from other  machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the  cache locations to check for the shared objects.

注意：如果镜像使用与 SSTATE_DIR 相同的结构，则需要在末尾添加 PATH，如下例所示。这将被替换为目录结构中的正确路径。

NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH  at the end as shown in the examples below. This will be substituted with the  correct path within the directory structure.

SSTATE_MIRRORS ?= "\

file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \

file://.* file:///some/local/dir/sstate/PATH"

# Yocto Project SState Mirror

Yocto 项目为其发布的版本提供了预构建的人工制品，你可以通过取消注释下面的行来启用这些人工制品。这意味着在开始联编时，联编会使用网络来检查工件，这同样会减慢联编速度，但也会加快联编速度，因为如果缓存中存在工件，就无需联编。它假定你的下载速度比构建速度快，这取决于你的网络。

The Yocto Project has prebuilt artefacts available for its releases, you can enable  use of these by uncommenting the following lines. This will mean the build uses  the network to check for artefacts at the start of builds, which does slow it down  equally, it will also speed up the builds by not having to build things if they are  present in the cache. It assumes you can download something faster than you can build it  which will depend on your network.

注意：为使其有效，您还需要将哈希等价直通到匹配服务器

Note: For this to work you also need hash-equivalence passthrough to the matching server

BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"

SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"

# Qemu configuration

默认情况下，本地 qemu 会内置一个 VNC 服务器，在该服务器上可以看到图形输出。下面一行也会启用 SDL UI 前端。

By default native qemu will build with a builtin VNC server where graphical output can be  seen. The line below enables the SDL UI frontend too.

PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

默认情况下，将联编 libsdl2-native，如果要使用主机的 libSDL 而不是使用libsdl2-native联编出来的最小版libsdl，请取消下面的 ASSUME_PROVIDED 行的注释。

By default libsdl2-native will be built, if you want to use your host's libSDL instead of  the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.

ASSUME_PROVIDED += "libsdl2-native"

你还可以启用 Gtk UI 前端，它的构建时间稍长，但能为控制模拟器增加一套方便的菜单。

You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds  a handy set of menus for controlling the emulator.

PACKAGECONFIG:append:pn-qemu-system-native = " gtk+"

# Hash Equivalence

启用对自动运行本地哈希等价服务器的支持，并指示 bitbake 使用哈希等价感知签名生成器。哈希等价可以提高 sstate 的重用率，因为它可以检测到给定的 sstate 工件何时可以等价重用，即使当前任务的哈希值与生成该工件的哈希值不匹配。

Enable support for automatically running a local hash equivalence server and  instruct bitbake to use a hash equivalence aware signature generator. Hash  equivalence improves reuse of sstate by detecting when a given sstate  artifact can be reused as equivalent, even if the current task hash doesn't  match the one that generated the artifact.

可使用“<HOSTNAME>:<PORT>”格式设置共享哈希等价服务器。

A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format.

BB_HASHSERVE = "auto"

BB_SIGNATURE_HANDLER = "OEEquivHash"

# Memory Resident Bitbake

Bitbake 的服务器组件可以在当前命令的用户界面完成后保留在内存中。这意味着后续命令可以运行得更快，因为 bitbake 不需要重新加载缓存文件等。以秒为单位，之后服务器将关闭。

Bitbake's server component can stay in memory after the UI for the current command  has completed. This means subsequent commands can run faster since there is no need  for bitbake to reload cache files and so on. Number is in seconds, after which the  server will shut down.

BB_SERVER_TIMEOUT = "60"

CONF_VERSION 会在每次 build/conf/ 发生不兼容变化时增加，用于跟踪该文件生成时的版本。如果这对你没有任何意义，可以放心地忽略它。

CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to  track the version of this file when it was generated. This can safely be ignored if  this doesn't mean anything to you.

CONF_VERSION = "2"