A compilation toolchain is the set of tools that allows you to compile code for your system. It consists of a compiler (in our case, gcc), binary utils like assembler and linker (in our case, binutils) and a C standard library (for example GNU Libc, uClibc-ng).
编译工具链是一组工具，允许您为您的系统编译代码。它包括编译器（在我们的情况下， gcc ），二进制工具如汇编器和链接器（在我们的情况下， binutils ）和 C 标准库（例如 GNU Libc，uClibc-ng）。

The system installed on your development station certainly already has a compilation toolchain that you can use to compile an application that runs on your system. If you’re using a PC, your compilation toolchain runs on an x86 processor and generates code for an x86 processor. Under most Linux systems, the compilation toolchain uses the GNU libc (glibc) as the C standard library. This compilation toolchain is called the "host compilation toolchain". The machine on which it is running, and on which you’re working, is called the "host system" ^[3].
安 装在您的开发站点上的系统肯定已经有一个编译工具链，您可以使用它来编译在您的系统上运行的应用程序。如果您使用的是个人电脑，您的编译工具链在 x86 处理器上运行，并为 x86 处理器生成代码。在大多数 Linux 系统下，编译工具链使用 GNU libc（glibc）作为 C 标准库。这个编译工具链被称为“主机编译工具链”。它正在运行的机器，以及您正在工作的机器，被称为“主机系统” ^[3] 。

The compilation toolchain is provided by your distribution, and Buildroot has nothing to do with it (other than using it to build a cross-compilation toolchain and other tools that are run on the development host).
编译工具链由您的发行版提供，Buildroot 与之无关（除了使用它来构建交叉编译工具链和在开发主机上运行的其他工具）。

As said above, the compilation toolchain that comes with your system runs on and generates code for the processor in your host system. As your embedded system has a different processor, you need a cross-compilation toolchain - a compilation toolchain that runs on your host system but generates code for your target system (and target processor). For example, if your host system uses x86 and your target system uses ARM, the regular compilation toolchain on your host runs on x86 and generates code for x86, while the cross-compilation toolchain runs on x86 and generates code for ARM.
如 上所述，系统自带的编译工具链在您的主机系统上运行，并为主机系统中的处理器生成代码。由于您的嵌入式系统使用不同的处理器，您需要一个交叉编译工具链 - 一个在您的主机系统上运行但为目标系统（和目标处理器）生成代码的编译工具链。例如，如果您的主机系统使用 x86，而目标系统使用 ARM，那么主机上的常规编译工具链在 x86 上运行并为 x86 生成代码，而交叉编译工具链在 x86 上运行并为 ARM 生成代码。

Buildroot provides two solutions for the cross-compilation toolchain:
Buildroot 为交叉编译工具链提供了两种解决方案：

The choice between these two solutions is done using the Toolchain Type option in the Toolchain menu. Once one solution has been chosen, a number of configuration options appear, they are detailed in the following sections.
在 Toolchain 菜单中使用 Toolchain Type 选项来选择这两个解决方案之间的选择。一旦选择了一个解决方案，将出现一些配置选项，这些选项在以下部分中详细说明。

make sdk

On a Linux system, the /dev directory contains special files, called device files, that allow userspace applications to access the hardware devices managed by the Linux kernel. Without these device files, your userspace applications would not be able to use the hardware devices, even if they are properly recognized by the Linux kernel.
在 Linux 系统上， /dev 目录包含称为设备文件的特殊文件，允许用户空间应用程序访问由 Linux 内核管理的硬件设备。如果没有这些设备文件，即使 Linux 内核正确识别了硬件设备，您的用户空间应用程序也无法使用这些硬件设备。

Under System configuration, /dev management, Buildroot offers four different solutions to handle the /dev directory :
在 System configuration ， /dev management 下，Buildroot 提供了四种不同的解决方案来处理 /dev 目录：

The Buildroot developers recommendation is to start with the Dynamic using devtmpfs only solution, until you have the need for userspace to be notified when devices are added/removed, or if firmwares are needed, in which case Dynamic using devtmpfs + mdev is usually a good solution.
Buildroot 开发人员建议首先使用仅使用 devtmpfs 的动态解决方案，直到需要在添加/移除设备时通知用户空间，或者需要固件时，此时通常使用动态使用 devtmpfs + mdev 是一个不错的解决方案。

Note that if systemd is chosen as init system, /dev management will be performed by the udev program provided by systemd.
请注意，如果选择 systemd 作为初始化系统，则/dev 管理将由 systemd 提供的 udev 程序执行。

The init program is the first userspace program started by the kernel (it carries the PID number 1), and is responsible for starting the userspace services and programs (for example: web server, graphical applications, other network servers, etc.).
初始化程序是内核启动的第一个用户空间程序（它携带 PID 编号 1），负责启动用户空间服务和程序（例如：Web 服务器、图形应用程序、其他网络服务器等）。

Buildroot allows to use three different types of init systems, which can be chosen from System configuration, Init system:
Buildroot 允许使用三种不同类型的 init 系统，可以从 System configuration ， Init system 中选择：

The solution recommended by Buildroot developers is to use the BusyBox init as it is sufficient for most embedded systems. systemd can be used for more complex situations.
Buildroot 开发人员推荐的解决方案是使用 BusyBox init，因为对于大多数嵌入式系统来说已经足够了。systemd 可用于更复杂的情况。

This is a collection of tips that help you make the most of Buildroot.
这是一些帮助您充分利用 Buildroot 的技巧的集合。

Display all commands executed by make: 
显示由 make 执行的所有命令：

 $ make V=1 <target>

Display the list of boards with a defconfig: 
显示具有 defconfig 的板的列表：

 $ make list-defconfigs

Display all available targets: 
显示所有可用的目标：

 $ make help

Not all targets are always available, some settings in the .config file may hide some targets:
并非所有目标始终可用， .config 文件中的一些设置可能会隐藏一些目标：

Cleaning: Explicit cleaning is required when any of the architecture or toolchain configuration options are changed.
清理：当更改任何架构或工具链配置选项时，需要显式清理。

To delete all build products (including build directories, host, staging and target trees, the images and the toolchain):
要删除所有构建产品（包括构建目录、主机、暂存和目标树、映像和工具链）：

 $ make clean

Generating the manual: The present manual sources are located in the docs/manual directory. To generate the manual:
生成手册：当前手册源位于 docs/manual 目录中。要生成手册：

 $ make manual-clean
 $ make manual

The manual outputs will be generated in output/docs/manual.
手册输出将生成在 output/docs/manual 中。

Resetting Buildroot for a new target: To delete all build products as well as the configuration:
为新目标重置 Buildroot：要删除所有构建产品以及配置：

 $ make distclean

Notes. If ccache is enabled, running make clean or distclean does not empty the compiler cache used by Buildroot. To delete it, refer to Section 8.13.3, “Using ccache in Buildroot”.
注意事项。如果启用了 ccache ，运行 make clean 或 distclean 不会清空 Buildroot 使用的编译器缓存。要删除它，请参阅第 8.13.3 节“在 Buildroot 中使用 ccache ”。

Dumping the internal make variables: One can dump the variables known to make, along with their values:
转储内部制作变量：可以转储已知于制作的变量及其值：

 $ make -s printvars VARS='VARIABLE1 VARIABLE2'
 VARIABLE1=value_of_variable
 VARIABLE2=value_of_variable

It is possible to tweak the output using some variables:
可以使用一些变量来调整输出：

For example: 例如：

 $ make -s printvars VARS=BUSYBOX_%DEPENDENCIES
 BUSYBOX_DEPENDENCIES=skeleton toolchain
 BUSYBOX_FINAL_ALL_DEPENDENCIES=skeleton toolchain
 BUSYBOX_FINAL_DEPENDENCIES=skeleton toolchain
 BUSYBOX_FINAL_PATCH_DEPENDENCIES=
 BUSYBOX_RDEPENDENCIES=ncurses util-linux

 $ make -s printvars VARS=BUSYBOX_%DEPENDENCIES QUOTED_VARS=YES
 BUSYBOX_DEPENDENCIES='skeleton toolchain'
 BUSYBOX_FINAL_ALL_DEPENDENCIES='skeleton toolchain'
 BUSYBOX_FINAL_DEPENDENCIES='skeleton toolchain'
 BUSYBOX_FINAL_PATCH_DEPENDENCIES=''
 BUSYBOX_RDEPENDENCIES='ncurses util-linux'

 $ make -s printvars VARS=BUSYBOX_%DEPENDENCIES RAW_VARS=YES
 BUSYBOX_DEPENDENCIES=skeleton toolchain
 BUSYBOX_FINAL_ALL_DEPENDENCIES=$(sort $(BUSYBOX_FINAL_DEPENDENCIES) $(BUSYBOX_FINAL_PATCH_DEPENDENCIES))
 BUSYBOX_FINAL_DEPENDENCIES=$(sort $(BUSYBOX_DEPENDENCIES))
 BUSYBOX_FINAL_PATCH_DEPENDENCIES=$(sort $(BUSYBOX_PATCH_DEPENDENCIES))
 BUSYBOX_RDEPENDENCIES=ncurses util-linux

The output of quoted variables can be reused in shell scripts, for example:
引用变量的输出可以在 shell 脚本中重复使用，例如：

 $ eval $(make -s printvars VARS=BUSYBOX_DEPENDENCIES QUOTED_VARS=YES)
 $ echo $BUSYBOX_DEPENDENCIES
 skeleton toolchain

Buildroot does not attempt to detect what parts of the system should be rebuilt when the system configuration is changed through make menuconfig, make xconfig or one of the other configuration tools. In some cases, Buildroot should rebuild the entire system, in some cases, only a specific subset of packages. But detecting this in a completely reliable manner is very difficult, and therefore the Buildroot developers have decided to simply not attempt to do this.
当系统配置通过 make menuconfig ， make xconfig 或其他配置工具更改时，Buildroot 不会尝试检测应重新构建系统的哪些部分。在某些情况下，Buildroot 应重新构建整个系统，而在某些情况下，只需重新构建特定的软件包子集。但以完全可靠的方式检测这一点非常困难，因此 Buildroot 开发人员决定简单地不尝试这样做。

Instead, it is the responsibility of the user to know when a full rebuild is necessary. As a hint, here are a few rules of thumb that can help you understand how to work with Buildroot:
相反，用户有责任知道何时需要进行完全重建。以下是一些经验法则的提示，可以帮助您了解如何使用 Buildroot：

Generally speaking, when you’re facing a build error and you’re unsure of the potential consequences of the configuration changes you’ve made, do a full rebuild. If you get the same build error, then you are sure that the error is not related to partial rebuilds of packages, and if this error occurs with packages from the official Buildroot, do not hesitate to report the problem! As your experience with Buildroot progresses, you will progressively learn when a full rebuild is really necessary, and you will save more and more time.
一 般来说，当您面临构建错误并且不确定您所做配置更改的潜在后果时，请进行完整重建。如果您收到相同的构建错误，则可以确定该错误与软件包的部分重建无关， 如果此错误发生在官方 Buildroot 软件包中，请毫不犹豫地报告问题！随着您对 Buildroot 的经验不断积累，您将逐渐学会何时真正需要进行完整重建，并且将节省越来越多的时间。

For reference, a full rebuild is achieved by running:
供参考，通过运行以下命令来实现完整重建：

$ make clean all

One of the most common questions asked by Buildroot users is how to rebuild a given package or how to remove a package without rebuilding everything from scratch.
Buildroot 用户经常问的一个最常见的问题是如何重新构建给定的软件包或如何在不从头开始重新构建的情况下删除软件包。

Removing a package is unsupported by Buildroot without rebuilding from scratch. This is because Buildroot doesn’t keep track of which package installs what files in the output/staging and output/target directories, or which package would be compiled differently depending on the availability of another package.
在不从头开始重新构建的情况下，Buildroot 不支持删除软件包。这是因为 Buildroot 不跟踪哪个软件包在 output/staging 和 output/target 目录中安装了哪些文件，或者哪个软件包的编译方式会因为另一个软件包的可用性而有所不同。

The easiest way to rebuild a single package from scratch is to remove its build directory in output/build. Buildroot will then re-extract, re-configure, re-compile and re-install this package from scratch. You can ask buildroot to do this with the make <package>-dirclean command.
从头开始重新构建单个软件包的最简单方法是删除其在 output/build 中的构建目录。然后 Buildroot 将重新提取、重新配置、重新编译和重新安装此软件包。您可以使用 make <package>-dirclean 命令要求 buildroot 这样做。

On the other hand, if you only want to restart the build process of a package from its compilation step, you can run make <package>-rebuild. It will restart the compilation and installation of the package, but not from scratch: it basically re-executes make and make install inside the package, so it will only rebuild files that changed.
另一方面，如果您只想从编译步骤重新启动软件包的构建过程，可以运行 make <package>-rebuild 。它将重新启动软件包的编译和安装过程，但不是从头开始：它基本上重新执行软件包内的 make 和 make install ，因此只会重新构建已更改的文件。

If you want to restart the build process of a package from its configuration step, you can run make <package>-reconfigure. It will restart the configuration, compilation and installation of the package.
如果您想从配置步骤重新启动软件包的构建过程，可以运行 make <package>-reconfigure 。它将重新启动软件包的配置、编译和安装。

While <package>-rebuild implies <package>-reinstall and <package>-reconfigure implies <package>-rebuild, these targets as well as <package> only act on the said package, and do not trigger re-creating the root filesystem image. If re-creating the root filesystem in necessary, one should in addition run make or make all.
虽然 <package>-rebuild 意味着 <package>-reinstall ， <package>-reconfigure 意味着 <package>-rebuild ，这些目标以及 <package> 仅对所述软件包起作用，并不会触发重新创建根文件系统映像。如果需要重新创建根文件系统，则还应运行 make 或 make all 。

Internally, Buildroot creates so-called stamp files to keep track of which build steps have been completed for each package. They are stored in the package build directory, output/build/<package>-<version>/ and are named .stamp_<step-name>. The commands detailed above simply manipulate these stamp files to force Buildroot to restart a specific set of steps of a package build process.
在内部，Buildroot 创建所谓的戳记文件，以跟踪每个软件包的构建步骤已完成的情况。它们存储在软件包构建目录中， output/build/<package>-<version>/ ，并命名为 .stamp_<step-name> 。上面详细介绍的命令只是简单地操作这些戳记文件，以强制 Buildroot 重新启动软件包构建过程的特定步骤。

Further details about package special make targets are explained in Section 8.13.5, “Package-specific make targets”.
有关软件包特殊的 make 目标的更多细节，请参阅第 8.13.5 节，“软件包特定的 make 目标”。

If you intend to do an offline build and just want to download all sources that you previously selected in the configurator (menuconfig, nconfig, xconfig or gconfig), then issue:
如果您打算进行离线构建，并且只想下载您先前在配置器（menuconfig、nconfig、xconfig 或 gconfig）中选择的所有源代码，请执行以下操作：

 $ make source

You can now disconnect or copy the content of your dl directory to the build-host.
您现在可以断开连接或复制您的 dl 目录内容到构建主机。

As default, everything built by Buildroot is stored in the directory output in the Buildroot tree.
默认情况下，Buildroot 构建的所有内容都存储在 Buildroot 树中的目录 output 中。

Buildroot also supports building out of tree with a syntax similar to the Linux kernel. To use it, add O=<directory> to the make command line:
Buildroot 还支持类似于 Linux 内核的外部构建。要使用它，请将 O=<directory> 添加到 make 命令行中：

 $ make O=/tmp/build menuconfig

Or:

 $ cd /tmp/build; make O=$PWD -C path/to/buildroot menuconfig

All the output files will be located under /tmp/build. If the O path does not exist, Buildroot will create it.
所有输出文件将位于 /tmp/build 下。如果 O 路径不存在，Buildroot 将创建它。

Note: the O path can be either an absolute or a relative path, but if it’s passed as a relative path, it is important to note that it is interpreted relative to the main Buildroot source directory, not the current working directory.
注意： O 路径可以是绝对路径，也可以是相对路径，但如果作为相对路径传递，重要的是要注意，它是相对于主 Buildroot 源目录解释的，而不是当前工作目录。

When using out-of-tree builds, the Buildroot .config and temporary files are also stored in the output directory. This means that you can safely run multiple builds in parallel using the same source tree as long as they use unique output directories.
在使用 out-of-tree 构建时，Buildroot 的 .config 和临时文件也存储在输出目录中。这意味着只要它们使用唯一的输出目录，您可以安全地并行运行多个构建，使用相同的源树。

For ease of use, Buildroot generates a Makefile wrapper in the output directory - so after the first run, you no longer need to pass O=<…> and -C <…>, simply run (in the output directory):
为了方便使用，Buildroot 在输出目录中生成一个 Makefile 包装器 - 因此在第一次运行后，您不再需要传递 O=<…> 和 -C <…> ，只需在（输出目录中）运行：

 $ make <target>

Buildroot also honors some environment variables, when they are passed to make or set in the environment:
当传递给 make 或在环境中设置时，Buildroot 也会尊重一些环境变量：

An example that uses config files located in the toplevel directory and in your $HOME:
一个示例，使用位于顶层目录和您的 $HOME 中的配置文件：

 $ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config

If you want to use a compiler other than the default gcc or g++ for building helper-binaries on your host, then do
如果您想在主机上构建辅助二进制文件时使用除默认的 gcc 或 g ++ 之外的编译器，则执行

 $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD

Filesystem images can get pretty big, depending on the filesystem you choose, the number of packages, whether you provisioned free space… Yet, some locations in the filesystems images may just be empty (e.g. a long run of zeroes); such a file is called a sparse file.
文件系统映像可能会变得非常庞大，这取决于您选择的文件系统、软件包的数量、是否预留了空闲空间等因素... 然而，在文件系统映像中的某些位置可能是空的（例如，一长串零）；这样的文件称为稀疏文件。

Most tools can handle sparse files efficiently, and will only store or write those parts of a sparse file that are not empty.
大多数工具可以高效处理稀疏文件，并且只会存储或写入那些不为空的稀疏文件部分。

For example: 例如：

Other tools may have similar options. Please consult their respective man pages.
其他工具可能具有类似的选项。请参阅各自的 man 手册。

You can use sparse files if you need to store the filesystem images (e.g. to transfer from one machine to another), or if you need to send them (e.g. to the Q&A team).
如果您需要存储文件系统映像（例如，从一台机器传输到另一台机器），或者需要发送它们（例如，发送给问答团队），则可以使用稀疏文件。

Note however that flashing a filesystem image to a device while using the sparse mode of dd may result in a broken filesystem (e.g. the block bitmap of an ext2 filesystem may be corrupted; or, if you have sparse files in your filesystem, those parts may not be all-zeroes when read back). You should only use sparse files when handling files on the build machine, not when transferring them to an actual device that will be used on the target.
请注意，当使用 dd 的稀疏模式将文件系统映像刷写到设备时，可能会导致文件系统损坏（例如，ext2 文件系统的块位图可能会损坏；或者，如果文件系统中有稀疏文件，则在读取时这些部分可能不全为零）。只有在处理构建机器上的文件时才应使用稀疏文件，而不 是在将它们传输到将在目标设备上使用的实际设备时。

Buildroot can produce a JSON blurb that describes the set of enabled packages in the current configuration, together with their dependencies, licenses and other metadata. This JSON blurb is produced by using the show-info make target:
Buildroot 可以生成一个 JSON 摘要，描述当前配置中启用的软件包集合，以及它们的依赖关系、许可证和其他元数据。通过使用 show-info make 目标生成此 JSON 摘要：

make show-info

Buildroot can also produce details about packages as HTML and JSON output using the pkg-stats make target. Amongst other things, these details include whether known CVEs (security vulnerabilities) affect the packages in your current configuration. It also shows if there is a newer upstream version for those packages.
Buildroot 还可以使用 pkg-stats make 目标生成有关软件包的 HTML 和 JSON 输出的详细信息。除其他事项外，这些详细信息还包括已知 CVE（安全漏洞）是否影响当前配置中的软件包。它还显示这些软件包是否有更新的上游版本。

make pkg-stats

One of Buildroot’s jobs is to know the dependencies between packages, and make sure they are built in the right order. These dependencies can sometimes be quite complicated, and for a given system, it is often not easy to understand why such or such package was brought into the build by Buildroot.
Buildroot 的工作之一是了解软件包之间的依赖关系，并确保它们按正确顺序构建。这些依赖关系有时可能相当复杂，对于给定的系统，通常不容易理解为什么 Buildroot 会将某个软件包引入构建过程中。

In order to help understanding the dependencies, and therefore better understand what is the role of the different components in your embedded Linux system, Buildroot is capable of generating dependency graphs.
为了帮助理解依赖关系，从而更好地了解嵌入式 Linux 系统中不同组件的作用，Buildroot 能够生成依赖图。

To generate a dependency graph of the full system you have compiled, simply run:
要生成您编译的完整系统的依赖图，只需运行：

make graph-depends

You will find the generated graph in output/graphs/graph-depends.pdf.
你将在 output/graphs/graph-depends.pdf 中找到生成的图形。

If your system is quite large, the dependency graph may be too complex and difficult to read. It is therefore possible to generate the dependency graph just for a given package:
如果您的系统非常庞大，则依赖图可能过于复杂且难以阅读。因此，可以仅为给定的软件包生成依赖图：

make <pkg>-graph-depends

You will find the generated graph in output/graph/<pkg>-graph-depends.pdf.
你将在 output/graph/<pkg>-graph-depends.pdf 中找到生成的图形。

Note that the dependency graphs are generated using the dot tool from the Graphviz project, which you must have installed on your system to use this feature. In most distributions, it is available as the graphviz package.
请注意，依赖图是使用 Graphviz 项目中的 dot 工具生成的，您必须在系统上安装此工具才能使用此功能。在大多数发行版中，它作为 graphviz 软件包提供。

By default, the dependency graphs are generated in the PDF format. However, by passing the BR2_GRAPH_OUT environment variable, you can switch to other output formats, such as PNG, PostScript or SVG. All formats supported by the -T option of the dot tool are supported.
默认情况下，依赖图以 PDF 格式生成。但是，通过传递 BR2_GRAPH_OUT 环境变量，您可以切换到其他输出格式，如 PNG、PostScript 或 SVG。所有 dot 工具的 -T 选项支持的格式都受支持。

BR2_GRAPH_OUT=svg make graph-depends

The graph-depends behaviour can be controlled by setting options in the BR2_GRAPH_DEPS_OPTS environment variable. The accepted options are:
graph-depends 的行为可以通过在 BR2_GRAPH_DEPS_OPTS 环境变量中设置选项来控制。接受的选项包括：

BR2_GRAPH_DEPS_OPTS='-d 3 --no-transitive --colors=red,green,blue' make graph-depends

When the build of a system takes a long time, it is sometimes useful to be able to understand which packages are the longest to build, to see if anything can be done to speed up the build. In order to help such build time analysis, Buildroot collects the build time of each step of each package, and allows to generate graphs from this data.
当系统构建时间较长时，有时了解构建时间最长的软件包是很有用的，以查看是否可以采取措施加快构建速度。为了帮助进行构建时间分析，Buildroot 收集每个软件包每个步骤的构建时间，并允许从这些数据生成图表。

To generate the build time graph after a build, run:
要在构建后生成构建时间图表，请运行：

make graph-build

This will generate a set of files in output/graphs :
这将在 output/graphs 中生成一组文件：

This graph-build target requires the Python Matplotlib and Numpy libraries to be installed (python-matplotlib and python-numpy on most distributions), and also the argparse module if you’re using a Python version older than 2.7 (python-argparse on most distributions).
此 graph-build 目标需要安装 Python Matplotlib 和 Numpy 库（在大多数发行版上为 python-matplotlib 和 python-numpy ），如果您使用的是早于 2.7 版本的 Python，则还需要 argparse 模块（在大多数发行版上为 python-argparse ）。

By default, the output format for the graph is PDF, but a different format can be selected using the BR2_GRAPH_OUT environment variable. The only other format supported is PNG:
默认情况下，图形的输出格式为 PDF，但可以使用 BR2_GRAPH_OUT 环境变量选择不同的格式。唯一支持的其他格式是 PNG：

BR2_GRAPH_OUT=png make graph-build

When your target system grows, it is sometimes useful to understand how much each Buildroot package is contributing to the overall root filesystem size. To help with such an analysis, Buildroot collects data about files installed by each package and using this data, generates a graph and CSV files detailing the size contribution of the different packages.
当目标系统增长时，了解每个 Buildroot 软件包对整体根文件系统大小的贡献是有用的。为了帮助进行这种分析，Buildroot 收集有关每个软件包安装的文件的数据，并使用这些数据生成关于不同软件包大小贡献的图形和 CSV 文件。

To generate these data after a build, run:
在构建后生成这些数据，请运行：

make graph-size

This will generate: 这将生成：

This graph-size target requires the Python Matplotlib library to be installed (python-matplotlib on most distributions), and also the argparse module if you’re using a Python version older than 2.7 (python-argparse on most distributions).
此 graph-size 目标需要安装 Python Matplotlib 库（在大多数发行版上为 python-matplotlib ），如果您使用的是早于 2.7 版本的 Python，则还需要安装 argparse 模块（在大多数发行版上为 python-argparse ）。

Just like for the duration graph, a BR2_GRAPH_OUT environment variable is supported to adjust the output file format. See Section 8.9, “Graphing the dependencies between packages” for details about this environment variable.
就像持续图一样，支持一个 BR2_GRAPH_OUT 环境变量来调整输出文件格式。有关此环境变量的详细信息，请参见第 8.9 节“绘制软件包之间的依赖关系”。

Additionally, one may set the environment variable BR2_GRAPH_SIZE_OPTS to further control the generated graph. Accepted options are:
另外，可以设置环境变量 BR2_GRAPH_SIZE_OPTS 来进一步控制生成的图。接受的选项包括：

Note. The collected filesystem size data is only meaningful after a complete clean rebuild. Be sure to run make clean all before using make graph-size.
注意。只有在完全清理重建之后，收集的文件系统大小数据才有意义。确保在使用 make graph-size 之前运行 make clean all 。

To compare the root filesystem size of two different Buildroot compilations, for example after adjusting the configuration or when switching to another Buildroot release, use the size-stats-compare script. It takes two file-size-stats.csv files (produced by make graph-size) as input. Refer to the help text of this script for more details:
要比较两个不同 Buildroot 编译的根文件系统大小，例如在调整配置或切换到另一个 Buildroot 版本后，请使用 size-stats-compare 脚本。它以两个 file-size-stats.csv 文件（由 make graph-size 生成）作为输入。有关更多详细信息，请参考此脚本的帮助文本：

utils/size-stats-compare -h

Note. This section deals with a very experimental feature, which is known to break even in some non-unusual situations. Use at your own risk.
注意。本部分涉及一个非常实验性的功能，即使在一些非常规情况下也可能出现故障。请自行承担风险。

Buildroot has always been capable of using parallel build on a per package basis: each package is built by Buildroot using make -jN (or the equivalent invocation for non-make-based build systems). The level of parallelism is by default number of CPUs + 1, but it can be adjusted using the BR2_JLEVEL configuration option.
Buildroot 一直能够在每个软件包基础上使用并行构建：每个软件包由 Buildroot 使用 make -jN （或者对于非基于 make 的构建系统的等效调用）构建。并行度默认为 CPU 数量+1，但可以使用 BR2_JLEVEL 配置选项进行调整。

Until 2020.02, Buildroot was however building packages in a serial fashion: each package was built one after the other, without parallelization of the build between packages. As of 2020.02, Buildroot has experimental support for top-level parallel build, which allows some signicant build time savings by building packages that have no dependency relationship in parallel. This feature is however marked as experimental and is known not to work in some cases.
直 到 2020.02，Buildroot 仍然以串行方式构建软件包：每个软件包都是一个接一个地构建的，软件包之间没有构建并行化。从 2020.02 开始，Buildroot 具有顶层并行构建的实验性支持，允许在没有依赖关系的软件包之间并行构建，从而节省构建时间。但是，该功能被标记为实验性，并且已知在某些情况下无法正常 工作。

In order to use top-level parallel build, one must:
要使用顶层并行构建，必须：

Internally, the BR2_PER_PACKAGE_DIRECTORIES will enable a mechanism called per-package directories, which will have the following effects:
在内部， BR2_PER_PACKAGE_DIRECTORIES 将启用一个名为每包目录的机制，其将产生以下效果：

When customizing Buildroot for your project, you will be creating one or more project-specific files that need to be stored somewhere. While most of these files could be placed in any location as their path is to be specified in the Buildroot configuration, the Buildroot developers recommend a specific directory structure which is described in this section.
当为您的项目定制 Buildroot 时，您将创建一个或多个需要存储在某处的特定项目文件。尽管这些文件中的大多数可以放置在任何位置，因为它们的路径需要在 Buildroot 配置中指定，但 Buildroot 开发人员建议使用本节中描述的特定目录结构。

Orthogonal to this directory structure, you can choose where you place this structure itself: either inside the Buildroot tree, or outside of it using a br2-external tree. Both options are valid, the choice is up to you.
与此目录结构正交的是，您可以选择将此结构放置在何处：要么在 Buildroot 树内部，要么在外部使用 br2-external 树。这两个选项都是有效的，选择权在您手中。

+-- board/
|   +-- <company>/
|       +-- <boardname>/
|           +-- linux.config
|           +-- busybox.config
|           +-- <other configuration files>
|           +-- post_build.sh
|           +-- post_image.sh
|           +-- rootfs_overlay/
|           |   +-- etc/
|           |   +-- <some files>
|           +-- patches/
|               +-- foo/
|               |   +-- <some patches>
|               +-- libbar/
|                   +-- <some other patches>
|
+-- configs/
|   +-- <boardname>_defconfig
|
+-- package/
|   +-- <company>/
|       +-- Config.in (if not using a br2-external tree)
|       +-- <company>.mk (if not using a br2-external tree)
|       +-- package1/
|       |    +-- Config.in
|       |    +-- package1.mk
|       +-- package2/
|           +-- Config.in
|           +-- package2.mk
|
+-- Config.in (if using a br2-external tree)
+-- external.mk (if using a br2-external tree)
+-- external.desc (if using a br2-external tree)

Details on the files shown above are given further in this chapter.
上面显示的文件的详细信息将在本章中进一步给出。

Note: if you choose to place this structure outside of the Buildroot tree but in a br2-external tree, the <company> and possibly <boardname> components may be superfluous and can be left out.
注意：如果您选择将此结构放在 Buildroot 树之外，而是放在一个 br2-external 树中，则<company>和可能的<boardname>组件可能是多余的，可以省略。

+-- board/
    +-- <company>/
        +-- common/
        |   +-- post_build.sh
        |   +-- rootfs_overlay/
        |   |   +-- ...
        |   +-- patches/
        |       +-- ...
        |
        +-- fooboard/
            +-- linux.config
            +-- busybox.config
            +-- <other configuration files>
            +-- post_build.sh
            +-- rootfs_overlay/
            |   +-- ...
            +-- patches/
                +-- ...

BR2_GLOBAL_PATCH_DIR="board/<company>/common/patches board/<company>/fooboard/patches"

As already briefly mentioned in Section 9.1, “Recommended directory structure”, you can place project-specific customizations in two locations:
正如在第 9.1 节“推荐的目录结构”中简要提到的那样，您可以将项目特定的定制内容放在两个位置：

One can tell Buildroot to use one or more br2-external trees by setting the BR2_EXTERNAL make variable set to the path(s) of the br2-external tree(s) to use. It can be passed to any Buildroot make invocation. It is automatically saved in the hidden .br2-external.mk file in the output directory. Thanks to this, there is no need to pass BR2_EXTERNAL at every make invocation. It can however be changed at any time by passing a new value, and can be removed by passing an empty value.
可以通过将 BR2_EXTERNAL make 变量设置为要使用的 br2-external 树的路径（路径）来告诉 Buildroot 使用一个或多个 br2-external 树。它可以传递给任何 Buildroot make 调用。它会自动保存在输出目录中的隐藏 .br2-external.mk 文件中。由于这一点，没有必要在每次 make 调用时传递 BR2_EXTERNAL 。但是，可以随时通过传递新值来更改它，并且可以通过传递空值来删除它。

Note. The path to a br2-external tree can be either absolute or relative. If it is passed as a relative path, it is important to note that it is interpreted relative to the main Buildroot source directory, not to the Buildroot output directory.
注意。对于 br2-external 树的路径可以是绝对路径，也可以是相对路径。如果作为相对路径传递，重要的是要注意，它是相对于主 Buildroot 源目录解释的，而不是相对于 Buildroot 输出目录。

Note: If using an br2-external tree from before Buildroot 2016.11, you need to convert it before you can use it with Buildroot 2016.11 onward. See Section 27.2, “Migrating to 2016.11” for help on doing so.
注意：如果使用的是 Buildroot 2016.11 之前的 br2-external 树，您需要在将其用于 Buildroot 2016.11 及以后版本之前进行转换。请参阅第 27.2 节“迁移到 2016.11”以获取帮助。

Some examples: 一些示例：

buildroot/ $ make BR2_EXTERNAL=/path/to/foo menuconfig

From now on, definitions from the /path/to/foo br2-external tree will be used:
从现在开始，将使用 /path/to/foo br2-external 树中的定义：

buildroot/ $ make
buildroot/ $ make legal-info

We can switch to another br2-external tree at any time:
我们可以随时切换到另一个 br2-external 树：

buildroot/ $ make BR2_EXTERNAL=/where/we/have/bar xconfig

We can also use multiple br2-external trees:
我们还可以使用多个 br2-external 树：

buildroot/ $ make BR2_EXTERNAL=/path/to/foo:/where/we/have/bar menuconfig

Or disable the usage of any br2-external tree:
或者禁用任何 br2-external 树的使用：

buildroot/ $ make BR2_EXTERNAL= xconfig

source "$BR2_EXTERNAL_BAR_42_PATH/package/package1/Config.in"
source "$BR2_EXTERNAL_BAR_42_PATH/package/package2/Config.in"

include $(sort $(wildcard $(BR2_EXTERNAL_BAR_42_PATH)/package/*/*.mk))

BR2_GLOBAL_PATCH_DIR=$(BR2_EXTERNAL_BAR_42_PATH)/patches/
BR2_ROOTFS_OVERLAY=$(BR2_EXTERNAL_BAR_42_PATH)/board/<boardname>/overlay/
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=$(BR2_EXTERNAL_BAR_42_PATH)/board/<boardname>/kernel.config

/path/to/br2-ext-tree/
  |- external.desc
  |     |name: BAR_42
  |     |desc: Example br2-external tree
  |     `----
  |
  |- Config.in
  |     |source "$BR2_EXTERNAL_BAR_42_PATH/toolchain/toolchain-external-mine/Config.in.options"
  |     |source "$BR2_EXTERNAL_BAR_42_PATH/package/pkg-1/Config.in"
  |     |source "$BR2_EXTERNAL_BAR_42_PATH/package/pkg-2/Config.in"
  |     |source "$BR2_EXTERNAL_BAR_42_PATH/package/my-jpeg/Config.in"
  |     |
  |     |config BAR_42_FLASH_ADDR
  |     |    hex "my-board flash address"
  |     |    default 0x10AD
  |     `----
  |
  |- external.mk
  |     |include $(sort $(wildcard $(BR2_EXTERNAL_BAR_42_PATH)/package/*/*.mk))
  |     |include $(sort $(wildcard $(BR2_EXTERNAL_BAR_42_PATH)/toolchain/*/*.mk))
  |     |
  |     |flash-my-board:
  |     |    $(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/flash-image \
  |     |        --image $(BINARIES_DIR)/image.bin \
  |     |        --address $(BAR_42_FLASH_ADDR)
  |     `----
  |
  |- package/pkg-1/Config.in
  |     |config BR2_PACKAGE_PKG_1
  |     |    bool "pkg-1"
  |     |    help
  |     |      Some help about pkg-1
  |     `----
  |- package/pkg-1/pkg-1.hash
  |- package/pkg-1/pkg-1.mk
  |     |PKG_1_VERSION = 1.2.3
  |     |PKG_1_SITE = /some/where/to/get/pkg-1
  |     |PKG_1_LICENSE = blabla
  |     |
  |     |define PKG_1_INSTALL_INIT_SYSV
  |     |    $(INSTALL) -D -m 0755 $(PKG_1_PKGDIR)/S99my-daemon \
  |     |                          $(TARGET_DIR)/etc/init.d/S99my-daemon
  |     |endef
  |     |
  |     |$(eval $(autotools-package))
  |     `----
  |- package/pkg-1/S99my-daemon
  |
  |- package/pkg-2/Config.in
  |- package/pkg-2/pkg-2.hash
  |- package/pkg-2/pkg-2.mk
  |
  |- provides/jpeg.in
  |     |config BR2_PACKAGE_MY_JPEG
  |     |    bool "my-jpeg"
  |     `----
  |- package/my-jpeg/Config.in
  |     |config BR2_PACKAGE_PROVIDES_JPEG
  |     |    default "my-jpeg" if BR2_PACKAGE_MY_JPEG
  |     `----
  |- package/my-jpeg/my-jpeg.mk
  |     |# This is a normal package .mk file
  |     |MY_JPEG_VERSION = 1.2.3
  |     |MY_JPEG_SITE = https://example.net/some/place
  |     |MY_JPEG_PROVIDES = jpeg
  |     |$(eval $(autotools-package))
  |     `----
  |
  |- provides/init.in
  |     |config BR2_INIT_MINE
  |     |    bool "my custom init"
  |     |    select BR2_PACKAGE_MY_INIT
  |     |    select BR2_PACKAGE_SKELETON_INIT_MINE if BR2_ROOTFS_SKELETON_DEFAULT
  |     `----
  |
  |- provides/skeleton.in
  |     |config BR2_ROOTFS_SKELETON_MINE
  |     |    bool "my custom skeleton"
  |     |    select BR2_PACKAGE_SKELETON_MINE
  |     `----
  |- package/skeleton-mine/Config.in
  |     |config BR2_PACKAGE_SKELETON_MINE
  |     |    bool
  |     |    select BR2_PACKAGE_HAS_SKELETON
  |     |
  |     |config BR2_PACKAGE_PROVIDES_SKELETON
  |     |    default "skeleton-mine" if BR2_PACKAGE_SKELETON_MINE
  |     `----
  |- package/skeleton-mine/skeleton-mine.mk
  |     |SKELETON_MINE_ADD_TOOLCHAIN_DEPENDENCY = NO
  |     |SKELETON_MINE_ADD_SKELETON_DEPENDENCY = NO
  |     |SKELETON_MINE_PROVIDES = skeleton
  |     |SKELETON_MINE_INSTALL_STAGING = YES
  |     |$(eval $(generic-package))
  |     `----
  |
  |- provides/toolchains.in
  |     |config BR2_TOOLCHAIN_EXTERNAL_MINE
  |     |    bool "my custom toolchain"
  |     |    depends on BR2_some_arch
  |     |    select BR2_INSTALL_LIBSTDCPP
  |     `----
  |- toolchain/toolchain-external-mine/Config.in.options
  |     |if BR2_TOOLCHAIN_EXTERNAL_MINE
  |     |config BR2_TOOLCHAIN_EXTERNAL_PREFIX
  |     |    default "arch-mine-linux-gnu"
  |     |config BR2_PACKAGE_PROVIDES_TOOLCHAIN_EXTERNAL
  |     |    default "toolchain-external-mine"
  |     |endif
  |     `----
  |- toolchain/toolchain-external-mine/toolchain-external-mine.mk
  |     |TOOLCHAIN_EXTERNAL_MINE_SITE = https://example.net/some/place
  |     |TOOLCHAIN_EXTERNAL_MINE_SOURCE = my-toolchain.tar.gz
  |     |$(eval $(toolchain-external-package))
  |     `----
  |
  |- linux/Config.ext.in
  |     |config BR2_LINUX_KERNEL_EXT_EXAMPLE_DRIVER
  |     |    bool "example-external-driver"
  |     |    help
  |     |      Example external driver
  |     |---
  |- linux/linux-ext-example-driver.mk
  |
  |- configs/my-board_defconfig
  |     |BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL_BAR_42_PATH)/patches/"
  |     |BR2_ROOTFS_OVERLAY="$(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/overlay/"
  |     |BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/post-image.sh"
  |     |BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/kernel.config"
  |     `----
  |
  |- patches/linux/0001-some-change.patch
  |- patches/linux/0002-some-other-change.patch
  |- patches/busybox/0001-fix-something.patch
  |
  |- board/my-board/kernel.config
  |- board/my-board/overlay/var/www/index.html
  |- board/my-board/overlay/var/www/my.css
  |- board/my-board/flash-image
  `- board/my-board/post-image.sh
        |#!/bin/sh
        |generate-my-binary-image \
        |    --root ${BINARIES_DIR}/rootfs.tar \
        |    --kernel ${BINARIES_DIR}/zImage \
        |    --dtb ${BINARIES_DIR}/my-board.dtb \
        |    --output ${BINARIES_DIR}/image.bin
        `----

External options  --->
    *** Example br2-external tree (in /path/to/br2-ext-tree/)
    [ ] pkg-1
    [ ] pkg-2
    (0x10AD) my-board flash address

External options  --->
    Example br2-external tree  --->
        *** Example br2-external tree (in /path/to/br2-ext-tree)
        [ ] pkg-1
        [ ] pkg-2
        (0x10AD) my-board flash address
    FOO_27  --->
        *** FOO_27 (in /path/to/another-br2-ext)
        [ ] foo
        [ ] bar

Target packages  --->
    Libraries  --->
        Graphics  --->
            [*] jpeg support
                jpeg variant ()  --->
                    ( ) jpeg
                    ( ) jpeg-turbo
                        *** jpeg from: Example br2-external tree ***
                    (X) my-jpeg
                        *** jpeg from: FOO_27 ***
                    ( ) another-jpeg

Toolchain  --->
    Toolchain ()  --->
        ( ) Custom toolchain
            *** Toolchains from: Example br2-external tree ***
        (X) my custom toolchain

The Buildroot configuration can be stored using the command make savedefconfig.
使用命令 make savedefconfig 可以存储 Buildroot 配置。

This strips the Buildroot configuration down by removing configuration options that are at their default value. The result is stored in a file called defconfig. If you want to save it in another place, change the BR2_DEFCONFIG option in the Buildroot configuration itself, or call make with make savedefconfig BR2_DEFCONFIG=<path-to-defconfig>.
这将通过删除处于默认值的配置选项来简化 Buildroot 配置。结果存储在名为 defconfig 的文件中。如果想将其保存在其他位置，请在 Buildroot 配置本身中更改 BR2_DEFCONFIG 选项，或使用 make savedefconfig BR2_DEFCONFIG=<path-to-defconfig> 调用 make。

The recommended place to store this defconfig is configs/<boardname>_defconfig. If you follow this recommendation, the configuration will be listed in make list-defconfigs and can be set again by running make <boardname>_defconfig.
建议将此 defconfig 存储在 configs/<boardname>_defconfig 。如果遵循此建议，配置将列在 make list-defconfigs 中，并可以通过运行 make <boardname>_defconfig 再次设置。

Alternatively, you can copy the file to any other place and rebuild with make defconfig BR2_DEFCONFIG=<path-to-defconfig-file>.
或者，您可以将文件复制到任何其他位置，并使用 make defconfig BR2_DEFCONFIG=<path-to-defconfig-file> 重新构建。

The configuration files for BusyBox, the Linux kernel, Barebox, U-Boot and uClibc should be stored as well if changed. For each of these components, a Buildroot configuration option exists to point to an input configuration file, e.g. BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE. To store their configuration, set these configuration options to a path where you want to save the configuration files, and then use the helper targets described below to actually store the configuration.
如果更改了 BusyBox、Linux 内核、Barebox、U-Boot 和 uClibc 的配置文件，则应该将其存储。对于这些组件中的每一个，都存在一个 Buildroot 配置选项，用于指向一个输入配置文件，例如 BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE 。要存储它们的配置，请将这些配置选项设置为您想要保存配置文件的路径，然后使用下面描述的辅助目标来实际存储配置。

As explained in Section 9.1, “Recommended directory structure”, the recommended path to store these configuration files is board/<company>/<boardname>/foo.config.
如第 9.1 节“推荐目录结构”中所解释的，存储这些配置文件的推荐路径是 board/<company>/<boardname>/foo.config 。

Make sure that you create a configuration file before changing the BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE etc. options. Otherwise, Buildroot will try to access this config file, which doesn’t exist yet, and will fail. You can create the configuration file by running make linux-menuconfig etc.
在更改 BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE 等选项之前，请确保创建配置文件。否则，Buildroot 将尝试访问此配置文件，但该文件尚不存在，操作将失败。您可以通过运行 make linux-menuconfig 等来创建配置文件。

Buildroot provides a few helper targets to make the saving of configuration files easier.
Buildroot 提供了一些辅助目标，以使配置文件的保存更加容易。

Besides changing the configuration through make *config, there are a few other ways to customize the resulting target filesystem.
除了通过 make *config 更改配置之外，还有其他几种方式可以定制生成的目标文件系统。

The two recommended methods, which can co-exist, are root filesystem overlay(s) and post build script(s).
两种推荐的方法，可以共存，分别是根文件系统叠加和构建后脚本。

Below three more methods of customizing the target filesystem are described, but they are not recommended.
下面描述了另外三种自定义目标文件系统的方法，但不建议使用。

Sometimes it is needed to add specific users in the target system. To cover this requirement, Buildroot provides support for so-called users tables. To use this feature, set config option BR2_ROOTFS_USERS_TABLES to a space-separated list of users tables, regular text files following the makeusers syntax.
有时需要在目标系统中添加特定用户。为了满足这一要求，Buildroot 提供了对所谓的用户表的支持。要使用此功能，请将配置选项 BR2_ROOTFS_USERS_TABLES 设置为用户表的空格分隔列表，这些用户表是遵循 makeusers 语法的常规文本文件。

As shown in Section 9.1, “Recommended directory structure”, the recommended location for such files is board/<company>/<boardname>/.
如第 9.1 节“推荐的目录结构”所示，此类文件的推荐位置是 board/<company>/<boardname>/ 。

It should be noted that if the custom users are related to a specific application, you should set variable FOO_USERS in the package’s .mk file instead (see Section 18.6.2, “generic-package reference”).
需要注意的是，如果自定义用户与特定应用程序相关联，应该在软件包的 .mk 文件中设置变量 FOO_USERS （请参阅第 18.6.2 节“ generic-package 参考”）。

While post-build scripts (Section 9.5, “Customizing the generated target filesystem”) are run before building the filesystem image, kernel and bootloader, post-image scripts can be used to perform some specific actions after all images have been created.
在构建文件系统映像、内核和引导加载程序之前运行后构建脚本（第 9.5 节“定制生成的目标文件系统”），后图像脚本可用于在创建所有图像后执行一些特定操作。

Post-image scripts can for example be used to automatically extract your root filesystem tarball in a location exported by your NFS server, or to create a special firmware image that bundles your root filesystem and kernel image, or any other custom action required for your project.
例如，后图像脚本可用于自动提取您的根文件系统 tarball 到由 NFS 服务器导出的位置，或者创建一个捆绑您的根文件系统和内核映像的特殊固件映像，或者为您的项目需要的任何其他自定义操作。

To enable this feature, specify a space-separated list of post-image scripts in config option BR2_ROOTFS_POST_IMAGE_SCRIPT (in the System configuration menu). If you specify a relative path, it will be relative to the root of the Buildroot tree.
要启用此功能，请在配置选项 BR2_ROOTFS_POST_IMAGE_SCRIPT （在 System configuration 菜单中）中指定一组以空格分隔的后图像脚本列表。如果指定相对路径，它将相对于 Buildroot 树的根目录。

Just like post-build scripts, post-image scripts are run with the main Buildroot tree as current working directory. The path to the images output directory is passed as the first argument to each script. If the config option BR2_ROOTFS_POST_SCRIPT_ARGS is not empty, these arguments will be passed to the script too. All the scripts will be passed the exact same set of arguments, it is not possible to pass different sets of arguments to each script.
就像后构建脚本一样，后图像脚本会以主 Buildroot 树作为当前工作目录运行。将 images 输出目录的路径作为每个脚本的第一个参数传递。如果配置选项 BR2_ROOTFS_POST_SCRIPT_ARGS 不为空，则这些参数也将传递给脚本。所有脚本将传递完全相同的参数集，无法向每个脚本传递不同的参数集。

Again just like for the post-build scripts, the scripts have access to the environment variables BR2_CONFIG, HOST_DIR, STAGING_DIR, TARGET_DIR, BUILD_DIR, BINARIES_DIR, CONFIG_DIR and BASE_DIR.
就像对于后构建脚本一样，脚本可以访问环境变量 BR2_CONFIG ， HOST_DIR ， STAGING_DIR ， TARGET_DIR ， BUILD_DIR ， BINARIES_DIR ， CONFIG_DIR 和 BASE_DIR 。

The post-image scripts will be executed as the user that executes Buildroot, which should normally not be the root user. Therefore, any action requiring root permissions in one of these scripts will require special handling (usage of fakeroot or sudo), which is left to the script developer.
后图像脚本将以执行 Buildroot 的用户身份执行，这通常不应该是 root 用户。因此，在这些脚本中需要根权限的任何操作将需要特殊处理（使用 fakeroot 或 sudo），这留给脚本开发者处理。

In general, any new package should be added directly in the package directory and submitted to the Buildroot upstream project. How to add packages to Buildroot in general is explained in full detail in Chapter 18, Adding new packages to Buildroot and will not be repeated here. However, your project may need some proprietary packages that cannot be upstreamed. This section will explain how you can keep such project-specific packages in a project-specific directory.
一般来说，任何新软件包都应直接添加到 package 目录，并提交到 Buildroot 上游项目。一般情况下如何向 Buildroot 添加软件包在第 18 章“向 Buildroot 添加新软件包”中有详细说明，这里不再重复。但是，您的项目可能需要一些无法上游的专有软件包。本节将解释如何将这些项目特定软件包保留在项目特定目录 中。

As shown in Section 9.1, “Recommended directory structure”, the recommended location for project-specific packages is package/<company>/. If you are using the br2-external tree feature (see Section 9.2, “Keeping customizations outside of Buildroot”) the recommended location is to put them in a sub-directory named package/ in your br2-external tree.
如第 9.1 节“推荐的目录结构”所示，项目特定软件包的推荐位置是 package/<company>/ 。如果您正在使用 br2-external 树功能（请参阅第 9.2 节“将自定义内容放在 Buildroot 之外”），建议将它们放在 br2-external 树中名为 package/ 的子目录中。

However, Buildroot will not be aware of the packages in this location, unless we perform some additional steps. As explained in Chapter 18, Adding new packages to Buildroot, a package in Buildroot basically consists of two files: a .mk file (describing how to build the package) and a Config.in file (describing the configuration options for this package).
但是，除非我们执行一些额外的步骤，否则 Buildroot 将不会意识到此位置中的软件包。如第 18 章“向 Buildroot 添加新软件包”中所解释的，Buildroot 中的软件包基本上由两个文件组成：一个 .mk 文件（描述如何构建软件包）和一个 Config.in 文件（描述此软件包的配置选项）。

Buildroot will automatically include the .mk files in first-level subdirectories of the package directory (using the pattern package/*/*.mk). If we want Buildroot to include .mk files from deeper subdirectories (like package/<company>/package1/) then we simply have to add a .mk file in a first-level subdirectory that includes these additional .mk files. Therefore, create a file package/<company>/<company>.mk with following contents (assuming you have only one extra directory level below package/<company>/):
Buildroot 将自动包含 package 目录的一级子目录中的 .mk 文件（使用模式 package/*/*.mk ）。如果我们希望 Buildroot 包含更深层子目录（如 package/<company>/package1/ ）中的 .mk 文件，那么我们只需在包含这些额外 .mk 文件的一级子目录中添加一个 .mk 文件。因此，请创建一个文件 package/<company>/<company>.mk ，其中包含以下内容（假设您在 package/<company>/ 下只有一个额外的目录级别）：

include $(sort $(wildcard package/<company>/*/*.mk))

For the Config.in files, create a file package/<company>/Config.in that includes the Config.in files of all your packages. An exhaustive list has to be provided since wildcards are not supported in the source command of kconfig. For example:
对于 Config.in 文件，请创建一个文件 package/<company>/Config.in ，其中包含所有软件包的 Config.in 文件。必须提供详尽的列表，因为 kconfig 的源命令中不支持通配符。例如：

source "package/<company>/package1/Config.in"
source "package/<company>/package2/Config.in"

Include this new file package/<company>/Config.in from package/Config.in, preferably in a company-specific menu to make merges with future Buildroot versions easier.
包括从 package/Config.in 中的 package/<company>/Config.in 新文件，最好放在公司特定菜单中，以便将来更容易地与 Buildroot 版本合并。

If using a br2-external tree, refer to Section 9.2, “Keeping customizations outside of Buildroot” for how to fill in those files.
如果使用 br2-external 树，请参阅第 9.2 节“将自定义内容保留在 Buildroot 之外”以了解如何填写这些文件。

Earlier in this chapter, the different methods for making project-specific customizations have been described. This section will now summarize all this by providing step-by-step instructions to storing your project-specific customizations. Clearly, the steps that are not relevant to your project can be skipped.
在本章的前面部分，已经描述了制作项目特定定制的不同方法。本节将通过提供逐步说明来总结所有内容，以存储您的项目特定定制。显然，与您的项目无关的步骤可以跳过。